Re: 2.6.13-rc6-mm2 - breaks USB unplug
Hi,
-rc6-mm2 breaks USB unplug for me. Happens with every USB device,
gcc-3.3.5 and gcc-3.4.4 as well as preempt and non-preempt and is 100%
reproducible.
-rc6-mm1 seems fine.
Reverting the following part of
driver-core-fix-bus_rescan_devices-race.patch
fixes this for me:
diff -puN drivers/base/dd.c~driver-core-fix-bus_rescan_devices-race
drivers/base/dd.c
--- devel/drivers/base/dd.c~driver-core-fix-bus_rescan_devices-race
2005-08-22 17:44:11.0 -0700
+++ devel-akpm/drivers/base/dd.c2005-08-22 17:44:11.0 -0700
@@ -127,10 +127,9 @@ int device_attach(struct device * dev)
int ret = 0;
down(>sem);
- if (dev->driver) {
- device_bind_driver(dev);
+ if (dev->driver)
ret = 1;
- } else
+ else
ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
up(>sem);
return ret;
dmesg and OOPS below (-laptop is just CONFIG_LOCALVERSION):
Linux version 2.6.13-rc6-mm2-laptop ([EMAIL PROTECTED]) (gcc-Version 3.4.4
(Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Wed Aug 31 12:05:38
CEST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009f800 (usable)
BIOS-e820: 0009f800 - 000a (reserved)
BIOS-e820: 000dc000 - 0010 (reserved)
BIOS-e820: 0010 - 2fee (usable)
BIOS-e820: 2fee - 2feec000 (ACPI data)
BIOS-e820: 2feec000 - 2ff0 (ACPI NVS)
BIOS-e820: 2ff0 - 3000 (reserved)
BIOS-e820: fec1 - fec2 (reserved)
BIOS-e820: ff80 - ffc0 (reserved)
BIOS-e820: fc00 - 0001 (reserved)
766MB LOWMEM available.
On node 0, present: 196320, spanned: 196320
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 192224 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:1
DMI present.
ACPI: RSDP (v000 ACER ) @ 0x000f62c0
ACPI: RSDT (v001 ACER Kestrel 0x20021012 LTP 0x) @ 0x2fee6205
ACPI: FADT (v001 ACER Kestrel 0x20021012 PTL 0x0050) @ 0x2feebf2c
ACPI: HPET (v001 ACER Kestrel 0x20021012 PTL 0x) @ 0x2feebfa0
ACPI: BOOT (v001 ACER Kestrel 0x20021012 LTP 0x0001) @ 0x2feebfd8
ACPI: DSDT (v001 ACER Kestrel 0x20021012 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: HPET id: 0x8086a201 base: 0x0
Allocating PCI resources starting at 3000 (gap: 3000:cec1)
Built 1 zonelists
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to d000 (fee0)
Initializing CPU#0
Kernel command line: BOOT_IMAGE=Test-Kernel ro root=306 lapic ec_polling
usb-handoff init 2
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1599.324 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 774328k/785280k available (1963k kernel code, 10488k reserved, 741k
data, 460k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3198.86 BogoMIPS (lpj=1599431)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbbf 0180
CPU: After vendor identify, caps: afe9fbbf 0180
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbbf 0040 0180
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0440)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd782, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20050729
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
Boot video device is :01:00.0
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *6)
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
ACPI: PCI Interrupt Link [LNKC] (IRQs *6)
ACPI: PCI Interrupt Link [LNKD] (IRQs *6)
ACPI: PCI Interrupt Link [LNKE] (IRQs *10)
ACPI: PCI Interrupt Link [LNKF] (IRQs 10) *0, disabled.
ACPI: PCI
Re: 2.6.13-rc6-mm2 - breaks USB unplug
Hi,
-rc6-mm2 breaks USB unplug for me. Happens with every USB device,
gcc-3.3.5 and gcc-3.4.4 as well as preempt and non-preempt and is 100%
reproducible.
-rc6-mm1 seems fine.
Reverting the following part of
driver-core-fix-bus_rescan_devices-race.patch
fixes this for me:
diff -puN drivers/base/dd.c~driver-core-fix-bus_rescan_devices-race
drivers/base/dd.c
--- devel/drivers/base/dd.c~driver-core-fix-bus_rescan_devices-race
2005-08-22 17:44:11.0 -0700
+++ devel-akpm/drivers/base/dd.c2005-08-22 17:44:11.0 -0700
@@ -127,10 +127,9 @@ int device_attach(struct device * dev)
int ret = 0;
down(dev-sem);
- if (dev-driver) {
- device_bind_driver(dev);
+ if (dev-driver)
ret = 1;
- } else
+ else
ret = bus_for_each_drv(dev-bus, NULL, dev, __device_attach);
up(dev-sem);
return ret;
dmesg and OOPS below (-laptop is just CONFIG_LOCALVERSION):
Linux version 2.6.13-rc6-mm2-laptop ([EMAIL PROTECTED]) (gcc-Version 3.4.4
(Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Wed Aug 31 12:05:38
CEST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009f800 (usable)
BIOS-e820: 0009f800 - 000a (reserved)
BIOS-e820: 000dc000 - 0010 (reserved)
BIOS-e820: 0010 - 2fee (usable)
BIOS-e820: 2fee - 2feec000 (ACPI data)
BIOS-e820: 2feec000 - 2ff0 (ACPI NVS)
BIOS-e820: 2ff0 - 3000 (reserved)
BIOS-e820: fec1 - fec2 (reserved)
BIOS-e820: ff80 - ffc0 (reserved)
BIOS-e820: fc00 - 0001 (reserved)
766MB LOWMEM available.
On node 0, present: 196320, spanned: 196320
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 192224 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:1
DMI present.
ACPI: RSDP (v000 ACER ) @ 0x000f62c0
ACPI: RSDT (v001 ACER Kestrel 0x20021012 LTP 0x) @ 0x2fee6205
ACPI: FADT (v001 ACER Kestrel 0x20021012 PTL 0x0050) @ 0x2feebf2c
ACPI: HPET (v001 ACER Kestrel 0x20021012 PTL 0x) @ 0x2feebfa0
ACPI: BOOT (v001 ACER Kestrel 0x20021012 LTP 0x0001) @ 0x2feebfd8
ACPI: DSDT (v001 ACER Kestrel 0x20021012 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: HPET id: 0x8086a201 base: 0x0
Allocating PCI resources starting at 3000 (gap: 3000:cec1)
Built 1 zonelists
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to d000 (fee0)
Initializing CPU#0
Kernel command line: BOOT_IMAGE=Test-Kernel ro root=306 lapic ec_polling
usb-handoff init 2
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1599.324 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 774328k/785280k available (1963k kernel code, 10488k reserved, 741k
data, 460k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3198.86 BogoMIPS (lpj=1599431)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbbf 0180
CPU: After vendor identify, caps: afe9fbbf 0180
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbbf 0040 0180
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0440)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd782, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20050729
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
Boot video device is :01:00.0
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *6)
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
ACPI: PCI Interrupt Link [LNKC] (IRQs *6)
ACPI: PCI Interrupt Link [LNKD] (IRQs *6)
ACPI: PCI Interrupt Link [LNKE] (IRQs *10)
ACPI: PCI Interrupt Link [LNKF] (IRQs 10) *0, disabled.
ACPI:
Re: 2.6.13-rc6-mm1 - OOPS in drivers/net/phy
Hi, the changes to drivers/net/phy in git-netdev-all.patch have some issues: 1) phy.c (libphy.ko) lacks MODULE_LICENCE(GPL), but uses GPL-only exports 2) after fixing this (or when compiling statically) it causes the following OOPS (new in rc6-mm1): Badness in kref_get at lib/kref.c:32 [] dump_stack+0x17/0x20 [] kref_get+0x46/0x50 [] kobject_get+0x12/0x20 [] get_bus+0x16/0x30 [] bus_add_driver+0x19/0xc0 [] driver_register+0x2a/0x40 [] phy_driver_register+0x49/0x90 [libphy] [] phy_init+0xe/0x40 [libphy] [] sys_init_module+0x149/0x1f0 [] sysenter_past_esp+0x54/0x75 --- | preempt count: ] --- Badness in kref_get at lib/kref.c:32 [] dump_stack+0x17/0x20 [] kref_get+0x46/0x50 [] kobject_get+0x12/0x20 [] kobject_init+0x28/0x40 [] kobject_register+0x1c/0x70 [] bus_add_driver+0x54/0xc0 [] driver_register+0x2a/0x40 [] phy_driver_register+0x49/0x90 [libphy] [] phy_init+0xe/0x40 [libphy] [] sys_init_module+0x149/0x1f0 [] sysenter_past_esp+0x54/0x75 --- | preempt count: ] --- Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01c3894 *pde = Oops: 0002 [#1] PREEMPT last sysfs file: /class/vc/vcs3/dev Modules linked in: libphy snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc ntfs vfat fat reiser4 zlib_deflate zlib_inflate usb_storage loop acpi_cpufreq yealink usbhid joydev acpi_sbs i2c_acpi_ec bcm4400 ehci_hcd uhci_hcd usbcore intel_agp agpgart psmouse CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010292 (2.6.13-rc6-mm1-laptop) EIP is at kobject_add+0x94/0xd0 eax: f18d4140 ebx: f18d406c ecx: edx: f18d4088 esi: ffea edi: f18d4148 ebp: ed089f14 esp: ed089f08 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 8250, threadinfo=ed088000 task=efd7c690) Stack: f18d406c ffea f18d40e0 ed089f30 c01c38f3 ed089f44 f18d4058 f18d4058 f18d406c ed089f54 c02363c4 f18d406c c0315706 f18d338f f18d4058 0805b198 f18d40dc ed089f70 c0236d1a 0011 000b Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x158/0x1c0 [] die+0xf5/0x180 [] do_page_fault+0x2a4/0x59d [] error_code+0x4f/0x54 [] kobject_register+0x23/0x70 [] bus_add_driver+0x54/0xc0 [] driver_register+0x2a/0x40 [] phy_driver_register+0x49/0x90 [libphy] [] phy_init+0xe/0x40 [libphy] [] sys_init_module+0x149/0x1f0 [] sysenter_past_esp+0x54/0x75 --- | preempt count: 0002 ] | 2 level deep critical section nesting: .. [] kobject_add+0x7e/0xd0 .[] .. ( <= kobject_register+0x23/0x70) .. [] die+0x38/0x180 .[] .. ( <= do_page_fault+0x2a4/0x59d) Code: 74 e2 89 f8 e8 ce 02 00 00 eb d9 b8 01 00 00 00 e8 12 4d 00 00 85 ff 74 36 8b 43 28 8d 53 1c 83 c0 08 89 43 1c 8b 48 04 89 50 04 <89> 11 89 4a 04 b8 01 00 00 00 e8 4d 4d 00 00 b8 00 e0 ff ff 21 <3>BUG: modprobe[8250] exited with nonzero preempt_count 1! --- | preempt count: 0001 ] | 1 level deep critical section nesting: .. [] kobject_add+0x7e/0xd0 .[] .. ( <= kobject_register+0x23/0x70) - 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: 2.6.13-rc6-mm1 - OOPS in drivers/net/phy
Hi, the changes to drivers/net/phy in git-netdev-all.patch have some issues: 1) phy.c (libphy.ko) lacks MODULE_LICENCE(GPL), but uses GPL-only exports 2) after fixing this (or when compiling statically) it causes the following OOPS (new in rc6-mm1): Badness in kref_get at lib/kref.c:32 [c0103b17] dump_stack+0x17/0x20 [c01c4456] kref_get+0x46/0x50 [c01c3a92] kobject_get+0x12/0x20 [c02364e6] get_bus+0x16/0x30 [c0236389] bus_add_driver+0x19/0xc0 [c0236d1a] driver_register+0x2a/0x40 [f18d3159] phy_driver_register+0x49/0x90 [libphy] [f080400e] phy_init+0xe/0x40 [libphy] [c0134fa9] sys_init_module+0x149/0x1f0 [c0102c6b] sysenter_past_esp+0x54/0x75 --- | preempt count: ] --- Badness in kref_get at lib/kref.c:32 [c0103b17] dump_stack+0x17/0x20 [c01c4456] kref_get+0x46/0x50 [c01c3a92] kobject_get+0x12/0x20 [c01c3788] kobject_init+0x28/0x40 [c01c38ec] kobject_register+0x1c/0x70 [c02363c4] bus_add_driver+0x54/0xc0 [c0236d1a] driver_register+0x2a/0x40 [f18d3159] phy_driver_register+0x49/0x90 [libphy] [f080400e] phy_init+0xe/0x40 [libphy] [c0134fa9] sys_init_module+0x149/0x1f0 [c0102c6b] sysenter_past_esp+0x54/0x75 --- | preempt count: ] --- Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01c3894 *pde = Oops: 0002 [#1] PREEMPT last sysfs file: /class/vc/vcs3/dev Modules linked in: libphy snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc ntfs vfat fat reiser4 zlib_deflate zlib_inflate usb_storage loop acpi_cpufreq yealink usbhid joydev acpi_sbs i2c_acpi_ec bcm4400 ehci_hcd uhci_hcd usbcore intel_agp agpgart psmouse CPU:0 EIP:0060:[c01c3894]Not tainted VLI EFLAGS: 00010292 (2.6.13-rc6-mm1-laptop) EIP is at kobject_add+0x94/0xd0 eax: f18d4140 ebx: f18d406c ecx: edx: f18d4088 esi: ffea edi: f18d4148 ebp: ed089f14 esp: ed089f08 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 8250, threadinfo=ed088000 task=efd7c690) Stack: f18d406c ffea f18d40e0 ed089f30 c01c38f3 ed089f44 f18d4058 f18d4058 f18d406c ed089f54 c02363c4 f18d406c c0315706 f18d338f f18d4058 0805b198 f18d40dc ed089f70 c0236d1a 0011 000b Call Trace: [c0103aea] show_stack+0x7a/0x90 [c0103c78] show_registers+0x158/0x1c0 [c0103e85] die+0xf5/0x180 [c02ee4c4] do_page_fault+0x2a4/0x59d [c0103777] error_code+0x4f/0x54 [c01c38f3] kobject_register+0x23/0x70 [c02363c4] bus_add_driver+0x54/0xc0 [c0236d1a] driver_register+0x2a/0x40 [f18d3159] phy_driver_register+0x49/0x90 [libphy] [f080400e] phy_init+0xe/0x40 [libphy] [c0134fa9] sys_init_module+0x149/0x1f0 [c0102c6b] sysenter_past_esp+0x54/0x75 --- | preempt count: 0002 ] | 2 level deep critical section nesting: .. [c01c387e] kobject_add+0x7e/0xd0 .[c01c38f3] .. ( = kobject_register+0x23/0x70) .. [c0103dc8] die+0x38/0x180 .[c02ee4c4] .. ( = do_page_fault+0x2a4/0x59d) Code: 74 e2 89 f8 e8 ce 02 00 00 eb d9 b8 01 00 00 00 e8 12 4d 00 00 85 ff 74 36 8b 43 28 8d 53 1c 83 c0 08 89 43 1c 8b 48 04 89 50 04 89 11 89 4a 04 b8 01 00 00 00 e8 4d 4d 00 00 b8 00 e0 ff ff 21 3BUG: modprobe[8250] exited with nonzero preempt_count 1! --- | preempt count: 0001 ] | 1 level deep critical section nesting: .. [c01c387e] kobject_add+0x7e/0xd0 .[c01c38f3] .. ( = kobject_register+0x23/0x70) - 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] Fix PPC signal handling of NODEFER, should not affect sa_mask
On Fri, 12 Aug 2005 14:59:49 -0400 (EDT) Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Fri, 12 Aug 2005, Chris Wright wrote: > > * Jan Engelhardt ([EMAIL PROTECTED]) wrote: > > > So, if in doubt what is really meant - check which of the two/three/+ > > > different behaviors the users out there favor most. > > > > Rather, check what happens in practice on other implementations. I don't > > have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must. > > > > I've supplied this before, but I'll send it again. Attached is a program > that should show the behavior of the sigaction. If someone has one of the > above mentioned boxes, please run this on the box and send back the > results. This is from NetBSD 2.0: sa_mask blocks other signals SA_NODEFER does not block other signals SA_NODEFER does not affect sa_mask SA_NODEFER and sa_mask does not block sig !SA_NODEFER blocks sig SA_NODEFER does not block sig sa_mask blocks sig This is from SFU 3.5 on WinXP (*): sa_mask blocks other signals SA_NODEFER does not block other signals SA_NODEFER does not affect sa_mask SA_NODEFER and sa_mask blocks sig !SA_NODEFER blocks sig SA_NODEFER blocks sig sa_mask blocks sig (*) original signal.h did not define SA_NODEFER, so take this with a grain of salt Marc - 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] Fix PPC signal handling of NODEFER, should not affect sa_mask
On Fri, 12 Aug 2005 14:59:49 -0400 (EDT) Steven Rostedt [EMAIL PROTECTED] wrote: On Fri, 12 Aug 2005, Chris Wright wrote: * Jan Engelhardt ([EMAIL PROTECTED]) wrote: So, if in doubt what is really meant - check which of the two/three/+ different behaviors the users out there favor most. Rather, check what happens in practice on other implementations. I don't have Solaris, HP-UX, Irix, AIX, etc. boxen at hand, but some folks must. I've supplied this before, but I'll send it again. Attached is a program that should show the behavior of the sigaction. If someone has one of the above mentioned boxes, please run this on the box and send back the results. This is from NetBSD 2.0: sa_mask blocks other signals SA_NODEFER does not block other signals SA_NODEFER does not affect sa_mask SA_NODEFER and sa_mask does not block sig !SA_NODEFER blocks sig SA_NODEFER does not block sig sa_mask blocks sig This is from SFU 3.5 on WinXP (*): sa_mask blocks other signals SA_NODEFER does not block other signals SA_NODEFER does not affect sa_mask SA_NODEFER and sa_mask blocks sig !SA_NODEFER blocks sig SA_NODEFER blocks sig sa_mask blocks sig (*) original signal.h did not define SA_NODEFER, so take this with a grain of salt Marc - 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: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, 5 Aug 2005 23:52:47 +0200 Martin Loschwitz <[EMAIL PROTECTED]> wrote: > > The situation in this case is somewhat obscene ... Originally, I had exactly > this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I > then went to compile 2.6.12.3, also with SMP, and it showed exactly the same > problem. I disable SMP, tried again -- voila, it worked. > > The kernel that I am encountering this error again now is 2.6.12.3 -- without > SMP or whatsoever. I'm just out of ideas on how to fix it this time. Did you always use the same machine? If so, can you rule out hardware issues? Can you reproduce this Oops at will? I can't reproduce this on various machines (all X86, kernels 2.6.11.9, 2.6.12.2, 2.6.13-rc4-mm1, no SMP) Regards - 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: preempt with selinux NULL pointer dereference
On Fri, 05 Aug 2005 17:46:13 +0100 Antoine Martin <[EMAIL PROTECTED]> wrote: > > > [ 4788.218995] Pid: 19002, comm: ssh Tainted: G M 2.6.13-rc5 > > > > Which of your modules is non-GPL and can you please remove them and see if > > there's still a problem? > Hmm. I occasionally use out-of-tree drivers (wlan cards mainly) so I > thought these could be the culprit, but all the above are in the source > tree (I keep the others out): >From Documentation/oops-tracing.txt: 'G' if all modules loaded have a GPL or compatible license, 'P' if any proprietary module has been loaded. ... In other words, your kernel is tainted, but all modules are GPL. See also the check in panic.c: ... tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G', ... It seems that yout kernel was tainted by a machine check exception (MCE). This should be visible in dmesg somewhere, and might indicate a hardware problem. Regards - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thu, 4 Aug 2005 23:07:33 -0500 Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > It requests BIOS to hand off control of USB which disables USB legacy > emulation > and all troubles associated with it. We could start with -mm... This also fixes an issue I encountered while doing power measurements: without uhci-hcd loaded, the system could not enter C3 state. This could be fixed by either loading uhci-hcd without devices attached or by specifying "usb-handoff". So, this can also fix "silent" issues. Regards - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thu, 4 Aug 2005 23:07:33 -0500 Dmitry Torokhov [EMAIL PROTECTED] wrote: It requests BIOS to hand off control of USB which disables USB legacy emulation and all troubles associated with it. We could start with -mm... This also fixes an issue I encountered while doing power measurements: without uhci-hcd loaded, the system could not enter C3 state. This could be fixed by either loading uhci-hcd without devices attached or by specifying usb-handoff. So, this can also fix silent issues. Regards - 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: preempt with selinux NULL pointer dereference
On Fri, 05 Aug 2005 17:46:13 +0100 Antoine Martin [EMAIL PROTECTED] wrote: [ 4788.218995] Pid: 19002, comm: ssh Tainted: G M 2.6.13-rc5 Which of your modules is non-GPL and can you please remove them and see if there's still a problem? Hmm. I occasionally use out-of-tree drivers (wlan cards mainly) so I thought these could be the culprit, but all the above are in the source tree (I keep the others out): From Documentation/oops-tracing.txt: 'G' if all modules loaded have a GPL or compatible license, 'P' if any proprietary module has been loaded. ... In other words, your kernel is tainted, but all modules are GPL. See also the check in panic.c: ... tainted TAINT_PROPRIETARY_MODULE ? 'P' : 'G', ... It seems that yout kernel was tainted by a machine check exception (MCE). This should be visible in dmesg somewhere, and might indicate a hardware problem. Regards - 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: local DDOS? Kernel panic when accessing /proc/ioports
On Fri, 5 Aug 2005 23:52:47 +0200 Martin Loschwitz [EMAIL PROTECTED] wrote: The situation in this case is somewhat obscene ... Originally, I had exactly this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I then went to compile 2.6.12.3, also with SMP, and it showed exactly the same problem. I disable SMP, tried again -- voila, it worked. The kernel that I am encountering this error again now is 2.6.12.3 -- without SMP or whatsoever. I'm just out of ideas on how to fix it this time. Did you always use the same machine? If so, can you rule out hardware issues? Can you reproduce this Oops at will? I can't reproduce this on various machines (all X86, kernels 2.6.11.9, 2.6.12.2, 2.6.13-rc4-mm1, no SMP) Regards - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Wed, 3 Aug 2005 15:59:24 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > This is the dynamic ticks patch for i386 as written by Tony Lindgen > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > Patch for 2.6.13-rc5 One issue (tested the -rc4 Version on -mm): - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. This matches "ticks to skip" below. Coincidence? - ping -f complains: .Warning: time of day goes back (-304us), taking countermeasures. ... .Warning: time of day goes back (-33us), taking countermeasures. Yet, system time _seems_ to be kept correctly. CPU is Pentium M. dmesg: Using pmtmr for high-res timesource dyn-tick: Found suitable timer: pmtmr dyn-tick: Maximum ticks to skip limited to 54 dyn-tick: Timer not enabled during boot sysfs: suitable: 1 enabled:1 using APIC: 0 Regards - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Thu, 4 Aug 2005 01:22:36 +0200 Christian Leber <[EMAIL PROTECTED]> wrote: > Just a few numbers: > > I tried it on a Laptop (Dell C810, P3m 1133 mhz) and measured the power > usage with an external device and it stayed with or without patch at > 27W. (HZ was at about 28) Does your machine enter C3 state? Check the usage in /proc/acpi/processor/CPU0/power If usage is 0, unplug all USB peripherals (at least those connected to uhci controllers). Also shut down sound servers. Without C3, there won't be any power savings from lower HZ. Desktop CPUs often don't support C3 at all. Marc - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Thu, 4 Aug 2005 01:22:36 +0200 Christian Leber [EMAIL PROTECTED] wrote: Just a few numbers: I tried it on a Laptop (Dell C810, P3m 1133 mhz) and measured the power usage with an external device and it stayed with or without patch at 27W. (HZ was at about 28) Does your machine enter C3 state? Check the usage in /proc/acpi/processor/CPU0/power If usage is 0, unplug all USB peripherals (at least those connected to uhci controllers). Also shut down sound servers. Without C3, there won't be any power savings from lower HZ. Desktop CPUs often don't support C3 at all. Marc - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Wed, 3 Aug 2005 15:59:24 +1000 Con Kolivas [EMAIL PROTECTED] wrote: This is the dynamic ticks patch for i386 as written by Tony Lindgen [EMAIL PROTECTED] and Tuukka Tikkanen [EMAIL PROTECTED]. Patch for 2.6.13-rc5 One issue (tested the -rc4 Version on -mm): - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. This matches ticks to skip below. Coincidence? - ping -f complains: .Warning: time of day goes back (-304us), taking countermeasures. ... .Warning: time of day goes back (-33us), taking countermeasures. Yet, system time _seems_ to be kept correctly. CPU is Pentium M. dmesg: Using pmtmr for high-res timesource dyn-tick: Found suitable timer: pmtmr dyn-tick: Maximum ticks to skip limited to 54 dyn-tick: Timer not enabled during boot sysfs: suitable: 1 enabled:1 using APIC: 0 Regards - 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: Calling suspend() in halt/restart/shutdown -> not a good idea
On Mon, 01 Aug 2005 17:09:31 +0200 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Hi ! > > Why are we calling driver suspend routines in these ? This is _not_ a > good idea ! On various machines, the mecanisms for shutting down are > quite different from suspend/resume, and current drivers have too many > bugs to make that safe. I keep getting all sort of reports of machines > not shutting down anymore. For example, my Centrino laptop will restart instead of power down with -mm kernels. To "fix" this I can either: - unplug power. Shutdown works when on battery power. - attach an external USB hard disk => power down always works. - remove device_suspend(PMSG_SUSPEND) => power down always works. Marc - 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: Calling suspend() in halt/restart/shutdown - not a good idea
On Mon, 01 Aug 2005 17:09:31 +0200 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Hi ! Why are we calling driver suspend routines in these ? This is _not_ a good idea ! On various machines, the mecanisms for shutting down are quite different from suspend/resume, and current drivers have too many bugs to make that safe. I keep getting all sort of reports of machines not shutting down anymore. For example, my Centrino laptop will restart instead of power down with -mm kernels. To fix this I can either: - unplug power. Shutdown works when on battery power. - attach an external USB hard disk = power down always works. - remove device_suspend(PMSG_SUSPEND) = power down always works. Marc - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Fri, 29 Jul 2005 19:15:42 -0400 Lee Revell <[EMAIL PROTECTED]> wrote: > > What kind of results do you get with a more realistic setup, like > running KDE or Gnome OOTB? > Here are results with KDE running. - no peripherals attached, i.e. truly mobile setup. - all modules loaded - klaptopdaemon disabled in order to eliminate competition in polling the already slow battery controller - furthermore, I found that artsd prevents entering C3 and generally increases power consumption (ALSA, snd_intel8x0) - voltage is 16.5V Since the results aren't as stable as in the minimal setup (especially with HZ=1000), I'll post raw numbers and averages: HZ=100: HZ=1000: DIFF: 1) averages: backlight on, artsd off: 765.00812.1242.12 backlight off, arstd off: 637.17679.6742.5 backlight on, artsd on: 927.60933.335.73 backlight off, artsd on: 799.46806.136.67 2) raw numbers: 771 mA <= backlight on 801 mA <= backlight on 764 mA 818 mA 763 mA 832 mA 763 mA 817 mA 764 mA 796 mA 766 mA 828 mA 764 mA 831 mA 635 mA <= backlight off 824 mA 635 mA 795 mA 635 mA 801 mA 636 mA 816 mA 636 mA 797 mA 646 mA 816 mA 638 mA 799 mA 637 mA 817 mA 639 mA 801 mA 634 mA 817 mA 637 mA 668 mA <= backlight off 636 mA 690 mA 637 mA 671 mA 764 mA <= backlight on 692 mA 771 mA 668 mA 929 mA <= artsd started 689 mA 924 mA 673 mA 942 mA 711 mA 927 mA 668 mA 925 mA 668 mA 926 mA 689 mA 925 mA 672 mA 926 mA 677 mA 923 mA 672 mA 929 mA 689 mA 797 mA <= backlight off 672 mA 800 mA 687 mA 800 mA 669 mA 813 mA 687 mA 799 mA 673 mA 797 mA 688 mA 798 mA 668 mA 799 mA 722 mA <= backlight on 800 mA 833 mA <= artsd started 797 mA 929 mA 799 mA 928 mA 797 mA 943 mA 797 mA 929 mA 932 mA <= backlight on 947 mA 929 mA 929 mA 935 mA 928 mA 945 mA 929 mA 929 mA 809 mA <= backlight off 799 mA 814 mA 799 mA 816 mA 799 mA 817 mA 799 mA 805 mA 799 mA 813 mA 800 mA 813 mA 800 mA 817 mA 799 mA 947 mA <= backlight on - 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/
Power consumption HZ100, HZ250, HZ1000: new numbers
Hi, I was finally able to get C3 state working. It seems that my BIOS is leaving USB controllers in an active state(?). Without any USB drivers loaded, C3 is not possible. With drivers loaded, but no device plugged in C3 works fine. Kernel is 2.6.13-rc3-mm3 + acpi-sbs. With working C3 there are indeed differences: Voltage is 16.5 V HZ=100: ~460 mA => 7.59 W HZ=250: ~468 mA => 7.72 W HZ=1000: ~494 mA => 8.15 W Results are quite stable. Test environment: - Pentium M 1.60GHz, model 13, stepping 6 - ondemand governor with acpi-cpufreq (idle at 600MHz) - no daemons running - no external devices attached, except display - WLAN disabled via kill switch - internal display disabled - hard disk in sleep mode (hdparm -Y), data dumped to ramfs - kernel configuration attached Regards config Description: Binary data
Power consumption HZ100, HZ250, HZ1000: new numbers
Hi, I was finally able to get C3 state working. It seems that my BIOS is leaving USB controllers in an active state(?). Without any USB drivers loaded, C3 is not possible. With drivers loaded, but no device plugged in C3 works fine. Kernel is 2.6.13-rc3-mm3 + acpi-sbs. With working C3 there are indeed differences: Voltage is 16.5 V HZ=100: ~460 mA = 7.59 W HZ=250: ~468 mA = 7.72 W HZ=1000: ~494 mA = 8.15 W Results are quite stable. Test environment: - Pentium M 1.60GHz, model 13, stepping 6 - ondemand governor with acpi-cpufreq (idle at 600MHz) - no daemons running - no external devices attached, except display - WLAN disabled via kill switch - internal display disabled - hard disk in sleep mode (hdparm -Y), data dumped to ramfs - kernel configuration attached Regards config Description: Binary data
Re: [PATCH 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
On Tue, 26 Jul 2005 11:36:01 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > machine_restart, machine_halt and machine_power_off are machine > specific hooks deep into the reboot logic, that modules > have no business messing with. Usually code should be calling > kernel_restart, kernel_halt, kernel_power_off, or > emergency_restart. So don't export machine_restart, > machine_halt, and machine_power_off so we can catch buggy users. The first is reiser4 in fs/reiser4/vfs_ops.c, line 1338. (Are filesystems supposed to restart the machine at all?!) Patch not tested properly, since this seems to be in error handling code, but compiles und runs fine. --- linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c.orig 2005-07-27 01:41:41.326382750 +0200 +++ linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c 2005-07-27 01:42:56.783098500 +0200 @@ -1335,7 +1335,7 @@ reiser4_internal void reiser4_handle_err sb->s_flags |= MS_RDONLY; break; case 2: - machine_restart(NULL); + kernel_restart(NULL); } } - 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: Reclaim space from unused ramdisk?
On Tue, 26 Jul 2005 15:16:58 -0700 Mike Mohr <[EMAIL PROTECTED]> wrote: > I wonder if it would be possible to somehow reclaim space that has > been previously reserved for a ramdisk without rebooting. I read the > ramdisk docs in the latest kernel source and it seems that it is not > currently possible. However, the kernel keeps track of the memory > allocated for said ramdisks; would it not be possible with root (or > even kernel) permissions to remove the flag that prevents the VM > subsystem from reclaiming that space? I realize that rot permissions > may not be high enough. In that case, could a module be written that > takes a device name as a parameter then uses it to look up the > reserved memory that device uses, then resets the necessary flag and > finally unloads itself? It would have to check that the filesystem > was unmounted, of course. > > How difficult would this be to write? Hi, ramfs (always there) and tmpfs (optional) already do this. tmpfs can be swapped out, ramfs always uses physical memory. mount -t ramfs none /mnt/blah mount -t tmpfs none /mnt/blah Regards - 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: Reclaim space from unused ramdisk?
On Tue, 26 Jul 2005 15:16:58 -0700 Mike Mohr [EMAIL PROTECTED] wrote: I wonder if it would be possible to somehow reclaim space that has been previously reserved for a ramdisk without rebooting. I read the ramdisk docs in the latest kernel source and it seems that it is not currently possible. However, the kernel keeps track of the memory allocated for said ramdisks; would it not be possible with root (or even kernel) permissions to remove the flag that prevents the VM subsystem from reclaiming that space? I realize that rot permissions may not be high enough. In that case, could a module be written that takes a device name as a parameter then uses it to look up the reserved memory that device uses, then resets the necessary flag and finally unloads itself? It would have to check that the filesystem was unmounted, of course. How difficult would this be to write? Hi, ramfs (always there) and tmpfs (optional) already do this. tmpfs can be swapped out, ramfs always uses physical memory. mount -t ramfs none /mnt/blah mount -t tmpfs none /mnt/blah Regards - 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 6/23] Don't export machine_restart, machine_halt, or machine_power_off.
On Tue, 26 Jul 2005 11:36:01 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: machine_restart, machine_halt and machine_power_off are machine specific hooks deep into the reboot logic, that modules have no business messing with. Usually code should be calling kernel_restart, kernel_halt, kernel_power_off, or emergency_restart. So don't export machine_restart, machine_halt, and machine_power_off so we can catch buggy users. The first is reiser4 in fs/reiser4/vfs_ops.c, line 1338. (Are filesystems supposed to restart the machine at all?!) Patch not tested properly, since this seems to be in error handling code, but compiles und runs fine. --- linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c.orig 2005-07-27 01:41:41.326382750 +0200 +++ linux-2.6.13-rc3-mm1/fs/reiser4/vfs_ops.c 2005-07-27 01:42:56.783098500 +0200 @@ -1335,7 +1335,7 @@ reiser4_internal void reiser4_handle_err sb-s_flags |= MS_RDONLY; break; case 2: - machine_restart(NULL); + kernel_restart(NULL); } } - 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: Power consumption HZ250 vs. HZ1000
On Mon, 25 Jul 2005 17:53:22 +0200 Pavel Machek <[EMAIL PROTECTED]> wrote: > USB devices prevent entering C3 and any interesting powersaving, > try without USB... Hmm, just did. I even tried the rather minimalistic configuration below. Still no C3. (And what seems even stranger: no C1.) Is this a BIOS Issue? Regards Tested config: CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-hztest" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_X86_PC=y CONFIG_MPENTIUMM=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_PREEMPT_NONE=y CONFIG_X86_TSC=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_MTRR=y CONFIG_REGPARM=y CONFIG_SECCOMP=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_HOTKEY=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y CONFIG_SYN_COOKIES=y CONFIG_IP_TCPDIAG=y CONFIG_TCP_CONG_BIC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_PNP=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=800 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_LIBPS2=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_SPEAKUP_DEFAULT="none" CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_DNOTIFY=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_1250=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_UTF8=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y - 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/
Power consumption HZ250 vs. HZ1000
Hi, I did some measurements in order to compare power drain with HZ250 and HZ1000. To measure the actual drain, I used the "smart" battery's internal measurement. (Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.) No clue how accurate this is. Here some battery details, in case someone knows: charge reporting error: 25% SB specification:v1.1 (with PEC) manufacturer name: Panasonic manufacture date:2004-11-27 device name: 02ZL device chemistry:Lion Kernel: 2.6.13-rc3-mm1 + acpi-sbs CPU: cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping: 6 The "ondemand" governor was running, using acpi_cpufreq. (Idle at 600MHz). Systems was running X11/KDE to get a more or less realistic scenario. No cron jobs, network traffic or additional applications. WLAN and built-in display were disabled completely, all fans and LEDs were off, internal hard disc was running. Additional peripherals: external keyboard, mouse, display and externally-powered hard disk (USB). The results are quite simple: In both configurations the current settles between 727-729 mA (Voltage ~16.5 V). Some issues: - C-states look strange: active state:C2 max_cstate: C8 bus master activity: 00887fff states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[01367471] C3: type[C3] promotion[--] demotion[C2] latency[085] usage[] - I don't know, how much polling of the battery affects results. Reads always block for ~10 seconds, and I used this behaviour for rate-limiting. - Is this approach valid at all? - I could repeat the test in single user mode with internal hard disc turned off. Regards - 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/
Power consumption HZ250 vs. HZ1000
Hi, I did some measurements in order to compare power drain with HZ250 and HZ1000. To measure the actual drain, I used the smart battery's internal measurement. (Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.) No clue how accurate this is. Here some battery details, in case someone knows: charge reporting error: 25% SB specification:v1.1 (with PEC) manufacturer name: Panasonic manufacture date:2004-11-27 device name: 02ZL device chemistry:Lion Kernel: 2.6.13-rc3-mm1 + acpi-sbs CPU: cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping: 6 The ondemand governor was running, using acpi_cpufreq. (Idle at 600MHz). Systems was running X11/KDE to get a more or less realistic scenario. No cron jobs, network traffic or additional applications. WLAN and built-in display were disabled completely, all fans and LEDs were off, internal hard disc was running. Additional peripherals: external keyboard, mouse, display and externally-powered hard disk (USB). The results are quite simple: In both configurations the current settles between 727-729 mA (Voltage ~16.5 V). Some issues: - C-states look strange: active state:C2 max_cstate: C8 bus master activity: 00887fff states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[01367471] C3: type[C3] promotion[--] demotion[C2] latency[085] usage[] - I don't know, how much polling of the battery affects results. Reads always block for ~10 seconds, and I used this behaviour for rate-limiting. - Is this approach valid at all? - I could repeat the test in single user mode with internal hard disc turned off. Regards - 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: Power consumption HZ250 vs. HZ1000
On Mon, 25 Jul 2005 17:53:22 +0200 Pavel Machek [EMAIL PROTECTED] wrote: USB devices prevent entering C3 and any interesting powersaving, try without USB... Hmm, just did. I even tried the rather minimalistic configuration below. Still no C3. (And what seems even stranger: no C1.) Is this a BIOS Issue? Regards Tested config: CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-hztest CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_X86_PC=y CONFIG_MPENTIUMM=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_PREEMPT_NONE=y CONFIG_X86_TSC=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_MTRR=y CONFIG_REGPARM=y CONFIG_SECCOMP=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_HOTKEY=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y CONFIG_SYN_COOKIES=y CONFIG_IP_TCPDIAG=y CONFIG_TCP_CONG_BIC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_PNP=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE= CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=800 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_LIBPS2=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_SPEAKUP_DEFAULT=none CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_DNOTIFY=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT=iso8859-1 CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_1250=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_UTF8=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y - 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/
