I wrote about this in a previous mail, but this is a repost as a separate
subject.
1) All sound applications on my system break on 2.5.70 and work fine on
2.4.21-rc4 with alsa 0.9.2. The problem is a lockup where the sound keeps
looping. The kernel log does not report anything, but:
- aplay locks up when beginning to play a wav. file
- xmms locks up on attempted stop or skipping back or forward (mp3)
- mplayer locks up on pause (mp3)
- xine locks up on start (mp3)
Soundcard uses snd-via82xx driver (ALC650)
2) Module issues.
Perhaps this is not a bug, but I cannot get the sound modules to autload.
I use module-init-tools 0.9.12, devfs, and I have set up moprobe.devfs and
modprobe.conf. I have kmod compiled in the kernel. The redhat initscripts are
not turning off autoloading - other things autoload fine.
Modprobe.devfs says:
alias /dev/snd snd-card-0
alias /dev/snd/* /dev/snd
alias /dev/sound/* /dev/sound
alias /dev/sound sound-slot-0
alias /dev/audio sound-slot-0
alias /dev/mixer sound-slot-0
alias /dev/dsp sound-slot-0
alias /dev/dspW sound-slot-0
alias /dev/midi sound-slot-0
Modprobe.conf says:
alias sound-slot-0 snd-via82xx
alias snd-card-0 snd-via82xx
install snd-via82xx /sbin/modprobe --ignore-install snd-via82xx && { alsactl
-f /etc/asound.state restore; }
remove snd-via82xx /sbin/modprobe -r --ignore-remove snd-via82xx && { alsactl
-f /etc/asound.state store; }
Devfsd.conf says:
REGISTER sound/.* PERMISSIONS root.audio 660
REGISTER snd/.* PERMISSIONS root.audio 660
And the modules won't load until I manually modprobe snd-via82xx.
Also...on modprobe --remove snd-via82xx:
[root@cobra etc]# modprobe --remove snd-via82xx
alsactl: save_state:1050: No soundcards found...
FATAL: Error running remove command for snd_via82xx
[root@cobra etc]#
Thank you for your help.
Alsa worked fine for me in 2.5.68-bk18. It started hanging on halt
in -bk19 and .70. I haven't played anything to see if it hangs on
access.
florin
--
"NT is to UNIX what a doughnut is to a particle accelerator."
tir, 27.05.2003 kl. 15.05 skrev Florin Iucha:
> Alsa worked fine for me in 2.5.68-bk18. It started hanging on halt
> in -bk19 and .70. I haven't played anything to see if it hangs on
> access.
I can confirm this behaviour. Kinda weird, I think it is rather
unrelated to sound itself, because there haven't been any changes in
that area. Hmm. Annoying. Except for this, I have absolutely no issues
with 2.5.70, everything works perfect. I love it :)
Best regards,
Stian
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
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 */
tir, 27.05.2003 kl. 20.51 skrev [email protected]:
> 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
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?
-----Original Message-----
From: Stian Jordet [mailto:[email protected]]
>
> tir, 27.05.2003 kl. 20.51 skrev [email protected]:
>> 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.
ons, 28.05.2003 kl. 14.55 skrev Downing, Thomas:
> -----Original Message-----
> From: Stian Jordet [mailto:[email protected]]
> >
> > tir, 27.05.2003 kl. 20.51 skrev [email protected]:
> >> 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
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."
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