Hi folks,
I have this really old Dell Latitude CPiA here containing the dreaded
neomagic combined audio/video chipset, and observe some hard lockup
sometimes, which is not supposed to be anything special wrt. other
people with similar laptops having the same trouble. The only regularity
I noticed was that after completely removing power to the machine, the
sound driver can be loaded without locking the thing hard. Any further
attempt, eg. rmmod and insmod or reboot with alsasound startup script,
will result in a dead machine. Every time. Cut the power, and next time
it will survive - exactly once.
Now this chip is a NM2200 / 256AV, and I already did some reading in the
alsa driver source code, but adding printk()s all over the place just
showed that it does not lock up during init_chip() or poking at the
registers during ac97_reset(), but shortly after the latter, approx.
half a second or so - it might still be a consequence thereof.
My basic idea is, with the device being entirely undocumented (to hell
with all hardware vendors who don't even release specs after the devices
are not even sold anymore, by the way), that the code is missing a
proper device reset, and trying to re-init some parts just kill the
machine. Cutting the power really is not that nice as a workaround. I'd
love to try something along the lines of saving the device's state as a
whole, and before reloading the module, restore that state again. The
difference between before and after should somehow give a clue about the
proper reset procedure - or so I hope.
Unfortunately I failed with my previous attempts to modify the driver
appropriately. Now that it's basically back to formula, I wanted to ask
whether there is a possibility to read and write back whole parts of
memory directly from/to the device, or if I should rather store each and
every register somewhere I can later restore it from, one by one. I'd
even prefer userspace, and am currently experimenting with pcidump.
Any hints would be greatly appreciated! Thanks a bunch,
Chris
On Sun, Mar 26, 2006 at 07:45:42AM +0200, Christian Trefzer wrote:
> ... currently experimenting with pcidump.
First of all, that is pcitweak. Reading all the register space
sequentially 32bit word-wise revealed the following:
If word #7 (counting from 0) is 0x22a0c0c0 the driver locks up while
loading, while with 0xa2a0c0c0 it will load. I'll try and reproduce the
case where I get the lockup-prone value, and then try to write the
working value there...
Later,
Chris
OK, apparently the importance of this issue is quite modest, so I won't
expect too much attention - not that I'd have presumed any in the first
place ; )
Here's what I found so far, anyway:
Writing the following to the device one word at a time prior to loading
snd-nm256 saved my laptop from hanging. It was dumped in a shell loop
after successful driver loading:
0x71918086
0x0220011f
0x06040003
0x00012000
0x00000000
0x00000000
0x20010100
0xa2a0c0c0
0xfef0fd00
0xf9f0f800
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x008c0000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
The following I get when reading stuff right before a crash:
0x71918086
0x0220011f
0x06040003
0x00012000
0x00000000
0x00000000
0x20010100
0x22a0c0c0
0xfef0fd00
0xf9f0f800
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x008c0000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
The funny part is that only writing word #7 won't save the suicidal
fsck from going over the edge, I only succeeded when writing all the
stuff back to the device. By the way, here's a diff:
--- nm256-device-beforedriver 2006-03-26 15:27:32.873773008 +0200
+++ nm256-device-driverloaded 2006-03-26 15:27:42.669283864 +0200
@@ -5,7 +5,7 @@
0x00000000
0x00000000
0x20010100
-0x22a0c0c0
+0xa2a0c0c0
0xfef0fd00
0xf9f0f800
0x00000000
It came out of suspend2 just the way it was supposed to crash, I flushed
the registers and it is now happily playing music for me. Strange
thing... For now, I'll add the register paint job to an install
directive in modprobe.conf, let's see what this can do.
Kind regards,
Chris
At Sun, 26 Mar 2006 07:45:42 +0200,
Christian Trefzer wrote:
>
> Hi folks,
>
> I have this really old Dell Latitude CPiA here containing the dreaded
> neomagic combined audio/video chipset, and observe some hard lockup
> sometimes, which is not supposed to be anything special wrt. other
> people with similar laptops having the same trouble. The only regularity
> I noticed was that after completely removing power to the machine, the
> sound driver can be loaded without locking the thing hard. Any further
> attempt, eg. rmmod and insmod or reboot with alsasound startup script,
> will result in a dead machine. Every time. Cut the power, and next time
> it will survive - exactly once.
>
> Now this chip is a NM2200 / 256AV, and I already did some reading in the
> alsa driver source code, but adding printk()s all over the place just
> showed that it does not lock up during init_chip() or poking at the
> registers during ac97_reset(), but shortly after the latter, approx.
> half a second or so - it might still be a consequence thereof.
>
> My basic idea is, with the device being entirely undocumented (to hell
> with all hardware vendors who don't even release specs after the devices
> are not even sold anymore, by the way), that the code is missing a
> proper device reset, and trying to re-init some parts just kill the
> machine. Cutting the power really is not that nice as a workaround. I'd
> love to try something along the lines of saving the device's state as a
> whole, and before reloading the module, restore that state again. The
> difference between before and after should somehow give a clue about the
> proper reset procedure - or so I hope.
>
> Unfortunately I failed with my previous attempts to modify the driver
> appropriately. Now that it's basically back to formula, I wanted to ask
> whether there is a possibility to read and write back whole parts of
> memory directly from/to the device, or if I should rather store each and
> every register somewhere I can later restore it from, one by one. I'd
> even prefer userspace, and am currently experimenting with pcidump.
>
>
> Any hints would be greatly appreciated! Thanks a bunch,
Try 2.6.16-git tree. Some patches for this problem are there.
Takashi
On Mon, 2006-03-27 at 12:16 +0200, Takashi Iwai wrote:
> > Any hints would be greatly appreciated! Thanks a bunch,
>
> Try 2.6.16-git tree. Some patches for this problem are there.
If this does not fix the problem then alsa-devel (cc'ed) is the best
list to discuss the issue.
Lee
Hi Takashi, Lee,
On Mon, Mar 27, 2006 at 05:59:59PM -0500, Lee Revell wrote:
> On Mon, 2006-03-27 at 12:16 +0200, Takashi Iwai wrote:
> >
> > Try 2.6.16-git tree. Some patches for this problem are there.
>
> If this does not fix the problem then alsa-devel (cc'ed) is the best
> list to discuss the issue.
Actually, the changes in Linus' current git have fixed the hang for me.
Good job - thanks a lot, guys!
Kind regards,
Chris
On Wed, Mar 29, 2006 at 04:43:03PM +0200, Christian Trefzer wrote:
> Hi Takashi, Lee,
>
>
> On Mon, Mar 27, 2006 at 05:59:59PM -0500, Lee Revell wrote:
> > On Mon, 2006-03-27 at 12:16 +0200, Takashi Iwai wrote:
> > >
> > > Try 2.6.16-git tree. Some patches for this problem are there.
> >
> > If this does not fix the problem then alsa-devel (cc'ed) is the best
> > list to discuss the issue.
>
> Actually, the changes in Linus' current git have fixed the hang for me.
> Good job - thanks a lot, guys!
>
> Kind regards,
> Chris
Takashi, would it be possible getting the fixes for this hard lookup
into 2.6.16.2?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 2006-03-31 at 23:12 +0200, Adrian Bunk wrote:
> > Actually, the changes in Linus' current git have fixed the hang for
> me.
> > Good job - thanks a lot, guys!
> >
> > Kind regards,
> > Chris
>
> Takashi, would it be possible getting the fixes for this hard lookup
> into 2.6.16.2?
>
Is a 225 line patch to fix a driver that's never worked appropriate for
-stable?
Lee