2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Mike Galbraith]

Greetings,

As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...

-[pid  8191] lstat64("/sys/class/net/eth1", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
-[pid  8191] lstat64("/sys/block/eth1", 0xafec0f9c) = -1 ENOENT (No such file or directory)

...and wandered off into lala-land.

It used to do...

+[pid  8905] lstat64("/sys/class/net/eth1", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
+[pid  8905] readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:09.0", 255) = 53
+[pid  8905] readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:09.0", 255) = 53

...and made working network interface.

	-Mike

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Mike Galbraith]

On Sun, 2006-07-09 at 20:22 +0200, Mike Galbraith wrote:
> Greetings,
> 
> As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
> 
> -[pid  8191] lstat64("/sys/class/net/eth1", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
> -[pid  8191] lstat64("/sys/block/eth1", 0xafec0f9c) = -1 ENOENT (No such file or directory)

Slight correction:  it's /sbin/getcfg that did the above, resulting in
ipup failing.

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Andrew Morton]

On Sun, 09 Jul 2006 20:22:09 +0200
Mike Galbraith <efault@gmx.de> wrote:

> Greetings,
> 
> As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
> 
> -[pid  8191] lstat64("/sys/class/net/eth1", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
> -[pid  8191] lstat64("/sys/block/eth1", 0xafec0f9c) = -1 ENOENT (No such file or directory)
> 
> ...and wandered off into lala-land.

Well that's amusing.  Ethernet-over-scsi?

> It used to do...
> 
> +[pid  8905] lstat64("/sys/class/net/eth1", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> +[pid  8905] readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:09.0", 255) = 53
> +[pid  8905] readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:09.0", 255) = 53
> 
> ...and made working network interface.
> 

I'd be suspecting
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.

If you could do a `patch -R' of that one it'd really help, thanks.

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On 09.07.2006 23:00, Andrew Morton wrote:

> On Sun, 09 Jul 2006 20:22:09 +0200
> Mike Galbraith <efault@gmx.de> wrote:
> 
>>As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...

Same here.

> I'd be suspecting
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
> 
> If you could do a `patch -R' of that one it'd really help, thanks.

Tried that, but failed with:

  LD      .tmp_vmlinux1
net/built-in.o: In function `dev_change_name':
: undefined reference to `class_device_rename'

Not sure whether that's an unclean patch reversal because of conflicts
with other patches (had a few "fuzz" and "offset" messages during the
patch -R), will have a look tomorrow.

HTH
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Stuttgart ist viel schöner als Berlin!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Andrew Morton]

On Mon, 10 Jul 2006 00:57:23 +0200
Tilman Schmidt <tilman@imap.cc> wrote:

> On 09.07.2006 23:00, Andrew Morton wrote:
> 
> > On Sun, 09 Jul 2006 20:22:09 +0200
> > Mike Galbraith <efault@gmx.de> wrote:
> > 
> >>As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
> 
> Same here.
> 
> > I'd be suspecting
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
> > 
> > If you could do a `patch -R' of that one it'd really help, thanks.
> 
> Tried that, but failed with:
> 
>   LD      .tmp_vmlinux1
> net/built-in.o: In function `dev_change_name':
> : undefined reference to `class_device_rename'
> 
> Not sure whether that's an unclean patch reversal because of conflicts
> with other patches (had a few "fuzz" and "offset" messages during the
> patch -R), will have a look tomorrow.
> 

drat, you'll also need to revert
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-class_device_rename-remove.patch

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[David Miller]

From: Andrew Morton <akpm@osdl.org>
Date: Sun, 9 Jul 2006 13:51:48 -0700

 ...
> > As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
 ...
> I'd be suspecting
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.

Oh well, it means we can't apply that patch as it does break
things.

Greg, do you test on SuSE installations? :-)

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> I'd be suspecting
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
>
> If you could do a `patch -R' of that one it'd really help, thanks.
This broke gnome NetworkManager as well.  Reverting the two patches 
makes it happy.

    J

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Mike Galbraith]

On Sun, 2006-07-09 at 13:51 -0700, Andrew Morton wrote:

> I'd be suspecting
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.

Yeah, that and gregkh-driver-class_device_rename-remove.patch brought it
back to reality.

	-Mike

2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Mike Galbraith]

Greetings,

While trying to figure out what happened to break suspend to disk on my
box, and booting between various other kernels to compare messages, I
accidentally captured the following during shutdown.  I have no idea if
failed suspends have anything to do with it, but it may, because I
haven't had this happen in any other circumstance.  I'm making a rash
presumption that the two or three other times the box has died on
shutdown (without serial console being connected) were the same.

kernel BUG at <bad filename>:45803! <-- what goeth on here.  it's slab.c:1542
invalid opcode: 0000 [#1]
PREEMPT SMP 
Modules linked in: ohci1394 prism54 xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec edd snd_ac97_bus snd_pcm snd_timer ieee1394 saa7134 snd soundcore ir_kbd_i2c bt878 snd_page_alloc i2c_i801 ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables tuner bttv video_buf firmware_class ir_common btcx_risc tveeprom sd_mod nls_iso8859_1 nls_cp437 nls_utf8
CPU:    1
EIP:    0060:[<b1068d9f>]    Not tainted VLI
EFLAGS: 00010046   (2.6.18-rc1-smp #163) 
EIP is at kmem_freepages+0xa1/0xa5
eax: 80040000   ebx: b18327e0   ecx: fffffff8   edx: 00000000
esi: 00000001   edi: dfeacbc0   ebp: b23cddbc   esp: b23cddac
ds: 007b   es: 007b   ss: 0068
Process umount (pid: 11083, ti=b23cd000 task=dffa4aa0 task.ti=b23cd000)
Stack: bfebfbfd dfeacbc0 b1594000 b1594000 b23cddd4 b1069002 bfebfbfd dfec36a4 
       b1594000 dfeacbc0 b23cddf8 b106914d 00000000 0000001b dfea22d8 00000019 
       ef2de7bc dfeacbc0 dfec36a4 b23cde34 b1068e29 00000000 dfea22c0 dfea22d8 
Call Trace:
 [<b1069002>] slab_destroy+0x53/0x95
 [<b106914d>] free_block+0x109/0x128
 [<b1068e29>] __cache_free+0x86/0x10d
 [<b1068f6f>] kmem_cache_free+0x37/0x4a
 [<b1068655>] shmem_destroy_inode+0x10/0x12
 [<b108579c>] destroy_inode+0x31/0x47
 [<b1085b17>] generic_delete_inode+0xcb/0x11c
 [<b108552f>] iput+0x5f/0x66
 [<b108389e>] dentry_iput+0x6b/0xb1
 [<b1084490>] prune_one_dentry+0x57/0x7a
 [<b10846f6>] prune_dcache+0x144/0x157
 [<b10847fc>] shrink_dcache_parent+0xb4/0xe8
 [<b107399b>] generic_shutdown_super+0x27/0x131
 [<b1073ae9>] kill_anon_super+0x12/0x35
 [<b1073b25>] kill_litter_super+0x19/0x1c
 [<b1073b85>] deactivate_super+0x5d/0x6f
 [<b10883d6>] mntput_no_expire+0x44/0x74
 [<b1079f9f>] path_release_on_umount+0x15/0x18
 [<b108948c>] sys_umount+0x3b/0x265
 [<b10896cf>] sys_oldumount+0x19/0x1b
 [<b10030b7>] syscall_call+0x7/0xb
 [<a7e8d73d>] 0xa7e8d73d
Code: 30 8b 57 3c 8b 45 f0 e8 d5 ac fe ff f6 47 36 02 74 11 8b 4f 3c b8 01 00 00 00 d3 e0 f0 29 05 14 ad 5f b1 83 c4 04 5b 5e 5f 5d c3 <0f> 0b eb b2 55 89 e5 57 56 53 83 ec 28 89 c6 89 d3 89 e0 25 00 
EIP: [<b1068d9f>] kmem_freepages+0xa1/0xa5 SS:ESP 0068:b23cddac

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Pekka Enberg]

On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> While trying to figure out what happened to break suspend to disk on my
> box, and booting between various other kernels to compare messages, I
> accidentally captured the following during shutdown.  I have no idea if
> failed suspends have anything to do with it, but it may, because I
> haven't had this happen in any other circumstance.  I'm making a rash
> presumption that the two or three other times the box has died on
> shutdown (without serial console being connected) were the same.

[snip]

> kernel BUG at <bad filename>:45803! <-- what goeth on here.  it's slab.c:1542

Looks as if kernel text is messed up.

> Code: 30 8b 57 3c 8b 45 f0 e8 d5 ac fe ff f6 47 36 02 74 11 8b 4f 3c b8 01 00 00 00 d3 e0 f0 29 05 14 ad 5f b1 83 c4 04 5b 5e 5f 5d c3 <0f> 0b eb b2 55 89 e5 57 56 53 83 ec 28 89 c6 89 d3 89 e0 25 00

See how ud2a comes after ret which doesn't match what GCC generates
for me at least. Furthermore, the BUG() line number is messed up (eb
b2). So doesn't look like a slab bug to me.

                                                    Pekka

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Mike Galbraith]

On Mon, 2006-07-10 at 11:42 +0300, Pekka Enberg wrote:
> On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> > While trying to figure out what happened to break suspend to disk on my
> > box, and booting between various other kernels to compare messages, I
> > accidentally captured the following during shutdown.  I have no idea if
> > failed suspends have anything to do with it, but it may, because I
> > haven't had this happen in any other circumstance.  I'm making a rash
> > presumption that the two or three other times the box has died on
> > shutdown (without serial console being connected) were the same.
> 
> [snip]
> 
> > kernel BUG at <bad filename>:45803! <-- what goeth on here.  it's slab.c:1542
> 
> Looks as if kernel text is messed up.
> 
> > Code: 30 8b 57 3c 8b 45 f0 e8 d5 ac fe ff f6 47 36 02 74 11 8b 4f 3c b8 01 00 00 00 d3 e0 f0 29 05 14 ad 5f b1 83 c4 04 5b 5e 5f 5d c3 <0f> 0b eb b2 55 89 e5 57 56 53 83 ec 28 89 c6 89 d3 89 e0 25 00
> 
> See how ud2a comes after ret which doesn't match what GCC generates
> for me at least. Furthermore, the BUG() line number is messed up (eb
> b2). So doesn't look like a slab bug to me.

Hm.  I've never _noticed_ gcc putting anything out there before.  This
is gcc version 4.1.2 20060531 (prerelease) (SUSE Linux).

000002ee <kmem_freepages>:
     2ee:	55                   	push   %ebp
     2ef:	89 e5                	mov    %esp,%ebp
     2f1:	57                   	push   %edi
     2f2:	56                   	push   %esi
     2f3:	53                   	push   %ebx
     2f4:	83 ec 04             	sub    $0x4,%esp
     2f7:	89 c7                	mov    %eax,%edi
     2f9:	89 55 f0             	mov    %edx,0xfffffff0(%ebp)
     2fc:	8b 48 3c             	mov    0x3c(%eax),%ecx
     2ff:	be 01 00 00 00       	mov    $0x1,%esi
     304:	d3 e6                	shl    %cl,%esi
     306:	89 d3                	mov    %edx,%ebx
     308:	81 c3 00 00 00 50    	add    $0x50000000,%ebx
     30e:	c1 eb 0c             	shr    $0xc,%ebx
     311:	c1 e3 05             	shl    $0x5,%ebx
     314:	03 1d 00 00 00 00    	add    0x0,%ebx
     31a:	8b 03                	mov    (%ebx),%eax
     31c:	89 f1                	mov    %esi,%ecx
     31e:	f7 d9                	neg    %ecx
     320:	c1 e8 1e             	shr    $0x1e,%eax
     323:	8b 04 85 00 00 00 00 	mov    0x0(,%eax,4),%eax
     32a:	ba 03 00 00 00       	mov    $0x3,%edx
     32f:	e8 fc ff ff ff       	call   330 <kmem_freepages+0x42>
     334:	85 f6                	test   %esi,%esi
     336:	74 18                	je     350 <kmem_freepages+0x62>
     338:	31 d2                	xor    %edx,%edx
     33a:	eb 03                	jmp    33f <kmem_freepages+0x51>
     33c:	83 c3 20             	add    $0x20,%ebx
     33f:	8b 03                	mov    (%ebx),%eax
     341:	84 c0                	test   %al,%al
     343:	79 4a                	jns    38f <kmem_freepages+0xa1>  <===
     345:	0f ba 33 07          	btrl   $0x7,(%ebx)
     349:	83 c2 01             	add    $0x1,%edx
     34c:	39 d6                	cmp    %edx,%esi
     34e:	75 ec                	jne    33c <kmem_freepages+0x4e>
     350:	89 e0                	mov    %esp,%eax
     352:	25 00 f0 ff ff       	and    $0xfffff000,%eax
     357:	8b 00                	mov    (%eax),%eax
     359:	8b 80 dc 04 00 00    	mov    0x4dc(%eax),%eax
     35f:	85 c0                	test   %eax,%eax
     361:	74 02                	je     365 <kmem_freepages+0x77>
     363:	01 30                	add    %esi,(%eax)
     365:	8b 57 3c             	mov    0x3c(%edi),%edx
     368:	8b 45 f0             	mov    0xfffffff0(%ebp),%eax
     36b:	e8 fc ff ff ff       	call   36c <kmem_freepages+0x7e>
     370:	f6 47 36 02          	testb  $0x2,0x36(%edi)
     374:	74 11                	je     387 <kmem_freepages+0x99>
     376:	8b 4f 3c             	mov    0x3c(%edi),%ecx
     379:	b8 01 00 00 00       	mov    $0x1,%eax
     37e:	d3 e0                	shl    %cl,%eax
     380:	f0 29 05 00 00 00 00 	lock sub %eax,0x0
     387:	83 c4 04             	add    $0x4,%esp
     38a:	5b                   	pop    %ebx
     38b:	5e                   	pop    %esi
     38c:	5f                   	pop    %edi
     38d:	5d                   	pop    %ebp
     38e:	c3                   	ret    
     38f:	0f 0b                	ud2a   
     391:	eb b2                	jmp    345 <kmem_freepages+0x57>

00000393 <__cache_free>:

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Pekka Enberg]

On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> Hm.  I've never _noticed_ gcc putting anything out there before.  This
> is gcc version 4.1.2 20060531 (prerelease) (SUSE Linux).

[snip]

Curious... GCC cuts line and file information after ud2a. Looking at
your stack trace, I am wondering who calls free_block() as we don't
see cache_flusharray() in the trace. Do you have CONFIG_NUMA enabled?

                                                    Pekka

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Mike Galbraith]

On Mon, 2006-07-10 at 13:33 +0300, Pekka Enberg wrote:
> On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> > Hm.  I've never _noticed_ gcc putting anything out there before.  This
> > is gcc version 4.1.2 20060531 (prerelease) (SUSE Linux).
> 
> [snip]
> 
> Curious... GCC cuts line and file information after ud2a. Looking at
> your stack trace, I am wondering who calls free_block() as we don't
> see cache_flusharray() in the trace. Do you have CONFIG_NUMA enabled?

Nope.

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Mike Galbraith]

On Mon, 2006-07-10 at 13:33 +0300, Pekka Enberg wrote:
> On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> > Hm.  I've never _noticed_ gcc putting anything out there before.  This
> > is gcc version 4.1.2 20060531 (prerelease) (SUSE Linux).
> 
> [snip]
> 
> Curious... GCC cuts line and file information after ud2a. Looking at
> your stack trace, I am wondering who calls free_block() as we don't
> see cache_flusharray() in the trace. Do you have CONFIG_NUMA enabled?

(gdb) list *__cache_free+0x86
0xb1068e39 is in __cache_free (slab.c:3152).
3147                            shared_array->avail += batchcount;
3148                            goto free_done;
3149                    }
3150            }
3151
3152            free_block(cachep, ac->entry, batchcount, node);
3153    free_done:
3154    #if STATS
3155            {
3156                    int i = 0;
(gdb)

It got inlined.

	-Mike

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Pekka Enberg]

On Mon, 2006-07-10 at 13:33 +0300, Pekka Enberg wrote:
> > Curious... GCC cuts line and file information after ud2a. Looking at
> > your stack trace, I am wondering who calls free_block() as we don't
> > see cache_flusharray() in the trace. Do you have CONFIG_NUMA enabled?

On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> It got inlined.

Right. Can't spot anything obviously wrong with the code. Try
CONFIG_DEBUG_SLAB if you can reproduce it.

                              Pekka

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On 10.07.2006 01:17, Andrew Morton wrote:

>>>I'd be suspecting
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
> [...] you'll also need to revert
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-class_device_rename-remove.patch

Ok, that helped. With these two reverted, my eth0 interface comes up
again as it should.

Thanks
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Stuttgart ist viel schöner als Berlin!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Greg KH]

On Sun, Jul 09, 2006 at 05:32:12PM -0700, David Miller wrote:
> From: Andrew Morton <akpm@osdl.org>
> Date: Sun, 9 Jul 2006 13:51:48 -0700
> 
>  ...
> > > As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
>  ...
> > I'd be suspecting
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
> 
> Oh well, it means we can't apply that patch as it does break
> things.

Ugh, that stinks.  I'll work on fixing up those helper applications so
this doesn't happen, and try to get an update into the 10.1 pipeline

So, I guess I'll just carry this forward for the next 6 months or so
till SuSE 10.0 support goes away.

> Greg, do you test on SuSE installations? :-)

Heh, most of the time yes, but this stuff only on a Gentoo box for some
reason.  Sorry about that.

thanks,

greg k-h

Re: 2.6.18-rc1-mm1: /sys/class/net/ethN becoming symlink befuddled /sbin/ifup

[Kay Sievers]

On Tue, 2006-07-11 at 15:59 -0700, Greg KH wrote:
> On Sun, Jul 09, 2006 at 05:32:12PM -0700, David Miller wrote:
> > From: Andrew Morton <akpm@osdl.org>
> > Date: Sun, 9 Jul 2006 13:51:48 -0700
> > 
> >  ...
> > > > As $subject says, up-to-date SuSE 10.0 /sbin/ifup became confused...
> >  ...
> > > I'd be suspecting
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/broken-out/gregkh-driver-network-class_device-to-device.patch.
> > 
> > Oh well, it means we can't apply that patch as it does break
> > things.
> 
> Ugh, that stinks.  I'll work on fixing up those helper applications so
> this doesn't happen, and try to get an update into the 10.1 pipeline
> 
> So, I guess I'll just carry this forward for the next 6 months or so
> till SuSE 10.0 support goes away.

Looks like an old version of libsysfs (1.3) is used and causes this
failure.

Kay

Re: 2.6.18-rc1: slab BUG_ON(!PageSlab(page)) upon umount after failed suspend

[Mike Galbraith]

On Mon, 2006-07-10 at 14:40 +0300, Pekka Enberg wrote:
> On Mon, 2006-07-10 at 13:33 +0300, Pekka Enberg wrote:
> > > Curious... GCC cuts line and file information after ud2a. Looking at
> > > your stack trace, I am wondering who calls free_block() as we don't
> > > see cache_flusharray() in the trace. Do you have CONFIG_NUMA enabled?
> 
> On 7/10/06, Mike Galbraith <efault@gmx.de> wrote:
> > It got inlined.
> 
> Right. Can't spot anything obviously wrong with the code. Try
> CONFIG_DEBUG_SLAB if you can reproduce it.

I reproduced it, but got no info from CONFIG_DEBUG_SLAB, because it
didn't get that far.

BUG: unable to handle kernel paging request at virtual address 6c657472
 printing eip:
b108558c
*pde = 00000000
Oops: 0002 [#1]
PREEMPT SMP 
Modules linked in: ohci1394 prism54 xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device saa7134 ieee1394 edd ir_kbd_i2c snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore i2c_i801 bt878 snd_page_alloc ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables tuner bttv video_buf firmware_class ir_common btcx_risc tveeprom sd_mod nls_iso8859_1 nls_cp437 nls_utf8
CPU:    1
EIP:    0060:[<b108558c>]    Not tainted VLI
EFLAGS: 00010202   (2.6.18-rc1-smp #1) 
EIP is at prune_one_dentry+0x23/0x7a
eax: 6c65746e   ebx: b15b611c   ecx: b15b6130   edx: b22390ec
esi: b15aa720   edi: ef660d84   ebp: ebb30e9c   esp: ebb30e94
ds: 007b   es: 007b   ss: 0068
Process umount (pid: 29772, ti=ebb30000 task=ea87eaa0 task.ti=ebb30000)
Stack: b15b611c b15aa720 ebb30eb8 b1085826 b15b6124 00000375 ef04daf0 b15aa720 
       b15aa6e4 ebb30ed8 b108592c b15aa720 b15aa6e4 0000038f ef660d84 b15aa6e4 
       b148a740 ebb30ef4 b1074acb 00000000 cfb90000 0000000f b148a720 ebb30f4c 
Call Trace:
 [<b1085826>] prune_dcache+0x144/0x157
 [<b108592c>] shrink_dcache_parent+0xb4/0xe8
 [<b1074acb>] generic_shutdown_super+0x27/0x131
 [<b1074c19>] kill_anon_super+0x12/0x35
 [<b1074c55>] kill_litter_super+0x19/0x1c
 [<b1074cb5>] deactivate_super+0x5d/0x6f
 [<b1089506>] mntput_no_expire+0x44/0x74
 [<b107b0cf>] path_release_on_umount+0x15/0x18
 [<b108a5bc>] sys_umount+0x3b/0x265
 [<b108a7ff>] sys_oldumount+0x19/0x1b
 [<b10030b7>] syscall_call+0x7/0xb
 [<a7f3f73d>] 0xa7f3f73d
Code: fe ff ff 89 d8 5b 5d c3 55 89 e5 56 53 89 c3 8b 40 04 a8 10 75 1f 83 c8 10 89 43 04 8d 4b 14 8b 43 14 8b 51 04 89 02 85 c0 74 03 <89> 50 04 c7 41 04 00 02 20 00 8d 4b 34 8b 53 34 8b 41 04 89 42 
EIP: [<b108558c>] prune_one_dentry+0x23/0x7a SS:ESP 0068:ebb30e94

(gdb) list *prune_one_dentry+0x23
0xb108558c is in prune_one_dentry (list.h:614).
609     {
610             struct hlist_node *next = n->next;
611             struct hlist_node **pprev = n->pprev;
612             *pprev = next;
613             if (next)
614                     next->pprev = pprev;
615     }
616
617     static inline void hlist_del(struct hlist_node *n)
618     {
(gdb) list *prune_dcache+0x144
0xb1085826 is in prune_dcache (dcache.c:457).
452                     /*
453                      * If this dentry is for "my" filesystem, then I can prune it
454                      * without taking the s_umount lock (I already hold it).
455                      */
456                     if (sb && dentry->d_sb == sb) {
457                             prune_one_dentry(dentry);
458                             continue;
459                     }
460                     /*
461                      * ...otherwise we need to be sure this filesystem isn't being
(gdb)