Skip to content

L
linux-davinci
Switch branch/tag
  1. 24 Apr, 2007 4 commits
  3. 23 Apr, 2007 3 commits
  5. 21 Apr, 2007 13 commits
  7. 20 Apr, 2007 10 commits
  9. 19 Apr, 2007 10 commits
    • Alan Cox's avatar
      pata_sis: Fix oops on boot · f3769e9d
      Alan Cox authored 
      A small number of SiS setups require special handling (not many judging
by how long this dumb bug survived). A couple of Fedora 7 devel testers
hit an Oops on pata_sis loading which is caused by terminal confusion
between chipset as 'the chipset we have found' and chipset as 'array
iterator'
Signed-off-by: default avatarAlan Cox <alan@redhat.com>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      f3769e9d
    • Paul Mackerras's avatar
      [PPP]: Fix skbuff.c:BUG due incorrect logic in process_input_packet() · 7c5050e3
      Paul Mackerras authored 
      From: Paul Mackerras <paulus@samba.org>

This fixes:

Subject: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6

process_input_packet() treats the case where the first byte is 0xff
(PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a
packet with a PPP protocol number of 0xff.  Arguably that's wrong
since PPP protocol 0xff is reserved, and the RFC does envision the
possibility of receiving frames where the control field has values
other than 0x03.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c5050e3
    • Stephen Hemminger's avatar
      sky2: version 1.14 · 93cd791e
      Stephen Hemminger authored 
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      93cd791e
    • Stephen Hemminger's avatar
      sky2: no jumbo on Yukon FE · d2adf4f6
      Stephen Hemminger authored 
      The Yukon FE (100mbit only) chips do not support large packets.
Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      d2adf4f6
    • Stephen Hemminger's avatar
      sky2: EC-U performance and jumbo support · b628ed98
      Stephen Hemminger authored 
      The Yukon EC Ultra chips have transmit settings for store and
forward and PCI buffering. By setting these appropriately, normal
performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo).

It is also possible to do Jumbo mode, but it means turning off
TSO and checksum offload so the performance gets worse. There isn't
enough buffering for checksum offload to work.
Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      b628ed98
    • Stephen Hemminger's avatar
      sky2: disable ASF on all chip types · 4f44d8ba
      Stephen Hemminger authored 
      Need to make sure and disable ASF on all chip types. Otherwise, there may be
random reboots.
Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      4f44d8ba
    • Stephen Hemminger's avatar
      sky2: handle descriptor errors · 40b01727
      Stephen Hemminger authored 
      There should never be descriptor error unless hardware or driver is buggy.
But if an error occurs, print useful information, clear irq, and recover.
Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      40b01727
    • Stephen Hemminger's avatar
      sky2: disable support for 88E8056 · 0a17e4c2
      Stephen Hemminger authored 
      This device is having all sorts of problems that lead to data corruption
and system instability.  It gets receive status and data out of order,
it generates descriptor and TSO errors, etc.

Until the problems are resolved, it should not be used by anyone
who cares about there system.
Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      0a17e4c2
    • Dave Jiang's avatar
      gianfar needs crc32 lib dependency · bf41a7c5
      Dave Jiang authored 
      Gianfar needs crc32 to be selected to compile.
Signed-off-by: default avatarDave Jiang <djiang@mvista.com>

--
 drivers/net/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      bf41a7c5
    • Linas Vepstas's avatar
      spidernet: Fix problem sending IP fragments · 33bdeec8
      Linas Vepstas authored 
      The basic structure of "normal" UDP/IP/Ethernet
frames (that actually work):
 - It starts with the Ethernet header (dest MAC, src MAC, etc.)
 - The next part is occupied by the IP header (version info, length of
packet, id=0, fragment offset=0, checksum, from / to address, etc.)
 - Then comes the UDP header (src / dest port, length, checksum)
 - Actual payload
 - Ethernet checksum

Now what's different for IP fragment:
 - The IP header has id set to some value (same for all fragments),
offset is set appropriately (i.e. 0 for first fragment, following
according to size of other fragments), size is the length of the frame.
 - UDP header is unchanged. I.e. length is according to full UDP
datagram, not just the part within the actual frame! But this is only
true within the first frame: all following frames don't have a valid
UDP-header at all.

The spidernet silicon seems to be quite intelligent: It's able to
compute (IP / UDP / Ethernet) checksums on the fly and tests if frames
are conforming to RFC -- at least conforming to RFC on complete frames.

But IP fragments are different as explained above:
I.e. for IP fragments containing part of a UDP datagram it sees
incompatible length in the headers for IP and UDP in the first frame
and, thus, skips this frame. But the content *is* correct for IP
fragments. For all following frames it finds (most probably) no valid
UDP header at all. But this *is* also correct for IP fragments.

The Linux IP-stack seems to be clever in this point. It expects the
spidernet to calculate the checksum (since the module claims to be able
to do so) and marks the skb's for "normal" frames accordingly
(ip_summed set to CHECKSUM_HW).
But for the IP fragments it does not expect the driver to be capable to
handle the frames appropriately. Thus all checksums are allready
computed. This is also flaged within the skb (ip_summed set to
CHECKSUM_NONE).

Unfortunately the spidernet driver ignores that hints. It tries to send
the IP fragments of UDP datagrams as normal UDP/IP frames. Since they
have different structure the silicon detects them the be not
"well-formed" and skips them.

The following one-liner against 2.6.21-rc2 changes this behavior. If the
IP-stack claims to have done the checksumming, the driver should not
try to checksum (and analyze) the frame but send it as is.
Signed-off-by: default avatarNorbert Eicker <n.eicker@fz-juelich.de>
Signed-off-by: default avatarLinas Vepstas <linas@austin.ibm.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      33bdeec8