iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on pasemi_mac, since
the device only exists as part of a big-endian system-on-chip, but
fixing this gets rid of a sparse warning and avoids having a bad example
in the tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
iph->tot_len is stored in network byte order, so access it using
ntohs(). This doesn't have any real world impact on ehea, since ehea
only exists for big-endian platfroms (at the moment at least) but fixing
this gets rid of a sparse warning and avoids having a bad example in the
tree.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When ehea_stop is called the function
cancel_work_sync(&port->reset_task) is used to ensure
that the reset task is not running anymore. We need an
additional flag to ensure that it can not be scheduled
after this call again for a certain time.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Required to allow distros to easily detect when ehea
module needs to be loaded
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
A mutex has to be replaced by spinlocks as it can be called from
a context which does not allow sleeping.
The kzalloc flag GFP_KERNEL has to be replaced by GFP_ATOMIC
for the same reason.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
After enabling CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING I get the
following warning when ethtool -s is first called on one of the
forcedeth ports:
=================================
[ INFO: inconsistent lock state ]
2.6.26-rc4 #28
---------------------------------
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
ethtool/1985 [HC0[0]:SC0[1]:HE1:SE0] takes:
(&np->lock){++..}, at: [<ffffffffa000c5fd>] nv_set_settings+0xc8/0x3de [forcedeth]
{in-hardirq-W} state was registered at:
[<ffffffffffffffff>] 0xffffffffffffffff
irq event stamp: 3606
hardirqs last enabled at (3605): [<ffffffff8068106f>] _spin_unlock_irqrestore+0x3f/0x68
hardirqs last disabled at (3604): [<ffffffff80680d38>] _spin_lock_irqsave+0x13/0x46
softirqs last enabled at (3534): [<ffffffff80246ba5>] __do_softirq+0xbc/0xc5
softirqs last disabled at (3606): [<ffffffff80680b33>] _spin_lock_bh+0x11/0x41
other info that might help us debug this:
2 locks held by ethtool/1985:
#0: (rtnl_mutex){--..}, at: [<ffffffff80596072>] rtnl_lock+0x12/0x14
#1: (_xmit_ETHER){-+..}, at: [<ffffffffa000c5e8>] nv_set_settings+0xb3/0x3de [forcedeth]
stack backtrace:
Pid: 1985, comm: ethtool Not tainted 2.6.26-rc4 #28
Call Trace:
[<ffffffff8025f190>] print_usage_bug+0x162/0x173
[<ffffffff8025fa8b>] mark_lock+0x231/0x41f
[<ffffffff802607cf>] __lock_acquire+0x4e7/0xcac
[<ffffffff8025fe64>] ? trace_hardirqs_on+0xf1/0x115
[<ffffffff80272c3a>] ? disable_irq_nosync+0x6f/0x7b
[<ffffffff80261375>] lock_acquire+0x55/0x6e
[<ffffffffa000c5fd>] ? :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff80680b15>] _spin_lock+0x2f/0x3c
[<ffffffffa000c5fd>] :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff8058f8bb>] dev_ethtool+0x186/0xea3
[<ffffffff8067f446>] ? mutex_lock_nested+0x243/0x275
[<ffffffff8025df2b>] ? debug_mutex_free_waiter+0x46/0x4a
[<ffffffff8067f469>] ? mutex_lock_nested+0x266/0x275
[<ffffffff8058e1ce>] dev_ioctl+0x4eb/0x600
[<ffffffff8068106f>] ? _spin_unlock_irqrestore+0x3f/0x68
[<ffffffff80580f91>] sock_ioctl+0x1f5/0x202
[<ffffffff802a322e>] vfs_ioctl+0x2a/0x77
[<ffffffff802a34d6>] do_vfs_ioctl+0x25b/0x270
[<ffffffff806807b6>] ? trace_hardirqs_on_thunk+0x35/0x3a
[<ffffffff802a352d>] sys_ioctl+0x42/0x65
[<ffffffff8021fffb>] system_call_after_swapgs+0x7b/0x80
This is caused by the following snippet in nv_set_settings:
netif_carrier_off(dev);
if (netif_running(dev)) {
nv_disable_irq(dev);
netif_tx_lock_bh(dev);
spin_lock(&np->lock);
/* stop engines */
nv_stop_rxtx(dev);
spin_unlock(&np->lock);
netif_tx_unlock_bh(dev);
}
Because of nv_disable_irq this is probably not really a problem
though (I guess) and replacing the spin_lock with spin_lock_irqsave
could keep interrupts disabled for a longer period of time because
of delays in nv_stop_rx and nv_stop_tx.
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Commit 4c13eb6657 ([ETH]: Make
eth_type_trans set skb->dev like the other *_type_trans) removed
skb->dev assignment from hdlc_fr.c:fr_rx(). Unfortunately it was also
needed for cases other than eth_type_trans().
Adding it back.
It's quite serious and may be a security risk as it causes a wrong
input interface indication (the physical hdlcX instead of logical
pvcX). Probably -stable class fix.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When converting the page number in a pte/pmd/pud/pgd between
machine and pseudo-physical addresses, the converted result was
being truncated at 32-bits. This caused failures on machines
with more than 4G of physical memory.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: "Christopher S. Aker" <caker@theshore.net>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The branch optimization fixes in 2.6.21 introduced a bug in
atomic_sub_if_positive that causes it to return even when the sc
instruction fails. The result is that e.g. down_trylock becomes unreliable
as the semaphore counter is not always decremented.
Original MUA-shredded patch from Morten Larsen <mlarsen@broadcom.com>.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: adding comment for ipaq forcing number of ports
USB: fix Oops on loading ipaq module since 2.6.26
USB: add a pl2303 device id
USB: another option device id
USB: don't lose disconnections during suspend
USB: fix interrupt disabling for HCDs with shared interrupt handlers
USB: New device ID for ftdi_sio driver
sisusbvga: Fix oops on disconnect.
USB: mass storage: new id for US_SC_CYP_ATACB
USB: ohci - record data toggle after unlink
USB: ehci - fix timer regression
USB: fix cdc-acm resume()
OHCI: Fix problem if SM501 and another platform driver is selected
The reason for forcing a number of ports should be documented.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thanks to umesh b <umesh.kollam@gmail.com> for the information here.
Cc: umesh b <umesh.kollam@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1111) fixes a bug in the hub driver. When a hub
resumes, disconnections that occurred while the hub was suspended are
lost.
A completely different fix for this problem has already been accepted
for 2.6.27; however the problem still needs to be handled in 2.6.26.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix interrupt disabling for HCDs with shared interrupt handlers
As has been discussed several times on LKML, IRQF_SHARED | IRQF_DISABLED
doesn't work reliably, i.e. a shared interrupt handler CAN'T be certain to
be called with interrupts disabled. Most USB HCD handlers use IRQF_DISABLED
and therefore havoc can break out if they share their interrupt with a
handler that doesn't use it.
On my test machine the yenta_socket interrupt handler (no IRQF_DISABLED)
was registered before ehci_hcd and one uhci_hcd instance. Therefore all
usb_hcd_irq() invocations for ehci_hcd and for one uhci_hcd instance
happened with interrupts enabled. That led to random lockups as USB core
HCD functions that acquire the same spinlock could be called twice
from interrupt handlers.
This patch updates usb_hcd_irq() to always disable/restore interrupts.
usb_add_hcd() will silently remove any IRQF_DISABLED requested from HCD code.
Signed-off-by: Stefan Becker <stefan.becker@nokia.com>
Cc: stable <stable@kernel.org>
Acked-by: David Brownell <david-b@pacbell.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a new device ID for the ftdio_sio driver.
The diff is with linus's tree as of this morning.
The device is the RigExpert Tiny USB Soundcard Transceiver Interface for ham
radio.
(I didn't actually test this. A fellow ham couldn't get the device to work, and
I suggested binding the device ID using sysfs - see
"http://jk.ufisa.uninett.no/usb/". However, he had had moved on to other things
by then. I guess adding the device ID to the kernel "on spec" won't hurt.
The relevant part of cat /proc/bus/usb/devices shows:
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=ed22 Rev= 5.00
S: Manufacturer=FTDI
S: Product=MixW RigExpert Tiny
S: SerialNumber=00000000
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
)
From: Jon K Hellan <hellan@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove dev_info call on disconnect. The sisusb_dev pointer may have been
set to zero by sisusb_delete at this point causing an oops.
The message does not provide any extra information over the standard USB
subsystem output so removing it does not affect functionality.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a problem with OHCI where canceling bulk or
interrupt URBs may lose track of the right data toggle. This
seems to be a longstanding bug, possibly dating back to the
Linux 2.4 kernel, which stayed hidden because
(a) about half the time the data toggle bit was correct;
(b) canceling such URBs is unusual; and
(c) the few drivers which cancel these URBs either
[1] do it only as part of shutting down, or
[2] have fault recovery logic, which recovers.
For those transfer types, the toggle is normally written back
into the ED when each TD is retired. But canceling bypasses
the mechanism used to retire TDs ... so on average, half the
time the toggle bit will be invalid after cancelation.
The fix is simple: the toggle state of any canceled TDs are
propagated back to the ED in the finish_unlinks function.
(Issue found by leonidv11@gmail.com ...)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Leonid <leonidv11@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a regression in the EHCI driver's TIMER_IO_WATCHDOG
behavior. The patch "USB: EHCI: add separate IAA watchdog timer" changed
how that timer is handled, so that short timeouts on the remaining
timer (unfortunately, overloaded) would never be used.
This takes a more direct approach, reorganizing the code slightly to
be explicit about only the I/O watchdog role now being overridable.
It also replaces a now-obsolete comment describing older timer behavior.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Leonid <leonidv11@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cdc-acm has
- a memory leak in resume()
- will fail to reactivate the read code path if this is needed.
his corrects it by deleting the useless relict code.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the SM501 and another platform driver, such as the SM501
then we end up defining PLATFORM_DRIVER twice. This patch
seperated the SM501 onto a seperate define of SM501_OHCI_DRIVER
so that it can be selected without overwriting the original
definition.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
To return garbage_args, the accept_stat must be 0, and we must have a
verifier. So we shouldn't be resetting the write pointer as we reject
the call.
Also, we must add the two placeholder words here regardless of success
of the unwrap, to ensure the output buffer is left in a consistent state
for svcauth_gss_release().
This fixes a BUG() in svcauth_gss.c:svcauth_gss_release().
Thanks to Aime Le Rouzic for bug report, debugging help, and testing.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Tested-by: Aime Le Rouzic <aime.le-rouzic@bull.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Due to a possible deadlock, the waking of the softirq was pushed outside
of the hrtimer base locks. See commit 0c96c5979a
Unfortunately this allows the task to migrate after setting up the softirq
and raising it. Since softirqs run a queue that is per-cpu we may raise the
softirq on the wrong CPU and this will keep the queued softirq task from
running.
To solve this issue, this patch disables preemption around the releasing
of the hrtimer lock and raising of the softirq.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The txx9_tmr_init() will not clear a timer counter register in a certain
case. The counter register is cleared on 1->0 transition of TCE bit if
CRE=1. So just clearing the TCE bit is not enough.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The introduction of a real dma cache invalidate makes it important
to have a correct cache line size, otherwise the kernel will gives
out two memory segment, which might share one cache line. The R4400
Indy/Indigo2 CPU modules are using a second level cache line size
of 128 bytes, so MIPS_L1_CACHE_SHIFT needs to be bumped up to 7 for
IP22.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It's possible that the crime interrupt handler is called without
pending interrupts (probably a hardware issue). To avoid irritating
"unexpected irq 71" messages, we now just ignore the spurious crime
interrupts.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The non-NUMA case of build_zonelist_cache() would initialize the
zlcache_ptr for both node_zonelists[] to NULL.
Which is problematic, since non-NUMA only has a single node_zonelists[]
entry, and trying to zero the non-existent second one just overwrote the
nr_zones field instead.
As kswapd uses this value to determine what reclaim work is necessary,
the result is that kswapd never reclaims. This causes processes to
stall frequently in low-memory situations as they always direct reclaim.
This patch initialises zlcache_ptr correctly.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Tested-by: Dan Williams <dan.j.williams@intel.com>
[ Simplified patch a bit ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The 192 byte cache is not necessary if we have a basic alignment of 128
byte. If it would be used then the 192 would be aligned to the next 128 byte
boundary which would result in another 256 byte cache. Two 256 kmalloc caches
cause sysfs to complain about a duplicate entry.
MIPS needs 128 byte aligned kmalloc caches and spits out warnings on boot without
this patch.
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
The legacy protocol's open operation doesn't handle an append operation
(it is expected that the client take care of it). We were incorrectly
passing the extended protocol's flag through even in legacy mode. This
was reported in bugzilla report #10689. This patch fixes the problem
by disallowing extended protocol open modes from being passed in legacy
mode and implemented append functionality on the client side by adding
a seek after the open.
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Unregistering a bridge device may cause virtual devices stacked on the
bridge, like vlan or macvlan devices, to be unregistered as well.
br_cleanup_bridges() uses for_each_netdev_safe() to iterate over all
devices during cleanup. This is not enough however, if one of the
additionally unregistered devices is next in the list to the bridge
device, it will get freed as well and the iteration continues on
the freed element.
Restart iteration after each bridge device removal from the beginning to
fix this, similar to what rtnl_link_unregister() does.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
<used> should be of type int (not size_t) since recv_actor can return
negative values and it is also used in a < 0 comparison.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
alpha:
net/ipv4/tcp.c: In function 'tcp_calc_md5_hash':
net/ipv4/tcp.c:2479: error: implicit declaration of function 'sg_init_table' net/ipv4/tcp.c:2482: error: implicit declaration of function 'sg_set_buf'
net/ipv4/tcp.c:2507: error: implicit declaration of function 'sg_mark_end'
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
fix this warning:
arch/x86/mm/init_64.c: In function 'early_memtest':
arch/x86/mm/init_64.c:524: warning: passing argument 2 of 'find_e820_area_size' from incompatible pointer type
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fedora reports that mem_init()'s zap_low_mappings(), extended to SMP in
61165d7a03 x86: fix app crashes after SMP
resume causes 32-bit Intel Mac machines to reboot very early when
booting with EFI.
The EFI code appears to manage low mappings for itself when needed; but
like many before it, confuses PSE with PAE. So it has only been mapping
half the space it needed when PSE but not PAE. This remained unnoticed
until we moved the SMP zap_low_mappings() before
efi_enter_virtual_mode(). Presumably could have been noticed years ago
if anyone ran a UP kernel on such machines?
Reported-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Glauber Costa <gcosta@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Peter Jones <pjones@redhat.com>
* 'i2c-fix' of git://aeryn.fluff.org.uk/bjdooks/linux:
I2C: S3C2410: Add MODULE_ALIAS() for s3c2440 device.
I2C: S3C2410: Fixup error codes returned rom a transfer.
I2C: S3C2410: Check ACK on byte transmission
* 'for-2.6.26' of git://git.kernel.dk/linux-2.6-block:
Properly notify block layer of sync writes
block: Fix the starving writes bug in the anticipatory IO scheduler
* git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb:
V4L/DVB (8178): uvc: Fix compilation breakage for the other drivers, if uvc is selected
V4L/DVB (8145a): USB Video Class driver
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] 5131/1: Annotate platform_secondary_init with trace_hardirqs_off
[ARM] 5117/1: pxafb: fix __devinit/exit annotations
[ARM] Export dma_sync_sg_for_device()
[ARM] 5109/1: Mark rtc sa1100 driver as wakeup source before registering it
[ARM] 5116/1: pxafb: cleanup and fix order of failure handling
[ARM] 5115/1: pxafb: fix ifdef for command line option handling
ARM: OMAP: Correcting the gpmc prefetch control register address
ARM: OMAP: DMA: Don't mark channel active in omap_enable_channel_irq
Not sure how this came to get inverted but it appears to have been my
mess up.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
sched: fix divide error when trying to configure rt_period to zero
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
i2c: Fix bad hint about irqs in i2c.h
i2c: Documentation: fix device matching description
