Re: ALSA problems: sound lockup, modules, 2.5.70

Re: ALSA problems: sound lockup, modules, 2.5.70

[Olivier NICOLAS]

Kernel: 2.5.70

Soundcard uses  snd-intel8x0


On module load

intel8x0: clocking to 48000
Slab corruption: start=deda495c, expend=deda4ad3, problemat=deda4a9c
Last user: [<c018e47d>](proc_destroy_inode+0x1d/0x20)
Data:
********************************************************************************************************************************************************************************************************************************************************************************************************************************AC 

36 96 DE ***************************************************A5
Next: 71 F0 2C .7D E4 18 C0 A5 C2 0F 17 B0 E6 AD DF 0C 00 00 00 A0 34
19
C0 00 00 00 00 00 00 00 00
slab error in check_poison_obj(): cache `proc_inode_cache': object was
modified after freeing
Call Trace:
   [<c0142237>] check_poison_obj+0x147/0x1b0
   [<c0143f2c>] kmem_cache_alloc+0x14c/0x180
   [<c018e40c>] proc_alloc_inode+0x1c/0x70
   [<c018e40c>] proc_alloc_inode+0x1c/0x70
   [<c0178cbe>] alloc_inode+0x1e/0x160
   [<c0178cbe>] alloc_inode+0x1e/0x160
   [<c01798bb>] new_inode+0x1b/0xd0
   [<c019054c>] proc_pid_make_inode+0x9c/0xe0
   [<c01904d0>] proc_pid_make_inode+0x20/0xe0
   [<c0143f2c>] kmem_cache_alloc+0x14c/0x180
   [<c0190a17>] proc_lookupfd+0x57/0x270
   [<c016bc5c>] real_lookup+0xdc/0x110
   [<c016c10b>] do_lookup+0x8b/0xa0
   [<c016c589>] link_path_walk+0x469/0x6a0
   [<c016ccde>] __user_walk+0x3e/0x60
   [<c01678fa>] sys_readlink+0x2a/0x90
   [<c015b1f6>] sys_open+0x76/0x90
   [<c01097f3>] syscall_call+0x7/0xb




On module unload

Unable to handle kernel paging request at virtual address 6b6b6b6b
   printing eip:
c0166e55
*pde = 00000000
Oops: 0002 [#1]
CPU:    0
EIP:    0060:[<c0166e55>]    Not tainted
EFLAGS: 00210202
EIP is at cdev_purge+0x35/0xb0
eax: 6b6b6b6b   ebx: c17cdc84   ecx: cb1f2ad8   edx: 6b6b6b6b
esi: c17cdc4c   edi: 00000000   ebp: d65c3f14   esp: d65c3efc
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 1828, threadinfo=d65c2000 task=d71572d0)
Stack: c0349060 00200286 c17cdc4c 00000000 c17cdc4c c0341298 d65c3f24
c0167162
         c17cdc4c c0342fe0 d65c3f34 c01f3425 c17cdc4c def25bd4 d65c3f4c
c0166a4f
         c17cdc4c 00000000 00000100 e0a10880 d65c3f5c e0a0ba99 00000074
e0a0be6a
Call Trace:
   [<c0167162>] cdev_dynamic_release+0x12/0x20
   [<c01f3425>] kobject_cleanup+0x45/0x50
   [<c0166a4f>] unregister_chrdev+0x5f/0x70
   [<e0a10880>] +0x0/0x180 [snd]
   [<e0a0ba99>] alsa_sound_exit+0x39/0x60 [snd]
   [<e0a0be6a>] +0x8b/0x41d [snd]
   [<c01388bf>] sys_delete_module+0x14f/0x180
   [<e0a10880>] +0x0/0x180 [snd]
   [<c014eb44>] sys_munmap+0x54/0x70

[PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[viro]

	Argh.  Missing initialization in char_dev.c - it's definitely
responsible for crap on unload.  Load side appears to be something else,
though...

--- C70/fs/char_dev.c	Mon May 26 22:21:39 2003
+++ linux/fs/char_dev.c	Tue May 27 14:48:53 2003
@@ -89,6 +89,8 @@
 	if (cd == NULL)
 		return ERR_PTR(-ENOMEM);
 
+	memset(cd, 0, sizeof(struct char_device_struct));
+
 	write_lock_irq(&chrdevs_lock);
 
 	/* temporary */

Re: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Stian Jordet]

tir, 27.05.2003 kl. 20.51 skrev viro@parcelfarce.linux.theplanet.co.uk:
> 	Argh.  Missing initialization in char_dev.c - it's definitely
> responsible for crap on unload.  Load side appears to be something else,
> though...

This did not fix my problem. When I unload one ALSA-modules after the
other, the system hangs when I come to the "snd" module. No oops or
panic, it just freezes. Other than that, ALSA works fine for me, just
frustrating when I reboot.

Best regards,
Stian

Re: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Ivan Gyurdiev]

Sorry for thread - not subscribed.

I solved all of my modules problems and every single one of them was my fault, 
combined with a minimalistic modprobe.conf syntax (no aliases to aliases? ) 
and devfs.

Lockups, however, are still there, and the patch did not help.
Here's some straces:

XMMS freezes on the following system call (attempt to stop a playing mp3):

gettimeofday({1054069621, 452855}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}, {fd=5, events=POLLIN}], 2, 9) = 1
gettimeofday({1054069621, 456248}, NULL) = 0
ioctl(3, FIONREAD, [32])                = 0
read(3, "\5\1\352\20\312V-\0\256\0\0\0\32\0\340\0\0\0\0\0n\0\226"..., 32) = 32
write(3, "\33\0\2\0\0\0\0\0+ \1\0", 12) = 12
read(3, "\1\2\354\20\0\0\0\0\32\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
write(3, ">\0\7\0\207\0\340\0\30\0\340\0005\0\340\0\0\0\0\0\0\0\0"..., 992) = 
992
read(3, "\1\2\23\21\0\0\0\0\32\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0p"..., 32) = 32
uname({sys="Linux", node="cobra", ...}) = 0
futex(0x42cb2e18, FUTEX_WAIT, 3882, NULL
\

XINE freezes on startup, and here's the beginning of a repeating sequence 
that says Timeout.

ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 1 (in [3], left {0, 28000})
ioctl(3, FIONREAD, [32])                = 0
read(3, "\10\3\252\v\333\2100\0\256\0\0\0\16\0\340\0\0\0\0\0\21"..., 32) = 32
ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 1 (in [3], left {0, 3000})
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, NULL)   = 0
futex(0x811a9b0, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, {144394552, 135234584}) = 0
ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 0 (Timeout)
ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 1 (in [3], left {0, 16000})
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, NULL)   = 0
futex(0x811a9b0, FUTEX_WAIT, 3, NULL)   = 0
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, {144394552, 135234584}) = 0
ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 0 (Timeout)
ioctl(3, FIONREAD, [0])                 = 0
select(4, [3], NULL, NULL, {0, 33000})  = 1 (in [3], left {0, 16000})
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, NULL)   = 0
futex(0x811a9b0, FUTEX_WAIT, 4, NULL)   = 0
futex(0x811a9d8, FUTEX_WAIT, 2, NULL)   = 0
futex(0x811a9d8, FUTEX_WAKE, 1, {144394552, 135234584}) = 0

is this info useful at all?

RE: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Downing, Thomas]

-----Original Message-----
From: Stian Jordet [mailto:liste@jordet.nu]
>
> tir, 27.05.2003 kl. 20.51 skrev viro@parcelfarce.linux.theplanet.co.uk:
>> 	Argh.  Missing initialization in char_dev.c - it's definitely
>> responsible for crap on unload.  Load side appears to be something >else,
>> though...
>
> This did not fix my problem. When I unload one ALSA-modules after the
> other, the system hangs when I come to the "snd" module. No oops or
> panic, it just freezes. Other than that, ALSA works fine for me, just
> frustrating when I reboot.
>
> Best regards,
> Stian

For what it's worth, maybe as a point to start to look for differences...

I am running 2.5.70-mm1, with snd-intel8x0 module.  Also SMP on Xeon P4
(2up), Intel chipset.  I am not having any problems with unloading snd.

So maybe the difference is between -mm1 and (IIRC) -bk1.

RE: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Stian Jordet]

ons, 28.05.2003 kl. 14.55 skrev Downing, Thomas:
> -----Original Message-----
> From: Stian Jordet [mailto:liste@jordet.nu]
> >
> > tir, 27.05.2003 kl. 20.51 skrev viro@parcelfarce.linux.theplanet.co.uk:
> >> 	Argh.  Missing initialization in char_dev.c - it's definitely
> >> responsible for crap on unload.  Load side appears to be something >else,
> >> though...
> >
> > This did not fix my problem. When I unload one ALSA-modules after the
> > other, the system hangs when I come to the "snd" module. No oops or
> > panic, it just freezes. Other than that, ALSA works fine for me, just
> > frustrating when I reboot.
> >
> > Best regards,
> > Stian
> 
> For what it's worth, maybe as a point to start to look for differences...
> 
> I am running 2.5.70-mm1, with snd-intel8x0 module.  Also SMP on Xeon P4
> (2up), Intel chipset.  I am not having any problems with unloading snd.
> 
> So maybe the difference is between -mm1 and (IIRC) -bk1.

Hmm. I will try -mm1 later today, but my problems started with
2.5.68-bk18 (IIRC). This is also a SMP-system, Dual P3 (But VIA
chipset): But it's a pity you don't see the problem. I was hoping
everyone had it :) Well, I'll try to insert some printk's and stuff, and
see what happens. And try -mm1

Best regards,
Stian

Re: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Florin Iucha]

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

On Wed, May 28, 2003 at 03:23:32PM +0200, Stian Jordet wrote:
> > > This did not fix my problem. When I unload one ALSA-modules after the
> > > other, the system hangs when I come to the "snd" module. No oops or
> > > panic, it just freezes. Other than that, ALSA works fine for me, just
> > > frustrating when I reboot.
> > >
> > > Best regards,
> > > Stian
> > 
> > For what it's worth, maybe as a point to start to look for differences...
> > 
> > I am running 2.5.70-mm1, with snd-intel8x0 module.  Also SMP on Xeon P4
> > (2up), Intel chipset.  I am not having any problems with unloading snd.
> > 
> > So maybe the difference is between -mm1 and (IIRC) -bk1.
> 
> Hmm. I will try -mm1 later today, but my problems started with
> 2.5.68-bk18 (IIRC). This is also a SMP-system, Dual P3 (But VIA
> chipset): But it's a pity you don't see the problem. I was hoping
> everyone had it :) Well, I'll try to insert some printk's and stuff, and
> see what happens. And try -mm1

Try -bk2: it contains Al Viro's second fix.

florin

-- 

"NT is to UNIX what a doughnut is to a particle accelerator."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Re: ALSA problems: sound lockup, modules, 2.5.70

[Stian Jordet]

ons, 28.05.2003 kl. 15.39 skrev Florin Iucha:
> On Wed, May 28, 2003 at 03:23:32PM +0200, Stian Jordet wrote:
> > > > This did not fix my problem. When I unload one ALSA-modules after the
> > > > other, the system hangs when I come to the "snd" module. No oops or
> > > > panic, it just freezes. Other than that, ALSA works fine for me, just
> > > > frustrating when I reboot.
> > > >
> > > > Best regards,
> > > > Stian
> > > 
> > > For what it's worth, maybe as a point to start to look for differences...
> > > 
> > > I am running 2.5.70-mm1, with snd-intel8x0 module.  Also SMP on Xeon P4
> > > (2up), Intel chipset.  I am not having any problems with unloading snd.
> > > 
> > > So maybe the difference is between -mm1 and (IIRC) -bk1.
> > 
> > Hmm. I will try -mm1 later today, but my problems started with
> > 2.5.68-bk18 (IIRC). This is also a SMP-system, Dual P3 (But VIA
> > chipset): But it's a pity you don't see the problem. I was hoping
> > everyone had it :) Well, I'll try to insert some printk's and stuff, and
> > see what happens. And try -mm1
> 
> Try -bk2: it contains Al Viro's second fix.

Thank you, this did indeed fix it. I'm usually good at catching changes
that is relevant for me, but this one slipped through. Thanks again :)

Best regards,
Stian