Linux-2.6.13-rc7

Linus Torvalds

unread,

Aug 24, 2005, 1:10:03 AM8/24/05

to Linux Kernel Mailing List

Hullo.

I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.

Most of the -rc7 changes are pretty trivial, either one-liners or
affecting some particular specific driver or unusual configuration. The
shortlog (appended) should give a pretty good idea of what's up.

Linus

---
Al Viro:
uml: fix the x86_64 build
[SPARC]: Fix weak aliases
jffs2: fix symlink error handling
Fix up symlink function pointers
Lots of Kconfig fixes
alpha gcc4 warnings
missing include in pcmcia_resource.c
alpha xchg fix
alpha spinlock code and bogus constraints
m32r smp.h gcc4 fixes
m32r icu_data gcc4 fixes
m32r_sio gcc4 fixes
broken inline asm on s390 (misuse of labels)
vidc gcc4 fix
emac netpoll fix
typo fix in qdio.c
qualifiers in return types - easy cases
missing exports on m32r
ad1980 makefile fix
%t... in vsnprintf
s390 __CHECKER__ ifdefs

Alexander Nyberg:
ns558 list handling fix

Alexey Dobriyan:
[NET]: Make skb->protocol __be16
freevxfs: fix breakage introduced by symlink fixes
zd1201 kmalloc size fix

Andi Kleen:
x86: Remove obsolete get_cpu_vendor call
x86_64: Don't print exceptions for ltrace
x86_64: Fix race in TSC synchronization
x86_64: Don't oops at boot when empty Opteron node has IO

Andrew Morton:
[NET]: Fix memory leak in sys_{send,recv}msg() w/compat
PCI: fix quirk-6700-fix.patch

Anton Altaparmakov:
NTFS: Fix bug in mft record writing where we forgot to set the device in
NTFS: Complete the previous fix for the unset device when mapping buffers

Antonino A. Daplas:
intelfb/fbdev: Save info->flags in a local variable

Antonino Daplas:
nvidiafb: Fix initial display corruption on certain laptops

Arnd Bergmann:
ppc64: add default config for BPA

Bartlomiej Zolnierkiewicz:
ide-floppy: fix IDEFLOPPY_TICKS_DELAY

Ben Colline:
[SPARC]: Deal with glibc changing macro names in modpost.c

Ben Dooks:
ARM: 2847/1: S3C24XX - Documentation for USB OHCI host
ARM: 2849/1: S3C24XX - USB host update (2848/1)
DM9000 - spinlock fixes
DM9000 - incorrect ioctl() handling

Benjamin Herrenschmidt:
ppc64: Fix Fan control for new PowerMac G5 2.7GHz machines

Bhavesh P. Davda:
NPTL signal delivery deadlock fix

Brian King:
ppc64: iommu vmerge fix

Christoph Hellwig:
ARM: switch fd1772.c from sleep_on to wait_event
[SPARC]: Use kthread infrastructure in envctrl
[SPARC]: Use kthread infrastructure in bbc_envctrl
[SPARC]: remove ifdef CONFIG_PCI from envctrl.c
[IA64] update CONFIG_PCI description

Christoph Lameter:
Fix ide-disk.c oops caused by hwif == NULL

Chuck Ebbert:
i386: fix incorrect FP signal code

Chuck Lever:
NFS: split nfsi->flags into two fields
NFS: use atomic bitops to manipulate flags in nfsi->flags
NFS: Introduce the use of inode->i_lock to protect fields in nfsi

Cornelia Huck:
s390: use klist in qeth driver

Dave Johnson:
[IPV4]: Fix negative timer loop with lots of ipv4 peers.

Dave Jones:
icn driver fails to unload when no hardware present

Dave Kleikamp:
Merge with /home/shaggy/git/linus-clean/
JFS: Improve sync barrier processing
Merge with /home/shaggy/git/linus-clean/
Merge with /home/shaggy/git/linus-clean/
JFS: Check for invalid inodes in jfs_delete_inode
Merge with /home/shaggy/git/linus-clean/
JFS: Fix race in txLock
Merge with /home/shaggy/git/linus-clean/

David Meybohm:
preempt race in getppid

David S. Miller:
[TG3]: Save initial PCI state before registering the netdevice.
[NETLINK]: Allocate and kill some netlink numbers.
[SPARC]: envctrl: ERR_PTR() --> PTR_ERR()
[SUNRPC]: Fix nsec --> usec conversion.
[SPARC64]: Fix 2 bugs in cpufreq drivers.
[TG3]: Update driver version and reldate.
[SPARC64]: Move kernel unaligned trap handlers into assembler file.
[TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail().
[TCP]: Document non-trivial locking path in tcp_v{4,6}_get_port().
[ROSE]: Fix missing unlocks in rose_route_frame()
[ROSE]: Fix typo in rose_route_frame() locking fix.

David Woodhouse:
Stop snd-powermac oopsing on non-pmac hardware.

Deepak Saxena:
Fix IXP4xx CLOCK_TICK_RATE

Dimitry Andric:
[ARM] 2850/1: Remove duplicate UART I/O mapping from s3c2410_iodesc

Dmitry Yusupov:
[TCP]: Do TSO deferral even if tail SKB can go out now.

Eric W. Biederman:
x86_64: Fix apicid versus cpu# confusion.

Evgeniy Polyakov:
w1: more debug level decrease.

Grant Coady:
ide: fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling

Greg Edwards:
[IA64] Refresh arch/ia64/configs/sn2_defconfig.

Greg Kroah-Hartman:
Fix manual binding infinite loop

Harald Welte:
don't try to do any NAT on untracked connections

Heikki Orsila:
[IPV4]: Debug cleanup

Herbert Xu:
[IPSEC]: Restrict socket policy loading to CAP_NET_ADMIN.
[TCP]: Adjust {p,f}ackets_out correctly in tcp_retransmit_skb()
[TCP]: Fix bug #5070: kernel BUG at net/ipv4/tcp_output.c:864
[TCP]: Fix bug #5070: kernel BUG at net/ipv4/tcp_output.c:864
[IPCOMP]: Fix false smp_processor_id warning
[RPC]: Kill bogus kmap in krb5

Ian Wienand:
[IA64] Simulator bootloader fails with gcc 4

Ingo Molnar:
[NETPOLL]: pre-fill skb pool

Ivan Kokshaysky:
VIA VT8235 PCI quirk

James Bottomley:
[SCSI] Bug 4940 Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup
remove name length check in a workqueue

James Morris:
Update contact info for James Morris

James...@Emulex.Com:
[SCSI] fix target scanning oops with fc transport class

Jan Kara:
Fix error handling in reiserfs
reiserfs+acl+quota deadlock fix

Jaroslav Kysela:
broken error path in drivers/pnp/card.c

Jay Vosburgh:
[TOKENRING]: Use interrupt-safe locking with rif_lock.

Jeff Dike:
uml: fix a crash under screen

Jeff Garzik:
libata: release prep (bump versions, etc.)

Jeff Moyer:
[NETPOLL]: rx_flags bugfix
[NETPOLL]: deadlock bugfix

Jiri Slaby:
PCI: update documentation

Johannes Stezenbach:
Fix DVB URL

John Hawkes:
fix for ia64 sched-domains code

John McCutchan:
fsnotify_name/inoderemove
fsnotify-cleanups
inotify: add MOVE_SELF event

John W. Linville:
i810_audio: fix release_region misordering in error exit from i810_probe

Juha-Matti Tapio:
ide: fix the BLK_DEV_IDEDMA_PCI dependency for drivers/ide/ppc/pmac.c

Keith Owens:
[IA64] Initialize some spinlocks

Ken Chen:
[IA64] fix nohalt boot option

Kenji Kaneshige:
[IA64] fix iosapic_remove build error for !HOTPLUG

Kristen Accardi:
PCI: 6700/6702PXH quirk
PCI Hotplug: new contact info

Kumar Gala:
ppc32: Fix MPC834x USB memory map offsets
cpm_uart: Fix dpram allocation and non-console uarts
cpm_uart: needs some love to compile with GCC4.0.1

Len Brown:
Merge ../to-linus-stable/
Merge ../from-linus

lepton:
usbnet oops fix

Linus Torvalds:
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/.../davem/net-2.6
Revert "PCI: restore BAR values..."
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../davem/sparc-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../jejb/scsi-rc-fixes-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/home/rmk/linux-2.6-arm-smp
Merge head 'upstream-fixes' of master.kernel.org:/.../jgarzik/libata-dev
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../davem/net-2.6
Fix up mmap of /dev/kmem
Revert "dc395x: Fix support for highmem"
Revert PCIBIOS_MIN_IO changes for 2.6.13
um: fix __pa/__va macro expansion problem
Merge master.kernel.org:/.../aia21/ntfs-2.6
Merge master.kernel.org:/.../lenb/to-linus
Merge head 'for-linus' of master.kernel.org:/.../shaggy/jfs-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Revert unnecessary zlib_inflate/inftrees.c fix
Merge head 'release' of master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../aia21/ntfs-2.6
Merge master.kernel.org:/.../davem/sparc-2.6
Merge head 'upstream-fixes' of master.kernel.org:/.../jgarzik/netdev-2.6
Merge master.kernel.org:/.../bart/ide-2.6
Fix nasty ncpfs symlink handling bug.
Merge master.kernel.org:/.../davem/sparc-2.6
Merge master.kernel.org:/.../davem/net-2.6
befs: fix up missed follow_link declaration change
Don't allow normal users to set idle IO priority
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge head 'upstream-fixes' of master.kernel.org:/.../jgarzik/libata-dev
Merge head 'upstream-fixes' of master.kernel.org:/.../jgarzik/misc-2.6
Linux v2.6.13-rc7

Luming Yu:
[ACPI] re-enable platform-specific hotkey drivers by default

Maneesh Soni:
Driver core: potentially fix use after free in class_device_attr_show

Markus Lidel:
i2o: remove new configuration API
I2O: added pci_request_regions() before using the controller

Matt Gillette:
ide: add support for Netcell Revolution to pci-ide generic driver

Matt Mackall:
[NETPOLL]: e1000 netpoll tweak
[NETPOLL]: netpoll_send_skb simplify
[NETPOLL]: add retry timeout
[NETPOLL]: fix initialization/NAPI race
[NETPOLL]: remove unused variable
Make RLIMIT_NICE ranges consistent with getpriority(2)

Matt Porter:
ppc32: fix ppc4xx stb03xxx dma build
ppc32: Fix PPC440SP SRAM controller DCRs

Michael Chan:
[TG3]: Fix SerDes detection

Michael Iatrou:
disable debug info in radeonfb old driver

Michael Krufky:
dvb: lgdt330x frontend: some bug fixes & add lgdt3303 support
dvb: lgdt330x frontend: trivial text cleanups
DVB: lgdt330x frontend: some bug fixes & add lgdt3303 support

Narendra Sankar:
serverworks: add support for new southbridge IDE

NeilBrown:
md: make sure mddev->bitmap_offset gets cleared between array instantiations.
md: make sure resync gets started when array starts.

Nicolas Pitre:
ARM: 2846/1: proper handling of CKEN for pxafb

Olaf Hering:
x86_64: add MODULE_ALIAS for aes

Patrick McHardy:
[IPV6]: Fix raw socket hardware checksum failures
[IPV6]: Fix SKB leak in ip6_input_finish()
[IPV6]: Fix raw socket hardware checksum failures
[IPV6]: Fix SKB leak in ip6_input_finish()
[IPV4]: Fix DST leak in icmp_push_reply()
[NETFILTER]: Fix ECN target TCP marking
[NETFILTER]: Fix HW checksum handling in ECN target
[NETFILTER]: Fix HW checksum handling in TCPMSS target
[NETFILTER]: Fix HW checksum handling in ip_queue/ip6_queue

Paul E. McKenney:
[DECNET]: Fix RCU race condition in dn_neigh_construct().

Paul Jackson:
cpuset release ABBA deadlock fix
cpu_exclusive sched domains on partial nodes temp fix

Paul Mackerras:
ppc64: update defconfigs

Paul Mundt:
sh: Make _syscall6() do the right thing.

Pete Zaitcev:
USB: usbmon: Copyrights and a typo

Peter Chubb:
[IA64] Updated zx1 defconfig
[IA64] Fix simulator boot (for real this time).

Pierre Ossman:
wbsd version bump
8139cp - redetect link after suspend

Ping Cheng:
USB: fix usb wacom tablet driver bug

Prarit Bhargava:
[IA64]: SN fix bus->sysdata pointer and memory cleanups

Ralf Baechle:
Build fix for the Sibyte I2C driver
IOC3 fixes
[NET]: Fix comment in loopback driver.
[NET]: Fix socket bitop damage
[AX25]: UID fixes

Ralf Baechle DL5RB:
6pack persistence fix

Richard Purdie:
ARM: 2851/1: Fix NWFPE extended precision exception handling

Robert Love:
[ARM] Add syscall stubs for inotify and ioprio system calls
inotify: fix idr_get_new_above usage
SH: inotify and ioprio syscalls
SH64: inotify and ioprio syscalls

Russell King:
ARM: Make sa1100fb_display_dma_period() an inline function
[ARM SMP] Only enable V6K instructions on V6 MP core CPUs
[ARM SMP] Clear the exclusive monitor on ARMv6 CPUs on context switch
[ARM] Use #defined constants for manipulating v6 hardware PTE bits
[ARM] Control v6 'global' bit via Linux PTE entries
[ARM] Remove extraneous whitespace introduced in previous ARMv6 patch

Salyzyn, Mark:
[SCSI] dpt_i2o pci_request_regions fix

Sean Lee:
[ARM] 2852/1: Correct the mistake in arch/arm/mm/Kconfig file

stephane...@hp.com:
[IA64] fix perfmon context load

Stephen Rothwell:
iSeries build with newer assemblers and compilers

Steve Dickson:
NFSv4: unbalanced BKL in nfs_atomic_lookup()

Steve French:
CIFS: Fix missing entries in search results
CIFS: Fix path name conversion for long filenames

Steven Rostedt:
nfsd to unlock kernel before exiting
Mobil Pentium 4 HT and the NMI

Steven Whitehouse:
[DECNET]: Use sk_stream_error function rather than DECnet's own

Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture

Tejun Heo:
sata: fix sata_sx4 dma_prep to not use sg->length
libata: fix EH-related lockup by properly cleaning EH command list

Thomas Graf:
[PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt()

Tony Luck:
pull perfmon context load into release tree
Auto-update from upstream
Auto-update from upstream
[IA64] Updated tiger defconfig
[IA64] remove unused function __ia64_get_io_port_base
Auto-update from upstream
Auto-update from upstream
Pull prarit-bus-sysdata into release branch
[IA64] backout incorrect fix for simulator boot issue

Trond Myklebust:
NFS: Ensure ACL xdr code doesn't overflow.
NFS: Ensure we always update inode->i_mode when doing O_EXCL creates

Vlad Yasevich:
[SCTP]: Add SENTINEL to SCTP MIB stats

Wim Van Sebroeck:
i8xx_tco.c: arm watchdog only when started

Zachary Amsden:
i386 / desc_empty macro is incorrect

Zwane Mwaikambo:
Update email addresses for Zwane

--- diffstat ---

Al Viro

unread,

Aug 24, 2005, 2:41:07 AM8/24/05

to Linus Torvalds, Linux Kernel Mailing List

On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:

> cpu_exclusive sched domains on partial nodes temp fix

.. breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get __first_cpu(&node_to_cpumask(...),...),
with obvious consequences.

Locally I'm turning node_to_cpumask() into define, just to see what else
had changed in the build, but we probably want saner solution for that
one...

Dinakar Guniguntala

unread,

Aug 24, 2005, 7:23:59 AM8/24/05

to Al Viro, Linus Torvalds, Linux Kernel Mailing List

On Wed, Aug 24, 2005 at 07:43:42AM +0100, Al Viro wrote:
> On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
>
> > cpu_exclusive sched domains on partial nodes temp fix
>

> ... breaks ppc64 since there we have node_to_cpumask() done as inlined

> function, not a macro. So we get __first_cpu(&node_to_cpumask(...),...),
> with obvious consequences.
>
> Locally I'm turning node_to_cpumask() into define, just to see what else
> had changed in the build, but we probably want saner solution for that
> one...

Not sure why this patch was included. I had reported yesterday that
it hangs up ppc64 on doing some exclusive cpuset operations. (I had
fixed the compile problem by having a temp for the cpumask variable)

So this patch is not ready to go in just yet. I am working on the fix,
hope to have it soon

-Dinakar

Paul Jackson

unread,

Aug 24, 2005, 2:45:31 PM8/24/05

to Al Viro, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

Al Viro wrote:
> ... breaks ppc64 since there we have node_to_cpumask() done as inlined

> function, not a macro. So we get __first_cpu(&node_to_cpumask(...),...),
> with obvious consequences.

I sent a patch for this a few hours ago, thanks to Paul Mackerras's report:

[PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix

It just makes a local copy of the cpumask_t in a local variable on the stack.

I'm still a couple of hours from actually verifying that ppc64 builds with
this - due to unrelated confusions on my end. Perhaps you or Mackerras will
report in first, to verify if this patch works as advertised.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.925.600.0401

Al Viro

unread,

Aug 24, 2005, 3:13:05 PM8/24/05

to Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Aug 24, 2005 at 11:43:51AM -0700, Paul Jackson wrote:
> Al Viro wrote:
> > ... breaks ppc64 since there we have node_to_cpumask() done as inlined
> > function, not a macro. So we get __first_cpu(&node_to_cpumask(...),...),
> > with obvious consequences.
>
> I sent a patch for this a few hours ago, thanks to Paul Mackerras's report:
>
> [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix
>
> It just makes a local copy of the cpumask_t in a local variable on the stack.
>
> I'm still a couple of hours from actually verifying that ppc64 builds with
> this - due to unrelated confusions on my end. Perhaps you or Mackerras will
> report in first, to verify if this patch works as advertised.

It does, no (build) regressions. BTW, tree is not far from allmodconfig
buildable on a bunch of targets now - yesterday pile of fixes was about
half of the set needed for that. Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
out of the box on the following set:
alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r,
m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc,
sparc64, s390, s390x, uml-i386, uml-amd64.

All of these - with allmodconfig, alpha, amd64 and i386 being tracked
separately as SMP and UP. Missing targets:
frv: need newer toolchain on build box
mips, parisc: need out-of-tree patches
v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain
h8300: binutils in FC4 doesn't know what to do with that target,
have not tried that on sarge yet.
sh, sh64: need kernel headers that would make glibc happy enough
to build libc headers for that puppy; I don't have them
cris, xtensa: haven't looked into those
arm26: needs gcc3 since gcc4 had dropped that target; I might take
a look into that on a sarge-based build box someday.

sun3 is seriously broken and I doubt that we'll see any takers for testing
2.6 on those anyway ;-)

A bunch of arm and ppc subarchitectures are not covered yet - I can add those
to build setup, just give me a list in order of preference. Or ask me how
to set up a cross-build farm of your own...

Alexey Dobriyan

unread,

Aug 24, 2005, 4:05:31 PM8/24/05

to Al Viro, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> Most of the remaining stuff is for
> m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
> out of the box on the following set:
> alpha,

Do I understand correctly that alpha in "--><-- close" list?

2.6.13-rc7, alpha, allmodconfig:

LD .tmp_vmlinux1
net/built-in.o: In function `kmalloc':
include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'
include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'

Guilty: net/ipv4/route.c

$ nm net/ipv4/route.o | grep kmalloc
U __you_cannot_kmalloc_that_much

> sh64: need kernel headers that would make glibc happy enough
> to build libc headers for that puppy;

binutils already compiled. Will drop a line. Or file a bug. :-\

Alexey Dobriyan

unread,

Aug 24, 2005, 4:25:53 PM8/24/05

to Al Viro, linux-...@vger.kernel.org

On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > sh64: need kernel headers that would make glibc happy enough
> > to build libc headers for that puppy;
>
> binutils already compiled. Will drop a line. Or file a bug. :-\

By some miracle gcc is also compiled. As of now (sh64, allmodconfig):

arch/sh64/kernel/pci_sh5.c: In function `map_cayman_irq':
arch/sh64/kernel/pci_sh5.c:334: error: `IRQ_P2INTA' undeclared

arch/sh64/kernel/dma.c: In function `init_dma':
arch/sh64/kernel/dma.c:248: error: storage size of 'vcr' isn't known

arch/sh64/mm/hugetlbpage.c: At top level:
arch/sh64/mm/hugetlbpage.c:84: error: conflicting types for 'huge_ptep_get_and_clear'
include/linux/hugetlb.h:64: error: previous declaration of 'huge_ptep_get_and_clear' was here

arch/sh64/mm/hugetlbpage.c: In function `huge_ptep_get_and_clear':
arch/sh64/mm/hugetlbpage.c:89: error: `i' undeclared

arch/sh64/mm/hugetlbpage.c:90:16: macro "pte_clear" requires 3 arguments, but only 1 given
arch/sh64/mm/hugetlbpage.c:90: error: `pte_clear' undeclared (first use in this
function)
arch/sh64/mm/hugetlbpage.c:91: error: `pte' undeclared (first use in this function)

arch/sh64/mach-sim/setup.c:25:11: error: unable to open 'asm/addrspace.h'
exists only in asm-{sh, m32r, mips}

Al Viro

unread,

Aug 24, 2005, 5:36:37 PM8/24/05

to Alexey Dobriyan, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:

> On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > Most of the remaining stuff is for
> > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> > and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
> > out of the box on the following set:
> > alpha,
>
> Do I understand correctly that alpha in "--><-- close" list?
>
> 2.6.13-rc7, alpha, allmodconfig:
>
> LD .tmp_vmlinux1
> net/built-in.o: In function `kmalloc':
> include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'
> include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'
>
> Guilty: net/ipv4/route.c
>
> $ nm net/ipv4/route.o | grep kmalloc
> U __you_cannot_kmalloc_that_much

Not here...

CC arch/alpha/lib/udelay.o
AR arch/alpha/lib/lib.a
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD .tmp_vmlinux3
KSYM .tmp_kallsyms3.S
AS .tmp_kallsyms3.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
STRIP arch/alpha/boot/vmlinux

Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5).

Which place triggers it in your build?

Willy TARREAU

unread,

Aug 24, 2005, 6:41:06 PM8/24/05

to Linus Torvalds, Linux Kernel Mailing List

Hello,

On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
>

> Hullo.
>
> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.
>
> Most of the -rc7 changes are pretty trivial, either one-liners or
> affecting some particular specific driver or unusual configuration. The
> shortlog (appended) should give a pretty good idea of what's up.

Well, it's been running here for a few hours this evening, and I must say
that I have not noticed anything strange yet (except the printk timestamps
which switch to zero twice during boot and start with funny values, but
that's not important). The box is a dual-k7 with aic7xxx, and NFSv3 over
an e1000 NIC. Tested with SMP and preempt enabled.

>
> Linus

Regards,
Willy

Voluspa

unread,

Aug 24, 2005, 8:22:55 PM8/24/05

to linux-...@vger.kernel.org

root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device

Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.

When the revolution comes, the author of acpi-hotkey.txt will face the
wall first.

Mvh
Mats Johannesson
--

Alexey Dobriyan

unread,

Aug 25, 2005, 3:19:09 AM8/25/05

to Al Viro, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
> On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > > Most of the remaining stuff is for
> > > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> > > and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
> > > out of the box on the following set:
> > > alpha,
> >
> > Do I understand correctly that alpha in "--><-- close" list?
> >
> > 2.6.13-rc7, alpha, allmodconfig:
> >
> > LD .tmp_vmlinux1
> > net/built-in.o: In function `kmalloc':
> > include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'
> > include/linux/slab.h:92: undefined reference to `__you_cannot_kmalloc_that_much'
> >
> > Guilty: net/ipv4/route.c
> >
> > $ nm net/ipv4/route.o | grep kmalloc
> > U __you_cannot_kmalloc_that_much
>
> Not here...
>
> CC arch/alpha/lib/udelay.o

> LD .tmp_vmlinux1
[snip]

> Allmodconfig on alpha, alpha-linux-gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5).

Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)

> Which place triggers it in your build?

net/ipv4/route.c:3152, call to rt_hash_lock_init().

From preprocessed source (reformatted):
-----------------------------------------------------------------------
typedef struct {
volatile unsigned int lock;

int on_cpu;
int line_no;
void *previous;
struct task_struct * task;
const char *base_file;
} spinlock_t;

static inline void *kmalloc(size_t size, unsigned int flags)
{
if (__builtin_constant_p(size)) {
int i = 0;

if (size <= 64) goto found; else i++;
if (size <= 128) goto found; else i++;
if (size <= 192) goto found; else i++;
if (size <= 256) goto found; else i++;
if (size <= 512) goto found; else i++;
if (size <= 1024) goto found; else i++;
if (size <= 2048) goto found; else i++;
if (size <= 4096) goto found; else i++;
if (size <= 8192) goto found; else i++;
if (size <= 16384) goto found; else i++;
if (size <= 32768) goto found; else i++;
if (size <= 65536) goto found; else i++;
if (size <= 131072) goto found; else i++;
{
extern void __you_cannot_kmalloc_that_much(void);
__you_cannot_kmalloc_that_much();
}
[snip]
-----------------------------------------------------------------------
{
int i;
rt_hash_locks = kmalloc(sizeof(spinlock_t) * 4096, (0x10u | 0x40u | 0x80u));
if (!rt_hash_locks)
panic("IP: failed to allocate rt_hash_locks\n");
for (i = 0; i < 4096; i++)
do {
*(&rt_hash_locks[i]) = (spinlock_t){ 0, -1, 0, ((void *)0), ((void *)0), ((void *)0) };
} while(0);
};
-----------------------------------------------------------------------

Geert Uytterhoeven

unread,

Aug 25, 2005, 5:30:41 AM8/25/05

to Al Viro, Paul Jackson, Paul Mackerras, Linus Torvalds, Linux Kernel Development, Sam Creasey

On Wed, 24 Aug 2005, Al Viro wrote:
> It does, no (build) regressions. BTW, tree is not far from allmodconfig
> buildable on a bunch of targets now - yesterday pile of fixes was about
> half of the set needed for that. Most of the remaining stuff is for
> m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> and if Geert ACKs them, we will be _very_ close to having 2.6.13 build

They look OK to me (sorry, I'm not in a position to really test them).
For thread_info related stuff, please coordinate with Roman.

> out of the box on the following set:
> alpha, amd64, arm (RPC and versatile being tracked), i386, ia64, m32r,
> m68k (!SUN3), ppc (6xx, 44x, chestnut being tracked), ppc64, sparc,
> sparc64, s390, s390x, uml-i386, uml-amd64.

Very nice! That must be a historical record ;-)

> v850, m68knommu: gcc gives ICE on attempt to build cross-toolchain

Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
for my uClinux experiments.

> sun3 is seriously broken and I doubt that we'll see any takers for testing
> 2.6 on those anyway ;-)

However, a few months ago it was still known to work in m68k CVS (ask Sammy).
And I didn't see any real compile regressions since then.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Sam Creasey

unread,

Aug 25, 2005, 9:59:25 AM8/25/05

to Geert Uytterhoeven, Al Viro, Paul Jackson, Paul Mackerras, Linus Torvalds, Linux Kernel Development

On Thu, 25 Aug 2005, Geert Uytterhoeven wrote:

> Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
> for my uClinux experiments.
>
> > sun3 is seriously broken and I doubt that we'll see any takers for testing
> > 2.6 on those anyway ;-)

Hey, I'm writing this on a sun3! :)

> However, a few months ago it was still known to work in m68k CVS (ask Sammy).
> And I didn't see any real compile regressions since then.

Looks like the last rev which really worked on the sun3 was 2.6.5, which
did work alright from m68k CVS (I did have another patch which needed to
be applied to actually get it to run, but that appears to have been only
fixes for the video/serial drivers, nothing "core").

I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at least compiling is a good
start point. Still, I'm going with Geert, and I'm not sure where the
compile regressions would have come from (outside of the video/serial
drivers, which don't compile in m68k CVS either).

What compile failures are you seeing?

-- Sam

Erik Mouw

unread,

Aug 25, 2005, 10:05:16 AM8/25/05

to Linus Torvalds, Linux Kernel Mailing List

On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:

> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.

There's something strange going on with either ACPI or cpufreq. When
the system boots, I see that the CPU is correctly detected as a 1200
MHz mobile Athlon, but once I log in /proc/cpuinfo says it's 2.6 or 3.6
GHz CPU. I don't have the laptop with me right now, but I'll send the
boot messages tonight.

Erik

--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Al Viro

unread,

Aug 25, 2005, 10:10:29 AM8/25/05

to Sam Creasey, Geert Uytterhoeven, Paul Jackson, Paul Mackerras, Linus Torvalds, Linux Kernel Development

On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:

> I have been a little out of it for a while on the sun3 stuffs, I'll admit
> (cursed day job), but I really, really intend to get recent 2.6 running
> again. Knowing that the rest of m68k is at least compiling is a good
> start point. Still, I'm going with Geert, and I'm not sure where the
> compile regressions would have come from (outside of the video/serial
> drivers, which don't compile in m68k CVS either).
>
> What compile failures are you seeing?

After looking at that for a while... It's the second hairball in there ;-)
flush_icache_range()/flush_icache_user_range() stuff, with all related
fun. Note that mainline has flush_ichace_range() in memory.c, which is
not picked by sun3.

Geert Uytterhoeven

unread,

Aug 25, 2005, 10:17:37 AM8/25/05

to Al Viro, Sam Creasey, Paul Jackson, Paul Mackerras, Linus Torvalds, Linux Kernel Development

On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
> > I have been a little out of it for a while on the sun3 stuffs, I'll admit
> > (cursed day job), but I really, really intend to get recent 2.6 running
> > again. Knowing that the rest of m68k is at least compiling is a good
> > start point. Still, I'm going with Geert, and I'm not sure where the
> > compile regressions would have come from (outside of the video/serial
> > drivers, which don't compile in m68k CVS either).
> >
> > What compile failures are you seeing?
>
> After looking at that for a while... It's the second hairball in there ;-)
> flush_icache_range()/flush_icache_user_range() stuff, with all related
> fun. Note that mainline has flush_ichace_range() in memory.c, which is
> not picked by sun3.

Indeed, the cache flush routines have to be moved to a separate file, as per
376-cache.diff. But that one depends on 362-cache.diff, that's why it's still
in my POSTPONED queue, until the originator has pushed that one upstream.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Sam Creasey

unread,

Aug 25, 2005, 10:18:20 AM8/25/05

to Al Viro, Geert Uytterhoeven, Paul Jackson, Paul Mackerras, Linus Torvalds, Linux Kernel Development

On Thu, 25 Aug 2005, Al Viro wrote:

> On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
>
> > I have been a little out of it for a while on the sun3 stuffs, I'll admit
> > (cursed day job), but I really, really intend to get recent 2.6 running
> > again. Knowing that the rest of m68k is at least compiling is a good
> > start point. Still, I'm going with Geert, and I'm not sure where the
> > compile regressions would have come from (outside of the video/serial
> > drivers, which don't compile in m68k CVS either).
> >
> > What compile failures are you seeing?
>
> After looking at that for a while... It's the second hairball in there ;-)
> flush_icache_range()/flush_icache_user_range() stuff, with all related
> fun. Note that mainline has flush_ichace_range() in memory.c, which is
> not picked by sun3.

Huh, my last compiling 2.6 sun3 tree ((old) m68k CVS) has those in
arch/m68k/mm/cache.c, which sun3 did use.

Ok, sounds like I need to make sure those are broken out sanely. I'm
pretty sure memory.c is a bad place for that, since (as you observed),
it's motorola-mmu only code (or, at least, was...)

I'm considerably less scared now. :)

-- Sam

Sebastian Kaergel

unread,

Aug 25, 2005, 11:50:04 AM8/25/05

to Linus Torvalds, linux-...@vger.kernel.org

On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <torv...@osdl.org> wrote:

> Antonino A. Daplas:
> intelfb/fbdev: Save info->flags in a local variable

> Sylvain Meyer:
> intelfb: Do not ioremap entire graphics aperture

One of these changes broke intelfb. The same .config from 2.6.13-rc6
does no longer work for -rc7. After booting the screen stays black, but
i can type blindly. I can also start X. dmesg does not show anything
unusual. any ideas?

Antonino A. Daplas

unread,

Aug 25, 2005, 12:25:41 PM8/25/05

to Sebastian Kaergel, Linus Torvalds, linux-...@vger.kernel.org, Sylvain Meyer

Sebastian Kaergel wrote:
> On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
> Linus Torvalds <torv...@osdl.org> wrote:
>
>> Antonino A. Daplas:
>> intelfb/fbdev: Save info->flags in a local variable
>> Sylvain Meyer:
>> intelfb: Do not ioremap entire graphics aperture

Probably this one. If vram is less than stolen size, intelfb
will only ioremap the framebuffer memory, excluding the
ringbuffer and the cursor memory.

Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
a display, try this patch.

CC'ed Sylvain.

Signed-off-by: Antonino Daplas <ada...@pol.net>
---

diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c
--- a/drivers/video/intelfb/intelfbdrv.c
+++ b/drivers/video/intelfb/intelfbdrv.c
@@ -502,7 +502,7 @@ intelfb_pci_register(struct pci_dev *pde
struct agp_bridge_data *bridge;
int aperture_bar = 0;
int mmio_bar = 1;
- int offset;
+ int offset, remap;

DBG_MSG("intelfb_pci_register\n");

@@ -662,11 +662,15 @@ intelfb_pci_register(struct pci_dev *pde
+ (dinfo->cursor.size >> 12);
}

+ if (dinfo->fbmem_gart)
+ remap = (dinfo->fb.offset << 12) + dinfo->fb.size;
+ else
+ remap = (dinfo->cursor.offset << 12) + dinfo->cursor.size;
+
/* Map the fb and MMIO regions */
/* ioremap only up to the end of used aperture */
dinfo->aperture.virtual = (u8 __iomem *)ioremap_nocache
- (dinfo->aperture.physical, (dinfo->fb.offset << 12)
- + dinfo->fb.size);
+ (dinfo->aperture.physical, remap);
if (!dinfo->aperture.virtual) {
ERR_MSG("Cannot remap FB region.\n");
cleanup(dinfo);

Sebastian Kaergel

unread,

Aug 25, 2005, 1:01:23 PM8/25/05

to Antonino A. Daplas, torv...@osdl.org, linux-...@vger.kernel.org, sylvai...@worldonline.fr

On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <ada...@gmail.com> wrote:

> Sebastian Kaergel wrote:
> > On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
> > Linus Torvalds <torv...@osdl.org> wrote:
> >
> >> Sylvain Meyer:
> >> intelfb: Do not ioremap entire graphics aperture
>
> Probably this one. If vram is less than stolen size, intelfb
> will only ioremap the framebuffer memory, excluding the
> ringbuffer and the cursor memory.
>
> Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
> a display, try this patch.
>
> CC'ed Sylvain.
>
> Signed-off-by: Antonino Daplas <ada...@pol.net>
> ---

Hi,
thanks for your quick reply, but it did not work. the screen remains
black when booting with video=intelfb:accel:0,{,no}hwcursor:0

Antonino A. Daplas

unread,

Aug 25, 2005, 1:46:36 PM8/25/05

to Sebastian Kaergel, torv...@osdl.org, linux-...@vger.kernel.org, sylvai...@worldonline.fr

Sebastian Kaergel wrote:
> On Fri, 26 Aug 2005 00:23:40 +0800
> "Antonino A. Daplas" <ada...@gmail.com> wrote:
>
>> Sebastian Kaergel wrote:
>>> On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
>>> Linus Torvalds <torv...@osdl.org> wrote:
>>>
>>>> Sylvain Meyer:
>>>> intelfb: Do not ioremap entire graphics aperture
>> Probably this one. If vram is less than stolen size, intelfb
>> will only ioremap the framebuffer memory, excluding the
>> ringbuffer and the cursor memory.
>>
>> Try booting with video=intelfb:accel:0,nohwcursor:0. If you get
>> a display, try this patch.
>>
>> CC'ed Sylvain.
>>
>> Signed-off-by: Antonino Daplas <ada...@pol.net>
>> ---
> <patch snipped>
>
> Hi,
> thanks for your quick reply, but it did not work. the screen remains
> black when booting with video=intelfb:accel:0,{,no}hwcursor:0

Can you try the patch anyway?

If the patch does not fix your problem, can you revert the patches and
see which is the culprit. I'm attaching those 2 patches.

Tony

intelfb-ioremap.diff

save_info_flags.diff

Sylvain Meyer

unread,

Aug 25, 2005, 2:50:53 PM8/25/05

to Sebastian Kaergel, Antonino A. Daplas, torv...@osdl.org, linux-...@vger.kernel.org

Sorry but could you re-explain me the problem. Tony, you've only

CC'ed me the end of the story.

Just a correction the options are video=intelfb:accel=0,hwcurso
r=0
with = and not :

Regards
Sylvain

Sebastian Kaergel a écrit:

Al Viro

unread,

Aug 25, 2005, 3:05:32 PM8/25/05

to Alexey Dobriyan, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org, r...@twiddle.net

On Thu, Aug 25, 2005 at 11:27:32AM +0400, Alexey Dobriyan wrote:
> Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
>
> > Which place triggers it in your build?
>
> net/ipv4/route.c:3152, call to rt_hash_lock_init().
>
> >From preprocessed source (reformatted):
> -----------------------------------------------------------------------
> typedef struct {
> volatile unsigned int lock;
>
> int on_cpu;
> int line_no;
> void *previous;
> struct task_struct * task;
> const char *base_file;
> } spinlock_t;
>
> static inline void *kmalloc(size_t size, unsigned int flags)

Oh, lovely...

a) gcc4 on alpha refuses to make that inline
b) bug is real, indeed - spinlock debugging + >32 CPU => panic in ip_rt_init()

IMO that's a question to rth: why do we really need to block always_inline
on alpha?

Richard Henderson

unread,

Aug 25, 2005, 6:17:31 PM8/25/05

to Al Viro, Alexey Dobriyan, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
> IMO that's a question to rth: why do we really need to block always_inline
> on alpha?

Because I use "extern inline" in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their address taken to be put into the alpha_machine_vector structures,
so we're guaranteed that they'll be out-of-line at least once.

But if you define inline to always_inline, the compiler complains when
its forced to fall back to the out-of-line copy. And rightly so -- the
feature was INVENTED for using compiler intrinsics that would in fact
not produce valid assembly unless certain parameters are constants.

I've complained about this before. You always-inline savages have
obsconded with ALL THREE inline keywords -- "inline", "__inline" and
"__inline__" -- so there is in fact no way to accomplish what I want.

So in a fit of pique I've locally undone not just one, but all of the
always-inline crap.

All that said, something's wrong if we couldn't generate an out-of-line
copy of kmalloc. The entire block protected by __builtin_constant_p
should have been eliminated. File a gcc bugzilla report.

r~

Al Viro

unread,

Aug 25, 2005, 6:49:40 PM8/25/05

to Alexey Dobriyan, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
> On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
> > IMO that's a question to rth: why do we really need to block always_inline
> > on alpha?
>
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines. These routines have
> their address taken to be put into the alpha_machine_vector structures,
> so we're guaranteed that they'll be out-of-line at least once.
>
> But if you define inline to always_inline, the compiler complains when
> its forced to fall back to the out-of-line copy. And rightly so -- the
> feature was INVENTED for using compiler intrinsics that would in fact
> not produce valid assembly unless certain parameters are constants.
>
> I've complained about this before. You always-inline savages have
> obsconded with ALL THREE inline keywords -- "inline", "__inline" and
> "__inline__" -- so there is in fact no way to accomplish what I want.
>
> So in a fit of pique I've locally undone not just one, but all of the
> always-inline crap.
>
> All that said, something's wrong if we couldn't generate an out-of-line
> copy of kmalloc. The entire block protected by __builtin_constant_p
> should have been eliminated. File a gcc bugzilla report.

It is eliminated. As the result, the compile-time checks disappear.
In this case it's more or less harmless - we miss some bugs that could
be caught at compile time, but that's it. In case of e.g. xchg() (same
technics of calling undefined function in the code that gets eliminated
if everything's right) it gave genuine bugs - gcc decided to create an
uninlined copy and to hell it went:

static inline unsigned long
__xchg(volatile void *ptr, unsigned long x, int size)
{
switch (size) {
case 1:
return __xchg_u8(ptr, x);
case 2:
return __xchg_u16(ptr, x);
case 4:
return __xchg_u32(ptr, x);
case 8:
return __xchg_u64(ptr, x);
}
__xchg_called_with_bad_pointer();
return x;
}
#define xchg(ptr,x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
})

blows to hell, since we have no way to tell gcc that it should _never_
be done non-inlined. Well, no way short of making __xchg a macro...

So what do you propose to use for that class of compile-time checks?
#define whenever they are used?

Antonino A. Daplas

unread,

Aug 25, 2005, 7:25:42 PM8/25/05

to Sylvain Meyer, Sebastian Kaergel, torv...@osdl.org, linux-...@vger.kernel.org

Sorry. Here's the start of the thread.

Tony

On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <torv...@osdl.org> wrote:

> > Antonino A. Daplas:
> > intelfb/fbdev: Save info->flags in a local variable

> > Sylvain Meyer:
> > intelfb: Do not ioremap entire graphics aperture

One of these changes broke intelfb. The same .config from 2.6.13-rc6

does no longer work for -rc7. After booting the screen stays black, but
i can type blindly. I can also start X. dmesg does not show anything
unusual. any ideas?

Danny ter Haar

unread,

Aug 26, 2005, 6:45:59 AM8/26/05

to linux-...@vger.kernel.org

Linus Torvalds <torv...@osdl.org> wrote:
> I really wanted to release a 2.6.13, but there's been enough changes
>while we've been waiting for other issues to resolve that I think it's
>best to do a -rc7 first.
>

>Most of the -rc7 changes are pretty trivial, either one-liners or
>affecting some particular specific driver or unusual configuration. The
>shortlog (appended) should give a pretty good idea of what's up.
>

> Linus

OK, i tried rc7 on my newsgateway and so far it keeps running after 50+
hours of 200megabit in & 200 megabitoutgoing network traffic and
sufficient storage to the scsi system.

Of course it will probably reboot just after sending this message.
If it stays up after 5 days of pounding it will get _my_ stamp of
aproval ;-)

----------
Linux 2.6.13-rc7 (root@newsgate) (gcc [can't parse]) #??? 1CPU [newsgate.(none)]

Memory: Total Used Free Shared Buffers
Mem: 2058040 2041552 16488 0 616
Swap: 0 0 0

Bootup: Wed Aug 24 09:50:30 2005 Load average: 3.39 3.25 3.16 2/80 12244

user : 5:06:34.95 10.0% page in : 0
nice : 0:42:50.54 1.4% page out: 0
system: 16:22:48.44 32.2% swap in : 0
idle : 0:25:08.22 0.8% swap out: 0
uptime: 2d 2:53:38.68 context :592311164

irq 0: 45792855 timer irq 12: 3
irq 1: 8 i8042 irq 24: 56420796 aic79xx
irq 2: 0 cascade [4] irq 25: 479838182 aic79xx, eth3
irq 4: 369 serial irq 28:1007452070 acenic
irq 8: 0 rtc

----------

Danny

Danny ter Haar

unread,

Aug 26, 2005, 9:52:49 AM8/26/05

to linux-...@vger.kernel.org

Danny ter Haar <d...@cistron.nl> wrote:
>Of course it will probably reboot just after sending this message.

Me and my big mouth...
If there is a god he is making fun of me right now ;-)

After 53 hours and 31 minutes it crashed.
dth pts/1 zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)

Prior to this kernel it had been running 2.6.12-mm1 without problems:
reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36)

I will now compile & run rc7-git1.

This machine has serial console but only for bootpurpose (no logging
possible) Wil try and setup some telnet capture service to try and
fetch error.

Masoud Sharbiani

unread,

Aug 26, 2005, 11:50:33 PM8/26/05

to Linus Torvalds, Linux Kernel Mailing List

Hello,
It crashes for me right off the bat:
Here is the kernel output:
---
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8
CONSOLE=/dev/ttyS0
[Linux-bzImage, setup=0x1200, size=0x1fe4fa]
savedefault
boot
Linux version 2.6.13-rc7-git1 (root@dual) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 SMP Fri Aug 26 15:18:21 EDT 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000002fff0000 (usable)
BIOS-e820: 000000002fff0000 - 000000002fff3000 (ACPI NVS)
BIOS-e820: 000000002fff3000 - 0000000030000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
767MB LOWMEM available.
found SMP MP-table at 000f5fd0
DMI 2.2 present.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl)
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 30000000:cec00000)
Built 1 zonelists
Kernel command line: root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 868.668 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 774032k/786368k available (2926k kernel code, 11824k reserved, 1174k data, 220k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1739.92 BogoMIPS (lpj=8699649)
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Pentium III (Coppermine) stepping 0a
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1737.36 BogoMIPS (lpj=8686805)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 0a
Total of 2 processors activated (3477.29 BogoMIPS).
ENABLING IO-APIC IRQs
TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb2c0, last bus=1
PCI: Using configuration type 1
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 *7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Bridge: 0000:00:01.0
IO window: a000-afff
MEM window: d0000000-d3ffffff
PREFETCH window: d4000000-d5ffffff
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1125070419.160:1): initialized
Installing knfsd (copyright (C) 1996 ok...@monad.swb.de).
Initializing Cryptographic API
PCI: Enabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Sleep Button (CM) [SLPB]
ACPI: CPU0 (power states: C1[C1])
ACPI: CPU1 (power states: C1[C1])
lp: driver loaded but no devices found
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 133 chipset
agpgart: AGP aperture is 256M @ 0xc0000000
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized tdfx 1.0.0 20010216 on minor 0: 3Dfx Interactive, Inc. Voodoo Banshee
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD por<1ai vxl0d0o6e anq:1000S [i1l
8S5P 1
50oduies linkedsio:: .C0 : o
sE P: 00i0:[<c1abl2e6>] Not tainted VLI
EFLAGS: 00010282 (2.6.13-rc7-git1)
EIP is at 0xc160e2e6
eax: efc4b800 ebx: c0537300 ecx: efc4b874 edx: efc4b874
esi: effa1f90 edi: ffffe000 ebp: effa0000 esp: effa1f8c
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=effa0000 task=effd2520)
Stack: 00000000 c160e2e0 c160e2e0 ffffe000 effa0000 c0537380 c0537300 c0100e10
00000002 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call Trace:
[<c0100e10>] cpu_idle+0x70/0x80
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e6 8c <ff> ff 00 00 00 00 2b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<0>Kernel panic - not syncing: Attempted to kill the idle task!
---
2.6.13-rc6 boots, but has the bug 5099 (at bugzilla.kernel.org).

cheers,

Masoud Sharbiani

Mitchell Blank Jr

unread,

Aug 26, 2005, 11:52:07 PM8/26/05

to Al Viro, Alexey Dobriyan, Paul Jackson, pau...@samba.org, torv...@osdl.org, linux-...@vger.kernel.org

Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.

Is there any reason not to just make the out-of-line version explicit?
i.e.:

/* in some .h file: */
static /*(always!)*/inline int my_func(void)
{
return FOO;
}
extern int OOL_my_func(void);

/* in some .c file: */
int OOL_my_func(void)
{
return my_func();
}

It's a little ugly but there really aren't that many cases of this, right?
Or is this just the principal of the thing? :-)

-Mitch

Deepak Saxena

unread,

Aug 27, 2005, 12:35:31 AM8/27/05

to Erik Mouw, Linux Kernel Mailing List

On Aug 25 2005, at 16:04, Erik Mouw was caught saying:

> On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> > I really wanted to release a 2.6.13, but there's been enough changes
> > while we've been waiting for other issues to resolve that I think it's
> > best to do a -rc7 first.
>
> There's something strange going on with either ACPI or cpufreq. When

Is there ever anything not strange going on with ACPI. :p

/me goes back to beer.

~Deepak

--
Deepak Saxena - dsa...@plexity.net - http://www.plexity.net

Even a stopped clock gives the right time twice a day.

Danny ter Haar

unread,

Aug 27, 2005, 7:43:32 AM8/27/05

to linux-...@vger.kernel.org

>I Wrote:
>After 53 hours and 31 minutes it crashed.
>dth pts/1 zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
>reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)
>
>Prior to this kernel it had been running 2.6.12-mm1 without problems:
>reboot system boot 2.6.12-mm1 Sun Aug 14 12:13 (9+21:36)
>
>I will now compile & run rc7-git1.

RC7-GIT7 barfed on me after some 20 hours:

root ttyS0 Fri Aug 26 16:32 - crash (20:44)
reboot system boot 2.6.13-rc7-git1 Fri Aug 26 16:32 (20:59)

I managed to get some information from the serial console:

scsi0: SCBPTR == 0x55, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff6e
CDB 0 0 0 0 0 0
STACK: 0x10c 0x0 0x0 0x0 0x0 0x0 0x0 0x0
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
DevQ(0:0:0): 0 waiting
DevQ(0:1:0): NMI Watchdog detected LOCKUP on CPU0CPU 0
Modules linked in: rawfs rtc evdev hw_random i2c_amd8111 tg3 e100 mii w83627hf eeprom lm85 i2c_sensor i2c_isa i2c_amd756 i2c_core psmouse
Pid: 168, comm: scsi_eh_0 Not tainted 2.6.13-rc7-git1
RIP: 0010:[<ffffffff802644f9>] <ffffffff802644f9>{serial_in+105}
RSP: 0018:ffff81007fc17b80 EFLAGS: 00000002
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff80473a40
RBP: 0000000000002705 R08: 0000000000000020 R09: 0000000000007930
R10: 0000000000000034 R11: 000000000000000a R12: ffffffff80473a40
R13: ffffffff8045f6fe R14: 000000000000000d R15: 000000000000000d
FS: 00002aaaab3cbe90(0000) GS:ffffffff80485800(0000) knlGS:00000000556ada40
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000515970 CR3: 000000007dc27000 CR4: 00000000000006e0
Process scsi_eh_0 (pid: 168, threadinfo ffff81007fc16000, task ffff8100033607c0)
Stack: ffffffff8026682d 0000000500000002 ffffffff803ebc60 0000000000007931
000000000000000d 0000000000000096 0000000000000010 0000000000000046
ffffffff8012ed9c 000000000000793e
Call Trace:<ffffffff8026682d>{serial8250_console_write+413} <ffffffff8012ed9c>{__call_console_drivers+76}
<ffffffff8012f053>{release_console_sem+339} <ffffffff8012fbc9>{vprintk+601}
<ffffffff8012fbc9>{vprintk+601} <ffffffff8012fc3e>{printk+78}
<ffffffff80325a40>{thread_return+0} <ffffffff8012fc3e>{printk+78}
<ffffffff8028c235>{ahd_print_register+261} <ffffffff802abc34>{ahd_platform_dump_card_state+100}
<ffffffff80296b0d>{ahd_dump_card_state+8973} <ffffffff802ad320>{ahd_linux_abort+624}
<ffffffff802aa590>{ahd_linux_sem_timeout+0} <ffffffff80284f5c>{scsi_error_handler+1324}
<ffffffff8010e396>{child_rip+8} <ffffffff80284a30>{scsi_error_handler+0}
<ffffffff8010e38e>{child_rip+0}

Code: 0f b6 c0 c3 66 66 90 41 57 49 89 f7 41 56 41 55 41 bd 00 01
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!

I don't know if this is enough information for the developers to go on.

For me it's back to 2.6.12-mm1 *snif*

Danny ter Haar

unread,

Aug 27, 2005, 8:02:30 AM8/27/05

to linux-...@vger.kernel.org

I hate responding to myself but it's necessary:

>RC7-GIT7 barfed on me after some 20 hours:

complete serial console message before it reset is on:

http://newsgate.newsserver.nl/kernel/

as is config-file.

Hardware: AMD64 running pure-64 debian ony tyan motherboard with opteron
250 cpu.

Erik Mouw

unread,

Aug 29, 2005, 9:34:21 AM8/29/05

to Deepak Saxena, Linux Kernel Mailing List

On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote:
> On Aug 25 2005, at 16:04, Erik Mouw was caught saying:
> > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> > > I really wanted to release a 2.6.13, but there's been enough changes
> > > while we've been waiting for other issues to resolve that I think it's
> > > best to do a -rc7 first.
> >
> > There's something strange going on with either ACPI or cpufreq. When
>
> Is there ever anything not strange going on with ACPI. :p

Heh :)

It gets even stranger: I had to boot to windows to be able to backup my
phone. After that, I couldn't recreate the 2.6/3.6 GHz CPU problem
anymore. Your explanation is as good as mine...

Erik

--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands