Tx descriptor overflow - take II.

Assume tp->dirty_tx = NUM_TX_DESC/2, tp->cur_tx = NUM_TX_DESC - 1,
watch "entry" go beyond NUM_TX_DESC. Actually this is where the same
bug in r8169 driver comes from.

From: Pablo Menichini <pablo@menichini.com.ar>
and maximilian attems <janitor@sternwelten.at>


while looking at kj mails from 200212 and 200301
this patch slept through
originally from: Pablo Menichini <pablo@menichini.com.ar>
rediffed and compile tested
patch applies on plain 2.6.0

maximilian attems <janitor@sternwelten.at>

handle kmalloc failures during init

diff -puN drivers/net/tokenring/3c359.c~tr3c_kmalloc drivers/net/tokenring/3c359.c


 linux-261-bk4-kj1-rddunlap/drivers/net/tokenring/3c359.c |   13 +++++++++++++
 1 files changed, 13 insertions(+)

The transmit routine will stop interrupting and hang, causing the
tx_timeout routine to attempt to restart the device when the 32-bit
cur_tx counter wraps below dirty_tx.  If the device had called
netif_stop_queue it will never call netif_wake_queue in the interrupt
routine (at least on an IA32 system) due to 32-bit wrap around arithmetic.

On my IA32 system 'dirty_tx > lp->cur_tx - TX_RING_SIZE + 2' would
always evaluate to false when dirty and cur_tx were less than 15,
preventing netif_wake_queue to be called.

By starting dirty_tx and cur_tx at 0xfffffff0 (to reduce test time) I
found that once cur_tx wrapped to zero, that transmitted buffers would
never be unmapped or freed because 'while (dirty_tx < lp->cur_tx) {'
was not true.  cur_tx would keep incrementing (in start_xmit) but dirty_tx
would not (in pcnet32_interrupt), thus leaking skb's and pci map entries.
On PPC machines, the system would quickly run out of pci maps.

Fix tested on PPC and IA32.

description:      remove double semi-colon typo;

Add capability to tag self generated ARP packets that are required
for receive load balancing in bonding. VLAN Id's are saved and used
each time a new IP connection is established since 8021q currently
supports IP binding.

Update module version and comment blocks.

Add capability to tag self generated learning packets that are
required to speed up port selection in the switch after a fail
over in bonding since some switches will only update their MAC
tables from tagged packets when VLAN support is turned on. All
VLAN Id's that have been configured on top of the bond interface
will be used in cyclic order.

Now that David Miller accepted the first half of this set into 2.6,
I'm resending the last half to you for inclusion in netdev-2.6.

Tested against latest netdev-2.6. Summary:

Change the bond interface to publish full VLAN hardware acceleration
offloading capabilities, and add capability in all xmit functions to
take special care for VLAN HW accel. tagged skb's that are going out
through a slave that is not offloading capable.

Add a mechanism to collect and save the VLAN Id's that have been
added on top of a bond interface, and propagate the register/add/kill
operations to the slaves.

Add blocking mechanism to prevent adding VLAN interfaces on top of a
bond that contains VLAN challenged slaves and to prevent adding VLAN
challenged slaves to a bond that already has VLAN interfaces on top
of it.

Add a section about VLAN to Documentation/networking/bonding.txt and
also correct some minor spelling/grammer errors.

This patch is the same as to mkiss a while ago, the current code triggers a
bug when reattaching a network device.

to uniquely identify the files, it's necessary to add the version of
each file. Please, don't remove the revision infos. It's really
important for us.

Patch 2/2
[SK98LIN]: Insert revision version and date [back] into the files

Patch 1/2
[SK98LIN]: Added Support for Belkin adapter
[SK98LIN]: Don't handle Yukon2 cards at the moment

The pcnet32 driver uses the incorrect length (of zero) in
pci_[un]map_single for receive buffers.  This is seen with SLAB_DEBUG
enabled.

Tested in IA32 system.  If this patch is not applied after my previous
one hunks #1, #3, and #5 will have an offset of -2 lines.

Jean discovered problem with my hp100 PCI changes.
This should fix the problem... The multi-bus probe logic error handling was
botched.

He validated it; so please apply

Here is the first of several individual patches to 2.6.3 for the pcnet32
driver.

The driver did not properly serialize accesses to chip registers, resulting
in reading/writing the wrong register.  This patch eliminates this problem
and gets rid of the cause of the symptom of 'bus master arbitration failure'.

It was easier to use generic_mii_ioctl than modify the current pcnet32_ioctl
routine with the necessary locks.  This has been re-tested on an IA32 system.

P4 support was previously ifdefed out for x86-64, remove that.

Enable the Intel AGP driver for x86-64 too.

The microcode driver needs to support 64bit physical addresses too.

This has all the x86-64 specific changes for Intel Prescott/Nocona
support.

It requires a few minor changes outside arch/x86_64, which I am sending
separately.

This patch is needed to boot an 64bit kernel on a 64-bit capable
Prescott machine.

The ugliest part is probably the swiotlb code.  In fact the code for
that is not even included, but just reused from IA64.  swiotlb
implements the PCI DMA API using bounce buffering.  I don't like this at
all, but there was no other way to support non DAC capable hardware
(like IDE or USB) on machines with >3GB.  Please redirect all flames for
that to the Intel chipset designers.

ChangeLog:
- Add Kconfig options for PSC
- Add support to reuse microcode driver from i386 (Suresh B Siddha)
- Try to optimize for the selected CPU
- Fix early CPUID check for Intel CPUs (Suresh B Siddha)
- Fix GDT to use the configured cache line size for padding
- Support monitor/mwait idle loop
- Support HyperThreading
- Support Intel CPUID flags
- Remove all 3dnow prefetches
- Add alternative() for the prefetchw prefetch inline.
- Include P4 driver in oprofile
- Support Intel NOPs in alternative

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

into redhat.com:/spare/repo/net-drivers-2.5

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-7

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-6

into kernel.bkbits.net:/home/davem/tg3-2.6

into kernel.bkbits.net:/home/davem/net-2.6

into redhat.com:/spare/repo/netdev-2.6/netdev-alloc-7

From: Neal Stephenson <neal@bakerst.org>

In 2.6.2, I noticed that my modprobe.conf line for tuner "options tuner
type=2" no longer worked.  It even failed with insmod "insmod tuner.ko
type=2".  dmesg reported

vmunix: tuner: chip found @ 0xc0
vmunix: tuner: type set to 19 (Temic PAL* auto (4006 FN5))
vmunix: tuner: type forced to 19 (Temic PAL* auto (4006 FN5)) [insmod]

I noticed that the a line had been removed from 2.6.1 and when it is added
everything works again.

into nuts.davemloft.net:/disk1/BK/net-2.6

into nuts.davemloft.net:/disk1/BK/net-2.6

Disable the RADEON_PARAM_SAREA_HANDLE ioctl on 64-bit architectures,
since it is only used on some embedded platforms, and it isn't 64-bit
safe.

drivers that need it. 

This allows us to have I2C as a module iff the FB driver
that needs it is a module.

This allows us to do something like

	config FB_RADEON
		select I2C_ALGOBIT if FB_RADEON_I2C

where FB_RADEON_I2C itself depends on FB_RADEON without getting a bogus
warning about recursive dependencies.

This matters because the select takes the default minimum dependancy
from the parent menu, so we want to do this under FB_RADEON rather than
under FB_RADEON_I2C (so that the I2C_ALGOBIT config depends properly
on the state of FB_RADEON)

	We used to have sync_blockdev() on each normal (== non-raw)
blkdev_put() + kill_bdev() on the final blkdev_put().  That worked
fine until we'd moved sync_blockdev() to the final blkdev_put().

	Now we have a nasty scenario:

open block device
open raw device
write on block device	# data ends up in cache
close block device	# no sync here, we still have the sucker opened
close raw device	# no sync here either
			# ... and cache is killed by kill_bdev()

	IOW, if we postpone sync to final close, we must do it regardless of
kind of close.  Otherwise we are in for data corruption and yes, it is easy
to trigger.  Fix is obvious...

1) First action must be to set MAC_EVENT to zero.
2) Do not forget to clear MI_COMPLETION/LNKSTATE_CHANGED
   status bits in MAC_STATUS register.

This fixes the bug wherein the link does not come up at all
at the first ifup done after tg3 module load.