- 11 Nov, 2005 3 commits
-
-
Jens Axboe authored
Paul Collins wrote: >I boot with elevator=cfq (wanted to try the ionice stuff, never got >around to it). Having decided to go back to the anticipatory >scheduler, I did the following: > ># echo anticipatory > /sys/block/hda/queue/scheduler ># echo anticipatory > /sys/block/hdc/queue/scheduler > >A while later I did 'sudo snooze', which produced the Oops below. > >Booting with elevator=as and then changing to cfq, sleep works fine. >But if I resume and change back to anticipatory I get a similar Oops >on the next 'sudo snooze'. > > > Oops: kernel access of bad area, sig: 11 [#1] > NIP: C01E1948 LR: C01D6A60 SP: EFBC5C20 REGS: efbc5b70 TRAP: 0300 >Not tainted > MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: 00000020, DSISR: 40000000 > TASK = efb012c0[1213] 'pmud' THREAD: efbc4000 > Last syscall: 54 GPR00: 00080000 EFBC5C20 EFB012C0 EFE9E044 >EFBC5CE8 00000002 00000000 C03B0000 GPR08: C046E5D8 00000000 >C03B47C8 E6A58360 22042422 1001E4DC 10010000 10000000 GPR16: >10000000 10000000 10000000 7FE4EB40 10000000 10000000 10010000 >C0400000 GPR24: C0380000 00000002 00000002 C046E0C0 00000000 >00000002 00000000 EFBC5CE8 NIP [c01e1948] as_insert_request+0xa8/0x6b0 > LR [c01d6a60] __elv_add_request+0xa0/0x100 > Call trace: > [c01d6a60] __elv_add_request+0xa0/0x100 > [c01ffb84] ide_do_drive_cmd+0xb4/0x190 > [c01fc1c0] generic_ide_suspend+0x80/0xa0 > [c01d4574] suspend_device+0x104/0x160 > [c01d47c0] device_suspend+0x120/0x330 > [c03f3b50] pmac_suspend_devices+0x50/0x1b0 > [c03f4294] pmu_ioctl+0x344/0x9b0 > [c0082aa4] do_ioctl+0x84/0x90 > [c0082b3c] vfs_ioctl+0x8c/0x460 > [c0082f50] sys_ioctl+0x40/0x80 > [c0004850] ret_from_syscall+0x0/0x4c Don't clear ->elevator_data on exit, if we are switching queues we are overwriting the data of the new io scheduler. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dimitri Puzin authored
This patch by Dimitri Puzin submitted through kernel Bugzilla #5514 fixes the following issue: Cannot build XFS filesystem support as module with quota support. It works only when the XFS filesystem support is compiled into the kernel. Menuconfig prevents from setting CONFIG_XFS_FS=m and CONFIG_XFS_QUOTA=y. How to reproduce: configure the XFS filesystem with quota support as module. The resulting kernel won't have quota support compiled into xfs.ko. Fix: Changing the fs/xfs/Kconfig file from tristate to bool lets you configure the quota support to be compiled into the XFS module. The Makefile-linux-2.6 checks only for CONFIG_XFS_QUOTA=y. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Nathan Scott <nathans@sgi.com> Signed-off-by:
-
Roger While authored
prism54 is leaking information when passing transmits to the firmware. There is no requirement to adjust the length to >= ETH_ZLEN. Just pass the skb length (after possible adjustment). Signed-off-by:
Roger While <simrw@sim-basis.de> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
- 08 Nov, 2005 2 commits
-
-
Greg Kroah-Hartman authored
-
Al Viro authored
You could open the /proc/sys/net/ipv4/conf/<if>/<whatever> file, then wait for interface to go away, try to grab as much memory as possible in hope to hit the (kfreed) ctl_table. Then fill it with pointers to your function. Then do read from file you've opened and if you are lucky, you'll get it called as ->proc_handler() in kernel mode. So this is at least an Oops and possibly more. It does depend on an interface going away though, so less of a security risk than it would otherwise be. Signed-off-by:
-
- 28 Oct, 2005 1 commit
-
-
Linus Torvalds authored
"Better late than never"
-
- 27 Oct, 2005 6 commits
-
-
Linus Torvalds authored
-
Dave Jones authored
Don't try to access not-present CPUs. Conservative governor will always oops on SMP without this fix. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=4781Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
Commit id 6142891a Andi Kleen reports that it seems to break things for some people, and since it's purely a small optimization, revert it for now. Signed-off-by:
-
Herbert Xu authored
This bug is responsible for causing the infamous "Treason uncloaked" messages that's been popping up everywhere since the printk was added. It has usually been blamed on foreign operating systems. However, some of those reports implicate Linux as both systems are running Linux or the TCP connection is going across the loopback interface. In fact, there really is a bug in the Linux TCP header prediction code that's been there since at least 2.1.8. This bug was tracked down with help from Dale Blount. The effect of this bug ranges from harmless "Treason uncloaked" messages to hung/aborted TCP connections. The details of the bug and fix is as follows. When snd_wnd is updated, we only update pred_flags if tcp_fast_path_check succeeds. When it fails (for example, when our rcvbuf is used up), we will leave pred_flags with an out-of-date snd_wnd value. When the out-of-date pred_flags happens to match the next incoming packet we will again hit the fast path and use the current snd_wnd which will be wrong. In the case of the treason messages, it just happens that the snd_wnd cached in pred_flags is zero while tp->snd_wnd is non-zero. Therefore when a zero-window packet comes in we incorrectly conclude that the window is non-zero. In fact if the peer continues to send us zero-window pure ACKs we will continue making the same mistake. It's only when the peer transmits a zero-window packet with data attached that we get a chance to snap out of it. This is what triggers the treason message at the next retransmit timeout. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Arnaldo Carvalho de Melo <acme@mandriva.com>
-
Roland McGrath authored
This just makes sure that a thread's expiry times can't get reset after it clears them in do_exit. This is what allowed us to re-introduce the stricter BUG_ON() check in a362f463. Signed-off-by:
-
Linus Torvalds authored
This reverts commit 3de463c7. Roland has another patch that allows us to leave the BUG_ON() in place by just making sure that the condition it tests for really is always true. That goes in next. Signed-off-by:
-
- 26 Oct, 2005 14 commits
-
-
Oleg Nesterov authored
There's a silly off-by-one error in the code that updates the expiration of posix CPU timers, causing them to not be properly updated when they hit exactly on their expiration time (which should be the normal case). This causes them to then fire immediately again, and only _then_ get properly updated. Signed-off-by: -
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
Pointed out by Oleg Nesterov, who has been walking over the code forwards and backwards. Signed-off-by: -
Ivan Kokshaysky authored
I've seen similar failure on alpha. Obviously, someone forgot to convert sg->handle stuff for PCI gart case. Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Andrew Morton authored
Convert nanoseconds to microseconds correctly. Spotted by Steve Dickson <SteveD@redhat.com> Signed-off-by:
-
Peter Wainwright authored
fsck_hfs reveals lots of temporary files accumulating in the hidden directory "\000\000\000HFS+ Private Data". According to the HFS+ documentation these are files which are unlinked while in use. However, there may be a bug in the Linux hfsplus implementation which causes this to happen even when the files are not in use. It looks like the "opencnt" field is never initialized as (I think) it should be in hfsplus_read_inode. This means that a file can appear to be still in use when in fact it has been closed. This patch seems to fix it for me. Signed-off-by:
Anton Altaparmakov <aia21@cantab.net> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Jeff Garzik authored
Although this message is having the intended effect of causing wireless driver maintainers to upgrade their code, I never should have merged this patch in its present form. Leading to tons of bug reports and unhappy users. Some wireless apps poll for statistics regularly, which leads to a printk() every single time they ask for stats. That's a little bit _too_ much of a reminder that the driver is using an old API. Change this to printing out the message once, per kernel boot. Signed-off-by:
-
Andrew Morton authored
With CONFIG_SMP=n: *** Warning: "cpu_online_map" [drivers/firmware/dcdbas.ko] undefined! due to set_cpus_allowed(). Signed-off-by:
-
Benjamin Herrenschmidt authored
The mpic interrupt controller driver (used on G5 and early pSeries among others) has a bug where it doesn't get the right virtual address for the timer registers. It causes the driver to poke at the MMIO space of whatever has been mapped just next to it (ouch !) when initializing and causes boot failures on some IBM machines. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Magnus Damm authored
The NUMA counters in struct per_cpu_pageset (linux/mmzone.h) are never cleared today. This works ok for CPU 0 on NUMA machines because boot_pageset[] is already zero, but for other CPU:s this results in uninitialized counters. Signed-off-by:
Magnus Damm <magnus@valinux.co.jp> Signed-off-by:
-
NeilBrown authored
There are still a couple of cases where md threads (the resync/recovery thread) is not interruptible since the change to use kthreads. All places there it tests "signal_pending", it should also test kthread_should_stop, as with this patch. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Ian Campbell authored
Patch from Ian Campbell Sparse complains about the definition of generic_fls in asm-arm/bitops.h: CHECK /home/icampbell/devel/kernel/2.6/arch/arm/mach-pxa/viper.c include2/asm/bitops.h:350:34: error: marked inline, but without a definition The definition is unnecessary since linux/bitops.h defines generic_fls before including asm/bitops.h and asm/bitops.h should not be included directly. There are still some places where asm/bitops.h is directly included, but I think that code should be fixed. I was a little wary of the patch for this reason but lubbock, mainstone and assabet all build OK and so do my in house boards... ARM is the only arch with the generic_fls prototype in this way. Signed-off-by:
Ian Campbell <icampbell@arcom.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Torvalds authored
When reserving an PCI quirk, note that in the kernel bootup messages. Also, parse the strange PIIX4 device resources - they should get their own PCI resource quirks, but for now just print out what it finds to verify that the code does the right thing. Signed-off-by:
-
- 25 Oct, 2005 5 commits
-
-
Jochen Friedrich authored
Signed-off-by:
Jochen Friedrich <jochen@scram.de> Signed-off-by:
-
Jochen Friedrich authored
Signed-off-by:
-
Yan Zheng authored
Signed-off-by:
Yan Zheng <yanzheng@21cn.com> Acked-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Andrew Morton authored
If qla2x00_probe_one()'s call to qla2x00_iospace_config() fails, we call qla2x00_free_device() to clean up. But because ha->dpc_pid hasn't been set yet, qla2x00_free_device() tries to stop a kernel thread which hasn't started yet. It does wait_for_completion() against an uninitialised completion struct and the kernel hangs up. Fix it by initialising ha->dpc_pid a bit earlier. Cc: Andrew Vasquez <andrew.vasquez@qlogic.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
-
Andrew Morton authored
My alpha build is exploding because asm/atomic.h now needs smb_mb(), which is over in the (not included) system.h. I fear what will happen if I include system.h into atomic.h, so let's put the barriers into their own header file. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
- 24 Oct, 2005 9 commits
-
-
Pavel Machek authored
This fixes compile problem when CONFIG_FB_PXA is not set. LD .tmp_vmlinux1 arch/arm/mach-pxa/built-in.o(.text+0x1d74): In function `spitz_get_hsync_len': : undefined reference to `pxafb_get_hsync_time' make: *** [.tmp_vmlinux1] Error 1 3.46user 0.46system 5.10 (0m5.106s) elapsed 77.01%CPU Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Justin Chen authored
Add the new ID 0x132a and configure the new PCI Diva console port. This device supports only 1 single console UART. Signed-off-by:
-
Bjorn Helgaas authored
Tested by Wolfgang Denk with this device: 00:0f.0 Network controller: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 01) Subsystem: Exsys EX-4055 4S(16C550) RS-232 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 10 Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=128] Region 1: I/O ports at 7080 [size=128] Region 2: I/O ports at 7400 [size=32] 00:0f.0 Class 0280: 10b5:9050 (rev 01) Subsystem: d84d:4055 Results with this patch: Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A PCI: Found IRQ 10 for device 0000:00:0f.0 ttyS4 at I/O 0x7400 (irq = 10) is a 16550A ttyS5 at I/O 0x7408 (irq = 10) is a 16550A ttyS6 at I/O 0x7410 (irq = 10) is a 16550A ttyS7 at I/O 0x7418 (irq = 10) is a 16550A Signed-off-by:Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
James Simmons authored
This small patch returns the stride/line length of the framebuffer via sysfs. Signed-off-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
-
Takashi Iwai authored
The patch fixes Oops from sound drivers using generic platform device but have no suspend/resume callbacks. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Miklos Szeredi authored
Without this patch, uml compile fails with: LD .tmp_vmlinux1 arch/um/kernel/built-in.o: In function `config_gdb_cb': arch/um/kernel/tt/gdb.c:129: undefined reference to `TASK_EXTERN_PID' Tested on i386, but fix needed on x86_64 too AFAICS. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Oleg Nesterov authored
This might be harmless, but looks like a race from code inspection (I was unable to trigger it). I must admit, I don't understand why we can't return TIMER_RETRY after 'spin_unlock(&p->sighand->siglock)' without doing bump_cpu_timer(), but this is what original code does. posix_cpu_timer_set: read_lock(&tasklist_lock); spin_lock(&p->sighand->siglock); list_del_init(&timer->it.cpu.entry); spin_unlock(&p->sighand->siglock); We are probaly deleting the timer from run_posix_cpu_timers's 'firing' local list_head while run_posix_cpu_timers() does list_for_each_safe. Various bad things can happen, for example we can just delete this timer so that list_for_each() will not notice it and run_posix_cpu_timers() will not reset '->firing' flag. In that case, .... if (timer->it.cpu.firing) { read_unlock(&tasklist_lock); timer->it.cpu.firing = -1; return TIMER_RETRY; } sys_timer_settime() goes to 'retry:', calls posix_cpu_timer_set() again, it returns TIMER_RETRY ... Signed-off-by:Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Oleg Nesterov authored
No need to rebalance when task exited Signed-off-by:
-
Oleg Nesterov authored
do_exit() clears ->it_##clock##_expires, but nothing prevents another cpu to attach the timer to exiting process after that. After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and before do_exit() calls 'schedule() local timer interrupt can find tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu does sys_wait4) interrupted task has ->signal == NULL. At this moment exiting task has no pending cpu timers, they were cleaned up in __exit_signal()->posix_cpu_timers_exit{,_group}(), so we can just return from irq. Signed-off-by:
-
