Bug 668088 - panic in b44 driver
Summary: panic in b44 driver
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
: 695370 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-01-07 20:49 UTC by darrell pfeifer
Modified: 2011-04-18 15:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-01 15:02:31 UTC
Type: ---

Attachments (Terms of Use)
dmesg from boot (70.36 KB, text/plain)
2011-01-13 20:47 UTC, darrell pfeifer
no flags Details

System ID Private Priority Status Summary Last Updated
Linux Kernel 25402 0 None None None Never

Description darrell pfeifer 2011-01-07 20:49:19 UTC
Description of problem:

Kernel panic - not syncing : map_single : buffer is not DMA'able
PID 1100, comm: NetworkManager Not tainted 2.6.37-2.fc15.x86_64 #1
Call Trace
ff...81475925 panic+0x91/0x1a4
8123bbba ?swtiotlb_map_page+0x8/0xcc
8123bcc7a swiotllb_map_page+0x8/oxcc
a020dbc7 dma_map_single_attrs.close.36+06x/0x83 [b44]
a020dad0 b44_alloc_rx_skb+0x7f/0x251 [b44]
a020d0f0 b44_init_rings=0x93/0xa8 [b44]
a020eb0c b44_open+ox263/0327 [b44]
813ce7b8 __dev_change_flags+0xad/ox131
813ce8bd dev_change_flags+0x21/0x57

Additional info:

(Sorry, copied off the screen)

The panic has been in all the 2.6.37 rawhide kernels I've tried, including the previous rc's.

I also grepped the kernel mailing list for the last several weeks, but haven't seen a mention of a b44 problem.

Comment 1 Christos Nouskas 2011-01-09 18:05:48 UTC
I confirm this. As soon as /sbin/ifconfig puts eth0 up, the kernel panics. Dell Vostro laptop with broadcom ethernet card (b44 module) and vanilla 2.6.37 kernel.

Comment 2 Chuck Ebbert 2011-01-11 17:46:52 UTC
Please attach the complete logs from booting the system with the failing kernel. You don't have to bring up the interface.

Comment 3 darrell pfeifer 2011-01-11 18:26:14 UTC
It panics and the boot log doesn't show anything. (I did try several times, and looked but no luck. That's why I resorted to copying and typing the panic message)

Comment 4 Christos Nouskas 2011-01-11 22:43:37 UTC
It doesn't panic when the module is loaded. I double-checked that booting single user. Modprobe-ing b44 is fine; it panics just when I issue "ifconfig eth0 up" (second time let some reasonable time after modprobe before bringing it up).

Comment 5 Christos Nouskas 2011-01-11 22:47:41 UTC
Same message as the original poster's:

Kernel panic - not syncing : map_single : buffer is not DMA'able
PID XXX, comm: ifconfig Not tainted 2.6.37-pf2 #2 x86_64
Call Trace [...]

I know it's not fedora, but I couldn't find a bug report elsewhere and had it both with vanilla and stock archlinux kernel.

Comment 6 Chuck Ebbert 2011-01-13 04:25:43 UTC
Please post the boot log from a successful boot without bringing up the interface. We need to see the messages printed during early boot when the software iommu loads.

Comment 7 darrell pfeifer 2011-01-13 20:47:19 UTC
Created attachment 473422 [details]
dmesg from boot

Dump of initial startup. Was obtained by booting single user and doing a dmesg. Didn't load b44 or ifup the interface.

Comment 8 Chuck Ebbert 2011-01-15 21:24:49 UTC
 PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
 Placing 64MB software IO TLB between ffff8800db400000 - ffff8800df400000
 software IO TLB at phys 0xdb400000 - 0xdf400000

So, the iotlb is above 1GB, but the b44 can only DMA to addresses below that. Does adding "iommu=soft" to the boot options make any difference?

Comment 9 Christos Nouskas 2011-01-15 21:56:36 UTC
I have almost the same dmesg (except for the address ranges starting at db600000).

Appending "iommu=soft" doesn't help, it still panics on "ifconfig eth0 up".

Comment 10 darrell pfeifer 2011-01-15 22:42:40 UTC
Same result for me. Still panics.

Comment 11 Chuck Ebbert 2011-02-01 05:27:43 UTC
Can someone try a 2.6.36 kernel to try and narrow down when this started happening? I tested 2.6.34 and 2.6.35 by forcibly enabling swiotlb and they were both OK.

There's a 2.6.36 kernel for F15 here:


Comment 12 darrell pfeifer 2011-02-01 14:00:52 UTC
That's the last kernel that worked for me. The problem started with the very first 2.6.37 kernel.

Comment 13 Chuck Ebbert 2011-02-01 16:51:55 UTC
(In reply to comment #12)
> That's the last kernel that worked for me. The problem started with the very
> first 2.6.37 kernel.

Can you find the lines like the ones in comment #8 from the 2.6.36 boot messages and post them here?

Comment 14 Christos Nouskas 2011-02-01 17:44:03 UTC
2.6.36 is fine, here's my relevant boot messages:

PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing 64MB software IO TLB between ffff880005c00000 - ffff880009c00000
software IO TLB at phys 0x5c00000 - 0x9c00000

Comment 15 Christos Nouskas 2011-02-02 20:44:05 UTC
I applied the patch proposed at http://groups.google.com/group/linux.kernel/browse_thread/thread/184c7cd190ae7b5a?pli=1 and it works.

PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing 64MB software IO TLB between ffff8800db600000 - ffff8800df600000
software IO TLB at phys 0xdb600000 - 0xdf600000

Comment 16 Fedora Update System 2011-02-28 16:41:56 UTC
Package kernel-2.6.38-0.rc6.git6.1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-2.6.38-0.rc6.git6.1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

Comment 17 darrell pfeifer 2011-03-01 15:02:31 UTC
This fixes the problem for me. Modprobing b44 doesn't cause a panic any more.

Comment 18 Fedora Update System 2011-03-04 09:55:45 UTC
kernel-2.6.38-0.rc6.git6.1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 John W. Linville 2011-04-18 15:12:08 UTC
*** Bug 695370 has been marked as a duplicate of this bug. ***

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