The PCI-E slot on T1000 connects directly to the Fire PCI chip with no
intervening bridges visible in the OBP tree.
Unfortunately the bus numbering of the device in that slot is
different (2) from the PCI host controller (0), and thus the
pci_bus_{read,write}_config_*() calls don't work out.
Complicating things further the Fire PCI controller has no config
space it responds to either.
For now treat this case specially so that devices in the slot work.
Longer term we need to perhaps cons up a dummy bridge between the Fire
and the PCI-E slot so that the bus hierarchy is complete inside of the
kernel and thus the bus numbering all works out right.
Signed-off-by: David S. Miller <davem@davemloft.net>
We should only use ports underneath "domain-services", other DS ports
in the MDESC aren't for us to use.
Signed-off-by: David S. Miller <davem@davemloft.net>
It doesn't matter for use in 64-bit objects, but when used in
32-bit environments the top 32-bits of the local and in
registers will get chopped off on the next register window
spill/restore which leads to difficult to track down and
subtle bugs.
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Fix missing load-twin usage in Niagara-1 memcpy.
[SPARC64]: Fix put_user() calls in binfmt_aout32.c
[SPARC]: Fix EBUS use of uninitialized variable.
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[IEEE80211]: avoid integer underflow for runt rx frames
[TCP]: secure_tcp_sequence_number() should not use a too fast clock
[SFQ]: Remove artificial limitation for queue limit.
DMA-mapped SMP (scsi management protocol) requests going /to/ the device
need the PCI DMA data direction to indicate such.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
dm9601 didn't take the ethernet header into account when calculating
RX MTU, causing packets bigger than 1486 to fail.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This driver erroneously zeros dev->tx_queue_len, since
mp->tx_ring_size has not yet been initialized. Actually,
the driver shouldn't modify tx_queue_len at all and should
leave the value set by alloc_etherdev(), currently 1000.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix 4032 chip undocumented "feature" where bit-8 is set
if the inbound completion is for a VLAN.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
There's a different version of DMI table for TECRA M3 where it has
proper vendor and product name entry. Add the entry to the broken
suspend list.
Angus Turnbull reported and provided initial patch.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Angus Turnbull <angus@twinhelix.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
For the case where the source is not aligned modulo 8
we don't use load-twins to suck the data in and this
kills performance since normal loads allocate in the
L1 cache (unlike load-twin) and thus big memcpys swipe
the entire L1 D-cache.
We need to allocate a register window to implement this
properly, but that actually simplifies a lot of things
as a nice side-effect.
Signed-off-by: David S. Miller <davem@davemloft.net>
Reported by Chris Evans <scarybeasts@gmail.com>:
> The summary is that an evil 80211 frame can crash out a victim's
> machine. It only applies to drivers using the 80211 wireless code, and
> only then to certain drivers (and even then depends on a card's
> firmware not dropping a dubious packet). I must confess I'm not
> keeping track of Linux wireless support, and the different protocol
> stacks etc.
>
> Details are as follows:
>
> ieee80211_rx() does not explicitly check that "skb->len >= hdrlen".
> There are other skb->len checks, but not enough to prevent a subtle
> off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag
> set.
>
> This leads to integer underflow and crash here:
>
> if (frag != 0)
> flen -= hdrlen;
>
> (flen is subsequently used as a memcpy length parameter).
How about this?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.
Problem spotted by Denys Fedoryshchenko
[ This bug was introduced by f859581519 ]
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the whole range of hash values.
Switched to Jenkins' hash.
Signed-off-by: Alexey Kuznetsov <kaber@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
For some reason old binutils genertate larger headers so increase the text
offset of the vdso to avoid linker errors.
Roland McGrath explains:
"There are extra symbols in the '.dynsym' section that are responsible
for the size difference (They also cause corresponding inflation in
'.gnu.version')
Older ld's wrongly generated these unneeded symbols in .dynsym. This
was fixed not all that long ago (2006); binutils-2.17.50.0.6 might be
the first fixed version, but I have not verified for sure where the
cutoff was.
The unneeded symbols et al from old ld add almost 700 bytes excess.
This limits fairly tightly the amount by which the actual text and
data in the vDSO can grow in the future without pushing the whole
file over 4kb. If it does grow later on, we should consider changing
the layout with a config option or something to pack it better
without that padding, when building the kernel with newer binutils."
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Roland McGrath <roland@redhat.com>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David S. Miller
Linus Torvalds
Jeff Garzik
Peter Korsgaard
Dale Farnsworth
Ron Mercer
Tejun Heo
Ingo Molnar
John W. Linville
Eric Dumazet
Alexey Kuznetsov
Andi Kleen