Bugs in Linux v2.6.29 drivers

The bugs in this table are from drivers in Linux v2.6.29.

Driver	Bug Details
8139too	Hardware dependence bug. Previously fixed here. The bug is visible here.
8139too	There's a race condition during driver unload when using the 8129 chip with this driver. Fixed here. The bug is visible here.
be2net	Calling netif_stop_queue before calling register_netdev. Fixed here. Bug is visible here.
be2net	Calling netif_carrier_off before calling register_netdev. Fixed here. Bug is visible here.
be2net	be_open returns errors but the TX queue is still marked as running. It should be stopped. Fixed here. Bug is visible here.
be2net	be_probe() returns positive numbers on error under some circumstances. It's unclear whether this is fixed. It likely is since this driver has been significantly modified since the 2.6.29 implementation, including the file be_cmds.c, which is where the original bug originated.
be2net	be_open() also returns positive numbers on error under some circumstances. Fixed here. Bug is visible here, though you'll have to find the locations that could generate the positive numbers. It's not obvious since the the driver propagates the invalid return values throughout the call stack.
be2net	Hardware dependence bug. be_tx_compl_get returns an unexpected value from the hardware in be_poll_tx, and this causes be_tx_compl_process to be called and fail with the BUG_ON. This bug has likely not been fixed. Bug is visible here.
be2net	During cleanup: be_exit_module -> be_remove -> be_close -> napi_disable -> be_poll_tx -> netif_wake_queue. This code path starts the tx queue during the shutdown sequence after the driver had called netif_stop_queue to disable it. It appears to be a race condition since be_poll_tx is clearly not called by napi_disable -- the stack is mixing up two threads. It's unclear whether this is fixed. Bug is visible here.
be2net (Not counted as a bug)	cleanup_module -> be_exit_module -> be_remove -> be_close -> be_rx_queues_destroy -> be_rx_q_clean -> get_rx_page_info -> pci_unmap_page. The problem here is that pci_unmap_page is freeing something it never allocated. Probably fixed here but it's unclear how precisely this happened. Since this bug is too complex to verify we don't count it.
dl2k	Hardware dependence bug in the shutdown routine rio_close. The problem is that it calls pci_unmap_single and passes in the parameter desc_to_dma(&np->rx_ring[i]). np->rx_ring is DMA memory allocated in rio_probe1 with the pci_alloc_consistent function. So, np->rx_ring[i].fraginfo could be anything, but that's what desc_to_dma is looking at. This bug is unfixed. Bug is visible here.
e1000	Driver incorrectly calls netif_stop_queue before calling register_netdev. Fixed here. Bug is visible here.
e1000	Calls netif_carrier_off before register_netdev. Fixed here. Bug is visible here.
e1000	There was a pci_map_page/pci_map_single/pci_unmap_page/pci_unmap_single mismatch. SymDrive found this using the object tracker mechanism. It was likely fixed here but we're unsure. The bug is distributed throughout the e1000_main.c file, here here.
econet	Reported here. Fixed here (and here). Bug is visible here.
econet	Reported here. Fixed here (and here). Bug is visible here.
et131x	Calls netif_carrier_off() before register_netdev. See et131x_link_detection_handler. Called in et131x_pci_setup. Fixed here. Bug visible here.
et131x	Hardware dependence bug, similar to that in dl2k. Function is pci_unmap_single in et131x_free_send_packet. The driver passes in addresses stored in DMA memory. It is unknown whether this bug is fixed. Bug is visible here.
forcedeth	There is a pci_map_single/map_page/unmap_single/unmap_page mismatch in nv_release_txskb. forcedeth doesn't use the DMA api quite right in its transmit completion path and in nv_loopback_test(). pci_map_single() should be paired with pci_unmap_single() and pci_map_page() should be paired with pci_unmap_page(). However, the forcedeth transmit path uses pci_map_single() and pci_map_page(), but the transmit completion path only uses pci_unmap_single(). Similarly, nv_loopback_test() uses pci_map_single() and pci_unmap_page(). This bug is fixed here. The bug is distributed throughout the forcedeth driver, here.
me4000	Copy/paste bug in me4000_open in which the developer accidentally passed the wrong parameter to spin_lock. The driver contains spin_lock(&cnt_context->use_lock);, but this is incorrect. Instead, it should be ext_int_context. This bug was fixed in the copy of the driver available from the manufacturer (here). However, the Linux kernel dropped the me4000 driver some time after the release of 2.6.29, and merged its functionality with the comedi driver, rendering this bug largely obsolete. Bug is visible here.
pcnet32 (Counted as one bug)	pcnet32_set_ringparam. This function does spin_lock_irqsave(lp->lock). It then calls pcnet32_realloc_rx_ring and pcnet32_realloc_tx_ring, which both call pci_free_consistent. This is is a "might sleep" function, and so produces kernel warnings (via WARN_ON(irqs_disabled()); in dma_free_coherent). Neither of these bugs is fixed. Bug is visible here.
pluto2	Data structures not initialized in right order. The problem here is that Pluto2 is doing a request_irq before it has initialized all necessary kernel data structures. If the device generates an interrupt, it may invoke pluto_dma_end. pluto_dma_end calls dvb_dmx_swfilter_packets This function assumes struct dvb_demux (demux)->lock is initialized. But pluto2 does not initialize this variable until after request_irq finishes -- it's initialized via dvb_dmx_init(dvbdemux); in pluto2_probe but that's after the request_irq call. This bug is not fixed and is distributed throughout the driver, here.
pluto2	tda1004x_release is never called anywhere. tda10046_attach allocates memory with kmalloc but never frees it. Pluto2 does not call the release routine (ops.release), but does call it in frontend_init on an error path. However, it does not call it during proper device shutdown. Moreover, dvb_frontend_detach is never called, which might have the effect of calling ops.release(). In other words, the problem is that this driver is calling tda10046_attach but not releasing it. The proper way is via dvb_frontend_detach. Moreover, the correct way to attach appears to be via dvb_attach, and pass tda10046_attach as an argument. Interestingly, the patch that adds dvb_frontend_detach says: "Remove buggy dvb_detach() macro and replace with unified dvb_frontend_detach() call. This bug is not fixed and is distributed throughout the driver, here.