- 14 Dec, 2007 33 commits
-
-
Andrew Morton authored
patch 24601bbc in mainline. revert commit 55d9fcf5 Author: Matthew Wilcox <matthew@wil.cx> Date: Mon Jul 30 15:19:18 2007 -0600 [SCSI] dpt_i2o: convert to SCSI hotplug model - Delete refereces to HOSTS_C - Switch to module_init/module_exit instead of detect/release - Don't pass around the host template and rename it to adpt_template - Switch from scsi_register/scsi_unregister to scsi_host_alloc, scsi_add_host, scsi_scan_host and scsi_host_put. Because it caused (for unknown reasons) Andres' all-data-reads-as-zeroes problem, reported at http://groups.google.com/group/fa.linux.kernel/msg/083a9acff0330234 Cc: Matthew Wilcox <matthew@wil.cx> Cc: Mark Salyzyn <mark_salyzyn@adaptec.com> Cc: James Bottomley <James.Bottomley@SteelEye.com> Acked-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Anders Henke <anders.henke@1und1.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
patch b64d7082 in mainline. The code in fb_ddc_read() is said to be based on the implementation of the radeon driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc5891c8a3ba284f13994d7bc1f1bfa8283982de However, comparing the old radeon driver code with the new fb_ddc code reveals some differences. Most notably, the I2C bus lines are held at the end of the function, while the original code was releasing them (as the comment above correctly says.) There are a few other differences, which appear to be responsible for read failures on my system. While tracing low-level I2C code in i2c-algo-bit, I noticed that the initial attempt to read the EDID always failed. It takes one retry for the read to succeed. As we are about to remove this automatic retry property from i2c-algo-bit, reading the EDID would really fail. As a summary, the I2C lines quirk which is supposedly needed to read EDID on some older monitors is currently breaking the (first) read on all other monitors (and might not even work with older ones - did anyone try since October 2006?) After applying the patch below, which makes the code in fb_ddc_read() really similar to what the radeon driver used to have, the first EDID read succeeds again. On top of that, as it appears that this code has been broken for one year now and nobody seems to have complained, I'm curious if it makes sense to keep this quirk in place. It makes the code more complex and slower just for the sake of monitors which I guess nobody uses anymore. Can't we just get rid of it? Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
Roger Leigh <rleigh@whinlatter.ukfsn.org> Tested-by:
Michael Buesch <mb@bu3sch.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Scott James Remnant authored
patch e6ceb32a in mainline. In wait_task_stopped() exit_code already contains the right value for the si_status member of siginfo, and this is simply set in the non WNOWAIT case. If you call waitid() with a stopped or traced process, you'll get the signal in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the same time, you'll get the signal << 8 | 0x7f Pass it unchanged to wait_noreap_copyout(); we would only need to shift it and add 0x7f if we were returning it in the user status field and that isn't used for any function that permits WNOWAIT. Signed-off-by:
Scott James Remnant <scott@ubuntu.com> Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Zhao Yakui authored
patch a7839e96 in mainline. On some systems the number of resources(IO,MEM) returnedy by PNP device is greater than the PNP constant, for example motherboard devices. It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver. [akpm@linux-foundation.org: fix text and coding-style a bit] Signed-off-by:
Li Shaohua <shaohua.li@intel.com> Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by:
-
Rafael J. Wysocki authored
patch cb43c54c in mainline. The APM emulation is currently broken as a result of commit 83144186 "Freezer: make kernel threads nonfreezable by default" that removed the PF_NOFREEZE annotations from apm_ioctl() without adding the appropriate freezer hooks. Fix it and remove the unnecessary variable flags from apm_ioctl(). Special thanks to Franck Bui-Huu <vagabon.xyz@gmail.com> for pointing out the problem. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Cc: Franck Bui-Huu <vagabon.xyz@gmail.com> Cc: Nigel Cunningham <nigel@nigel.suspend2.net> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Steven Rostedt authored
From Steven Rostedt <srostedt@redhat.com> patch ce6bd420 in mainline. David Holmes found a bug in the -rt tree with respect to pthread_cond_timedwait. After trying his test program on the latest git from mainline, I found the bug was there too. The bug he was seeing that his test program showed, was that if one were to do a "Ctrl-Z" on a process that was in the pthread_cond_timedwait, and then did a "bg" on that process, it would return with a "-ETIMEDOUT" but early. That is, the timer would go off early. Looking into this, I found the source of the problem. And it is a rather nasty bug at that. Here's the relevant code from kernel/futex.c: (not in order in the file) [...] smlinkage long sys_futex(u32 __user *uaddr, int op, u32 val, struct timespec __user *utime, u32 __user *uaddr2, u32 val3) { struct timespec ts; ktime_t t, *tp = NULL; u32 val2 = 0; int cmd = op & FUTEX_CMD_MASK; if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) { if (copy_from_user(&ts, utime, sizeof(ts)) != 0) return -EFAULT; if (!timespec_valid(&ts)) return -EINVAL; t = timespec_to_ktime(ts); if (cmd == FUTEX_WAIT) t = ktime_add(ktime_get(), t); tp = &t; } [...] return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); } [...] long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout, u32 __user *uaddr2, u32 val2, u32 val3) { int ret; int cmd = op & FUTEX_CMD_MASK; struct rw_semaphore *fshared = NULL; if (!(op & FUTEX_PRIVATE_FLAG)) fshared = ¤t->mm->mmap_sem; switch (cmd) { case FUTEX_WAIT: ret = futex_wait(uaddr, fshared, val, timeout); [...] static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared, u32 val, ktime_t *abs_time) { [...] struct restart_block *restart; restart = ¤t_thread_info()->restart_block; restart->fn = futex_wait_restart; restart->arg0 = (unsigned long)uaddr; restart->arg1 = (unsigned long)val; restart->arg2 = (unsigned long)abs_time; restart->arg3 = 0; if (fshared) restart->arg3 |= ARG3_SHARED; return -ERESTART_RESTARTBLOCK; [...] static long futex_wait_restart(struct restart_block *restart) { u32 __user *uaddr = (u32 __user *)restart->arg0; u32 val = (u32)restart->arg1; ktime_t *abs_time = (ktime_t *)restart->arg2; struct rw_semaphore *fshared = NULL; restart->fn = do_no_restart_syscall; if (restart->arg3 & ARG3_SHARED) fshared = ¤t->mm->mmap_sem; return (long)futex_wait(uaddr, fshared, val, abs_time); } So when the futex_wait is interrupt by a signal we break out of the hrtimer code and set up or return from signal. This code does not return back to userspace, so we set up a RESTARTBLOCK. The bug here is that we save the "abs_time" which is a pointer to the stack variable "ktime_t t" from sys_futex. This returns and unwinds the stack before we get to call our signal. On return from the signal we go to futex_wait_restart, where we update all the parameters for futex_wait and call it. But here we have a problem where abs_time is no longer valid. I verified this with print statements, and sure enough, what abs_time was set to ends up being garbage when we get to futex_wait_restart. The solution I did to solve this (with input from Linus Torvalds) was to add unions to the restart_block to allow system calls to use the restart with specific parameters. This way the futex code now saves the time in a 64bit value in the restart block instead of storing it on the stack. Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64 in thread_info.h, when there's a #ifdef __KERNEL__ just below that. Not sure what that is there for. If this turns out to be a problem, I've tested this with using "unsigned int" for u32 and "unsigned long long" for u64 and it worked just the same. I'm using u32 and u64 just to be consistent with what the futex code uses. Signed-off-by:
Steven Rostedt <srostedt@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
-
Karsten Keil authored
patch 0f13864e in mainline. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9416Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
H. Peter Anvin authored
patch 7ed19290 in mainline. The 386 and 486 needs a jump immediately after setting %cr0 in order to serialize the pipeline. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Eddie Dong authored
patch 8668a3c4 in mainline. Resetting an SMP guest will force AP enter real mode (RESET) with paging enabled in protected mode. While current enter_rmode() can only handle mode switch from nonpaging mode to real mode which leads to SMP reboot failure. Fix by reloading the mmu context on entering real mode. Signed-off-by:
Yaozu (Eddie) Dong <eddie.dong@intel.com> Signed-off-by:
Qing He <qing.he@intel.com> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Avi Kivity authored
patch 78f78268 in mainline. When resetting from userspace, we need to handle the flags being cleared even after we are in real mode. Signed-off-by:
-
Avi Kivity authored
patch 0967b7bf in mainline. If we defer updating rip until pio instructions are executed, we have a problem with reset: a pio reset updates rip, and when the instruction completes we skip the emulated instruction, pointing rip somewhere completely unrelated. Fix by updating rip when we see decode the instruction, not after emulation. Signed-off-by:
-
Amit Shah authored
patch 404fb881 in mainline. The clts code didn't use set_cr0 properly, so our lazy FPU processing wasn't being done by the clts instruction at all. (this isn't called on Intel as the hardware does the decode for us) Signed-off-by:
Amit Shah <amit.shah@qumranet.com> Signed-off-by:
-
Marko Kohtala authored
This is not in mainline, as it was fixed differently in that tree. first_cpu(cpus) returns the only CPU when NR_CPUS is 1 regardless of the cpus mask. Therefore we avoid a kernel hang in KVM_SET_MEMORY_REGION ioctl on uniprocessor by not entering the loop at all. Signed-off-by:
Marko Kohtala <marko.kohtala@gmail.com> Signed-off-by:
-
Amit Shah authored
patch 00b2ef47 in mainline. emulator_write_std() is not implemented, and calling write_emulated should work just as well in place of write_std. Fixes emulator failures with the push r/m instruction. Signed-off-by:
-
Avi Kivity authored
patch cf5a94d1 in mainline. 'invd' can destroy host data, and 'wbinvd' allows the guest to induce long (milliseconds) latencies. Noted by Ben Serebrin. Signed-off-by:
-
Avi Kivity authored
patch 651a3e29 in mainline. Emulate the 'invd' instruction (opcode 0f 08). Signed-off-by:
-
Aurelien Jarno authored
patch 4e62417b in mainline. The patch belows changes the access type to register from memory for instructions that are declared as SrcMem or DstMem, but have a ModR/M byte with Mod = 3. It fixes (at least) the lmsw and smsw instructions on an AMD64 CPU, which are needed for FreeBSD. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Sheng Yang authored
patch a012e65a in mainline. Implement emulation of instruction: movnti m32/m64, r32/r64 opcode: 0x0f 0xc3 Needed to support Linux 2.6.16 as guest (used for mmio). Signed-off-by:
Sheng Yang <sheng.yang@intel.com> Signed-off-by:
-
Thomas Gleixner authored
patch 62f0f61e in mainline Relative hrtimers with a large timeout value might end up as negative timer values, when the current time is added in hrtimer_start(). This in turn is causing the clockevents_set_next() function to set an huge timeout and sleep for quite a long time when we have a clock source which is capable of long sleeps like HPET. With PIT this almost goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code sorts this out in the next timer interrupt, so we never noticed that problem which has been there since the first day of hrtimers. This bug became more apparent in 2.6.24 which activates HPET on more hardware. Signed-off-by:
-
Ayaz Abdulla authored
patch 9e555930 in mainline. Fix a long boot delay in the forcedeth driver. During initialization, the timeout for the handshake between mgmt unit and driver can be very long. The patch reduces the timeout by eliminating a extra loop around the timeout logic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Cc: Alex Howells <astinus@gentoo.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Ayaz Abdulla authored
patch 490dde89 in mainline. This patch adds new device ids and features for mcp79 devices into the forcedeth driver. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Karsten Keil authored
patch eafe1aa3 in mainline. Fix possible memory overrun issue in the isdn ioctl code. Found by ADLAB <adlab@venustech.com.cn> Signed-off-by:
-
Hugh Dickins authored
patch e84e2e13 in mainline tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case in which shmem_getpage receives the page from its caller instead of allocating. We must cover this case by clear_highpage before SetPageUptodate, as before. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
David Brownell authored
patch 1cb52658 in mainline. A recent patch added software synchronization during EHCI startup, so ports aren't switched away from the companion controllers after resets have started. This patch adds a short delay letting hardware finish that port switching before any new resets begin ... so both ends of that hardware race window are closed. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Cc: Dave Miller <davem@davemloft.net> Cc: Dely Sy <dely.l.sy@intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Oliver Neukum authored
patch 5cf1973a in mainline to make HAL like the microtek driver's devices the parent must be correctly set. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
William Pettersson authored
changeset dac4ae0d in mainline. Input: ALPS - add support for model found in Dell Vostro 1400 Signed-off-by:
William Pettersson <william.pettersson@gmail.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Herbert Xu authored
patch a98ce5c6 in mainline. Fix synchronize_irq races with IRQ handler As it is some callers of synchronize_irq rely on memory barriers to provide synchronisation against the IRQ handlers. For example, the tg3 driver does tp->irq_sync = 1; smp_mb(); synchronize_irq(); and then in the IRQ handler: if (!tp->irq_sync) netif_rx_schedule(dev, &tp->napi); Unfortunately memory barriers only work well when they come in pairs. Because we don't actually have memory barriers on the IRQ path, the memory barrier before the synchronize_irq() doesn't actually protect us. In particular, synchronize_irq() may return followed by the result of netif_rx_schedule being made visible. This patch (mostly written by Linus) fixes this by using spin locks instead of memory barries on the synchronize_irq() path. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
-
Peter P Waskiewicz Jr authored
[PKT_SCHED]: Check subqueue status before calling hard_start_xmit [ Upstream commit: 5f1a485d ] The only qdiscs that check subqueue state before dequeue'ing are PRIO and RR. The other qdiscs, including the default pfifo_fast qdisc, will allow traffic bound for subqueue 0 through to hard_start_xmit. The check for netif_queue_stopped() is done above in pkt_sched.h, so it is unnecessary for qdisc_restart(). However, if the underlying driver is multiqueue capable, and only sets queue states on subqueues, this will allow packets to enter the driver when it's currently unable to process packets, resulting in expensive requeues and driver entries. This patch re-adds the check for the subqueue status before calling hard_start_xmit, so we can try and avoid the driver entry when the queues are stopped. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Zou Nan hai authored
patch ace8b3d6 in mainline. cache_nice_tries and flags entry do not appear in proc fs sched_domain directory, because ctl_table entry is skipped. This patch fixes the issue. Signed-off-by:
Zou Nan hai <nanhai.zou@intel.com> Signed-off-by:
-
Christian Borntraeger authored
commit 5d0360ee upstream. We have seen ramdisk based install systems, where some pages of mapped libraries and programs were suddendly zeroed under memory pressure. This should not happen, as the ramdisk avoids freeing its pages by keeping them dirty all the time. It turns out that there is a case, where the VM makes a ramdisk page clean, without telling the ramdisk driver. On memory pressure shrink_zone runs and it starts to run shrink_active_list. There is a check for buffer_heads_over_limit, and if true, pagevec_strip is called. pagevec_strip calls try_to_release_page. If the mapping has no releasepage callback, try_to_free_buffers is called. try_to_free_buffers has now a special logic for some file systems to make a dirty page clean, if all buffers are clean. Thats what happened in our test case. The simplest solution is to provide a noop-releasepage callback for the ramdisk driver. This avoids try_to_free_buffers for ramdisk pages. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Jan Kara <jack@suse.cz> Acked-by:
Nick Piggin <npiggin@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Evgeniy Polyakov authored
[NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage() [ Upstream commit: 77996525 ] Reported by Chuck Ebbert as: https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14 This routine is called each time hash should be replaced, nf_conn has extension list which contains pointers to connection tracking users (like nat, which is right now the only such user), so when replace takes place it should copy own extensions. Loop above checks for own extension, but tries to move higer-layer one, which can lead to above oops. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Eric Dumazet authored
[NET] random : secure_tcp_sequence_number should not assume CONFIG_KTIME_SCALAR [ Upstream commit: 6dd10a62 ] All 32 bits machines but i386 dont have CONFIG_KTIME_SCALAR. On these machines, ktime.tv64 is more than 4 times the (correct) result given by ktime_to_ns() Again on these machines, using ktime_get_real().tv64 >> 6 give a 32bits rollover every 64 seconds, which is not wanted (less than the 120 s MSL) Using ktime_to_ns() is the portable way to get nsecs from a ktime, and have correct code. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Marcelo Tosatti authored
patch 29f5f2a1 in mainline. Properly account for queue commands, this fixes a problem reported by Holger Schurig when using the debugfs interface. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
- 26 Nov, 2007 7 commits
-
-
Greg Kroah-Hartman authored
-
Dan Williams authored
patch 0b531676 in mainline. ipw2200 makes extensive use of background scanning when unassociated or down. Unfortunately, the firmware sends scan completed events many times per second, which the driver pushes directly up to userspace. This needlessly wakes up processes listening for wireless events many times per second. Batch together scan completed events for non-user-requested scans and send them up to userspace every 4 seconds. Scan completed events resulting from an SIOCSIWSCAN call are pushed up without delay. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Ortwin Glück authored
patch d466a919 in mainline. Not surprisingly the Nikon D40X DSC needs the same quirks as the D40, but it has a separate ID. See http://bugs.gentoo.org/show_bug.cgi?id=191431 From: Ortwin Glück <odi@odi.ch> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by:
-
Phil Dibowitz authored
patch 16eb345f in mainline. Upgrade the unusual_devs.h file to support the Nikon D200 Signed-off-by:
Mike Pagano <mpagano-kernel@mpagano.com> Signed-off-by:
Phil Dibowitz <phil@ipom.com> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by:
-
Ingo Molnar authored
patch a3b13c23 in mainline. sched_clock() is not a reliable time-source, use cpu_clock() instead. Signed-off-by:
-
Ingo Molnar authored
This is a merge of commits a5f2ce3c and 43581a10 in mainline to fix a warning in the 2.6.23.3 kernel release. softlockup watchdog: style cleanups kernel/softirq.c grew a few style uncleanlinesses in the past few months, clean that up. No functional changes: text data bss dec hex filename 1126 76 4 1206 4b6 softlockup.o.before 1129 76 4 1209 4b9 softlockup.o.after ( the 3 bytes .text increase is due to the "<1>" appended to one of the printk messages. ) Signed-off-by:
Satyam Sharma <satyam@infradead.org> Signed-off-by:
-
David P. Reed authored
patch c399da0d in mainline. x86: fix freeze in x86_64 RTC update code in time_64.c Fix hard freeze on x86_64 when the ntpd service calls update_persistent_clock() A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion dv9000z laptop. This freeze is due to the use of spin_lock(&rtc_lock) under the assumption (per a bad comment) that set_rtc_mmss is called only with interrupts disabled. The call from ntp.c to update_persistent_clock is made with interrupts enabled. [ tglx@linutronix.de: ported to 2.6.23.stable ] Signed-off-by:
David P. Reed <dpreed@reed.com> Signed-off-by:
-
