linux-toradex.git/drivers, branch v2.6.17.13

sky2: version 1.6.1

2006-09-08T21:51:40+00:00

Since this code incorporates some of the fixes from 2.6.18, change
the version number.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sky2: fix fiber support

2006-09-08T21:51:40+00:00

Fix support for fiber based devices.  Needed to keep track of PMD type to
add workaround in setup. Add support for gigabit half duplex fiber.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sky2: MSI test timing

2006-09-08T21:51:40+00:00

The test for MSI IRQ could have timing issues. The PCI write needs to be 
pushed out before waiting, and the wait queue should be initialized before
the IRQ.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sky2: use dev_alloc_skb for receive buffers

2006-09-08T21:51:40+00:00

Several code paths assume an additional 16 bytes of header padding
on the receive path. Use dev_alloc_skb to get that padding.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sky2: clear status IRQ after empty

2006-09-08T21:51:40+00:00

Don't clear status IRQ until list has been read to avoid causing
status list wraparound. Clearing IRQ forces a Transmit Status update
if it is pending.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

sky2: accept flow control

2006-09-08T21:51:39+00:00

Don't program the GMAC to reject flow control packets.
This maybe the cause of some of the transmit hangs.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

dm: Fix deadlock under high i/o load in raid1 setup.

2006-09-08T21:51:39+00:00

On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
we experienced frequent deadlock of the system under high i/o load.  'cat
/dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
after a few GB, 'cp' would be left in 'D' state along with kjournald and
kmirrord.  The functions cp and kjournald were blocked in did vary, but
kmirrord's wchan always pointed to 'mempool_alloc()'.  We've seen this pattern
on 2.6.15 and 2.6.17 kernels.  http://lkml.org/lkml/2005/4/20/142 indicates
that this problem has been around even before.

So much for the facts, here's my interpretation: mempool_alloc() first tries
to atomically allocate the requested memory, or falls back to hand out
preallocated chunks from the mempool.  If both fail, it puts the calling
process (kmirrord in this case) on a private waitqueue until somebody refills
the pool.  Where the only 'somebody' is kmirrord itself, so we have a
deadlock.

I worked around this problem by falling back to a (blocking) kmalloc when
before kmirrord would have ended up on the waitqueue.  This defeats part of
the benefits of using the mempool, but at least keeps the system running.  And
it could be done with a two-line change.  Note that mempool_alloc() clears the
GFP_NOIO flag internally, and only uses it to decide whether to wait or return
an error if immediate allocation fails, so the attached patch doesn't change
behaviour in the non-deadlocking case.  Path is against current git
(2.6.18-rc4), but should apply to earlier versions as well.  I've tested on
2.6.15, where this patch makes the difference between random lockup and a
stable system.

Signed-off-by: Daniel Kobras 
Acked-by: Alasdair G Kergon 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Missing PCI id update for VIA IDE

2006-09-08T21:51:39+00:00

The following change from -mm is important to 2.6.18 (actually to 2.6.17
but its too late for that). This was contributed over three months ago
by VIA to Bartlomiej and nothing happened. As a result the new chipset
is now out and Linux won't run on it. By the time 2.6.18 is finalised
this will be the defacto standard VIA chipset so support would be a good
plan.

Tested in -mm for a while, its essentially a PCI ident update but for
the bridge chip because VIA do things in weird ways.


Signed-off-by: Greg Kroah-Hartman

uhci-hcd: fix list access bug

2006-09-08T21:51:39+00:00

When skipping to the last TD of an URB, go to the _last_ entry in the
list instead of the _first_ entry (as780).  This fixes Bugzilla #6747 and
possibly others.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

TG3: Disable TSO by default

2006-09-08T21:51:38+00:00

Disable TSO by default on some chips due to hardware errata.

Enabling TSO can lead to tx timeouts in some cases when the TSO
header size exceeds 80 bytes on the affected chips.  This limit
can be exceeded when the TCP header contains the timestamp option
plus 2 SACK blocks, for example.  A more complete workaround is
available in the next 2.6.18 kernel.

Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman