24 Apr, 2007
9 commits
-
Signed-off-by: Miguel Ojeda Sandonis
Cc: "Antonino A. Daplas"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
pcd_lock and pf_spin_lock are passed to blk_init_queue() which, seeing them
as valid lock pointer, sets it as ->queue_lock.The problem is that pcd_lock and pf_spin_lock aren't initialized anywhere.
Signed-off-by: Alexey Dobriyan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There was schedule() missing in the TIOCMIWAIT ioctl. Solve it by moving
the code to the wait_event_interruptible.Signed-off-by: Jiri Slaby
Cc: Jan Yenya Kasprzak
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There was schedule() missing in the TIOCMIWAIT ioctl. Solve it by moving
the code to the wait_event_interruptible.Cc: Jan "Yenya" Kasprzak
Signed-off-by: Jiri Slaby
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Jan "Yenya" Kasprzak
Acked-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I encountered the following kernel panic. The cause of this problem was
NULL pointer access in check_modem_status() in 8250.c. I confirmed this
problem is fixed by the attached patch, but I don't know this is the
correct fix.sadc[4378]: NaT consumption 2216203124768 [1]
Modules linked in: binfmt_misc dm_mirror dm_mod thermal processor fan
container button sg e100 eepro100 mii ehci_hcd ohci_hcdPid: 4378, CPU 0, comm: sadc
psr : 00001210085a2010 ifs : 8000000000000289 ip : []
Not tainted
ip is at check_modem_status+0xf1/0x360Call Trace:
[] show_stack+0x40/0xa0
[] show_regs+0x840/0x880
[] die+0x1c0/0x2c0
[] die_if_kernel+0x50/0x80
[] ia64_fault+0x11e0/0x1300
[] ia64_leave_kernel+0x0/0x280
[] check_modem_status+0xf0/0x360
[] serial8250_get_mctrl+0x20/0xa0
[] uart_read_proc+0x250/0x860
[] proc_file_read+0x1d0/0x4c0
[] vfs_read+0x1b0/0x300
[] sys_read+0x70/0xe0
[] ia64_ret_from_syscall+0x0/0x20
[] __kernel_syscall_via_break+0x0/0x20Fix the possible NULL pointer access in check_modem_status() in 8250.c. The
check_modem_status() would access 'info' member of uart_port structure, but it
is not initialized before uart_open() is called. The check_modem_status() can
be called through /proc/tty/driver/serial before uart_open() is called.Signed-off-by: Kenji Kaneshige
Signed-off-by: Taku Izumi
Cc: Russell King
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
USRobotics Wireless Adapter (Model 5423) works well with current
zd1211rw driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7).It just needs its ID added to the list of devices.
Signed-off-by: S.Çağlar Onur
Signed-off-by: Linus Torvalds -
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SUNHME]: Fix module unload.
[SUNLANCE]: Fix module unload.
[SUNQE]: Fix MAC address assignment.
[SBUS] vfc_dev.c: kzalloc -
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[PPP]: Fix skbuff.c:BUG due incorrect logic in process_input_packet()
22 Apr, 2007
4 commits
-
Signed-off-by: Marcel van Nies
Signed-off-by: David S. Miller -
Signed-off-by: Marcel van Nies
Signed-off-by: David S. Miller -
The MAC address assignment at module loading is simply forgotten.
The bug at module unloading is caused by an incorrect call.The bug at module unloading does not only happen for sunqe,
sunlance and sunhme (sbus) suffer from it too.I've tested this on my SS20.
Signed-off-by: Marcel van Nies
Signed-off-by: David S. Miller -
Replacing kmalloc/memset combination with kzalloc.
Signed-off-by: vignesh babu
Signed-off-by: David S. Miller
21 Apr, 2007
3 commits
-
ide_hwif_to_major[] has only 10 entries as there are 10 major numbers
reserved for IDE (if somebody needs more it shouldn't be hard to fix).Signed-off-by: Bartlomiej Zolnierkiewicz
-
The driver crashes the kernel on HPT302N chips due to the missing initializer
for 'hpt302n.settings' having been unfortunately overlooked so far. :-<Much thanks to Mike Mattie for pin-pointing the reason of crash.
Signed-off-by: Sergei Shtylyov
Signed-off-by: Bartlomiej Zolnierkiewicz -
Add PCI ID for a newer variant of cardbus CF/IDE adapter card.
Signed-off-by: Mark Lord
Signed-off-by: Bartlomiej Zolnierkiewicz
20 Apr, 2007
14 commits
-
This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. It's been
linked to lockups of the e1000 hardware, see for examplehttps://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
but it's likely that the commit itself is not really introducing the
bug, but just allowing an unrelated problem to rear its ugly head (ie
one current working theory is that the code exposes us to a hardware
race condition by decreasing the amount of time we spend in each NAPI
poll cycle).We'll revert it until root cause is known. Intel has a repeatable
reproduction on two different machines and bus traces of the hardware
doing something bad.Acked-by: Jesse Brandeburg
Cc: Jeff Garzik
Cc: David S. Miller
Cc: Greg KH
Cc: Dave Jones
Cc: Auke Kok
Cc: Andrew Morton
Signed-off-by: Linus Torvalds -
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
pata_sis: Fix oops on boot -
A small number of SiS setups require special handling (not many judging
by how long this dumb bug survived). A couple of Fedora 7 devel testers
hit an Oops on pata_sis loading which is caused by terminal confusion
between chipset as 'the chipset we have found' and chipset as 'array
iterator'Signed-off-by: Alan Cox
Signed-off-by: Jeff Garzik -
From: Paul Mackerras
This fixes:
Subject: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
process_input_packet() treats the case where the first byte is 0xff
(PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a
packet with a PPP protocol number of 0xff. Arguably that's wrong
since PPP protocol 0xff is reserved, and the RFC does envision the
possibility of receiving frames where the control field has values
other than 0x03.Signed-off-by: David S. Miller
-
Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
The Yukon FE (100mbit only) chips do not support large packets.
Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
The Yukon EC Ultra chips have transmit settings for store and
forward and PCI buffering. By setting these appropriately, normal
performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo).It is also possible to do Jumbo mode, but it means turning off
TSO and checksum offload so the performance gets worse. There isn't
enough buffering for checksum offload to work.Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
Need to make sure and disable ASF on all chip types. Otherwise, there may be
random reboots.Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
There should never be descriptor error unless hardware or driver is buggy.
But if an error occurs, print useful information, clear irq, and recover.Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
This device is having all sorts of problems that lead to data corruption
and system instability. It gets receive status and data out of order,
it generates descriptor and TSO errors, etc.Until the problems are resolved, it should not be used by anyone
who cares about there system.Signed-off-by: Stephen Hemminger
Signed-off-by: Jeff Garzik -
Gianfar needs crc32 to be selected to compile.
Signed-off-by: Dave Jiang
--
drivers/net/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Signed-off-by: Jeff Garzik -
The basic structure of "normal" UDP/IP/Ethernet
frames (that actually work):
- It starts with the Ethernet header (dest MAC, src MAC, etc.)
- The next part is occupied by the IP header (version info, length of
packet, id=0, fragment offset=0, checksum, from / to address, etc.)
- Then comes the UDP header (src / dest port, length, checksum)
- Actual payload
- Ethernet checksumNow what's different for IP fragment:
- The IP header has id set to some value (same for all fragments),
offset is set appropriately (i.e. 0 for first fragment, following
according to size of other fragments), size is the length of the frame.
- UDP header is unchanged. I.e. length is according to full UDP
datagram, not just the part within the actual frame! But this is only
true within the first frame: all following frames don't have a valid
UDP-header at all.The spidernet silicon seems to be quite intelligent: It's able to
compute (IP / UDP / Ethernet) checksums on the fly and tests if frames
are conforming to RFC -- at least conforming to RFC on complete frames.But IP fragments are different as explained above:
I.e. for IP fragments containing part of a UDP datagram it sees
incompatible length in the headers for IP and UDP in the first frame
and, thus, skips this frame. But the content *is* correct for IP
fragments. For all following frames it finds (most probably) no valid
UDP header at all. But this *is* also correct for IP fragments.The Linux IP-stack seems to be clever in this point. It expects the
spidernet to calculate the checksum (since the module claims to be able
to do so) and marks the skb's for "normal" frames accordingly
(ip_summed set to CHECKSUM_HW).
But for the IP fragments it does not expect the driver to be capable to
handle the frames appropriately. Thus all checksums are allready
computed. This is also flaged within the skb (ip_summed set to
CHECKSUM_NONE).Unfortunately the spidernet driver ignores that hints. It tries to send
the IP fragments of UDP datagrams as normal UDP/IP frames. Since they
have different structure the silicon detects them the be not
"well-formed" and skips them.The following one-liner against 2.6.21-rc2 changes this behavior. If the
IP-stack claims to have done the checksumming, the driver should not
try to checksum (and analyze) the frame but send it as is.Signed-off-by: Norbert Eicker
Signed-off-by: Linas Vepstas
Signed-off-by: Andrew Morton
Signed-off-by: Jeff Garzik -
Remove assumption that PHY interrupts use GPIOs 3 and 5.
Deal with PHY interrupts connected to any GPIO pins.Signed-off-by: Divy Le Ray
Signed-off-by: Jeff Garzik -
Reuse the incoming skb when a clientless abort req is recieved.
The release of RDMA connections HW resources might be deferred in
low memory situations.
Ensure that no further activity is passed up to the RDMA driver
for these connections.Signed-off-by: Divy Le Ray
Signed-off-by: Jeff Garzik
19 Apr, 2007
1 commit
-
Nonpae guest pdes are shadowed by two pae ptes, so we double the offset
twice: once to account for the pte size difference, and once because we
need to shadow pdes for a single guest pde.But when writing to the upper guest pde we also need to truncate the
lower bits, otherwise the multiply shifts these bits into the pde index
and causes an access to the wrong shadow pde. If we're at the end of the
page (accessing the very last guest pde) we can even overflow into the
next host page and oops.Signed-off-by: Avi Kivity
18 Apr, 2007
7 commits
-
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband:
IB/mthca: Fix data corruption after FMR unmap on Sinai -
* Last write during i2c_xfer is of the wrong byte (off-by-1).
* Read length is wrong for some of the reads (mistakenly used the PEC
version)Signed-off-by: Olof Johansson
Signed-off-by: Jean Delvare
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Looks like a local change I made to be able to test-compile the i2c-pasemi
driver leaked upstream.Signed-off-by: Jean Delvare
Acked-by: Olof Johansson
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Users have been complaining about the w83627ehf driver flooding their logs
with debug messages like:w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128
or:
w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8
The reason is that we failed to actually write the LSB of the encoded clock
divider value for that fan, causing the next read to report the same old value
again and again.Additionally, the fan number was improperly reported, making the bug harder to
find.Signed-off-by: Jean Delvare
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It got its lock and unlock backwards.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=8334
(obviously, this code could be using plain old spin_lock_irq(), too)
Cc:
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It turns out that the last patch to change set_cs to be kept in the
controller's structure instead of the platform data was an incomplete
change, and did not change the references to platfrom data in the setup
xfer code. (This can prevent an oops.)Reported-by:
Signed-off-by: Ben Dooks
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
While digging through my MAP_FIXED changes, I found that rather obvious
bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area()
is expected to return an address, not a pfn.Signed-off-by: Benjamin Herrenschmidt
Acked-By: David Howells
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2007
1 commit
-
In mthca_arbel_fmr_unmap(), the high bits of the key are masked off.
This gets rid of the effect of adjust_key(), which makes sure that
bits 3 and 23 of the key are equal when the Sinai throughput
optimization is enabled, and so it may happen that an FMR will end up
with bits 3 and 23 in the key being different. This causes data
corruption, because when enabling the throughput optimization, the
driver promises the HCA firmware that bits 3 and 23 of all memory keys
will always be equal.Fix by re-applying adjust_key() after masking the key.
Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for
help in debug.Signed-off-by: Michael S. Tsirkin
Signed-off-by: Roland Dreier
15 Apr, 2007
1 commit
-
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something.