This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 326411 - Freeze On Boot w/ Audigy PCMCIA
Freeze On Boot w/ Audigy PCMCIA
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-10 10:44 EDT by Edoardo Patelli
Modified: 2008-06-20 15:05 EDT (History)
8 users (show)

See Also:
Fixed In Version: 2.6.25.6-27.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-20 15:05:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
log file of soundcard detection (54.81 KB, text/plain)
2008-02-08 12:11 EST, Edoardo Patelli
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 9304 None None None Never

  None (edit)
Description Edoardo Patelli 2007-10-10 10:44:44 EDT
+++ This bug was initially created as a clone of Bug #242208 +++

Description of problem:
If I leave my Soundblaster PCMCIA Audigy 2 ZS card plugged in during startup the
computer simply freezes when reaching the UDEV startup.  Unplugging it at this
point makes no difference.  If I start with it unplugged then the computer boots
up fine.  If I plug it after the KDE desktop has finished loading then the
computer freezes again.

I know for sure that it was working fine a couple of days ago when using Fedora
Core 6.  It is very important to have this working on my Clevo D900k laptop
since the built in sound card has terrible quality.


How reproducible:

Steps to Reproduce:
1. Insert the Audigy PCMCIA card into the PCMCIA slot
2. Boot into Fedora 7 with grub

Thanks for your help.

-- Additional comment from triplehaata@gmail.com on 2007-06-03 10:37 EST --
I have the same issue for my PCMCIA Audigy 2 ZS, and it can be reproduced in 
the same fashion. Fedora Core 6 had no issues.

After reading a similar report for a Audigy 2 ZS Platinum (PCI) Live Drive I 
suspect it may be related as when it is attached a similar situation occurs at 
boot.

I have a Systemax Neotach 3300 (Mitac 8350) with a Texas Instruments PCI4510 PC 
card Carbus Controller (rev 2)

-- Additional comment from etheban@yahoo.it on 2007-06-22 10:36 EST --
I have the same problem with my Sony Vaio FE11S and the PCMCIA Audigy 2 ZS.
I think that the problem is related to the kernel. I try to run Fedora 7
adopting the kernel of fedora 6 and it works perfectly. 


-- Additional comment from cebbert@redhat.com on 2007-06-26 19:33 EST --
Which version of ALSA is this using?
cat /proc/asound/version

Has it correctly identified the sound card?
cat /proc/asound/cards



-- Additional comment from triplehaata@gmail.com on 2007-06-26 23:26 EST --
I am using ALSA version 1.0.14rc3 (Wed Mar 14 07:25:50 2007 UTC)

As for identifying the sound card, everything stops the moment the card is 
plugged into the PCMCIA card slot, so there is no way I can check whether it 
has identified the sound card or not (unless there are some log files I can 
check). Same issue with inserting the card on boot, stops at or after udev (the 
screen goes blank in both cases).

Thanks

-- Additional comment from calsurferpunk@aol.com on 2007-06-27 10:23 EST --
Ditto to Jacob Alexander.  Same ALSA version and unable to check if card
identified.  Thanks for looking into it.

-- Additional comment from kmberry@speakeasy.net on 2007-06-29 01:33 EST --
I have the same problem with my Toshiba Satellite A135-SS2276 and fc8.   My alsa
version is 1.0.12rc1 and I sm using 2.6.18-1.2798.fc6 to get the card working.

-- Additional comment from etheban@yahoo.it on 2007-07-03 06:54 EST --
Updating: 
With the last updating now I can plug-in the PCMCIA without frozed the system but:

1) If the PCMCIA is plugged into the PCMCIA card slot during startup the
computer simply freezes when reaching the UDEV startup.

2) I can not used the audio card. On the Administrator -> soundcard detection
the sound card is recongnized but NO PCM device available. 

3) No problem with the FC6 Kernel. 


-- Additional comment from roos@bluebottle.com on 2007-07-25 04:38 EST --
Same problem with audigy 2 zs on thinkpad t43 (2669), alsa version 1.0.14,
fedora 7, 2.6.22.1-27.fc7. Worked well in fc6 with 2.6.20. 

This is dmesg output after inserting, freezing and removing:

snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
pccard: card ejected from slot 0
snd-emu10k1: Suspected sound card removal
Audigy2 value: Special config.
snd-emu10k1: Suspected sound card removal
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
emu10k1:I2C:timeout status=0xffffffff
Writing to ADC failed!
snd-emu10k1: Suspected sound card removal
ACPI: PCI interrupt for device 0000:0c:00.0 disabled


-- Additional comment from jarin.franek@post.cz on 2007-07-31 18:18 EST --
Created an attachment (id=160373)
scsconfig.log and kernel oops log (zip archive)

The same freeze during startup or plugin on my HP nx7000 NB with Fedora 7 upto
kernel 2.6.22.1-27.fc7.

With 2.6.22.1-33.fc7 things are a bit different now:

* No freeze during startup with the PCMCIA card plugged in
     NB boots up, I log into KDE, but no sound comes out from the Audigy card
* kernel OOPS (BUG) when the PCMCIA card plugged in (booted without)
     The initialization of the card fails, and during roll-back
     probably resources are freed that were never allocated,
     see the attached log (excerpt from /var/log/messages)

Note also that the card is identified as Audigy Value SB0400 by the sound card
detection utility (this was the same in Fedora 6 where all worked fine),
however, KMix states properly Audigy 2 ZS Notebook [SB0530] - a bit of
inconsistency. Anyway, the card is not working, I cannot hear the test sound so
created the scsconfig.log as advised by the sound card detection utility, see
the attachment.


-- Additional comment from triplehaata@gmail.com on 2007-08-01 16:12 EST --
It now works for me in FC7 kernel 2.6.22.1-41.fc7 when booting with the card. 
The test sound plays through the headphone jack, as well as the surround jack.

As for booting without the card and inserting afterwords, I cannot get it to work.
However, I was never able to get it to work in fc6 either.

-- Additional comment from jarin.franek@post.cz on 2007-08-02 18:28 EST --
I have updated to the new kernel 2.6.22.1-41.fc7 and the latest alsa libs and 
can confirm that when booting with the card plugged-in on my HP nx7000 NB, the 
card works, I can hear the test sound (my thanks to everyone involved in fixing 
the issue). Maybe it has worked with 2.6.22.1-33.fc7 as well, it took me some 
time to adjust the knobs on the KMix to get the sound from the soundcard 
detection utility (it is the 'OLD PCM' knob and not the 'PCM' as I had 
expected).

For me the original issue is solved, but once again, plugging the card after 
booting without it (hotplug) causes a kernel Oops. The same bug as in my 
previous post.







-- Additional comment from calsurferpunk@aol.com on 2007-08-02 18:33 EST --
Well I thought the problem might be resolved, but the card is once again not
working.  I can leave it plugged in during startup and everything loads
correctly, but the card is not activated properly once I get to the KDE desktop.
 I have kernel 2.6.22.1-41.fc7 along with all of the latest updates as of 8/2/07.

The strange thing is that everything seemed to be working fine for a day or two,
but now the card is not recognized again under soundcard detection.  It's almost
like it was teasing me by working for those couple of days...

-- Additional comment from etheban@yahoo.it on 2007-08-03 03:54 EST --
With the Kernel 2.6.22.1-41.fc7 my audigy 2 zs on sony vaio works perfectly. 
The only problem remains the hotplug but as Jacob Alexander the hotplug did not
work in fc6 either.

-- Additional comment from calsurferpunk@aol.com on 2007-08-03 10:17 EST --
Well strangely enough, mine is working correctly this morning also on my CLEVO
D900K.  The problem now seems to be that it works at random times.  Yesterday I
restarted and turned off the computer several times with no change, yet today I
start it up and the sound card is detected correctly.  Very strange.  I just
wish it were more consistent.

-- Additional comment from etheban@yahoo.it on 2007-10-06 11:47 EST --
I tried my AUDIGY 2 ZS on SONY VAIO FE11S under fedora 8 test 3 (7.92) but it
does NOT work! 
The computer simply freezes when reaching the UDEV startup. 
I hope that this problem will be fixed before the release of the Fedora 8. 


-- Additional comment from roos@bluebottle.com on 2007-10-10 05:38 EST --
Same here, it has not been working on any of the 64-bit kernels in f8t est 2/3
here. Have not been trying 32-bit. Hangs on udev when inserted start and freezes
machine when inserted later.

-- Additional comment from roos@bluebottle.com on 2007-10-10 05:40 EST --
Should I submit a new thread with f8-tag or could this thread be cloned?
Comment 1 daniele 2007-11-15 02:20:55 EST
audigy 2 zs pcmcia works fine on (fedora7 + yum update) but freezes on (fedora8
x86_64  + yum update) on my laptop.
Comment 2 Jaroslav Franek 2007-11-15 03:47:28 EST
I think it is about the kernel (regardless of Fedora version):
2.6.20 and later 2.6.22.x worked well
2.6.21 and 2.6.23 have the boot issue with the SB PCMCIA
I have got i686 architecture (HP nx7000 notebook), so it is not x86_64 specific.
Hot-plug/unplug never worked (kernel Oops, panic).
Comment 3 daniele 2007-11-20 05:50:00 EST
Yes, I verified on my laptop HP dv8051 turion 64:
2.6.23 have boot issue with audigy pcmcia regardless fedora version (fedora7/8)
and architecture (i386/x86_64)
2.6.22 work well 

(In reply to comment #2)
> I think it is about the kernel (regardless of Fedora version):
Comment 4 Tero Nieminen 2008-01-04 16:07:52 EST
Same freeze on boot sequence (at udev) (with Audigy 2 ZS notebook inserted) and
freeze on insert when on desktop (ie. hot-plug). Boot continues if csrd is
removed. SOn desktop unfreese when unplugged - after ahat a lot of lines like:

---
Jan  4 20:54:04 localhost kernel: snd-emu10k1: Suspected sound card removal
Jan  4 20:55:05 localhost kernel:last message repeated 4004 times
Jan  4 20:56:06 localhost kernel:last message repeated 4023 times
Jan  4 20:57:07 localhost kernel:last message repeated 4018 times
Jan  4 20:58:08 localhost kernel:last message repeated 4216 times
Jan  4 20:59:09 localhost kernel:last message repeated 5319 times
---

in /var/log/messages until next reboot. Tried additional kernel parameters: 
cbmemsize=256M cbiosize=4096. No noticeable change.


System imformation: 

Dell latitude D800/kernel-2.6.23.9-85.fc8
$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Nov 20 19:16:42
2007 UTC).

Rgds, Tero

PS. Used to work ok for me too under Fc6. Failed with fc7 and now fails with fc8.
Comment 5 Edoardo Patelli 2008-02-08 12:11:20 EST
Created attachment 294384 [details]
log file of soundcard detection

After the last update of F8 I am able to start the Laptop with the PCMCIA cards
plugged in. Also the hot-plug seems to work. Moreover it seems work with all
the kernel version 2.6.23.* and 2.6.24.*

However the sound card is still not working. I added the log file generated by
the soundcard detection program.
Comment 6 Jaroslav Franek 2008-02-14 18:53:14 EST
To Edoardo:
If I were you I would first took care of the broken partition (see dmesg)

EXT3-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT3 FS on sda5, internal journal
...
EXT3-fs error (device sda5): htree_dirblock_to_tree: bad entry in directory
#10246640: rec_len % 4 != 0 - offset=0, inode=1852793951, rec_len=101, name_len=115

After securing your data, please attend to CPUs: I noticed that you have two CPU
cores, which may be different situation to having only single CPU (my case). If
one of your CPUs is stuck, the other still executes kernel threads. Is it
possible that you boot up with one CPU stuck and the other taking all the burden
of running the system? Just a crazy idea... Check top or gkrellm.

Now a bit more seriously: I saw a problem with initializing and probing the card

cannot find the slot for index 0 (range 0-7), error: -16
EMU10K1_Audigy: probe of 0000:0b:00.0 failed with error -12   

The first one is error 16 (EBUSY) from snd_card_new() and it means that you want
to create a snd_card kernel object at slot 0, however that slot is locked at the
moment (snd_cards_lock bit is set). Looks like a nice synchronization issue :-)
Maybe I will have some time to look at it... Anyway, the result is that the
kernel object is freed and NULL pointer returned. Since this was called from the
probe and it gets NULL pointer instead of the pointer to proper snd_card object,
the probe thinks that there was not enough memory to allocate the object and
returns 12 i.e. ENOMEM. Wow, no snd_card object, no sound. That may be the
reason why your SB appears to be dead.


Comment 7 Edoardo Patelli 2008-03-21 17:16:29 EDT
Thanks Jaroslav for your comments.

I have also tested the Fedora 9 (rawhide) but nothing changed.  
The system still freezing during the booting at the udev ! (regardless of Fedora
version)

Will we see one day the solution of this bug? 
Comment 8 Solomon Peachy 2008-03-23 11:04:24 EDT
Add another vote for me:

Hangs at udev on startup; card insertion hangs system too.

Kernel 2.6.24.3-34.fc8 on an x86_64 laptop (Ferrari 4000)
Comment 9 Jaroslav Franek 2008-05-25 16:44:33 EDT
I took few kernel rpms from koji.fedoraproject.org to find an approximate origin
of the bug. Here is the result:

latest working kernel:   kernel-2.6.23-0.15.rc0.git1.fc8
first broken kernel:     kernel-2.6.23-0.35.rc0.git6.fc8

If anything happened wrong then it must have been between them. All later
kernels, including Fedora 9's 2.6.25 froze at boot with Audigy plugged in.

Building vanilla kernels using Fedora .config(s) I got rougher interval:

kernel OK:      2.6.22
kernel broken:  2.6.23-rc1 and later

It is difficult to bisect vanilla kernels, since Fedora changed .config too
between 2.6.22 and 2.6.23. Too many possibilities to test. Takes ages to build a
kernel on my aging laptop...
Comment 10 Keith G. Robertson-Turner 2008-05-26 00:13:43 EDT
kernel-2.6.23-0.15.rc0.git1.fc8 only /seems/ to work because it is not in fact
loading any modules. If you follow the boot process, you'll see that it attempts
and fails to find /lib/modules/2.6.22-0.15.rc0.git1.fc8/modules.dep (note:
2.6.22 is the /wrong/ version). Why it does this, I have no idea, but looking at
the spec there seems to be a lot of hacky stuff going on WRT modifying the
version number based on whether or not it is a release package.

If you do:

ln -s /lib/modules/2.6.23-0.15.rc0.git1.fc8 /lib/modules/2.6.22-0.15.rc0.git1.fc8

Then reboot with the Audigy card still inserted, you'll find that it hangs just
as before.

Like others here, I skipped Fedora 7, and upgraded (clean) from 6 to 8, so I
have no idea exactly when this broke. I'll just have to keep regressing back
through older kernels until I find one that works, I suppose.
Comment 11 Jaroslav Franek 2008-05-26 15:38:16 EDT
You are right. I was overexcited to get it past the udev phase so I forgot to
check dmesg. Sorry for the misinformation. None of 2.6.23 or later Fedora
kernels work for me...

In the meantime, the bisection of vanilla kernel led me into the set of CFS
patches in the very beginning of the 2.6.23 development stage. This is in
accordance with the fact the kernel-2.6.23-0.15.rc0.git1.fc8 is not booting. Few
more steps to go, but I am afraid that the CFS scheduler only triggered a
landmine somewhere else in the code.

I am still on 2.6.22.9-91.fc7, the last Fedora release kernel that boot with the
 SB Audigy ZS Notebook plugged in. I even tried the Fedora 9 Preview live DVD,
kernel 2.6.25 I guess, but boot froze in udev, too.


Comment 12 Keith G. Robertson-Turner 2008-05-26 19:16:05 EDT
I'm going to do a prep-build of the 2.6.22.9-91.fc7 and 2.6.23.1-10.fc7 SRPMS,
then diff the relevant sections(emu10k1), to see if anything obvious changed,
but if the bug is a knock-on effect from something else (e.g. scheduler) then
I'm out of my depth.

The comments from kernel bugzilla 9304 seem to indicate that this is a timing issue.
Comment 13 Jaroslav Franek 2008-05-27 17:50:01 EDT
The latest news: It is not the CFS scheduler who triggered the landmine. It is
most probably different kernel .config. The whole bisection led me back to 2.6.22. 

I tried to compile vanilla 2.6.22 with the Fedora config:
config-2.6.22.9-91.fc7. The resulting kernel boot successfully and I am using it
just at the moment.

While I tried .config taken from Fedora 2.6.23-rc0.something, modified slightly
during bisection, the very same code of 2.6.22 compiles into a kernel that hangs
in udev during boot the same way the Fedora release kernels 2.6.23+ do.

This gives the search another dimension, now it is necessary to carefully
examine differences in .configs and find the offending one (or more). More
kernel builds, my laptop would love me... It is hot already :-)

I reckon you do not need to examine the source differences between 2.6.22.9 and
2.6.23.1. It won't give you the answer. There were couple of thousands of
patches between them...

The problem from kernel bugzilla 9304 should be fixed in 2.6.24 (-rc4?). I tried
with Fedora 8 kernel 2.6.24.3 on another notebook, but kernel froze during boot
as usual (udev stage).
Comment 14 Jaroslav Franek 2008-06-03 14:07:16 EDT
Got it. Well, almost...

The offending configuration item is: CONFIG_DEBUG_SHIRQ

The flag was activated for 2.6.23 and later Fedora kernels. It causes the
landmine to explode.

WORKAROUND (NOT A SOLUTION):
For you guys who want to make use of the Audigy with your laptop there is a
simple workaround till the proper solution is available: When the Fedora kernel
is rebuilt with the CONFIG_DEBUG_SHIRQ flag not set, the Soundblaster Audigy ZS
notebook no longer freezes the boot, or the system when hot-plug in/out. I have
tested this with both Fedora 7 (2.6.23.17-82, i686) and Fedora 8 (2.6.24.7-92,
x86_64) kernels. Note that this is 'probabilistic' approach: it may still
explode, but the probability is rather insignificant.


WHAT IS GOING ON:
There is an inherent synchronization gap when creating a device object that uses
a shared interrupt (irq) handler. The handler is registered from "device_create"
function, could be somewhere in the middle when the device object is not fully
constructed. However, once the handler is registered, it can be triggered
anytime (other devices may generate interrupts). The Linux calls all handlers
passes them the appropriate device object and lets them decide whether to handle
the irq or not (usually by polling some device's register). The irq handler must
be able to cope with such situation, where the device object is not fully
constructed (upon device plugin, boot) or partially destroyed (upon unplugging).
The CONFIG_DEBUG_SHIRQ inserts a certain code that triggers the irq handler
immediately after registration within request_irq() call.

It seems that this 'early' interrupt gives the system a fatal blow when Audigy 2
ZS Notebook PCMCIA card is involved.

I still do some research to pinpoint the location of the landmine more precisely.


OTHER INFO:
The Linux kernel bug #9304 seems to be not relevant. It was fixed in 2.6.24, but
 did not help to resolve this Audigy boot issue.

I could not test it on newer kernels, e.g. Fedora 9's 2.6.25. If anyone could
please post your results.
Comment 15 Keith G. Robertson-Turner 2008-06-04 01:54:23 EDT
This config also causes problems elsewhere, e.g. bug #362621 which was also
filed upstream by Chuck:

http://kerneltrap.org/mailarchive/linux-kernel/2008/2/29/1032864

I take it upstream will handle this eventually, or should we look at patching
emu10k1? Would just disabling CONFIG_DEBUG_SHIRQ cause too many problems elsewhere?
Comment 16 Jaroslav Franek 2008-06-04 04:56:43 EDT
Wicked as it sounds, but the CONFIG_DEBUG_SHIRQ is there to cause such
'problems' on purpose, to force as many as possible device drivers to be fixed.
Disabling the CONFIG_DEBUG_SHIRQ would be counterproductive as it will allow
certain drivers' sync bugs to live happily ever after and strike unexpectedly.
The way to go is to patch emu10k1 (provided the problem is there, but the
probability is quite high).

Last night I have pinpointed the freeze point to be in sound/pci/emu10k1/irq.c,
snd_emu10k1_interrupt():

	while (((status = inl(emu->port + IPR)) != 0) && (timeout < 1000)) {

Early reading from the I/O port seems to be the problem. I scheduled few more
experiments to be sure to blame the emu10k1 setup routine (there is also some
pci stuff involved...).
Comment 17 Jacob Alexander 2008-06-04 14:08:04 EDT
Fedora 9 x86_64 2.6.25-3-18 with kernel option CONFIG_DEBUG_SHIRQ off works.

Thank you so much Jaroslav!!

I can confirm that hot-plugging works as well.
Comment 18 Jaroslav Franek 2008-06-04 18:14:52 EDT
Glad to hear that :-)

After few more nasty experiments I am sure to blame the emu10k1 setup routine.
Now I have a pretty good idea what is going on. I have created and tested a
patch. It works on Fedora 7 (2.6.23-17, i686, single-core), but without hot-plug
- it Oopses like 2.6.22 kernels did. But on 2.6.25 the hot-plug is no longer
experimental feature so I hope it would work well.

Tomorrow I am going to test it on Fedora 8 (2.6.24.7, x86_64, dual-core), and if
it passes the tests I will submit the patch to upstream for proper flaming. Lets
hope this longstanding issue gets resolved soon.
Comment 19 Keith G. Robertson-Turner 2008-06-05 05:12:48 EDT
I should probably file a new bug on this, but IMHO CONFIG_DEBUG_SHIRQ should not
be set on production/release kernels, since it is deliberately designed to break
non-compliant drivers.

Now certainly this is desirable from a development POV, and those buggy drivers
will be be identified and fixed more quickly with this set, since the entire
userbase will be exposed to it, but I question the prudence of deliberately
breaking end users (non testers) systems.

I'm inclined to suggest that this config should be reserved for rawhide and
release candidates only.

Opinions?
Comment 20 Jaroslav Franek 2008-06-06 17:11:35 EDT
Good news: My patch was accepted by ALSA maintainers and merged into Linux
kernel upstream in 2.6.26-rc5-git2.

The patch moves the irq handler registration after the I/O ports activation,
thus eliminating the hangup in the irq handler. So now the SB Audigy2 PCMCIA
works well even with the CONFIG_DEBUG_SHIRQ set to 'y'.

To Fedora guys:
If you decide to to silence the CONFIG_DEBUG_SHIRQ flag, there is no urgent need
for the patch in Fedora 8, 9, as the probability of system hangup is decently
low. Otherwise you can grab the patch here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=7d87500bbe68c2176197d039f3655301ad678db6;hp=bbdb913e91f0c2b301f124200f85f96fffb5c7ed

Anyway, you now have enough information to deal with this bug quickly ;-)
Comment 21 Keith G. Robertson-Turner 2008-06-06 19:57:17 EDT
Nice work :)

+1 submit for testing.
Comment 22 Peter Oyler 2008-06-08 01:12:45 EDT
I'm pretty new to Linux, so does comment 20 mean that come kernel 2.6.26 the
problem should be taken care of?
Comment 23 Chuck Ebbert 2008-06-09 17:32:34 EDT
Fixed in 2.6.25.6-21
Comment 24 Fedora Update System 2008-06-11 21:20:30 EDT
kernel-2.6.25.6-24.fc8 has been submitted as an update for Fedora 8
Comment 25 Fedora Update System 2008-06-12 22:20:38 EDT
kernel-2.6.25.6-24.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5267
Comment 26 Fedora Update System 2008-06-17 13:24:01 EDT
kernel-2.6.25.6-27.fc8 has been submitted as an update for Fedora 8
Comment 27 Fedora Update System 2008-06-20 15:04:44 EDT
kernel-2.6.25.6-27.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.