Bugzilla – Bug 619021
Inserting nozomi driven UMTS card causes oops and takes down system
Last modified: 2010-09-08 13:56:01 UTC
How to reproduce: insert Option UMTS card (Novell corporate standard in Germany) into PCMCIA slot, experience oops, and see system freeze within some ten seconds. Alternately, boot with the card in the slot from the beginning, and see the boot process hang. [ 187.308141] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 [ 187.308197] pci 0000:16:00.0: reg 10: [mem 0x00000000-0x000007ff] [ 187.308305] pci 0000:16:00.0: BAR 0: assigned [mem 0x80000000-0x800007ff] [ 187.308318] pci 0000:16:00.0: BAR 0: set to [mem 0x80000000-0x800007ff] (PCI address [0x80000000-0x800007ff] [ 187.308340] pci 0000:16:00.0: cache line size of 64 is not supported [ 187.314783] Initializing Nozomi driver 2.1d (build date: Jun 28 2010 20:07:17) [ 187.314805] nozomi 0000:16:00.0: Init, new card found [ 187.314811] nozomi 0000:16:00.0: enabling device (0000 -> 0002) [ 187.314820] nozomi 0000:16:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 187.314824] nozomi 0000:16:00.0: Card type is: 2048 [ 187.610781] nozomi 0000:16:00.0: Version of card: 3 [ 187.610897] nozomi 0000:16:00.0: Initialization OK! [ 188.317188] nozomi 0000:16:00.0: Device READY! [ 188.842244] Warning: dev (noz3) tty->count(0) != #fd's(1) in tty_open [ 188.842254] noz: activated 3: ffff8800786cd558 [ 188.842437] Warning: dev (noz2) tty->count(0) != #fd's(1) in tty_open [ 188.842444] noz: activated 2: ffff8800786cd3b8 [ 188.842549] Warning: dev (noz1) tty->count(0) != #fd's(1) in tty_open [ 188.842556] noz: activated 1: ffff8800786cd218 [ 188.842658] Warning: dev (noz0) tty->count(0) != #fd's(1) in tty_open [ 188.842665] noz: activated 0: ffff8800786cd078 [ 188.842787] BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 [ 188.842796] IP: [<ffffffff814a1610>] mutex_lock+0x10/0x40 [ 188.842812] PGD 75025067 PUD 77b62067 PMD 0 [ 188.842821] Oops: 0002 [#1] PREEMPT SMP [ 188.842829] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0000:16:00.0/tty/noz0/uevent [ 188.842838] CPU 0
The above was with kernel-desktop-2.6.34-11.4.x86_64, alas kernel-default-2.6.34-12.1.x86_64 crashes and burns exactly the same.
Created attachment 378419 [details] Logfile: "/var/log/messages"
The Kernel 2.6.34-12-default and the Kernel 2.6.34-12-desktop crashes too. #uname -a Linux gf01.xx.xx.xx.de 2.6.34-12-default #1 SMP 2010-06-29 02:39:08 +0200 i686 i686 i386 GNU/Linux
Created attachment 378745 [details] nozomi-fix-tty-count This should fix that. Building a test kernel.
Thanks for looking into this, Jiri. I tried a test kernel with your patch, alas the system still freezes. Is it possible there is more than one issue with the nozomi driver at work? (I tried to capture the system log, the one on disk did not have anything this and, but I could try and type off what the system logged to all graphical terminals.) Also, if that helps, I could have a card taken to Praha tomorrow. Just let me know.
(In reply to comment #6) > I tried a test kernel with your > patch, alas the system still freezes. Is it possible there is more > than one issue with the nozomi driver at work? Highly likely. Alan rewrote many parts of the driver without testing them. > (I tried to capture > the system log, the one on disk did not have anything this and, but > I could try and type off what the system logged to all graphical > terminals.) Yup, it would be helpful. It would be enough to capture it by camera. > Also, if that helps, I could have a card taken to Praha tomorrow. I'm far away from Praha, it won't help me. Thanks anyway.
Created attachment 379015 [details] Kernel panic with the first issue fixed (In reply to comment #7) > Highly likely. Alan rewrote many parts of the driver without testing them. Great. :-( On the positive side, by testing both the original kernel and your patched one I am happy to confirm that your patch in attachment #2 [details] indeed fixes the warnings. Any chance you can push that patch into the stable 2.6.32 kernel and/or our SLE 11 SP1 kernel as well? This card is one of the official Novell cards in Germany, so this will help our internal rollout, too. > Yup, it would be helpful. It would be enough to capture it by camera. Hah, this time around I managed to get you a nice log. :-)
Created attachment 379151 [details] nozomi-set-tty-driver_data.patch Yet another one line fix. Building kernel, will appear at: http://labs.suse.cz/jslaby/bug-619021/
Created attachment 379303 [details] Excerpt from /var/log/messages for comment #10 (In reply to comment #9) > Created an attachment (id=379151) [details] > nozomi-set-tty-driver_data.patch Good news, and bad news. The good news is that the system no longer crashes when I insert the card. The bad news is, that the card does not work, that is, I am not able to establish a connection (which works fine with kernel 2.6.33.6-147 from Fedora 13). Let me attach the relevant part from the log file. What this shows are three connection attempts using NetworkManager. The first one took 20 seconds or so and then failed, whereas subsequent attempts failed right away in less than a second. Anything you can read out of that?
(In reply to comment #10) > Let me attach the relevant part from the log file. What this shows > are three connection attempts using NetworkManager. The first one > took 20 seconds or so and then failed, whereas subsequent attempts > failed right away in less than a second. Anything you can read out > of that? Thank, but I don't see anything obvious. Could you retest with the new kernel from labs? It contains some more debug info.
Created attachment 380002 [details] /var/log/messages for comment #12 Thanks, Jiri. I did an extensive amount of testing, and here is what I found. Basically, and that is good news, the card now works. There are two things not satisfactory yet, and both are shown in the log I am attaching: 1. When a connection is active (in NetworkManager using the nozomi driven card), removing the card leads to a system halt. 2. When I suspend (to RAM) with the card in the slot and resume, establishing a connection no longer works. The first attempt to do so takes many seconds to fail, the second one thereafter fails immediately. Removing the card and inserting it again works around this and I can establish a connection again. The original issue (inserting the card causes an OOPS) has been addressed; would you prefer me to file new bugs for items 1 and 2, or perhaps just for item 2 in this comment? Again, if you could push the two existing patches in comments #4 and #9 upstream, into the openSUSE 11.3 kernel and into 2.6.32.x and/or our own 2.6.32-based tree that would be great. Thanks!
Gerald, I thought original issue was already fixed. And the first issue in your comment 12 cause system halt? Which means the driver still have some bugs? And the second one should be related to NetworkManager, it would be better to separate another bug for it.
Jiri, Do you let the patch in updates or upstream? And what's the status for first issue in Commnet 12? Thanks!
Any updates?
(In reply to comment #12) > Again, if you could push the two existing patches in comments #4 and #9 > upstream, into the openSUSE 11.3 kernel and into 2.6.32.x and/or our > own 2.6.32-based tree that would be great. Thanks! 2.6.32 is not affected. It's now upstream, in 2.6.34 and 2.6.35 stables and in 11.3 repo (.34-based).
(In reply to comment #17) > 2.6.32 is not affected. It's now upstream, in 2.6.34 and 2.6.35 stables > and in 11.3 repo (.34-based). Cool, thanks a lot Jiri! Bin Li, based on your recommendation I have filed a new report for item 2 of comment #12, it is Bug #630486 Inserting nozomi driven UMTS card causes oops and takes down system. I cannot always reproduce item 1 in that comment, so let's ignore this for the time being and close this report as fixed.
The SWAMPID for this issue is 35398. This issue was rated as moderate. Please submit fixed packages until 2010-09-07. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-devel, kernel-ec2-devel, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-vmi-devel, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop Products: openSUSE 11.3 (debug, i586, x86_64)