- 13 Oct, 2006 19 commits
-
-
Greg Kroah-Hartman authored
-
Roberto Castagnola authored
MX300 does not have an EXTRA_BTN - it is a simple wheel mouse with an additional task-switcher button, which is reported as side button (and not task button). Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tejun Heo authored
All softreset methods are responsible for detecting device presence and succeed softreset in such cases. AHCI didn't use to check for device presence before proceeding with softreset and this caused unnecessary reset retrials during probing. This patch adds presence detection to AHCI softreset. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Daniel Drake <dsd@gentoo.org> Signed-off-by:
-
Pierre Ossman authored
Both MMC and SD specifications specify (although a bit unclearly in the MMC case) that a sector size of 512 bytes must always be supported by the card. Cards can report larger "native" size than this, and cards >= 2 GB even must do so. Most other readers use 512 bytes even for these cards. We should do the same to be compatible. Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Cc: Daniel Drake <dsd@gentoo.org> Signed-off-by:
-
Linus Torvalds authored
This is confirmed to fix a hang due to PCI resource conflicts with setting up the Cardbus bridge on old laptops with the 440MX chipsets. Original report by Alessio Sangalli, lspci debugging help by Pekka Enberg, and trial patch suggested by Daniel Ritz: "From the docs available i would _guess_ this thing is really similar to the 82443BX/82371AB combination. at least the SMBus base address register is hidden at the very same place (32bit at 0x90 in function 3 of the "south" brigde)" The dang thing is largely undocumented, but the patch was corroborated by Asit Mallick: "I am trying to find the register information. 440MX is an integration of 440BX north-bridge without AGP and PIIX4E (82371EB). PIIX4 quirk should cover the ACPI and SMBus related I/O registers." and verified to fix the problem by Alessio. Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Dmitry Torokhov <dtor_core@ameritech.net> Tested-by:
Alessio Sangalli <alesan@manoweb.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Joerg Ahrens authored
I am using a Xircom CEM33 pcmcia NIC which has occasional hardware problems. If the netdev watchdog detects a transmit timeout, do_reset is called which msleeps - this is illegal in atomic context. This patch schedules the timeout handling as a workqueue item. Signed-off-by:
-
David Miller authored
Prevents filters from being added if the first generated handle already exists. Signed-off-by:
Kim Nordlund <kim.nordlund@nokia.com> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
David S. Miller authored
[SPARC64]: Kill bogus check from bootmem_init(). There is an ancient and totally incorrect sanity check being done on the ramdisk location. The check assumes that the kernel is always loaded to physical address zero, which is wrong. It was trying to validate the ramdisk value by saying that if it fell within the kernel image address range it must be wrong. Anyways, kill this because it actually creates problems. The 'ramdisk_image' should always be adjusted down by KERNBASE. SILO can easily put the ramdisk in a location which causes this test to trigger, breaking things. [ Based almost entirely upon a patch from Ben Collins. ] Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[SPARC64]: Fix sched_clock() wrapping every ~17 seconds. Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 --> 128" bit multiply like PowerPC and IA64 do. We were doing a "64 X 64 --> 64" bit multiple which causes overflow very quickly with a 30-bit quotient shift. So use a quotientshift count of 10 instead of 30, just like x86 and ARM do. This also fixes the wrapping of printk timestamp values every ~17 seconds. Signed-off-by:
-
Yeasah Pell authored
The cx24109 datasheet says: "NOTE: if A=0, then N=N+1" The current code is the result of a misinterpretation of the datasheet to mean exactly the opposite of the requirement -- The actual value of N is 1 greater than the value written when A is 0, so 1 needs to be *subtracted* from it to compensate. Signed-off-by:
Yeasah Pell <yeasah@schwide.net> Signed-off-by:
Steven Toth <stoth@hauppauge.com> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Hans Verkuil authored
The msp3430G and msp3435G models cannot do Automatic Standard Detection, so these should be forced to BTSC. These chips are early production versions for the msp34xxG series and are quite rare. Due to broken handling of the 'standard' option in 2.6.17, there is no workaround possible. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hidetoshi Seto authored
Following function can drops d_count twice against one reference by lookup_one_len. <SOURCE> /** * sysfs_update_file - update the modified timestamp on an object attribute. * @kobj: object we're acting for. * @attr: attribute descriptor. */ int sysfs_update_file(struct kobject * kobj, const struct attribute * attr) { struct dentry * dir = kobj->dentry; struct dentry * victim; int res = -ENOENT; mutex_lock(&dir->d_inode->i_mutex); victim = lookup_one_len(attr->name, dir, strlen(attr->name)); if (!IS_ERR(victim)) { /* make sure dentry is really there */ if (victim->d_inode && (victim->d_parent->d_inode == dir->d_inode)) { victim->d_inode->i_mtime = CURRENT_TIME; fsnotify_modify(victim); /** * Drop reference from initial sysfs_get_dentry(). */ dput(victim); res = 0; } else d_drop(victim); /** * Drop the reference acquired from sysfs_get_dentry() above. */ dput(victim); } mutex_unlock(&dir->d_inode->i_mutex); return res; } </SOURCE> PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/* have negative d_count value. This patch removes unnecessary dput(). Signed-off-by:Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Badari Pulavarty authored
ext3-get-blocks support caused ~20% degrade in Sequential read performance (tiobench). Problem is with marking the buffer boundary so IO can be submitted right away. Here is the patch to fix it. 2.6.18-rc6:
-
Michael-Luke Jones authored
This patch is identical to that introduced in 1a1276e7 to the Linus' 2.6 development tree by Alan Cox. 'This is based on the proposed patches flying around but also checks that the device in question is new enough to have word 93 rather thanb blindly assuming word 93 == 0 means SATA (see ATA-5, ATA-7)' -- Alan Cox Required for my SATA drive on an Asus Pundit-R to operate above 33MBps. Signed-off-by:
Michael-Luke Jones <mlj28@cam.ac.uk> Signed-off-by:
-
Trond Myklebust authored
Whenever the directory changes, we want to make sure that we always invalidate its page cache. Fix up update_changeattr() and nfs_mark_for_revalidate() so that they do so. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
nlm_traverse_files() is not allowed to hold the nlm_file_mutex while calling nlm_inspect file, since it may end up calling nlm_release_file() when releaseing the blocks. Signed-off-by:
-
Chuck Lever authored
Some hardware uses port 664 for its hardware-based IPMI listener. Teach the RPC client to avoid using that port by raising the default minimum port number to 665. Test plan: Find a mainboard known to use port 664 for IPMI; enable IPMI; mount NFS servers in a tight loop. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Nikita Danilov authored
nfs_wb_page() waits on request completion and, as a result, is not safe to be called from nfs_release_page() invoked by VM scanner as part of GFP_NOFS allocation. Fix possible deadlock by analyzing gfp mask and refusing to release page if __GFP_FS is not set. Signed-off-by:
Nikita Danilov <danilov@gmail.com> Signed-off-by:
-
Ang Way Chuang authored
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that allows an attacker to send a malformed ULE packet with SNDU length of 0 and bring down the receiving machine. This patch fix the bug and has been tested on version 2.6.17.11. This bug is 100% reproducible and the modified source code (GPL) used to produce this bug will be posted on http://nrg.cs.usm.my/downloads.htm shortly. The kernel will produce a dump during CRC32 checking on faulty ULE packet. Signed-off-by:
Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by:
-
- 09 Sep, 2006 3 commits
-
-
Greg Kroah-Hartman authored
-
Jeff Mahoney authored
This patch adds idr_replace() to replace an existing pointer in a single operation. Device-mapper will use this to update the pointer it stored against a given id. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Alan Cox authored
pci_ids.h: add some VIA IDE identifiers Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
- 08 Sep, 2006 18 commits
-
-
Greg Kroah-Hartman authored
-
Stephen Hemminger authored
Since this code incorporates some of the fixes from 2.6.18, change the version number. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Stephen Hemminger authored
Fix support for fiber based devices. Needed to keep track of PMD type to add workaround in setup. Add support for gigabit half duplex fiber. Signed-off-by:
-
Stephen Hemminger authored
The test for MSI IRQ could have timing issues. The PCI write needs to be pushed out before waiting, and the wait queue should be initialized before the IRQ. Signed-off-by:
-
Stephen Hemminger authored
Several code paths assume an additional 16 bytes of header padding on the receive path. Use dev_alloc_skb to get that padding. Signed-off-by:
-
Stephen Hemminger authored
Don't clear status IRQ until list has been read to avoid causing status list wraparound. Clearing IRQ forces a Transmit Status update if it is pending. Signed-off-by:
-
Stephen Hemminger authored
Don't program the GMAC to reject flow control packets. This maybe the cause of some of the transmit hangs. Signed-off-by:
-
Daniel Kobras authored
On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid, we experienced frequent deadlock of the system under high i/o load. 'cat /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly after a few GB, 'cp' would be left in 'D' state along with kjournald and kmirrord. The functions cp and kjournald were blocked in did vary, but kmirrord's wchan always pointed to 'mempool_alloc()'. We've seen this pattern on 2.6.15 and 2.6.17 kernels. http://lkml.org/lkml/2005/4/20/142 indicates that this problem has been around even before. So much for the facts, here's my interpretation: mempool_alloc() first tries to atomically allocate the requested memory, or falls back to hand out preallocated chunks from the mempool. If both fail, it puts the calling process (kmirrord in this case) on a private waitqueue until somebody refills the pool. Where the only 'somebody' is kmirrord itself, so we have a deadlock. I worked around this problem by falling back to a (blocking) kmalloc when before kmirrord would have ended up on the waitqueue. This defeats part of the benefits of using the mempool, but at least keeps the system running. And it could be done with a two-line change. Note that mempool_alloc() clears the GFP_NOIO flag internally, and only uses it to decide whether to wait or return an error if immediate allocation fails, so the attached patch doesn't change behaviour in the non-deadlocking case. Path is against current git (2.6.18-rc4), but should apply to earlier versions as well. I've tested on 2.6.15, where this patch makes the difference between random lockup and a stable system. Signed-off-by:
Daniel Kobras <kobras@linux.de> Acked-by:
-
Yingchao Zhou authored
An up() is called in kernel/stop_machine.c on failure, and also in the caller (unconditionally). Signed-off-by:
Zhou Yingchao <yingchao.zhou@gmail.com> Signed-off-by:
-
Alan Cox authored
The following change from -mm is important to 2.6.18 (actually to 2.6.17 but its too late for that). This was contributed over three months ago by VIA to Bartlomiej and nothing happened. As a result the new chipset is now out and Linux won't run on it. By the time 2.6.18 is finalised this will be the defacto standard VIA chipset so support would be a good plan. Tested in -mm for a while, its essentially a PCI ident update but for the bridge chip because VIA do things in weird ways. Signed-off-by: -
Chen-Li Tien authored
Signed-off-by:
Chen-Li Tien <cltien@gmail.com> Signed-off-by:
-
David S. Miller authored
[PKTGEN]: Make sure skb->{nh,h} are initialized in fill_packet_ipv6() too. Mirror the bug fix from fill_packet_ipv4() Signed-off-by: -
Robin Holt authored
Jack Steiner identified a problem where XPC can cause a silent data corruption. On module load, the placement may cause the xpc_remote_copy_buffer to span two physical pages. DMA transfers are done to the start virtual address translated to physical. This patch changes the buffer from a statically allocated buffer to a kmalloc'd buffer. Dean Nelson reviewed this before posting. I have tested it in the configuration that was showing the memory corruption and verified it works. I also added a BUG_ON statement to help catch this if a similar situation is encountered. Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
Dean Nelson <dcn@sgi.com> Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Alan Stern authored
When skipping to the last TD of an URB, go to the _last_ entry in the list instead of the _first_ entry (as780). This fixes Bugzilla #6747 and possibly others. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Ernie Petrides authored
Fix check for bad address; use macro instead of open-coding two checks. Taken from RHEL4 kernel update. For background, the BAD_ADDR() macro should return TRUE if the address is TASK_SIZE, because that's the lowest address that is *not* valid for user-space mappings. The macro was correct in binfmt_aout.c but was wrong for the "equal to" case in binfmt_elf.c. There were two in-line validations of user-space addresses in binfmt_elf.c, which have been appropriately converted to use the corrected BAD_ADDR() macro in the patch you posted yesterday. Note that the size checks against TASK_SIZE are okay as coded. The additional changes that I propose are below. These are in the error paths for bad ELF entry addresses once load_elf_binary() has already committed to exec'ing the new image (following the tearing down of the task's original address space). The 1st hunk deals with the interp-side of the outer "if". There were two problems here. The printk() should be removed because this path can be triggered at will by a bogus interpreter image created and used by a malicious user. Further, the error code should not be ENOEXEC, because that causes the loop in search_binary_handler() to continue trying other exec handlers (twice, in fact). But it's too late for this to work correctly, because the user address space has already been torn down, and an exec() failure cannot be returned to the user code because the code no longer exists. The only recovery is to force a SIGSEGV, but it's best to terminate the search loop immediately. I somewhat arbitrarily chose EINVAL as a fallback error code, but any error returned by load_elf_interp() will override that (but this value will never be seen by user-space). The 2nd hunk deals with the non-interp-side of the outer "if". There were two problems here as well. The SIGSEGV needs to be forced, because a prior sigaction() syscall might have set the associated disposition to SIG_IGN. And the ENOEXEC should be changed to EINVAL as described above. Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Christian Borntraeger authored
This patch adds a barrier() in futex unqueue_me to avoid aliasing of two pointers. On my s390x system I saw the following oops: Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000 Oops: 0004 [#1] CPU: 0 Not tainted Process mytool (pid: 13613, task: 000000003ecb6ac0, ksp: 00000000366bdbd8) Krnl PSW : 0704d00180000000 00000000003c9ac2 (_spin_lock+0xe/0x30) Krnl GPRS: 00000000ffffffff 000000003ecb6ac0 0000000000000000 0700000000000000 0000000000000000 0000000000000000 000001fe00002028 00000000000c091f 000001fe00002054 000001fe00002054 0000000000000000 00000000366bddc0 00000000005ef8c0 00000000003d00e8 0000000000144f91 00000000366bdcb8 Krnl Code: ba 4e 20 00 12 44 b9 16 00 3e a7 84 00 08 e3 e0 f0 88 00 04 Call Trace: ([<0000000000144f90>] unqueue_me+0x40/0xe4) [<0000000000145a0c>] do_futex+0x33c/0xc40 [<000000000014643e>] sys_futex+0x12e/0x144 [<000000000010bb00>] sysc_noemu+0x10/0x16 [<000002000003741c>] 0x2000003741c The code in question is: static int unqueue_me(struct futex_q *q) { int ret = 0; spinlock_t *lock_ptr; /* In the common case we don't take the spinlock, which is nice. */ retry: lock_ptr = q->lock_ptr; if (lock_ptr != 0) { spin_lock(lock_ptr); /* * q->lock_ptr can change between reading it and * spin_lock(), causing us to take the wrong lock. This * corrects the race condition. [...] and my compiler (gcc 4.1.0) makes the following out of it: 00000000000003c8 <unqueue_me>: 3c8: eb bf f0 70 00 24 stmg %r11,%r15,112(%r15) 3ce: c0 d0 00 00 00 00 larl %r13,3ce <unqueue_me+0x6> 3d0: R_390_PC32DBL .rodata+0x2a 3d4: a7 f1 1e 00 tml %r15,7680 3d8: a7 84 00 01 je 3da <unqueue_me+0x12> 3dc: b9 04 00 ef lgr %r14,%r15 3e0: a7 fb ff d0 aghi %r15,-48 3e4: b9 04 00 b2 lgr %r11,%r2 3e8: e3 e0 f0 98 00 24 stg %r14,152(%r15) 3ee: e3 c0 b0 28 00 04 lg %r12,40(%r11) /* write q->lock_ptr in r12 */ 3f4: b9 02 00 cc ltgr %r12,%r12 3f8: a7 84 00 4b je 48e <unqueue_me+0xc6> /* if r12 is zero then jump over the code.... */ 3fc: e3 20 b0 28 00 04 lg %r2,40(%r11) /* write q->lock_ptr in r2 */ 402: c0 e5 00 00 00 00 brasl %r14,402 <unqueue_me+0x3a> 404: R_390_PC32DBL _spin_lock+0x2 /* use r2 as parameter for spin_lock */ So the code becomes more or less: if (q->lock_ptr != 0) spin_lock(q->lock_ptr) instead of if (lock_ptr != 0) spin_lock(lock_ptr) Which caused the oops from above. After adding a barrier gcc creates code without this problem: [...] (the same) 3ee: e3 c0 b0 28 00 04 lg %r12,40(%r11) 3f4: b9 02 00 cc ltgr %r12,%r12 3f8: b9 04 00 2c lgr %r2,%r12 3fc: a7 84 00 48 je 48c <unqueue_me+0xc4> 400: c0 e5 00 00 00 00 brasl %r14,400 <unqueue_me+0x38> 402: R_390_PC32DBL _spin_lock+0x2 As a general note, this code of unqueue_me seems a bit fishy. The retry logic of unqueue_me only works if we can guarantee, that the original value of q->lock_ptr is always a spinlock (Otherwise we overwrite kernel memory). We know that q->lock_ptr can change. I dont know what happens with the original spinlock, as I am not an expert with the futex code. Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Acked-by:Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@timesys.com> Signed-off-by:
Christian Borntraeger <borntrae@de.ibm.com> Signed-off-by:
-
Trond Myklebust authored
fcntl(F_SETSIG) no longer works on leases because lease_release_private_callback() gets called as the lease is copied in order to initialise it. The problem is that lease_alloc() performs an unnecessary initialisation, which sets the lease_manager_ops. Avoid the problem by allocating the target lease structure using locks_alloc_lock(). Signed-off-by:
-
YOSHIFUJI Hideaki authored
[IPV6]: Fix kernel OOPs when setting sticky socket options. Bug noticed by Remi Denis-Courmont <rdenis@simphalempin.com>. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
