Re: kernel status, 4 Aug 2005
Hello Andrew, > [Bugme-new] [Bug 4992] New: Power off stops > http://bugzilla.kernel.org/show_bug.cgi?id=4992 Works for me now. I've tested with 2.6.13-rc6 a few hours again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove suspend() calls from shutdown path
Hello Ben, Andrew,
This patch helps me if I disconnect all USB peripherals before shutting
down notebook. With connected peripherals (USB mouse, PL2303
USB<->serial converter/port) - powering off process stops right after
unmounting filesystems but before hda power off ...
There is a bug report for this too:
http://bugzilla.kernel.org/show_bug.cgi?id=4992
Z.
On Thu, Aug 04, 2005 at 11:36:26AM +0200, Benjamin Herrenschmidt wrote:
> Hi Andrew !
>
> This patch remove the calls to device_suspend() from the shutdown path
> that were added sometime during 2.6.13-rc*. They aren't working properly
> on a number of configs (I got reports from both ppc powerbook users and
> x86 users) causing the system to not shutdown anymore.
>
> I think it isn't the right approach at the moment anyway. We have
> already a shutdown() callback for the drivers that actually care about
> shutdown and the suspend() code isn't yet in a good enough shape to be
> so much generalized. Also, the semantics of suspend and shutdown are
> slightly different on a number of setups and the way this was patched in
> provides little way for drivers to cleanly differenciate. It should have
> been at least a different message.
>
> For 2.6.13, I think we should revert to 2.6.12 behaviour and have a
> working suspend back.
>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> Index: linux-work/kernel/sys.c
> ===
> --- linux-work.orig/kernel/sys.c 2005-08-01 14:03:46.0 +0200
> +++ linux-work/kernel/sys.c 2005-08-04 11:32:51.0 +0200
> @@ -404,7 +404,6 @@
> {
> notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
> system_state = SYSTEM_HALT;
> - device_suspend(PMSG_SUSPEND);
> device_shutdown();
> printk(KERN_EMERG "System halted.\n");
> machine_halt();
> @@ -415,7 +414,6 @@
> {
> notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
> system_state = SYSTEM_POWER_OFF;
> - device_suspend(PMSG_SUSPEND);
> device_shutdown();
> printk(KERN_EMERG "Power down.\n");
> machine_power_off();
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove suspend() calls from shutdown path
On Thu, 2005-08-04 at 17:20 +0200, Benjamin Herrenschmidt wrote: > On Thu, 2005-08-04 at 15:16 +0300, Zilvinas Valinskas wrote: > > Hello Ben, Andrew, > > > > This patch helps me if I disconnect all USB peripherals before shutting > > down notebook. With connected peripherals (USB mouse, PL2303 > > USB<->serial converter/port) - powering off process stops right after > > unmounting filesystems but before hda power off ... > > > > There is a bug report for this too: > > http://bugzilla.kernel.org/show_bug.cgi?id=4992 > > This is unclear. > > I would expect the behaviour you report to happen _without_ this patch, > that is with current git tree, and I would expect this patch to fix it > by reverting to the previous 2.6.12 behaviour... > > Ben. Sys-rq - T: shows device_suspend() is called, perhaps that explains. It seems that any attempt to suspend either USB hub or device connected to it results in freeze. :\ Just guessing. Anything else should I try ? hcd_submit_urb wait_for_completion default_wake_function usb_start_wait_urb timeout_kill usb_internal_control_msg usb_control_msg hub_port_suspend __usb_suspend_device locktree usb_suspend_device __link_walk_path device_suspend <- still called ? ohci_reboot generic_ide_ioctl activate_task __group_send_sig_info sys_kill block_ioctl block_ioctl do_ioctl vfs_ioctl get_name sys_ioctl sys_enter_esp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ABit KT7A-RAIN random lock ups
Hello listers, as of yesterday I started to get random hard lockups. It was strange because just before that I've never had one ... MB worked just fine for now about two months. Until yesterday ... I tried to boot 2.4.3-ac14, 2.4.4, 2.4.4-ac4 ... the same. Btw. I have ACPI enabled, so sometimes I see lots of defunc processes kacpidpc defunct ... and that number keeps growing. Ok, I see that new kernel might misbehave but for example 2.4.3-ac14 used to work as charm and there I see the same ... tons of defunc processes ... until fork: resource temporary unavailable error ... So that's not the kernel (my guess.). Last night I booted up win 98 to play unreal tournament. Then booted back to linux ... and there we go I hit strange pile of the problems and I don't know how to deal with them. Tinkered for a while. Disable acpi or so ... trying to recompile kernels - random lock ups. Sometimes it works fine for longer time sometimes it hangs much faster ... most of time I saw kacpidpc defuncs ... Yet later 5am. in the morning I gave up. ... But then I realized that win 98 did something ... lets try clean up BIOS'es (with jumper). Now it works just fine again as it used to ... Now I don't have a clue as to what was wrong ? Win98 reprograms hardware ? and linux can't handle it in this "win98" state ? Looks like it :( No Ooops. Just plain hard lock up. No cpu not overclocked. Latest BIOS version. My hardware : 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:08.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 07) 00:0f.1 Input device controller: Creative Labs SB Live! (rev 07) 01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 swoop@tweakster:~$ cat /proc/ide/via --VIA BusMastering IDE Configuration Driver Version: 3.23 South Bridge: VIA vt82c686b ^ Revision: ISA 0x40 IDE 0x6 Highest DMA rate: UDMA100 BM-DMA base:0xd000 PCI clock: 33MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit swoop@tweakster:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 850.047 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1697.38 Any ideas ? -- Zilvinas Valinskas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon possible fixes
On Sun, May 06, 2001 at 07:44:19PM +0300, Jussi Laako wrote: > Seth Goldberg wrote: > > > > and rebooted, the system stayed up a lot longer, but it still crashed (I > > was in Xwindows and the crash was partially written to the log file) > > after around 3 minutes of work in X. > > Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS > A7V133 & Duron/800 when using IDE autotuning (PDC20265). > > Still haven't got any replies suggesting any reason for lockups I'm seeing > (no oopses). Or is the Promise driver just buggy, because system is solid > with noautotune. RAID5 (md) on that server is just little bit sluggish with > ~1.7 MB/s transfer rate... I should have stayed with SCSI disks... http://www.viahardware.com/ there you should find (if I'm right) somewhere mentioned that you likely to trash your hard drives or experience random lock ups with KT133a chipset especially if you use off-board ide controller ... As to why it happens is beyond me to explain ... (maybe even this doesn't apply for case). -- Zilvinas Valinskas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA/PDC/Athlon
On Wed, May 16, 2001 at 08:25:56PM +0300, Jussi Laako wrote: > I tested 2.4.4-ac9 today on A7V133 machine. It booted up, but can't stand > any load. It will deadlock (without oops) when the network/disk system faces > any load. > reset/clear CMOS with jumper. I get this kind of instability each time I have to boot to win9x (with latest and greatest via drivers) and back to linux. Just of sudden linux freezes or if I have apcid running sometimes it oops' on boot sometimes later ... lots of defunc kacpid ... threads. looks like VIA drivers do something to hardware (or maybe only ACPI part of hardware ... I don't know.) and linux can't handle hardware is this new "after win9x" state ... reset/clear CMOS with jumper helped. MB ABit KT7A-RAID 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) VT82C686b actually :) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:08.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 07) 00:0f.1 Input device controller: Creative Labs SB Live! (rev 07) 01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 > > - Jussi Laako > > -- > PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B > Available at PGP keyservers > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Zilvinas Valinskas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc3
Hello lkml, Linux kernel v2.6.23-rc3 booted ok and so far everything is fine. I have HP Compaq nx9420 laptop (Dual Core). Just a few things that I found interesting: 1. /sys/devices/system/clocksource/clocksource0/* $ sudo grep . * available_clocksource:hpet hpet acpi_pm jiffies tsc ^ listed twice ;) not a big deal but still. current_clocksource:hpet seems selected ;) although in dmesg there are $ dmesg | grep -i hpet $ dmesg | grep -i hpet ACPI: HPET 7FFE59BC, 0038 (r1 HP 309F1 HP 1) ACPI: HPET id: 0x8086a201 base: 0xfed0 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz hpet_resources: 0xfed0 is busy ^^ ? strange. Time: hpet clocksource has been installed. 2. ACPI related (?) - one fan is always on, even when system is idling. It never stops ;) $ acpi -bt Battery 1: charged, 98% Thermal 1: ok, 48.0 degrees C Thermal 2: ok, 38.0 degrees C Thermal 3: active[5], 47.0 degrees C Thermal 4: ok, 37.0 degrees C Thermal 5: ok, 32.0 degrees C Thermal 6: ok, 25.0 degrees C In earlier kernel versions it was turned on when needed (mostly during compilation ...) and then when system is cooled enough fan was automatically turned off. 3. the same messages are printed twice (2.6.23-rc2 was fine). Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f800 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 ACPI: EC: Look up EC in DSDT ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 1st time ACPI: Interpreter enabled ACPI: (supports S0 S3) ACPI: Using IOAPIC for interrupt routing ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 2nd time ACPI: PCI Root Bridge [C003] (:00) Otherwise I am happy with 2.6.23-rc3. Thank y'all ;) Best regards, Zilvinas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc3
Hello, I have also noticed that there are other messages printed twice, not a big problem but still ;) . Perhaps it should be that way, don't know. $ dmesg | grep sda sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Inserting USB key also has the same behavior: Initializing USB Mass Storage driver... scsi6 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb-storage: device found at 4 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 6:0:0:0: Direct-Access USB 2.0 Flash Disk 1100 PQ: 0 ANSI: 0 CCS sd 6:0:0:0: [sdb] 4062208 512-byte hardware sectors (2080 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] 4062208 512-byte hardware sectors (2080 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 6:0:0:0: [sdb] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg2 type 0 On Mon, 2007-08-13 at 15:23 +0300, Zilvinas Valinskas wrote: > Hello lkml, > > Linux kernel v2.6.23-rc3 booted ok and so far everything is fine. I have > HP Compaq nx9420 laptop (Dual Core). > > Just a few things that I found interesting: > > 1. /sys/devices/system/clocksource/clocksource0/* > > $ sudo grep . * > available_clocksource:hpet hpet acpi_pm jiffies tsc > ^ listed twice ;) not a big deal but still. > current_clocksource:hpet > seems selected ;) although in dmesg there are > > $ dmesg | grep -i hpet > $ dmesg | grep -i hpet > ACPI: HPET 7FFE59BC, 0038 (r1 HP 309F1 HP 1) > ACPI: HPET id: 0x8086a201 base: 0xfed0 > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 > hpet0: 3 64-bit timers, 14318180 Hz > hpet_resources: 0xfed0 is busy > ^^ ? strange. > > Time: hpet clocksource has been installed. > > 2. ACPI related (?) - one fan is always on, even when system is idling. > > It never stops ;) > > $ acpi -bt > Battery 1: charged, 98% > Thermal 1: ok, 48.0 degrees C > Thermal 2: ok, 38.0 degrees C > Thermal 3: active[5], 47.0 degrees C > Thermal 4: ok, 37.0 degrees C > Thermal 5: ok, 32.0 degrees C > Thermal 6: ok, 25.0 degrees C > > > In earlier kernel versions it was turned on when needed (mostly during > compilation ...) and then when system is cooled enough fan was > automatically turned off. > > 3. the same messages are printed twice (2.6.23-rc2 was fine). > > Brought up 2 CPUs > NET: Registered protocol family 16 > ACPI: bus type pci registered > PCI: BIOS Bug: MCFG area at f800 is not E820-reserved > PCI: Not using MMCONFIG. > PCI: Using configuration type 1 > ACPI: EC: Look up EC in DSDT > ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 > 1st time > ACPI: Interpreter enabled > ACPI: (supports S0 S3) > ACPI: Using IOAPIC for interrupt routing > ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 > 2nd time > ACPI: PCI Root Bridge [C003] (:00) > > > Otherwise I am happy with 2.6.23-rc3. Thank y'all ;) > > Best regards, > Zilvinas > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc3
Hello Michal, This morning I have booted laptop, for a while fan had been turned off. But then after a light load (compiling stuff & co), fan was turned on and now it is still on. [EMAIL PROTECTED]:~$ acpi -bt Battery 1: charged, 97% Thermal 1: ok, 48.0 degrees C Thermal 2: ok, 37.0 degrees C Thermal 3: ok, 46.0 degrees C Thermal 4: ok, 37.0 degrees C Thermal 5: ok, 32.0 degrees C Thermal 6: ok, 20.0 degrees C Temperatures don't seem to be that high to keep the fan on. Z. On Mon, 2007-08-13 at 18:49 +0200, Michal Piotrowski wrote: > Hi Zilvinas, > > On 13/08/07, Zilvinas Valinskas <[EMAIL PROTECTED]> wrote: > > Hello lkml, > > > > Linux kernel v2.6.23-rc3 booted ok and so far everything is fine. I have > > HP Compaq nx9420 laptop (Dual Core). > > > > Just a few things that I found interesting: > > > > 1. /sys/devices/system/clocksource/clocksource0/* > > > > $ sudo grep . * > > available_clocksource:hpet hpet acpi_pm jiffies tsc > > ^ listed twice ;) not a big deal but still. > > current_clocksource:hpet > > seems selected ;) although in dmesg there are > > > > $ dmesg | grep -i hpet > > $ dmesg | grep -i hpet > > ACPI: HPET 7FFE59BC, 0038 (r1 HP 309F1 HP 1) > > ACPI: HPET id: 0x8086a201 base: 0xfed0 > > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 > > hpet0: 3 64-bit timers, 14318180 Hz > > hpet_resources: 0xfed0 is busy > > ^^ ? strange. > > > > Time: hpet clocksource has been installed. > > > > 2. ACPI related (?) - one fan is always on, even when system is idling. > > > > It never stops ;) > > Hmmm... looks like a thermal trip points problem. > > > > > $ acpi -bt > > Battery 1: charged, 98% > > Thermal 1: ok, 48.0 degrees C > > Thermal 2: ok, 38.0 degrees C > > Thermal 3: active[5], 47.0 degrees C > > Thermal 4: ok, 37.0 degrees C > > Thermal 5: ok, 32.0 degrees C > > Thermal 6: ok, 25.0 degrees C > > > > > > In earlier kernel versions it was turned on when needed (mostly during > > compilation ...) and then when system is cooled enough fan was > > automatically turned off. > > > > 3. the same messages are printed twice (2.6.23-rc2 was fine). > > > > Brought up 2 CPUs > > NET: Registered protocol family 16 > > ACPI: bus type pci registered > > PCI: BIOS Bug: MCFG area at f800 is not E820-reserved > > PCI: Not using MMCONFIG. > > PCI: Using configuration type 1 > > ACPI: EC: Look up EC in DSDT > > ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 > > 1st time > > ACPI: Interpreter enabled > > ACPI: (supports S0 S3) > > ACPI: Using IOAPIC for interrupt routing > > ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 > > 2nd time > > ACPI: PCI Root Bridge [C003] (:00) > > > > > > Otherwise I am happy with 2.6.23-rc3. Thank y'all ;) > > > > Best regards, > > Zilvinas > > Regards, > Michal > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello, In short, on shutdown my laptop is always freezing now. I was able to capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please see .config and log messages at http://barclay.balt.net/~zilvinas/oops/ Kernel version I had built according git is : [EMAIL PROTECTED]:/projects/linux-amd64.git$ git describe HEAD v2.6.22-rc1-29-gfaa8b6c On top of that I have CFS v12 applied (no other changes otherwise). Please note that there is ''fglrx.ko'' loaded and kernel is tainted because of that (feel free to ignore the report ...). Anyway, 'sysrq-P' always show that PC is stuck at (NFS lockd?) and it is always the same backtrace is shown. 'sysrq-t' output is in 'kernel-nfs-freeze.log' file (did not want to post it here). Pid: 3652, comm: lockd Tainted: P 2.6.22-rc1-cfs-v12 #1 [] wq_barrier_func+0x0/0x10 [] destroy_workqueue+0x75/0xa0 [] :sunrpc:rpciod_down+0xf4/0x170 [] :lockd:lockd+0x244/0x300 [] schedule_tail+0x3f/0xb0 [] child_rip+0xa/0x12 [] :lockd:lockd+0x0/0x300 [] :lockd:lockd+0x0/0x300 [] child_rip+0x0/0x12 Hope this helps. Thanks in advance for any advice how to solve problem ! For now I am back to '2.6.21.1-cfs-v10'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello Oleg, Andrew, Sure no problem Oleg, compiling now, reboot will follow with results. Thank you both ! On Thu, 2007-05-17 at 02:55 +0400, Oleg Nesterov wrote: > Zilvinas, could you try the patch below? > > It is a shot in the dark. I hope I'll suggest somethimg better tomorrow. > > Oleg. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello Oleg, Patch seems to help and it seems kernel doesn't free anymore. I've booted new kernel and did : #1 $ sudo /etc/init.d/nfs-kernel-server stop #2 $ sudo /etc/init.d/nfs-common stop Previously it was enough to run '#1' to freeze the kernel. This time with your patch applied #1 and #2 worked fine. So far so good. Don't know why , but I've tried to run #1 & #2 several times - as a result OOPS (kernel is tainted). Opps from dmesg: [ 429.103734] usb 1-5.4: link qh8-0601/81003ebac320 start 7 [1/2 us] [ 436.009276] nfsd: last server has exited [ 436.009410] nfsd: unexporting all filesystems [ 436.011395] RPC: failed to contact local rpcbind server (errno 5). [ 460.950495] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 460.950659] NFSD: starting 90-second grace period [ 615.796112] nfsd: last server has exited [ 615.796121] nfsd: unexporting all filesystems [ 615.800976] RPC: failed to contact local rpcbind server (errno 5). [ 619.444368] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 619.03] NFSD: starting 90-second grace period [ 620.576730] nfsd: last server has exited [ 620.576739] nfsd: unexporting all filesystems [ 620.581036] RPC: failed to contact local rpcbind server (errno 5). [ 621.606324] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 621.606359] NFSD: starting 90-second grace period [ 622.561989] nfsd: last server has exited [ 622.561999] nfsd: unexporting all filesystems [ 623.639396] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 623.639430] NFSD: starting 90-second grace period [ 623.639487] Unable to handle kernel paging request at RIP: [ 623.639492] [] __kfree_skb+0x9f/0x150 [ 623.639504] PGD 203067 PUD 0 [ 623.639510] Oops: 0002 [1] PREEMPT SMP [ 623.639515] CPU 0 [ 623.639519] Modules linked in: fglrx(P) nfs nfsd exportfs lockd nfs_acl sunrpc ppdev lp autofs4 ipw3945 ieee80211 ieee80211_crypt ipv6 deflate zlib_deflate twofish twofish_common camellia serpent blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null af_key piix ide_core dm_crypt dm_snapshot dm_mirror dm_mod sbp2 loop coretemp cpufreq_conservative cpufreq_stats acpi_cpufreq freq_table usbhid pl2303 ohci1394 ieee1394 usbserial pcmcia firmware_class snd_hda_intel snd_pcm_oss snd_mixer_oss sdhci snd_pcm joydev iTCO_wdt fw_ohci fw_core mmc_core snd_timer tg3 sg snd yenta_socket rsrc_nonstatic pcmcia_core crc_itu_t iTCO_vendor_support tifm_7xx1 tsdev parport_pc parport intel_agp tpm_infineon tpm tpm_bios uhci_hcd sr_mod tifm_core ehci_hcd psmouse soundcore snd_page_alloc pcspkr serio_raw evdev cdrom [ 623.639616] Pid: 616, comm: udevd Tainted: P 2.6.22-rc1-cfs-v12 #2 [ 623.639622] RIP: 0010:[] [] __kfree_skb+0x9f/0x150 [ 623.639631] RSP: 0018:81003ed87be8 EFLAGS: 00010286 [ 623.639635] RAX: 81003f2144a0 RBX: RCX: [ 623.639641] RDX: 0130 RSI: 8100285eb400 RDI: [ 623.639646] RBP: 8100285eb400 R08: 0050eaf0 R09: [ 623.639651] R10: R11: 0246 R12: 81003f214400 [ 623.639656] R13: 81003ed87ee8 R14: 8100285eb440 R15: [ 623.639662] FS: 2b0370c18e00() GS:80603000() knlGS: [ 623.639667] CS: 0010 DS: ES: CR0: 8005003b [ 623.639672] CR2: CR3: 3ed6c000 CR4: 06e0 [ 623.639678] Process udevd (pid: 616, threadinfo 81003ed86000, task 81003ecd) [ 623.639682] Stack: 81003ed87ee8 81003ed87e68 8100285eb400 8043b6a6 [ 623.639694] 0001 810001ff7b80 0050 81003ed87db8 [ 623.639702] [ 623.639709] Call Trace: [ 623.639719] [] netlink_recvmsg+0x176/0x3a0 [ 623.639739] [] sock_recvmsg+0x150/0x170 [ 623.639754] [] autoremove_wake_function+0x0/0x30 [ 623.639768] [] core_sys_select+0x26e/0x350 [ 623.639785] [] __d_lookup+0x165/0x180 [ 623.639797] [] sys_recvfrom+0xfe/0x190 [ 623.639807] [] remove_wait_queue+0x19/0x60 [ 623.639823] [] sys_select+0x44/0x1c0 [ 623.639836] [] system_call+0x7e/0x83 [ 623.639849] [ 623.639851] [ 623.639852] Code: f0 ff 0f 0f 94 c0 84 c0 75 27 66 c7 85 a8 00 00 00 00 00 66 [ 623.639871] RIP [] __kfree_skb+0x9f/0x150 [ 623.639878] RSP [ 623.639881] CR2: Hmm, I've got something different now :( - On Thu, 2007-05-17 at 02:55 +0400, Oleg Nesterov wrote: > On Wed, 16 May 2007 21:00:41 +0300 > Zilvinas Valinskas <[EMAIL PROTECTED]> wrote: > > > > In short, on shutdown my laptop is always freezing now. I was able to > > capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Pl
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
: 1716, comm: kjournald Tainted: P 2.6.22-rc1-cfs-v12 #2 May 17 11:36:57 zv kernel: [ 647.184519] RIP: 0010:[] [] kmem_cache_alloc+0x2f /0x60 May 17 11:36:57 zv kernel: [ 647.184528] RSP: 0018:81003e399d00 EFLAGS: 00010002 May 17 11:36:57 zv kernel: [ 647.184533] RAX: RBX: 0206 RCX: 0001 May 17 11:36:57 zv kernel: [ 647.184538] RDX: 810001a269d0 RSI: 00011200 RDI: 80610070 May 17 11:36:57 zv kernel: [ 647.184543] RBP: 81003ff9d000 R08: 0003 R09: May 17 11:36:57 zv kernel: [ 647.184548] R10: R11: 802f00c0 R12: 00011210 May 17 11:36:57 zv kernel: [ 647.184554] R13: 81003ff9d030 R14: 81003e399d10 R15: 0010 May 17 11:36:57 zv kernel: [ 647.184560] FS: () GS:810001fbd080() knlGS:00 00 May 17 11:36:57 zv kernel: [ 647.184565] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b May 17 11:36:57 zv kernel: [ 647.184569] CR2: 0001 CR3: 21285000 CR4: 06e0 May 17 11:36:57 zv kernel: [ 647.184576] Process kjournald (pid: 1716, threadinfo 81003e398000, task 81003e 36a000) May 17 11:36:57 zv kernel: [ 647.184580] Stack: 0001 80272433 810035e49180 802fe7f 2 May 17 11:36:57 zv kernel: [ 647.184591] 810020cc4850 810035e49180 810038bed180 0004 May 17 11:36:57 zv kernel: [ 647.184600] 81003f453420 0001 0001 810035e49180 May 17 11:36:57 zv kernel: [ 647.184607] Call Trace: May 17 11:36:57 zv kernel: [ 647.184617] [] mempool_alloc+0x43/0x120 May 17 11:36:57 zv kernel: [ 647.184626] [] __journal_file_buffer+0xe2/0x240 May 17 11:36:57 zv kernel: [ 647.184640] [] bio_alloc_bioset+0x34/0x120 May 17 11:36:57 zv kernel: [ 647.184651] [] bio_alloc+0x10/0x30 May 17 11:36:57 zv kernel: [ 647.184657] [] submit_bh+0x5f/0x130 May 17 11:36:57 zv kernel: [ 647.184666] [] journal_commit_transaction+0x1013/0x13f0 May 17 11:36:57 zv kernel: [ 647.184677] [] thread_return+0x51/0x675 May 17 11:36:57 zv kernel: [ 647.184688] [] lock_timer_base+0x34/0x70 May 17 11:36:57 zv kernel: [ 647.184702] [] kjournald+0xdf/0x240 May 17 11:36:57 zv kernel: [ 647.184712] [] autoremove_wake_function+0x0/0x30 May 17 11:36:57 zv kernel: [ 647.184720] [] kjournald+0x0/0x240 May 17 11:36:57 zv kernel: [ 647.184727] [] kjournald+0x0/0x240 May 17 11:36:57 zv kernel: [ 647.184735] [] kthread+0x4b/0x80 May 17 11:36:57 zv kernel: [ 647.184743] [] child_rip+0xa/0x12 May 17 11:36:57 zv kernel: [ 647.184765] [] child_rip+0x0/0x12 May 17 11:36:57 zv kernel: [ 647.184771] May 17 11:36:57 zv kernel: [ 647.184774] May 17 11:36:57 zv kernel: [ 647.184775] Code: 48 8b 04 c1 48 89 42 10 53 9d 5b 48 89 c8 c3 66 90 49 89 d0 May 17 11:36:57 zv kernel: [ 647.184801] RSP :) game over. *sighs* May 17 11:37:26 zv kernel: [ 675.960418] SysRq : Emergency Sync May 17 11:37:26 zv kernel: [ 675.965493] Emergency Sync complete May 17 11:37:26 zv kernel: [ 676.652982] SysRq : Emergency Sync May 17 11:37:26 zv kernel: [ 676.653112] Emergency Sync complete May 17 11:37:27 zv kernel: [ 677.425588] SysRq : Emergency Sync May 17 11:37:27 zv kernel: [ 677.426232] Emergency Sync complete May 17 11:37:29 zv kernel: [ 679.500230] SysRq : Emergency Sync May 17 11:37:29 zv kernel: [ 679.500385] Emergency Sync complete May 17 11:37:38 zv kernel: [ 688.671466] SysRq : Emergency Sync May 17 11:37:38 zv kernel: [ 688.675806] Emergency Sync complete May 17 11:37:39 zv kernel: [ 689.012734] SysRq : Emergency Sync May 17 11:37:39 zv kernel: [ 689.012881] Emergency Sync complete May 17 11:37:39 zv kernel: [ 689.575176] SysRq : Emergency Remount R/O May 17 11:37:40 zv kernel: [ 690.296747] SysRq : Emergency Remount R/O On Thu, 2007-05-17 at 11:21 +0300, Zilvinas Valinskas wrote: > Hello Oleg, > > Patch seems to help and it seems kernel doesn't free anymore. I've > booted new kernel and did : > > #1 $ sudo /etc/init.d/nfs-kernel-server stop > #2 $ sudo /etc/init.d/nfs-common stop > > Previously it was enough to run '#1' to freeze the kernel. This time > with your patch applied #1 and #2 worked fine. So far so good. Don't > know why , but I've tried to run #1 & #2 several times - as a result > OOPS (kernel is tainted). Opps from dmesg: > > [ 429.103734] usb 1-5.4: link qh8-0601/81003ebac320 start 7 [1/2 us] > [ 436.009276] nfsd: last server has exited > [ 436.009410] nfsd: unexporting all filesystems > [ 436.011395] RPC: failed to contact local rpcbind server (errno 5). > [ 460.950495] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state > recovery directory > [ 460.950659] NFSD: starting 90-second grace period > [ 615.796112] nfsd: last server has exited > [ 615.796121] n
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello Oleg, On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote: > Hello Zilvinas, > > On 05/17, Zilvinas Valinskas wrote: > > > > Patch seems to help and it seems kernel doesn't free anymore. I've > > booted new kernel and did : > > OK, thank you very much. So, we have some other problems, and I _think_ > that workqueue.c is not the source of them. You are welcome. I wish I could determine and fix the problem myself. I will try to help, debug the problem as long as there is any progress or ideas to try out. > However, I can't understand why cleanup_workqueue_thread() hangs anyway. > It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU. According > to kernel-nfs-freeze.log it is TASK_RUNNING. Strange. > > It is very sad, because this code was supposed to be cleanuped anyway, > but if it is really buggy, it would be great to know why. Can this be related to : CONFIG_PREEMPT=y # CONFIG_PREEMPT_BKL is not set > Perhaps, we can understand the problem with your help. Could you please > revert the patch I sent, and send me (privately) the output of > > objdump -d kernel/workqueue.o I have uploaded files at http://barclay.balt.net/~zilvinas/oops/ workqueue.objdump - without any patch. workqueue+oleg-old.objdump - with older patch Oleg sent on Thu, 17 May. workqueue+oleg-new.objdump - with the newest patch from Oleg applied. For what it's worth, I am using Debian/Unstable $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c ++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) $ ld -V GNU ld (GNU Binutils for Debian) 2.17.50.20070426 Supported emulations: elf_x86_64 elf_i386 i386linux > ? I doubt very much I'll see something interesting, but who knows... > > Thanks! > > Oleg. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello, Have found this in dmesg (well earlier because of initcall_debug) I've never noticed that during boot (scrolls away too fast). Anyway - [7.841871] NetLabel: Initializing [7.841983] NetLabel: domain hash size = 128 [7.842095] NetLabel: protocols = UNLABELED CIPSOv4 [7.842219] NetLabel: unlabeled traffic allowed by default [7.842338] BUG: at include/linux/slub_def.h:77 kmalloc_index() [7.842451] [7.842452] Call Trace: [7.842677] [] get_slab+0x1cc/0x260 [7.842791] [] __kmalloc+0xd/0x80 [7.842907] [] cache_k8_northbridges+0x7e/0x100 [7.843024] [] gart_iommu_init+0x33/0x5b0 [7.843140] [] netlbl_unlabel_acceptflg_set+0x86/0xf0 [7.843255] [] pci_iommu_init+0x9/0x20 [7.843370] [] kernel_init+0x157/0x330 [7.843485] [] child_rip+0xa/0x12 [7.843601] [] acpi_ds_init_one_object+0x0/0x7c [7.843715] [] kernel_init+0x0/0x330 [7.843829] [] child_rip+0x0/0x12 [7.843941] [7.844056] PCI-GART: No AMD northbridge found. Does this backtrace looks sane ? Hmm, netlabel code mixes with acpi_ds_init_one_object() ... Strange. On Wed, 2007-05-16 at 12:15 -0700, Andrew Morton wrote: > On Wed, 16 May 2007 21:00:41 +0300 > Zilvinas Valinskas <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > In short, on shutdown my laptop is always freezing now. I was able to > > capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please > > see .config and log messages at http://barclay.balt.net/~zilvinas/oops/ > > > > Kernel version I had built according git is : > > > > [EMAIL PROTECTED]:/projects/linux-amd64.git$ git describe HEAD > > v2.6.22-rc1-29-gfaa8b6c > > > > On top of that I have CFS v12 applied (no other changes otherwise). > > Please note that there is ''fglrx.ko'' loaded and kernel is tainted > > because of that (feel free to ignore the report ...). > > > > Anyway, 'sysrq-P' always show that PC is stuck at (NFS lockd?) and it is > > always the same backtrace is shown. 'sysrq-t' output is in > > 'kernel-nfs-freeze.log' file (did not want to post it here). > > > > Pid: 3652, comm: lockd Tainted: P 2.6.22-rc1-cfs-v12 #1 > > > > [] wq_barrier_func+0x0/0x10 > > [] destroy_workqueue+0x75/0xa0 > > [] :sunrpc:rpciod_down+0xf4/0x170 > > [] :lockd:lockd+0x244/0x300 > > [] schedule_tail+0x3f/0xb0 > > [] child_rip+0xa/0x12 > > [] :lockd:lockd+0x0/0x300 > > [] :lockd:lockd+0x0/0x300 > > [] child_rip+0x0/0x12 > > > > Hope this helps. Thanks in advance for any advice how to solve problem ! > > For now I am back to '2.6.21.1-cfs-v10'. > > > > Thanks for the report. I'm thinking "Oleg". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LOCKDEP warning if CONFIG_DETECT_SOFTLOCKUP=y
Hello lkml,
Booting ixp4xx/ARM/BE with lockdep enabled to test my code, I got a
lockdep warning (see below). Does it mean that soft-lockup detector is
started too early ? Any advice how to approach and fix the problem are
appreciated very much. If CONFIG_DETECT_SOFTLOCKUP=n, lockdep does not
complain.
Kernel is vanilla 2.6.21-rc4 + lockdep-stacktrace.diff from
http://svn.wantstofly.org/kernel/ repository.
[0.00] Linux version 2.6.21-rc4 ([EMAIL PROTECTED]) (gcc version 4.2.0
20070207 (prerelease) (http://www.wilibox.com)) #12 Fri Mar 16 16:05:39 EET 2007
[0.00] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE),
cr=39ff
[0.00] Machine: Intel IXDP425 Development Platform
[0.00] Memory policy: ECC disabled, Data cache writeback
...
[0.00] Built 1 zonelists. Total pages: 16256
[0.00] Kernel command line: initcall_debug loglevel=8 i2c_debug=9
root=/dev/mtdblock2 console=ttyS0,115200 ro init=/linuxrc
[0.00] PID hash table entries: 256 (order: 8, 1024 bytes)
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc.,
Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES:8
[0.00] ... MAX_LOCK_DEPTH: 30
[0.00] ... MAX_LOCKDEP_KEYS:2048
[0.00] ... CLASSHASH_SIZE: 1024
[0.00] ... MAX_LOCKDEP_ENTRIES: 8192
[0.00] ... MAX_LOCKDEP_CHAINS: 16384
[0.00] ... CHAINHASH_SIZE: 8192
[0.00] memory used by lock dependency info: 1096 kB
[0.00] per task-struct memory footprint: 1200 bytes
[0.00]
[0.00] | Locking API testsuite:
... ...
[0.59] ---
[0.59] Good, all 218 testcases passed! |
[0.59] -
[0.59] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.60] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104)
[0.84] Mount-cache hash table entries: 512
[0.84] CPU: Testing write buffer coherency: ok
[0.84] INFO: trying to register non-static key.
[0.84] the code is fine but needs lockdep annotation.
[0.84] turning off the locking correctness validator.
Don't know how to fix that.
[0.84] [] (dump_stack+0x0/0x14) from []
(__lock_acquire+0x640/0x1110)
[0.84] [] (__lock_acquire+0x0/0x1110) from []
(lock_acquire+0x84/0x98)
[0.84] [] (lock_acquire+0x0/0x98) from []
(_spin_lock_irqsave+0x48/0x5c)
[0.84] [] (_spin_lock_irqsave+0x0/0x5c) from []
(sched_setscheduler+0xd4/0x2a8)
[0.84] r6 = C04D6000 r5 = C04D1820 r4 = 0001
[0.84] [] (sched_setscheduler+0x0/0x2a8) from []
(watchdog+0x30/0x6c)
[0.84] [] (watchdog+0x0/0x6c) from []
(kthread+0x108/0x118)
[0.84] r4 =
[0.84] [] (kthread+0x0/0x118) from []
(do_exit+0x0/0x894)
[0.84] r7 = r6 = r5 = r4 =
[0.84] Calling initcall 0xc0009980: ptrace_break_init+0x0/0x2c()
With gdb it points to *__task_rq_lock(struct task_struct *p)
(gdb) l *sched_setscheduler+0xd4
0x1644 is in sched_setscheduler (kernel/sched.c:395).
390 {
391 struct rq *rq;
392
393 repeat_lock_task:
394 rq = task_rq(p);
395 spin_lock(&rq->lock);
396 if (unlikely(rq != task_rq(p))) {
397 spin_unlock(&rq->lock);
398 goto repeat_lock_task;
399 }
(gdb)
I think it is really about ->pi_lock, on line 4134, that lockdep doesn't know
anything about.
4130 /*
4131 * make sure no PI-waiters arrive (or leave) while we are
4132 * changing the priority of the task:
4133 */
4134 spin_lock_irqsave(&p->pi_lock, flags);
4135 /*
4136 * To be able to change p->policy safely, the apropriate
4137 * runqueue lock must be held.
4138 */
4139 rq = __task_rq_lock(p);
Best regards,
Žilvinas Valinskas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LOCKDEP warning if CONFIG_DETECT_SOFTLOCKUP=y
Hello Ingo,
I think I've found a solution for a problem. Is this sane thing to do ?
At least lockdep is happy now, does not complain anymore. It seems that
->pi_lock was not register with lockdep correctly (something about
classes ... 8).
diff --git a/kernel/fork.c b/kernel/fork.c
index d154cc7..6af959c 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -933,8 +933,8 @@ asmlinkage long sys_set_tid_address(int __user *tidptr)
static inline void rt_mutex_init_task(struct task_struct *p)
{
-#ifdef CONFIG_RT_MUTEXES
spin_lock_init(&p->pi_lock);
+#ifdef CONFIG_RT_MUTEXES
plist_head_init(&p->pi_waiters, &p->pi_lock);
p->pi_blocked_on = NULL;
#endif
On Fri, 2007-03-16 at 16:55 +0200, Zilvinas Valinskas wrote:
> Hello lkml,
>
> Booting ixp4xx/ARM/BE with lockdep enabled to test my code, I got a
> lockdep warning (see below). Does it mean that soft-lockup detector is
> started too early ? Any advice how to approach and fix the problem are
> appreciated very much. If CONFIG_DETECT_SOFTLOCKUP=n, lockdep does not
> complain.
>
> Kernel is vanilla 2.6.21-rc4 + lockdep-stacktrace.diff from
> http://svn.wantstofly.org/kernel/ repository.
>
>
> [0.00] Linux version 2.6.21-rc4 ([EMAIL PROTECTED]) (gcc version
> 4.2.0 20070207 (prerelease) (http://www.wilibox.com)) #12 Fri Mar 16 16:05:39
> EET 2007
> [0.00] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE),
> cr=39ff
> [0.00] Machine: Intel IXDP425 Development Platform
> [0.00] Memory policy: ECC disabled, Data cache writeback
> ...
>
> [0.00] Built 1 zonelists. Total pages: 16256
> [0.00] Kernel command line: initcall_debug loglevel=8 i2c_debug=9
> root=/dev/mtdblock2 console=ttyS0,115200 ro init=/linuxrc
> [0.00] PID hash table entries: 256 (order: 8, 1024 bytes)
> [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc.,
> Ingo Molnar
> [0.00] ... MAX_LOCKDEP_SUBCLASSES:8
> [0.00] ... MAX_LOCK_DEPTH: 30
> [0.00] ... MAX_LOCKDEP_KEYS:2048
> [0.00] ... CLASSHASH_SIZE: 1024
> [0.00] ... MAX_LOCKDEP_ENTRIES: 8192
> [0.00] ... MAX_LOCKDEP_CHAINS: 16384
> [0.00] ... CHAINHASH_SIZE: 8192
> [0.00] memory used by lock dependency info: 1096 kB
> [0.00] per task-struct memory footprint: 1200 bytes
> [0.00]
> [0.00] | Locking API testsuite:
>
> ... ...
>
> [0.59] ---
> [0.59] Good, all 218 testcases passed! |
> [0.59] -
> [0.59] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> [0.60] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104)
> [0.84] Mount-cache hash table entries: 512
> [0.84] CPU: Testing write buffer coherency: ok
> [0.84] INFO: trying to register non-static key.
> [0.84] the code is fine but needs lockdep annotation.
> [0.84] turning off the locking correctness validator.
>
> Don't know how to fix that.
>
> [0.84] [] (dump_stack+0x0/0x14) from []
> (__lock_acquire+0x640/0x1110)
> [0.84] [] (__lock_acquire+0x0/0x1110) from []
> (lock_acquire+0x84/0x98)
> [0.84] [] (lock_acquire+0x0/0x98) from []
> (_spin_lock_irqsave+0x48/0x5c)
> [0.84] [] (_spin_lock_irqsave+0x0/0x5c) from []
> (sched_setscheduler+0xd4/0x2a8)
> [0.84] r6 = C04D6000 r5 = C04D1820 r4 = 0001
> [0.84] [] (sched_setscheduler+0x0/0x2a8) from []
> (watchdog+0x30/0x6c)
> [0.84] [] (watchdog+0x0/0x6c) from []
> (kthread+0x108/0x118)
> [0.84] r4 =
> [0.84] [] (kthread+0x0/0x118) from []
> (do_exit+0x0/0x894)
> [0.84] r7 = r6 = r5 = r4 =
> [0.84] Calling initcall 0xc0009980: ptrace_break_init+0x0/0x2c()
>
> With gdb it points to *__task_rq_lock(struct task_struct *p)
>
> (gdb) l *sched_setscheduler+0xd4
> 0x1644 is in sched_setscheduler (kernel/sched.c:395).
> 390 {
> 391 struct rq *rq;
> 392
> 393 repeat_lock_task:
> 394 rq = task_rq(p);
> 395 spin_lock(&rq->lock);
> 396 if (unlikely(rq != task_rq(p))) {
> 397 spin_unlock(&rq->lock);
> 398 goto repeat_lock_task;
> 399 }
> (gdb)
>
> I think it is really about ->pi_lock, on line 4134, that lockdep doesn't know
> anything about.
>
> 4130 /*
> 4131 * make sure no
Kernel Oops in pl2303_shutdown()
Hello,
Before 2.6.21-rc4 (vanilla) serial was oopsing if I pull usb-serial
cable while minicom was running. Now it doesn't matter if minicom is
running or minicom closed, pulling serial cable results in such oops.
(gdb) l *pl2303_shutdown+0x45
0x1f95 is in pl2303_shutdown (include/linux/device.h:471).
466 #endif
467
468 static inline void *
469 dev_get_drvdata (struct device *dev)
470 {
471 return dev->driver_data;
472 }
473
474 static inline void
475 dev_set_drvdata (struct device *dev, void *data)
In drivers/usb/serial/pl2303.c file:
907 for (i = 0; i < serial->num_ports; ++i) {
908 priv = usb_get_serial_port_data(serial->port[i]);
909 if (priv) {
910 pl2303_buf_free(priv->buf);
911 kfree(priv);
912 usb_set_serial_port_data(serial->port[i], NULL);
913 }
It seems on line 908 'serial->port' is NULL here already ? Something has changed
in drivers/usb/serial/.
ps.
Kernel is tainted because of fglrx.ko kernel module.
Mar 18 23:55:21 zv kernel: [21529.080060] usb 3-1: USB disconnect, address 2
Mar 18 23:55:21 zv kernel: [21529.080064] usb 3-1: unregistering device
Mar 18 23:55:21 zv kernel: [21529.080068] usb 3-1: usb_disable_device nuking
all URBs
Mar 18 23:55:21 zv kernel: [21529.080079] usb 3-1: unregistering interface
3-1:1.0
Mar 18 23:55:21 zv kernel: [21529.080141] usbdev3.2_ep81: ep_device_release
called for usbdev3.2_ep81
Mar 18 23:55:21 zv kernel: [21529.080177] usbdev3.2_ep02: ep_device_release
called for usbdev3.2_ep02
Mar 18 23:55:21 zv kernel: [21529.080210] usbdev3.2_ep83: ep_device_release
called for usbdev3.2_ep83
Mar 18 23:55:21 zv kernel: [21529.080284] pl2303 ttyUSB0: pl2303 converter now
disconnected from ttyUSB0
Mar 18 23:55:21 zv kernel: [21529.080330] BUG: using smp_processor_id() in
preemptible [0001] code: khubd/224
Mar 18 23:55:21 zv kernel: [21529.080339] caller is oops_begin+0xb/0x80
Mar 18 23:55:21 zv kernel: [21529.080343]
Mar 18 23:55:21 zv kernel: [21529.080344] Call Trace:
Mar 18 23:55:21 zv kernel: [21529.080358] []
debug_smp_processor_id+0xae/0xc0
Mar 18 23:55:21 zv kernel: [21529.080365] []
oops_begin+0xb/0x80
Mar 18 23:55:21 zv kernel: [21529.080373] []
do_page_fault+0x6b4/0x860
Mar 18 23:55:21 zv kernel: [21529.080381] []
sprintf+0x51/0x60
Mar 18 23:55:21 zv kernel: [21529.080392] []
__wake_up+0x43/0x70
Mar 18 23:55:21 zv kernel: [21529.080402] []
_spin_unlock_irqrestore+0x16/0x40
Mar 18 23:55:21 zv kernel: [21529.080411] []
netlink_broadcast+0x2ee/0x350
Mar 18 23:55:21 zv kernel: [21529.080423] []
simple_unlink+0x61/0x80
Mar 18 23:55:21 zv kernel: [21529.080433] []
error_exit+0x0/0x84
Mar 18 23:55:21 zv kernel: [21529.080450] []
:usbserial:port_release+0x0/0x40
Mar 18 23:55:21 zv kernel: [21529.080461] []
kobject_release+0x0/0x10
Mar 18 23:55:21 zv kernel: [21529.080473] []
:pl2303:pl2303_shutdown+0x45/0x90
Mar 18 23:55:21 zv kernel: [21529.080489] []
:usbserial:destroy_serial+0xb7/0x170
Mar 18 23:55:21 zv kernel: [21529.080501] []
:usbserial:destroy_serial+0x0/0x170
Mar 18 23:55:21 zv kernel: [21529.080508] []
kref_put+0x65/0x80
Mar 18 23:55:21 zv kernel: [21529.080521] []
:usbserial:usb_serial_disconnect+0x98/0xd0
Mar 18 23:55:21 zv kernel: [21529.080534] []
usb_unbind_interface+0x6d/0xd0
Mar 18 23:55:21 zv kernel: [21529.080544] []
__device_release_driver+0x91/0xc0
Mar 18 23:55:21 zv kernel: [21529.080552] []
device_release_driver+0x33/0x60
Mar 18 23:55:21 zv kernel: [21529.080561] []
bus_remove_device+0x6e/0x90
Mar 18 23:55:21 zv kernel: [21529.080569] []
device_del+0x163/0x1e0
Mar 18 23:55:21 zv kernel: [21529.080578] []
usb_disable_device+0xef/0x1c0
Mar 18 23:55:21 zv kernel: [21529.080588] []
usb_disconnect+0xe6/0x180
Mar 18 23:55:21 zv kernel: [21529.080598] []
hub_thread+0x629/0x1030
Mar 18 23:55:21 zv kernel: [21529.080606] []
task_rq_lock+0x4c/0x90
Mar 18 23:55:21 zv kernel: [21529.080613] []
__switch_to+0x42/0x2b0
Mar 18 23:55:21 zv kernel: [21529.080642] []
_spin_unlock_irq+0x15/0x40
Mar 18 23:55:21 zv kernel: [21529.080658] []
autoremove_wake_function+0x0/0x30
Mar 18 23:55:21 zv kernel: [21529.080670] []
hub_thread+0x0/0x1030
Mar 18 23:55:21 zv kernel: [21529.080676] []
keventd_create_kthread+0x0/0x90
Mar 18 23:55:21 zv kernel: [21529.080683] []
kthread+0xd9/0x120
Mar 18 23:55:21 zv kernel: [21529.080690] []
__call_usermodehelper+0x0/0x80
Mar 18 23:55:21 zv kernel: [21529.080696] []
schedule_tail+0x3f/0xb0
Mar 18 23:55:21 zv kernel: [21529.080705] []
child_rip+0xa/0x12
Mar 18 23:55:21 zv kernel: [21529.080713] []
keventd_create_kthread+0x0/0x90
Mar 18 23:55:21 zv kernel: [21529.080727] []
kthread+0x0/0x120
Mar 18 23:55:21 zv kernel: [21529.080733] []
child_rip+0x0/0x12
Mar 18 23:55:21 zv kernel: [21529.080739]
Mar 18 23:55:21 zv kernel: [21529.080743] Unable to handle kernel NULL pointer
de
Re: Kernel Oops in pl2303_shutdown()
Hello Adrian, reverting d9a7ecacac5f8274d2afce09aadcf37bdb42b93a does help. thanks ! On Mon, 2007-03-19 at 17:34 +0100, Adrian Bunk wrote: > On Mon, Mar 19, 2007 at 05:27:58PM +0200, Zilvinas Valinskas wrote: > > Hello, > > > > Before 2.6.21-rc4 (vanilla) serial was oopsing if I pull usb-serial > > cable while minicom was running. Now it doesn't matter if minicom is > > running or minicom closed, pulling serial cable results in such oops. > >... > > Does the patch from [1] fix it? > > cu > Adrian > > [1] http://lkml.org/lkml/2007/3/13/217 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Oops in ext3 (kernel tainted, fglrx
Hello lkml, A moment ago I've got this beauty below. Kernel is tainted due to fglrx.ko feel free to ignore. ATI drivers 8.40.4 and for some reason iwl3945(F). What does it mean (F) - forced insmod ? :\ iwl3945 driver is from git repository. I am running 2.6.23-rc3, 2GB of RAM, dual Core, HP nx9420 laptop. What does it mean 'PGD 73414067 PUD 0' ? Page table directory corrupted ? Aug 21 12:44:00 zv kernel: PGD 73414067 PUD 0 Aug 21 12:44:00 zv kernel: CPU 1 Aug 21 12:44:00 zv kernel: Modules linked in: nfs cpufreq_ondemand fglrx(P) rfcomm l2cap nfsd exportfs lockd nfs_acl auth_rpcgss sunrpc ppdev lp autofs4 ipv6 deflate zlib_deflate twofish twofish_common camellia serpent blowfish des cbc aes xcbc sha256 sha1 crypto_null af_key dm_crypt dm_snapshot dm_mirror dm_mod firewire_sbp2 loop coretemp cpufreq_conservative cpufreq_stats acpi_cpufreq freq_table arc4 ecb blkcipher pcmcia joydev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm pl2303 snd_timer iwl3945(F) snd sdhci firmware_class yenta_socket soundcore mac80211 rsrc_nonstatic tifm_7xx1 hci_usb parport_pc mmc_core usbserial tifm_core psmouse bluetooth cfg80211 pcspkr snd_page_alloc parport pcmcia_core iTCO_wdt intel_agp serio_raw video output battery container ac button tsdev evdev ext3 jbd mbcache sg sr_mod cdrom generic piix ide_core usbhid hid sd_mod ata_piix firewire_ohci ata_generic ahci firewire_core libata scsi_mod crc_itu_t tg3 ehci_hcd uhci_hcd thermal processor fan Aug 21 12:44:00 zv kernel: Pid: 5475, comm: evolution Tainted: PF 2.6.23-rc3 #1 Aug 21 12:44:00 zv kernel: RIP: 0010:[] [] :ext3:ext3_try_to_allocate_with_rsv+0x3df/0x4e3 Aug 21 12:44:00 zv kernel: RSP: 0018:810034fe9758 EFLAGS: 00010286 Aug 21 12:44:00 zv kernel: RAX: RBX: RCX: Aug 21 12:44:00 zv kernel: RDX: 810034fe9878 RSI: 8815de90 RDI: 81006ce87380 Aug 21 12:44:00 zv kernel: RBP: 81004c26cbc0 R08: 810034fe97b8 R09: 0011 Aug 21 12:44:00 zv kernel: R10: 81006ce87000 R11: 81006cd60268 R12: 0007 Aug 21 12:44:00 zv kernel: R13: 81007b413cc0 R14: 81007cd45000 R15: 81004c26cbc0 Aug 21 12:44:00 zv kernel: FS: 41802950(0063) GS:8100011c8c40() knlGS: Aug 21 12:44:00 zv kernel: CS: 0010 DS: ES: CR0: 8005003b Aug 21 12:44:00 zv kernel: CR2: CR3: 7c13 CR4: 06e0 Aug 21 12:44:00 zv kernel: DR0: DR1: DR2: Aug 21 12:44:00 zv kernel: DR3: DR6: 0ff0 DR7: 0400 Aug 21 12:44:00 zv kernel: Process evolution (pid: 5475, threadinfo 810034fe8000, task 810037e65040) Aug 21 12:44:00 zv kernel: Stack: 81004c26cbe0 1bef7c7f4cc0 81006cd60268 0066802a2954 Aug 21 12:44:00 zv kernel: 81001d9273d8 0033 00337fff 0066 Aug 21 12:44:00 zv kernel: 81004c26cbe0 0066 81004c26cbc0 802a3ece Aug 21 12:44:00 zv kernel: Call Trace: Aug 21 12:44:00 zv kernel: [] __bread+0x6/0x76 Aug 21 12:44:00 zv kernel: [] :ext3:ext3_new_blocks+0x1ee/0x65e Aug 21 12:44:00 zv kernel: [] :ext3:ext3_get_blocks_handle+0x405/0x8e4 Aug 21 12:44:00 zv kernel: [] :jbd:do_get_write_access+0x47b/0x4ad Aug 21 12:44:00 zv kernel: [] :jbd:__journal_file_buffer+0x125/0x21c Aug 21 12:44:00 zv kernel: [] :ext3:ext3_get_block+0xc2/0xe4 Aug 21 12:44:00 zv kernel: [] __block_prepare_write+0x18a/0x441 Aug 21 12:44:00 zv kernel: [] :ext3:ext3_get_block+0x0/0xe4 Aug 21 12:44:00 zv kernel: [] block_prepare_write+0x1a/0x25 Aug 21 12:44:00 zv kernel: [] :ext3:ext3_prepare_write+0xb2/0x17b Aug 21 12:44:00 zv kernel: [] generic_file_buffered_write+0x288/0x61a Aug 21 12:44:00 zv kernel: [] current_fs_time+0x1e/0x24 Aug 21 12:44:00 zv kernel: [] sock_common_recvmsg+0x30/0x45 Aug 21 12:44:00 zv kernel: [] __generic_file_aio_write_nolock+0x33f/0x3a9 Aug 21 12:44:00 zv kernel: [] autoremove_wake_function+0x0/0x2e Aug 21 12:44:00 zv kernel: [] generic_file_aio_write+0x61/0xc1 Aug 21 12:44:00 zv kernel: [] :ext3:ext3_file_write+0x16/0x94 Aug 21 12:44:00 zv kernel: [] do_sync_write+0xc9/0x10c Aug 21 12:44:00 zv kernel: [] autoremove_wake_function+0x0/0x2e Aug 21 12:44:00 zv kernel: [] vfs_write+0xce/0x157 Aug 21 12:44:00 zv kernel: [] sys_write+0x45/0x6e Aug 21 12:44:00 zv kernel: [] system_call+0x7e/0x83 Aug 21 12:44:00 zv kernel: Aug 21 12:44:00 zv kernel: Aug 21 12:44:00 zv kernel: Code: 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Aug 21 12:44:00 zv kernel: RSP Aug 21 12:46:06 zv kernel: SysRq : Emergency Sync Aug 21 12:46:07 zv kernel: Emergency Sync complete Aug 21 12:46:07 zv kernel: SysRq : Emergency Sync Aug 21 12:46:07 zv kernel: Emergency Sync complete Aug 21 12:46:08 zv kernel: SysRq : Emergency Remount R/O - To unsubscribe from this list: send the line "unsubscribe linux-
Re: Pausing kernel boot messages
Esteban, Alternatively, read Documentation/networking/netconsole.txt. Might help or might not. It depends when system is crashing. On Mon, 2007-08-27 at 13:53 +0200, Hans-Jürgen Koch wrote: > Am Montag 27 August 2007 13:21 schrieb Esteban Fernandez: > > How do you pause the kernel boot messages ? > > > > ^S, Pause and Scroll lock do nothing and you can't Shift-Page-Up after a > > kernel panic. > > These are functions of a shell (like bash), which you haven't got yet during > kernel boot. You can read the kernel boot messages _after_ your system's up > using dmesg etc. > If you can't do that, e.g. because your kernel always hangs during boot, you > could enable a serial console in your kernel and watch/log your kernel > messages with a terminal program running on a different computer. > > Hans > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
