It's been two weeks since rc6, but let's face it, with xmas and new years

(and birthdays) in between, there hasn't actually been a lot of working

days, and the incremental patch from -rc6 is about half the size of the

one from rc5->rc6.
And I'll be charitable and claim it's because it's all stabilizing, and

not because we've all been in a drunken stupor over the holidays.
The shortlog (appended below) is short and fairly informative. It's all

really just a lot of rather small changes. The diffstat shows a lot of

one- and two-liners, with just a few drivers (and the Cell platform)

getting a bit more attention, and the SLUB support of /proc/slabinfo

showing up as a blip.
Both git trees and tar-balls/patches pushed out, should be mirroring out

within minutes. So there are no excuses to not try it out, and see if your

favorite regression has been fixed.
		Linus
---

Akos Maroy (1):

      fix: using joysticks in 32 bit applications on 64 bit systems
Al Viro (20):

      [TG3]: Endianness annotations.

      [TG3]: Endianness bugfix.

      typhoon: endianness bug in tx/rx byte counters

      typhoon: missing le32_to_cpu() in get_drvinfo

      typhoon: set_settings broken on big-endian

      typhoon: missed rx overruns on big-endian

      typhoon: memory corruptor on big-endian if TSO is enabled

      typhoon: trivial endianness annotations

      cycx: annotations and fixes (.24 fodder?)

      asix fixes

      yellowfin: annotations and fixes (.24 fodder?)

      dl2k endianness fixes (.24 fodder?)

      r8169 endianness

      rrunner: use offsetof() instead of homegrown insanity

      3c574 and 3c589 endianness fixes (.24?)

      fec_mpc52xx: write in C...

      3c359 endianness annotations and fixes

      uml: user of helper_wait() got missed when it got extra arguments

      restrict reading from /proc/<pid>/maps to those who share ->mm or can ptrace pid

      [CASSINI]: Fix endianness bug.
Bartlomiej Zolnierkiewicz (10):

      ide-cd: fix SAMS...
[ message continues ]

At first glance, looks fine and fast here on dual-athlon XP desktop with

adaptec SCSI, NFS, e1000 and SBLive. All the comments here did not look

encouraging, but I'll let it run as long as possible there since I

encountered no build nor boot error.
Cheers,

Willy
--

Hello,
	Got this when doing usual looping over /proc entries on fresh test kernel:
WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()

Call Trace:

 [0000000000492704] lockdep_stats_show+0x6ac/0x6c0

 [00000000004eb4b4] seq_read+0x5c/0x340

 [000000000050b2bc] proc_reg_read+0x64/0xa0

 [00000000004cd72c] vfs_read+0x74/0x120

 [00000000004cdb4c] sys_read+0x34/0x60

 [00000000004062d4] linux_sparc_syscall32+0x3c/0x40

 [0000000000012ff4] 0x12ffc
and this would be:
#ifdef CONFIG_DEBUG_LOCKDEP

        DEBUG_LOCKS_WARN_ON(debug_atomic_read(&nr_unused_locks) != nr_unused);

#endif
Regards,
	Mariusz
Linux sparc64 2.6.24-rc7 #3 SMP PREEMPT Tue Jan 8 19:23:15 CET 2008 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux
Gnu C                  3.4.6

Gnu make               3.81

binutils               2.18

util-linux             2.12r

mount                  2.12r

module-init-tools      3.4

e2fsprogs              1.40.3

Linux C Library        2.6.1

Dynamic linker (ldd)   2.6.1

Procps                 3.2.7

Net-tools              1.60

Kbd                    1.13

Sh-utils               6.9

udev                   115

Modules Loaded         snd_pcm_oss snd_mixer_oss snd_sun_cs4231 snd_pcm snd_timer snd soundcore snd_page_alloc sunhme sr_mod cdrom sg

From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Please turn off lockdep on sparc64, currently it not

reliable.  I have many things to audit, including how

the stack frames are presented to the lockdep layer.
So any problem you run into can be due to issues like

that.

--

is this anything the core lockdep code could help improve? Let us know

if any aspect is hindering you.
	Ingo

--

From: Ingo Molnar <mingo@elte.hu>
No, it's a sparc64 issue.
Another problem I ran into are the huge static table sizes

lockdep uses.  They really need to be either made smaller or

dynamically allocated.
Sparc64 has hard limitations on kernel size (due to firmware

and bootloader issues) and I hit these limits if I am not

careful on SMP with lockdep enabled.
Andi Kleen and I discussed in a thread several weeks ago.

I believe Andi even came up with a suggested direction to

fix this.
--

yeah, i'll pick them up, probably tomorrow.
	Ingo

--

What is the usual looping, please?
---

~Randy

--

#!/bin/bash
for i in `find /proc -type f`; do

        echo -n "cat $i > /dev/null ... ";

        ( cat $i > /dev/null & );

        echo "done";

done
Regards,
	Mariusz

--

OK, thanks.  Probably not related to the problem report, but

the script should probably check each file for 'readable' (-r).

/proc/sysrq-trigger is write-only...
--

~Randy

--

Hm... true. Good hint.
Thanks,
	Mariusz
--

HI all...
With this kernel I'm getting frequent temporary freezes (system comes

back responsive after a minute or so...). I see this in dmesg:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata3.00: cmd ca/00:08:67:10:18/00:00:00:00:00/e2 tag 0 dma 4096 out

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata3.00: status: { DRDY }

ata3: soft resetting link

ata3.00: configured for UDMA/133

ata3: EH complete

sd 2:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)

sd 2:0:0:0: [sdb] Write Protect is off

sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00

sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata4.00: cmd c8/00:08:ef:0b:c7/00:00:00:00:00/e7 tag 0 dma 4096 in

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: soft resetting link

ata4.00: configured for UDMA/133

ata4: EH complete

sd 3:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)

sd 3:0:0:0: [sdc] Write Protect is off

sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00

sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
See this are two different drives, I doubt both drives have gone nuts

at the same time...
Controllers:

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)

00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)

03:04.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02)
Drives (sda is PATA, sd[bcd] are SATA,

werewolf:~> lsscsi

[0:0:0:0]    disk    ATA      ST3120022A       3.06  /dev/sda

[0:0:1:0]    cd/dvd  HL-DT-ST DVDRAM GSA-H10N  JL12  /dev/sr0

[2:0:0:0]    disk    ATA      ST3200822AS      3.01  /dev/sdb

[3:0:0:0]    disk    ATA      MAXTOR STM332082 3.AA  /dev/sdc

[4:0:0:0]    disk    ATA      Maxtor 7Y250M0   YAR5  /dev/sdd

werewolf:~> df

Filesystem    ...
[ message continues ]

That's weird.  There hasn't been any related changes.  Does going back

to 2.6.24-rc6 fix the problem?
--

tejun

--

Hi,
Okay, then, it's less likely a regression and more likely a newly
You do that using LABEL, UUID or device ID.  Just run 'ls -l
Unfortunately not but you can boot into single mode where there's

nothing trying to access the disk without your explicit command and

verify access to each hard disk.
Hmm... You are seeing timeouts from multiple harddisks.  The first thing

I would try is to reseat the cables and connect the SATA hard drives to

a separate power supply and see whether that changes anything.
--

tejun

--

I'm still pending to pysically remove the disks (or at least unplug the

cable...), but I have realized a cusious thing: after some errors, the

kernel is lowering the disk speed (UDMA/133, then 100, then 33):
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata3.00: cmd c8/00:08:07:81:3f/00:00:00:00:00/e0 tag 0 dma 4096 in

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata3.00: status: { DRDY }

ata3: soft resetting link

ata3.00: configured for UDMA/133

ata3: EH complete

...

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata3.00: cmd c8/00:48:05:73:33/00:00:00:00:00/ef tag 0 dma 36864 in

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata3.00: status: { DRDY }

ata3: soft resetting link

ata3.00: configured for UDMA/133

ata3: EH complete

...

(one more 133)

...

ata3.00: limiting speed to UDMA/100:PIO4

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata3.00: cmd c8/00:40:8d:9c:84/00:00:00:00:00/eb tag 0 dma 32768 in

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata3.00: status: { DRDY }

ata3: soft resetting link

ata3.00: configured for UDMA/100

...

(3 more 100)

...

ata3.00: limiting speed to UDMA/33:PIO4

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen

ata3.00: cmd ca/00:08:9f:00:1a/00:00:00:00:00/e2 tag 0 dma 4096 out

         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata3.00: status: { DRDY }

ata3: soft resetting link

ata3.00: configured for UDMA/33

...
Perhaps this gives a clue.

Or I just had bad luck and 2 of my 4 disks broke at the same time.
--

J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:

                                         \         It's better when it's free

Mandriva Linux release 2008.1 (Cooker) for i586

Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT

--

That's the standard error handling behavior.  Timeouts are likely to
As I said, the first thing I would try is to connect the drives to a

separate PSU and re-seating cables as you're seeing problems on two

drives simultaneously.
--

tejun

--

I finally found the bad drive (the most obvious one as I would expect,

it was recycled from an older box...).

I tried removing completely the drive from power and controller, and then

running with it powered but not connected. No single error any more on

any of the other 3 drives. I have been updating my distro, rebuilding the

rpm database, moving big files between drives, even all at the same time.

No error.
I can't believe it, but a bad drive was causing timeouts on other drive

_on other controller_, the bad one was attached to the Promise and the

good ones on the ICH5 SATA (both integrated in motherboard).

Or there is a strange interaction in my board (Asus PC-DL), or there is

a nasty bug in the kernel...
--

J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:

                                         \         It's better when it's free

Mandriva Linux release 2008.1 (Cooker) for i586

Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT

--

Hmmm... That's an interesting story.  Can you please connect the faulty

harddrive to a separate power supply and connect the drive to the

controller and see whether IO errors go away?
--

tejun

--

Reminds me of my 2.6.24 regression bug:

http://bugzilla.kernel.org/show_bug.cgi?id=9393

--

avuton

--

 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

--

El Sun, 6 Jan 2008 14:19:16 -0800 (PST)

  Booted with it and I see 
 [   37.043998]

[   37.043999] Call Trace:

[   37.044001]  <IRQ>  [<ffffffff80227fe3>] enqueue_task+0x13/0x30

[   37.044040]  [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0xd30

[   37.044044]  [<ffffffff80228062>] activate_task+0x32/0x50

[   37.044073]  [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_handler+0xbb/0x120

[   37.044086]  [<ffffffff80238d08>] tasklet_action+0x48/0xb0

[   37.044091]  [<ffffffff80238c09>] __do_softirq+0x69/0xe0

[   37.044097]  [<ffffffff8020ce2c>] call_softirq+0x1c/0x30

[   37.044101]  [<ffffffff8020efe5>] do_softirq+0x35/0x90

[   37.044105]  [<ffffffff80238aa5>] irq_exit+0x95/0xa0

[   37.044108]  [<ffffffff8020f0c0>] do_IRQ+0x80/0x100

[   37.044111]  [<ffffffff8020a840>] default_idle+0x0/0x40

[   37.044115]  [<ffffffff8020c181>] ret_from_intr+0x0/0xa

[   37.044117]  <EOI>  [<ffffffff8020a869>] default_idle+0x29/0x40                                         ...
[ message continues ]

Can you post the lines above this?

This might be a WARN_ON_ONCE() triggering, for which fixes are on their way into

the wireless-2.6 tree.
--

Greetings Michael.

--

El Mon, 7 Jan 2008 17:24:03 +0100
 This?
[   37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx()

[   37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3

[   37.043998]

[   37.043999] Call Trace:

[   37.044001]  <IRQ>  [<ffffffff80227fe3>] enqueue_task+0x13/0x30

[   37.044040]  [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0xd30

[   37.044044]  [<ffffffff80228062>] activate_task+0x32/0x50

[   37.044073]  [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_handler+0xbb/0x120

[   37.044086]  [<ffffffff80238d08>] tasklet_action+0x48/0xb0

[   37.044091]  [<ffffffff80238c09>] __do_softirq+0x69/0xe0

[   37.044097]  [<ffffffff8020ce2c>] call_softirq+0x1c/0x30

[   37.044101]  [<ffffffff8020efe5>] do_softirq+0x35/0x90

[   37.044105]  [<ffffffff80238aa5>] irq_exit+0x95/0xa0

[   37.044108]  [<ffffffff8020f0c0>] do_IRQ+0x80/0x100

[   37.044111]  [<ffffffff8020a840>] default_idle+0x0/0x40

[   37.044115]  [<ffffffff8020c181>] ret_from_...
[ message continues ]

Can you check if that is the

WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);

in rx.c line 1486?

If that is the one, then fixes are already on their way upstream.

Ignore the harmless warning for now.
--

Greetings Michael.

--

El Mon, 7 Jan 2008 18:30:51 +0100
 How can I check? The source code I build does indeed have the line

 you quoted on net/mac80211/rx.c:1486 Is that what you are asking for?
--

Yes fine.

Patches are on their way. Ignore the warning for now. It is harmless.
--

Greetings Michael.

--

El Tue, 8 Jan 2008 16:30:30 +0100
  Thank you very much for your time. Keep on the good work :)
--

El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
   MODPOST vmlinux.o

WARNING: vmlinux.o(.text+0x10508): Section mismatch: reference to .init.text:fork_idle (between 'do_fork_idle' and 'lapic_timer_broadcast')

WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to .init.data.2:trampoline_level4_pgt (between 'ident_complete' and 'secondary_startup_64')

WARNING: vmlinux.o(.text.head+0xeb): Section mismatch: reference to .init.data.2:trampoline_level4_pgt (between 'ident_complete' and 'secondary_startup_64')
 Config:
#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.24-rc6

# Sun Jan  6 17:11:46 2008

#

CONFIG_64BIT=y

# CONFIG_X86_32 is not set

CONFIG_X86_64=y

CONFIG_X86=y

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

# CONFIG_QUICKLIST is not set

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_RWSEM_GENERIC_SPINLOCK=y

# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set

# CONFIG_ARCH_HAS_ILOG2_U32 is not set

# CONFIG_ARCH_HAS_ILOG2_U64 is not set

CONFIG_GENERIC_CALIBRATE_DELAY=y

CONFIG_GENERIC_TIME_VSYSCALL=y

CONFIG_ARCH_SUPPORTS_OPROFILE=y

CONFIG_ZONE_DMA32=y

CONFIG_ARCH_POPULATES_NODE_MAP=y

CONFIG_AUDIT_ARCH=y

CONFIG_GENERIC_HARDIRQS=y

CONFIG_GENERIC_IRQ_PROBE=y

CONFIG_GENERIC_PENDING_IRQ=y

# CONFIG_KTIME_SCALAR is not set

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#

# General setup

#

CONFIG_EXPERIMENTAL=y

CONFIG_LOCK_KERNEL=y

CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""

CONFIG_LOCALVERSION_AUTO=y

CONFIG_SWAP=y

CONFIG_SYSVIPC=y

CONFIG_SYSVIPC_SYSCTL=y

CONFIG_POSIX_MQUEUE=y

# CONFIG_BSD_PROCESS_ACCT is not set

# CONFIG_TASKSTATS is not set

# CONFIG_USER_NS is not set

# CONFIG_PID_NS is not set...
[ message continues ]

Caused by following patch:

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408

Author: Vivek Goyal <vgoyal@in.ibm.com>

Date:   Wed May 2 19:27:07 2007 +0200
    [PATCH] x86-64: Relocatable Kernel Support
Vivek - will you look after this?
	Sam

--

El Mon, 7 Jan 2008 17:31:39 +0100
 Still seeing this as of v2.6.24-rc7-205-g5d5d800
#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.24-rc7

# Sun Jan 13 19:31:41 2008

#

CONFIG_64BIT=y

# CONFIG_X86_32 is not set

CONFIG_X86_64=y

CONFIG_X86=y

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

# CONFIG_QUICKLIST is not set

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_RWSEM_GENERIC_SPINLOCK=y

# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set

# CONFIG_ARCH_HAS_ILOG2_U32 is not set

# CONFIG_ARCH_HAS_ILOG2_U64 is not set

CONFIG_GENERIC_CALIBRATE_DELAY=y

CONFIG_GENERIC_TIME_VSYSCALL=y

CONFIG_ARCH_SUPPORTS_OPROFILE=y

CONFIG_ZONE_DMA32=y

CONFIG_ARCH_POPULATES_NODE_MAP=y

CONFIG_AUDIT_ARCH=y

CONFIG_GENERIC_HARDIRQS=y

CONFIG_GENERIC_IRQ_PROBE=y

CONFIG_GENERIC_PENDING_IRQ=y

# CONFIG_KTIME_SCALAR is not set

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#

# General setup

#

CONFIG_EXPERIMENTAL=y

CONFIG_LOCK_KERNEL=y

CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""

CONFIG_LOCALVERSION_AUTO=y

CONFIG_SWAP=y

CONFIG_SYSVIPC=y

CONFIG_SYSVIPC_SYSCTL=y

CONFIG_POSIX_MQUEUE=y

# CONFIG_BSD_PROCESS_ACCT is not set

# CONFIG_TASKSTATS is not set

# CONFIG_USER_NS is not set

# CONFIG_PID_NS is not set

# CONFIG_AUDIT is not set

CONFIG_IKCONFIG=y

CONFIG_IKCONFIG_PROC=y

CONFIG_LOG_BUF_SHIFT=15

# CONFIG_CGROUPS is not set

CONFIG_FAIR_GROUP_SCHED=y

CONFIG_FAIR_USER_SCHED=y

# CONFIG_FAIR_CGROUP_SCHED is not set

# CONFIG_SYSFS_DEPRECATED is not set

CONFIG_RELAY=y

CONFIG_BLK_DEV_INITRD=y

CONFIG_INITRAMFS_SOURCE=""

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

CONFIG_SYSCTL=y

# CONFIG_EMBEDDED is not set

CONFIG_UID16=y

CONFIG_SYSCTL_S...
[ message continues ]

Caused by following commit:

commit 65f27f38446e1976cc98fd3004b110fedcddd189

Author: David Howells <dhowells@redhat.com>

Date:   Wed Nov 22 14:55:48 2006 +0000
    WorkStruct: Pass the work_struct pointer instead of context data
David - will you look into this?
	Sam

--

[arch/x86/kernel/smpboot_64.c]

	void do_fork_idle(struct work_struct *work)
Needs labelling with __cpuinit.
David

--

Do you have a config?
David

--

El Mon, 07 Jan 2008 23:27:35 +0000
 My config follows:
#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.24-rc6

# Sun Jan  6 17:11:46 2008

#

CONFIG_64BIT=y

# CONFIG_X86_32 is not set

CONFIG_X86_64=y

CONFIG_X86=y

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

# CONFIG_QUICKLIST is not set

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_RWSEM_GENERIC_SPINLOCK=y

# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set

# CONFIG_ARCH_HAS_ILOG2_U32 is not set

# CONFIG_ARCH_HAS_ILOG2_U64 is not set

CONFIG_GENERIC_CALIBRATE_DELAY=y

CONFIG_GENERIC_TIME_VSYSCALL=y

CONFIG_ARCH_SUPPORTS_OPROFILE=y

CONFIG_ZONE_DMA32=y

CONFIG_ARCH_POPULATES_NODE_MAP=y

CONFIG_AUDIT_ARCH=y

CONFIG_GENERIC_HARDIRQS=y

CONFIG_GENERIC_IRQ_PROBE=y

CONFIG_GENERIC_PENDING_IRQ=y

# CONFIG_KTIME_SCALAR is not set

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#

# General setup

#

CONFIG_EXPERIMENTAL=y

CONFIG_LOCK_KERNEL=y

CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""

CONFIG_LOCALVERSION_AUTO=y

CONFIG_SWAP=y

CONFIG_SYSVIPC=y

CONFIG_SYSVIPC_SYSCTL=y

CONFIG_POSIX_MQUEUE=y

# CONFIG_BSD_PROCESS_ACCT is not set

# CONFIG_TASKSTATS is not set

# CONFIG_USER_NS is not set

# CONFIG_PID_NS is not set

# CONFIG_AUDIT is not set

CONFIG_IKCONFIG=y

CONFIG_IKCONFIG_PROC=y

CONFIG_LOG_BUF_SHIFT=15

# CONFIG_CGROUPS is not set

CONFIG_FAIR_GROUP_SCHED=y

CONFIG_FAIR_USER_SCHED=y

# CONFIG_FAIR_CGROUP_SCHED is not set

# CONFIG_SYSFS_DEPRECATED is not set

CONFIG_RELAY=y

CONFIG_BLK_DEV_INITRD=y

CONFIG_INITRAMFS_SOURCE=""

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

CONFIG_SYSCTL=y

# CONFIG_EMBEDDED is not set

CONFIG_UID16=y

CONFIG_SYSCTL_SYSCALL=y

CONFIG_KALLSYMS=y

#...
[ message continues ]

Hi,
When booting the 2.6.24-rc7 kernel on the powerpc, kernel bug at

kernel.sched.c is triggered
[    0.000000] Kernel command line: ro console=hvc0 rhgb quiet root=LABEL=/

[    0.149567] BUG: scheduling while atomic: kthreadd/2/0x0006f34c

[    0.149655] BUG: scheduling while atomic: kthreadd/3/0xbe0d8168

[    0.149714] ------------[ cut here ]------------

[    0.149722] kernel BUG at kernel/sched.c:5156!

cpu 0x0: Vector: 700 (Program Check) at [c0000001be0dbd70]

    pc: c00000000006c090: .migration_thread+0x64/0x31c

    lr: c00000000008e348: .kthread+0x78/0xc4

    sp: c0000001be0dbff0

   msr: 8000000000029032

  current = 0xc0000000ee11ccc0

  paca    = 0xc000000000532d00

    pid   = 3, comm = kthreadd

kernel BUG at kernel/sched.c:5156!

enter ? for help

[c0000001be0dc0b0] c00000000008e348 .kthread+0x78/0xc4

[c0000001be0dc140] c00000000002a550 .kernel_thread+0x4c/0x68
0:mon> t

[c0000001be0dc0b0] c00000000008e348 .kthread+0x78/0xc4

[c0000001be0dc140] c00000000002a550 .kernel_thread+0x4c/0x68

0:mon> r

R00 = 0000000000000001   R16 = 4000000001c00000

R01 = c0000001be0dbff0   R17 = c000000000403920

R02 = c0000000006072f8   R18 = 0000000000000000

R03 = 0000000000000000   R19 = 000000000019b000

R04 = c0000000ee11ccc0   R20 = c0000000004c9550

R05 = 0000000000000000   R21 = 00000000020c9550

R06 = c000000000532d00   R22 = 00000000020c97c0

R07 = c0000001be0d81b0   R23 = c0000000004c97c0

R08 = 0000000000000000   R24 = 00000000018bf8d0

R09 = c0000000ee11ccbf   R25 = 0000000000000000

R10 = fffffffffffffffc   R26 = c0000000006a4968

R11 = c000000000532d00   R27 = c0000000006a00b0

R12 = c00000000002a550   R28 = c0000000ee143c98

R13 = c000000000532d00   R29 = c000000000f35b80

R14 = 0000000000000000   R30 = c0000000005b4190

R15 = c0000000004050a0   R31 = c0000000005cf910

pc  = c00000000006c090 .migration_thread+0x64/0x31c

lr  = c00000000008e348 .kthread+0x78/0xc4

msr = 8000000000029032   cr  = 28000024

ctr = c00000000006c02c   xer = 0000000020000004   trap =  700
(gdb) p kthr...
[ message continues ]

hm, that looks pretty nasty. Wondering why the atomic check did not

produce a stacktrace. By the time we get to the migration thread's code

it's probably late and we just get to see the effects of data

corruption.
	Ingo

--

Hi,
The defconfig make fails on x86_64 (AMD box) with following error
  CHK     include/linux/utsrelease.h

  CALL    scripts/checksyscalls.sh

  CHK     include/linux/compile.h

  GEN     .version

  CHK     include/linux/compile.h

  UPD     include/linux/compile.h

  CC      init/version.o

  LD      init/built-in.o

  LD      .tmp_vmlinux1

make: *** [.tmp_vmlinux1] Error 1
# gcc --version

gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-59)
This was reported by Adrian Bunk http://lkml.org/lkml/2007/12/1/39
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

And by myself long before that...

http://lkml.org/lkml/2007/10/1/308
Since then I have had a private report that upgrading libtool would

solve the issue, but I have to admit I'm a bit skeptical, as I don't

quite get how libtool would be involved in the kernel building process

at all.
--

Jean Delvare

--

That's odd.  afacit the only kmalloc in dmi_id_init() is
        dmi_dev = kzalloc(sizeof(*dmi_dev), GFP_KERNEL);
and even gcc-3.2.3 should be able to get that right.
Could you please a) verify that simply removing that line fixes the build

error and then b) try to find some way of fixing it?
Try replacing `sizeof(*dmi_dev)' with `sizeof(struct dmi_device_attribute)'

and any other tricks you can think of to try to make the compiler process

the code differently.
--

removing the line fixes the issue, but changing the sizeof(*dmi_dev) to

sizeof(struct device) is not helping.
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

--

Hi, Andrew,
We tried the following, generated stabs information. The size of struct

device is 560 bytes. We found that dead code was not being eliminated

(__you_cannot_kmalloc_that_much), even though no one called that

function. I suspect builtin_constant_p() and dead code elimination as

the root causes of this error.
--

	Warm Regards,

	Balbir Singh

	Linux Technology Center

	IBM, ISTL

--

On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
sounds like a bad idea; a compile time failure is of course nicer than

a runtime failure for the cases we can find the bug at compile-time already.
We should however investigate using one of the two following gcc function attributes;

they can give the user a lot better diagnostic information than what we have

right now:
error ("message")

    If this attribute is used on a function declaration and a call to

such a function is not eliminated through dead code elimination or

other optimizations, an error which will include message will be

diagnosed. This is useful for compile time checking, especially

together with __builtin_constant_p and inline functions where checking

the inline function arguments is not possible through extern char

[(condition) ? 1 : -1]; tricks. While it is possible to leave the

function undefined and thus invoke a link failure, when using this

attribute the problem will be diagnosed earlier and with exact location

of the call even in presence of inline functions or when not emitting

debugging information.
warning ("message")

    If this attribute is used on a function declaration and a call to

such a function is not eliminated through dead code elimination or

other optimizations, a warning which will include message will be

diagnosed. This is useful for compile time checking, especially

together with __builtin_constant_p and inline functions. While it is

possible to define the function with a message in .gnu.warning*

section, when using this attribute the problem will be diagnosed

earlier and with exact location of the call even in presence of inline

functions or when not emitting debugging information. 
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

There is not much chance of a runtime failure these days since kmalloc now

supports up to 4MB allocs.

--

On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
I think it'd be better to just put suitable workarounds at the offending

callsites.  We've only seen three or four of them in several months.
--

Hi Andrew, hi Chritoph,
Interesting theory... So I tried to split half of the code of

dmi_id_init() to a subfunction and bingo! gcc 3.2.3 is now able to
Here's a workaround for dmi-id.
Subject: Fix for __you_cannot_kmalloc_that_much failure in dmi-id
gcc 3.2 has a hard time coping with the code in dmi_id_init():
make: *** [.tmp_vmlinux1] Error 1
Moving half of the code to a separate function seems to help. This is

a no-op for gcc 4.1 which will successfully inline the code anyway.
Signed-off-by: Jean Delvare <khali@linux-fr.org>

---

 drivers/firmware/dmi-id.c |   19 ++++++++++++++-----

 1 file changed, 14 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc7.orig/drivers/firmware/dmi-id.c	2007-10-24 09:59:28.000000000 +0200

+++ linux-2.6.24-rc7/drivers/firmware/dmi-id.c	2008-01-08 10:32:00.000000000 +0100

@@ -175,12 +175,11 @@ static struct device *dmi_dev;
 extern int dmi_available;
-static int __init dmi_id_init(void)

+/* In a separate function to keep gcc 3.2 happy - do NOT merge this in

+   dmi_id_init! */

+static void __init dmi_id_init_attr_table(void)

 {

-	int ret, i;

-

-	if (!dmi_available)

-		return -ENODEV;

+	int i;
 	/* Not necessarily all DMI fields are available on all

 	 * systems, hence let's built an attribute table of just

@@ -205,6 +204,16 @@ static int __init dmi_id_init(void)

 	ADD_DMI_ATTR(chassis_serial,    DMI_CHASSIS_SERIAL);

 	ADD_DMI_ATTR(chassis_asset_tag, DMI_CHASSIS_ASSET_TAG);

 	sys_dmi_attributes[i++] = &sys_dmi_modalias_attr.attr;

+}

+

+static int __init dmi_id_init(void)

+{

+	int ret;

+

+	if (!dmi_available)

+		return -ENODEV;

+

+	dmi_id_init_attr_table();
 	ret = class_register(&dmi_class);

 	if (ret)
I'll now check if I can do something similar for snd-mixer-oss.
--

Jean Delvare

--

And here you go, this is a unified patch fixing both bugs. The dmi-id

part is unchanged. Testers and reviewers are welcome.
* * * * *
gcc 3.2 has a hard time coping with the code in dmi_id_init():
make: *** [.tmp_vmlinux1] Error 1
Moving half of the code to a separate function seems to help. This is

a no-op for gcc 4.1 which will successfully inline the code anyway.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
A similar problem has been reported in snd_mixer_oss_build_input(),

fix it as well.
Signed-off-by: Jean Delvare <khali@linux-fr.org>

Cc: Dave Airlie <airlied@linux.ie>

---

 drivers/firmware/dmi-id.c  |   17 +++++--

 sound/core/oss/mixer_oss.c |  101 +++++++++++++++++++++++++++-----------------

 2 files changed, 75 insertions(+), 43 deletions(-)
--- linux-2.6.24-rc7.orig/drivers/firmware/dmi-id.c	2008-01-08 12:57:48.000000000 +0100

+++ linux-2.6.24-rc7/drivers/firmware/dmi-id.c	2008-01-08 13:06:15.000000000 +0100

@@ -175,12 +175,9 @@ static struct device *dmi_dev;
 extern int dmi_available;
-static int __init dmi_id_init(void)

+static void __init dmi_id_init_attr_table(void)

 {

-	int ret, i;

-

-	if (!dmi_available)

-		return -ENODEV;

+	int i;
 	/* Not necessarily all DMI fields are available on all

 	 * systems, hence let's built an attribute table of just

@@ -205,6 +202,16 @@ static int __init dmi_id_init(void)

 	ADD_DMI_ATTR(chassis_serial,    DMI_CHASSIS_SERIAL);

 	ADD_DMI_ATTR(chassis_asset_tag, DMI_CHASSIS_ASSET_TAG);

 	sys_dmi_attributes[i++] = &sys_dmi_modalias_attr.attr;

+}

+

+static int __init dmi_id_init(void)

+{

+	int ret;

+

+	if (!dmi_available)

+		return -ENODEV;

+

+	dmi_id_init_attr_table();
 	ret = class_register(&dmi_class);

 	if (ret)

--- linux-2.6.24-rc7.orig/sound/core/oss/mixer_oss.c	2008-01-08 12:57:48.000000000 +0100

+++ linux-2.6.24-rc7/sound/core/oss/mixer_oss.c	2008-01-08 13:21:12.000000000 +0100

@@ -925,6 +925,68 @@ static void mixer_slot_clear(struct snd_

 	rslot-&g...
[ message continues ]

Hi Jean,
Thank you, I have tested the patch, it fixes the build failure.
 Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

 Signed-off-by: Jean Delvare <khali@linux-fr.org>

 ---

 drivers/firmware/dmi-id.c |   19 ++++++++++++++-----

 1 file changed, 14 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc7.orig/drivers/firmware/dmi-id.c	2007-10-24 09:59:28.000000000 +0200

+++ linux-2.6.24-rc7/drivers/firmware/dmi-id.c	2008-01-08 10:32:00.000000000 +0100

@@ -175,12 +175,11 @@ static struct device *dmi_dev;
 extern int dmi_available;
-static int __init dmi_id_init(void)

+/* In a separate function to keep gcc 3.2 happy - do NOT merge this in

+   dmi_id_init! */

+static void __init dmi_id_init_attr_table(void)

 {

-	int ret, i;

-

-	if (!dmi_available)

-		return -ENODEV;

+	int i;
 	/* Not necessarily all DMI fields are available on all

 	 * systems, hence let's built an attribute table of just

@@ -205,6 +204,16 @@ static int __init dmi_id_init(void)

 	ADD_DMI_ATTR(chassis_serial,    DMI_CHASSIS_SERIAL);

 	ADD_DMI_ATTR(chassis_asset_tag, DMI_CHASSIS_ASSET_TAG);

 	sys_dmi_attributes[i++] = &sys_dmi_modalias_attr.attr;

+}

+

+static int __init dmi_id_init(void)

+{

+	int ret;

+

+	if (!dmi_available)

+		return -ENODEV;

+

+	dmi_id_init_attr_table();
 	ret = class_register(&dmi_class);

 	if (ret)
I'll now check if I can do something similar for snd-mixer-oss.
--

Jean Delvare

--

Hi,
The make allyesconfig build fails on x86_64 (AMD box) with the following

error
  CHK     include/linux/version.h

  CHK     include/linux/utsrelease.h

  CALL    scripts/checksyscalls.sh

  CHK     include/linux/compile.h

  CHK     include/linux/version.h

make[2]: `scripts/unifdef' is up to date.

make[2]: *** No rule to make target `|', needed by `asm-generic'.  Stop.

make[1]: *** [headers_install] Error 2

make: *** [vmlinux] Error 2
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

--

Which make version are you using - it looks like a make bug.

Did this occur with an older kernel or has this behaviour just started?
To get further you can disable "headers check" in kernel hacking menu

but we need to find out why it fails for you.
Note: '|' is used to say that a prerequisite is 'order only' in

scripts/Makefile.headersinst
	Sam

--

Hi Sam,
After disabling the headers_check, the build failure is not seen,

i tried compiling 2.6.24-rc{2,3,4,5,6,7} all of these have this failure.

And when i tried compiling 2.6.23 with allyesconfig i got the following

error
  SYSCALL arch/x86_64/vdso/vdso.so

/usr/bin/ld: section .data [ffffffffff700900 -> ffffffffff700917] overlaps section .plt [ffffffffff7008e4 -> ffffffffff700903]

collect2: ld returned 1 exit status

make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1

make: *** [arch/x86_64/vdso] Error 2
# make --version

GNU Make version 3.79.1
# ld -v

GNU ld version 2.14.90.0.4 20030523
# gcc --version

gcc (GCC) 3.2.3 20030502 
let me know if, i could help you with more information.

--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

--

The "orders only" facility were added in GNU make 3.80 so that explains the

bug you see in first place.

We should try to avoid this use since we do not require make 3.80 yet.
	Sam

--

Linus Torvalds wrote:

..
We're still missing the sata_qstor regression fix from Tejun,

and the patch from Venkatesh Pallipadi that reinstates max_cstate

in sysfs for !CPU_IDLE.
Cheers
--

I'm not seeing those in my inbox. I don't go out trolling for patches,

because I expect that if the author of the patch really wants me to apply

it, he'd send it upstream.
But I know a number of people are on vacation, and I suspect some of these

fixes are just queued up, waiting for that.  E.g. I think Jeff is supposed

to be back this week, etc..
			Linus

--

Hello,
Yeap, I have two patches pending for #upstream-fixes.
http://article.gmane.org/gmane.linux.ide/26750

http://article.gmane.org/gmane.linux.ide/26822
Jeff, can you ack those?
Thanks.
--

tejun

--