Based upon a report from Michael Tokarev <mjt@tls.msk.ru>:
Just saw in dmesg:
ioctl32(kvm:4408): Unknown cmd fd(9) cmd(800454cf){t:'T';sz:4} arg(ffc668e4) on /dev/net/tun
Signed-off-by: David S. Miller <davem@davemloft.net>
This documentation is old. Add a short note to describe why aliases
are no long necessary, and remove the old contact/edit info.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It oopsd for me in skb_seq_read. addr2line said it was
linux-2.6/net/core/skbuff.c:2228, which is this line:
while (st->frag_idx < skb_shinfo(st->cur_skb)->nr_frags) {
I added some printks in there and it looks like we hit this:
} else if (st->root_skb == st->cur_skb &&
skb_shinfo(st->root_skb)->frag_list) {
st->cur_skb = skb_shinfo(st->root_skb)->frag_list;
st->frag_idx = 0;
goto next_skb;
}
Actually I did some testing and added a few printks and found that the
st->cur_skb->data was 0 and hence the ptr used by iscsi_tcp was null.
This caused the kernel panic.
if (abs_offset < block_limit) {
- *data = st->cur_skb->data + abs_offset;
+ *data = st->cur_skb->data + (abs_offset - st->stepped_offset);
I enabled the debug_tcp and with a few printks found that the code did
not go to the next_skb label and could find that the sequence being
followed was this -
It hit this if condition -
if (st->cur_skb->next) {
st->cur_skb = st->cur_skb->next;
st->frag_idx = 0;
goto next_skb;
And so, now the st pointer is shifted to the next skb whereas actually
it should have hit the second else if first since the data is in the
frag_list.
else if (st->root_skb == st->cur_skb &&
skb_shinfo(st->root_skb)->frag_list) {
st->cur_skb = skb_shinfo(st->root_skb)->frag_list;
goto next_skb;
}
Reversing the two conditions the attached patch fixes the issue for me
on top of Herbert's patches.
Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The frag_list handling was broken in skb_seq_read:
1) We didn't add the stepped offset when looking at the head
are of fragments other than the first.
2) We didn't take the stepped offset away when setting the data
pointer in the head area.
3) The frag index wasn't reset.
This patch fixes both issues.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reducing jumbo ring size below 1024 reduces throughput for old
firmwares (3.4.216 and older) running on older (NX2031) chip,
so restore it back to 1024.
This was reduced in commit 32ec803348
("netxen: reduce memory footprint").
Raising jumbo ring size from 512 to 1024, adds ~4MB per port, but
there's still big saving because of original patch (~20MB per port).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ath5k_config updates the software context without taking sc->lock.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When CONFIG_CFG80211_REG_DEBUG is enabled and an intersection
occurs we are printing the regulatory domain passed by CRDA
and indicating its the intersected regulatory domain. Lets fix
this and print the intersection as originally intended.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes two issues with the sanity check loop when processing
the country IE:
1. Do not use frequency for the current subband channel check,
this was a big fat typo.
2. Apply the 5 GHz 4-channel steps when considering max channel
on each subband as was done with a recent patch.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch fixes memcpy to NULL address when the ucode DMA allocation failure.
This is a fix to bug
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1861
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After reports of poor performance, a review of the latest vendor driver
(rtl8187_linux_26.1025.0328.2007) for RTL8187L devices was undertaken.
A difference was found in the code used to index the OFDM power tables. When
the Linux driver was changed, my unit works at a much greater range than
before. I think this fixes Bugzilla #12380 and has been tested by at least
two other users.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Martín Ernesto Barreyro <barreyromartin@gmail.com>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
His email address keeps bouncing, and he's not interested in mac80211
patches etc. anyway.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
as per https://bugs.launchpad.net/bugs/294391. These got one sample of
each iPod generation going. However there still occurred I/O stalls
with the 3rd generation iPod which remain undiagnosed at the time of
this writing.
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
According to https://bugs.launchpad.net/bugs/294391
- 3rd generation iPods need the "fix capacity" workaround after all
(apparently they crash after the last sector was accessed),
- 2nd generation iPods need the "128 kB maximum request size"
workaround.
Alas both iPod generations feature the same model ID in the config ROM,
hence we can only define a shared quirks list entry for them. Luckily
the fix capacity workaround did not show a negative effect in Jarod's
tests with 2nd gen. iPod.
A side note: Apple computers in target mode (or at least an x86 Mac
mini) don't have firmware_version and model_id, hence none of the iPod
quirks list entries is active for them.
Tested-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This reverts commit 5a611268b6.
It is causing occasional boot crashes, caused by certain
linker versions (GNU ld version 2.18.50.0.6-2 20080403) messing up:
82dcc000 D __per_cpu_load
c16e6000 A __per_cpu_load_abs
The __per_cpu_load value is out of whack. Hpa noticed the following
detail:
* (gdb) p/x -(0xc16e6000-0x82dcc000)
* $2 = 0xc16e6000
* I.e. one is the other << 1
The two symbols should be equal.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch explicitly initializes McBSP Transmit Configuration
Control Register (XCCR) and Receive Configuration Control
Register (RCCR) to their reset values. Reset values are 26 ns
of DX delay and Transmit DMA disabled for XCCR register;
receive full cycle mode enabled and Receive DMA disabled for
RCCR register.
This patch requires a counterpart in OMAP McBSP driver before
to apply it. The required changes in McBSP were sent and approved
in linux-omap mailing list and patch is going upstream
(commit 3127f8f859 from linux-omap-2.6
tree).
Signed-off-by: Misael Lopez Cruz <x0052729@ti.com>
[ jarkko.nikula@nokia.com: Commit id for counterpart patch corrected ]
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The WM8753 driver multiplexes the DAI structures it exposes to the
outside world, leaving them uninitialised until the codec probes. Since
the DAI name is used during the registration and setup process provide a
dummy name.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many people get it wrong and add device IDs into hid_blacklist instead
of hid_ignore_list. Let's put a little comment in place.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_ignore_list additions for the Antec-branded SoundGraph iMon VFD and LCD
devices (0x15c2:0x0044 and 0x0045).
These devices are driven by lirc.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The logic for testing for disconnection is reversed in an ioctl leading
to false reports of disconnection.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Folkert van Heusden <folkert@vanheusden.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Report descriptor fixup for MS 1028 receiver changes also values for
Keyboard and Consumer, which incorrectly trims the range, causing correct
events being thrown away before passing to userspace.
We need to keep the GenDesk usage fixup though, as it reports totally bogus
values about axis.
Reported-by: Lucas Gadani <lgadani@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The sockaddr declared on the stack in cifs_get_tcp_session is too small
for IPv6 addresses. Change it from "struct sockaddr" to "struct
sockaddr_storage" to prevent stack corruption when IPv6 is used.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
We have used approximately 15 second timeouts on nonblocking sends in the past, and
also 15 second SMB timeout (waiting for server responses, for most request types).
Now that we can do blocking tcp sends,
make blocking send timeout approximately the same (15 seconds).
Signed-off-by: Steve French <sfrench@us.ibm.com>
When a search is pending of a parent directory, and a child directory
within it is removed, we need to reset the parent directory's time
so that we don't reuse the (now stale) search results.
Thanks to Gunter Kukkukk for reporting this:
> got the following failure notification on irc #samba:
>
> A user was updating from subversion 1.4 to 1.5, where the
> repository is located on a samba share (independent of
> unix extensions = Yes or No).
> svn 1.4 did work, 1.5 does not.
>
> The user did a lot of stracing of subversion - and wrote a
> testapplet to simulate the failing behaviour.
> I've converted the C++ source to C and added some error cases.
>
> When using "./testdir" on a local file system, "result2"
> is always (nil) as expected - cifs vfs behaves different here!
>
> ./testdir /mnt/cifs/mounted/share
>
> returns a (failing) valid pointer.
Acked-by: Dave Kleikamp <shaggy@us.ibm.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
When rt modules were added they (each) included their own md5
with names which collided with the existing names of cifs's md5 functions.
Renaming cifs's md5 modules so we don't collide with them.
> Stephen Rothwell wrote:
> When CIFS is built-in (=y) and staging/rt28[67]0 =y, there are multiple
> definitions of:
>
> build-r8250.out:(.text+0x1d8ad0): multiple definition of `MD5Init'
> build-r8250.out:(.text+0x1dbb30): multiple definition of `MD5Update'
> build-r8250.out:(.text+0x1db9b0): multiple definition of `MD5Final'
>
> all of which need to have more unique identifiers for their global
> symbols (e.g., rt28_md5_init, cifs_md5_init, foo, blah, bar).
>
CC: Greg K-H <gregkh@suse.de>
Signed-off-by: Steve French <sfrench@us.ibm.com>
cifs: turn smb_send into a wrapper around smb_sendv
Rename smb_send2 to smb_sendv to make it consistent with kernel naming
conventions for functions that take a vector.
There's no need to have 2 functions to handle sending SMB calls. Turn
smb_send into a wrapper around smb_sendv. This also allows us to
properly mark the socket as needing to be reconnected when there's a
partial send from smb_send.
Also, in practice we always use the address and noblocksnd flag
that's attached to the TCP_Server_Info. There's no need to pass
them in as separate args to smb_sendv.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Fix function parameter name in kernel-doc:
Warning(linux-next-20090120//drivers/base/core.c:1289): No description found for parameter 'dev'
Warning(linux-next-20090120//drivers/base/core.c:1289): Excess function parameter 'root' description in 'root_device_unregister'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following features were added to the UIO framework in the near past:
* Generic drivers for platform devices (uio_pdrv, uio_pdrv_genirq)
* an "offset" sysfs attribute for memory mappings
Unfortunately, all this went in without documentation (won't happen again...)
This patch updates UIO documentation.
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Acked-by: Uwe Kleine-König <ukleinek@strlen.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Updated jp_JP/stable_kernel_rules.txt due to changes in the main version
of the file.
Also, this patch is already reviewed by Japanese translation community
called JF.
Signed-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On m68k:
drivers/staging/agnx/agnx.h: In function 'agnx_read32':
drivers/staging/agnx/agnx.h:10: error: implicit declaration of function 'ioread32'
drivers/staging/agnx/agnx.h: In function 'agnx_write32':
drivers/staging/agnx/agnx.h:15: error: implicit declaration of function 'iowrite32'
drivers/staging/agnx/sta.c: In function 'get_sta_power':
drivers/staging/agnx/sta.c:94: error: implicit declaration of function 'memcpy_fromio'
drivers/staging/agnx/sta.c: In function 'set_sta_power':
drivers/staging/agnx/sta.c:103: error: implicit declaration of function 'memcpy_toio'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Compile tested.
task_struct->signal is not protected by RCU, the code is bogus.
Change the code to take ->siglock to pin ->signal.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ktime_t isn't ment to directly access on all arches, so use the proper
conversion functions instead to figure out what time is remaining.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Mike Lockwood <lockwood@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Meilhaus drivers do not like being built into the kernel right now,
so force them to be a module.
Reported-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
comedi doesn't like being built into the kernel right now, so force it
to be a module.
Reported-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reported-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
who also provided a first version of the fix.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter
limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3).
Our previously too large limit doesn't matter though if the controller
reports its max_receive correctly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This makes sbp2 behave more like firewire-sbp2 which reports 0xff000000
as immediate value if there are no unit directory entries for model_id
or firmware_revision.
It does not reduce matches with the currently existing quirks table; the
only zero entry there is for a device which actually does have a zero
model_id. It only changes how model_id and firmware_revision are logged
if they are missing.
Other functionally unrelated changes: The model_id member of quirks
list entries is renamed to model; the value (but not the effect) of
SBP2_ROM_VALUE_WILDCARD is changed. Now this part of the source is
identical with firewire-sbp2 for easier maintenance.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter
limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3).
Our previously too large limit doesn't matter though if the controller
reports its max_receive correctly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Daniel Marjamäki