Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it causes random memory corruptions on systems
Manfred Spraul wrote: Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it causes random memory c
Jeff Garzik wrote: Manfred Spraul wrote: Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it cau
Good catch. Btw, should we perhaps disallow (or at least WARN_ON()) pci_map_single() with a length of zero? I think it's always likely a bug.. However, that "skb->end - skb->data" calculation is a bi
Linus Torvalds wrote: Of course, on the alloc path, it seems to add an additional "NV_RX_ALLOC_PAD" thing, so maybe the "end-data" thing makes sense. The problem is the pci_unmap_single() call that h
These proper text encodings are easy to _apply_, because the raw email is uncorrupted. However, attachments are still broken for a very fundamental reason: basically no email client will ever quote t
"skb->end - skb->data" calculation is a bit strange. It correctly maps the whole skb, but nod wouldn't it make more sense to use the length we actually tell the card to use? In other words, wouldn't
Linus Torvalds wrote: On Sat, 24 Dec 2005, Manfred Spraul wrote: Linus Torvalds wrote: Of course, on the alloc path, it seems to add an additional "NV_RX_ALLOC_PAD" thing, so maybe the "end-data" thi
Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it causes random memory corruptions on systems
Manfred Spraul wrote: Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it causes random memory c
Two critical bugs were found in forcedeth 0.47: - TSO doesn't work. - pci_map_single() for the rx buffers is called with size==0. This bug is critical, it causes random memory corruptions on systems
Good catch. Btw, should we perhaps disallow (or at least WARN_ON()) pci_map_single() with a length of zero? I think it's always likely a bug.. However, that "skb->end - skb->data" calculation is a bi
Of course, on the alloc path, it seems to add an additional "NV_RX_ALLOC_PAD" thing, so maybe the "end-data" thing makes sense. The problem is the pci_unmap_single() call that happens during nv_close
These proper text encodings are easy to _apply_, because the raw email is uncorrupted. However, attachments are still broken for a very fundamental reason: basically no email client will ever quote t
"skb->end - skb->data" calculation is a bit strange. It correctly maps the whole skb, but nod wouldn't it make more sense to use the length we actually tell the card to use? In other words, wouldn't
Of course, on the alloc path, it seems to add an additional "NV_RX_ALLOC_PAD" thing, so maybe the "end-data" thing makes sense. The problem is the pci_unmap_single() call that happens during nv_clos