* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
@ 2006-07-03 10:50 ` Michal Piotrowski
2006-07-03 10:56 ` 2.6.17-mm6 Andrew Morton
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
` (14 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Michal Piotrowski @ 2006-07-03 10:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tigran Aivazian, linux-kernel
Hi,
On 03/07/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
Something is missing in drivers/base/firmware_class.c?
WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
needs unknown symbol release_firmware
WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
needs unknown symbol request_firmware
WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
needs unknown symbol release_firmware
WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
needs unknown symbol request_firmware
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski
@ 2006-07-03 10:56 ` Andrew Morton
2006-07-03 11:36 ` 2.6.17-mm6 Michal Piotrowski
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 10:56 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: tigran, linux-kernel
On Mon, 3 Jul 2006 12:50:26 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> On 03/07/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
>
> Something is missing in drivers/base/firmware_class.c?
>
> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
> needs unknown symbol release_firmware
> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
> needs unknown symbol request_firmware
> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
> needs unknown symbol release_firmware
> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
> needs unknown symbol request_firmware
>
Presumably you'll need CONFIG_FW_LOADER?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:56 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 11:36 ` Michal Piotrowski
2006-07-03 12:27 ` 2.6.17-mm6 Michal Piotrowski
0 siblings, 1 reply; 126+ messages in thread
From: Michal Piotrowski @ 2006-07-03 11:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: tigran, linux-kernel
Andrew Morton wrote:
> On Mon, 3 Jul 2006 12:50:26 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
>> Hi,
>>
>> On 03/07/06, Andrew Morton <akpm@osdl.org> wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>>>
>> Something is missing in drivers/base/firmware_class.c?
>>
>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>> needs unknown symbol release_firmware
>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>> needs unknown symbol request_firmware
>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>> needs unknown symbol release_firmware
>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>> needs unknown symbol request_firmware
>>
>
> Presumably you'll need CONFIG_FW_LOADER?
>
Yes, thanks. How about this patch?
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig
--- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200
+++ linux-mm/arch/i386/Kconfig 2006-07-03 13:26:51.000000000 +0200
@@ -399,6 +399,7 @@ config X86_REBOOTFIXUPS
config MICROCODE
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
+ depends on FW_LOADER
---help---
If you say Y here and also to "/dev file system support" in the
'File systems' section, you will be able to update the microcode on
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:36 ` 2.6.17-mm6 Michal Piotrowski
@ 2006-07-03 12:27 ` Michal Piotrowski
2006-07-03 13:28 ` 2.6.17-mm6 Dmitry Torokhov
0 siblings, 1 reply; 126+ messages in thread
From: Michal Piotrowski @ 2006-07-03 12:27 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, tigran, linux-kernel, Greg KH
> Andrew Morton wrote:
>> On Mon, 3 Jul 2006 12:50:26 +0200
>> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On 03/07/06, Andrew Morton <akpm@osdl.org> wrote:
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>>>>
>>> Something is missing in drivers/base/firmware_class.c?
>>>
>>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>>> needs unknown symbol release_firmware
>>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>>> needs unknown symbol request_firmware
>>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>>> needs unknown symbol release_firmware
>>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko
>>> needs unknown symbol request_firmware
>>>
>> Presumably you'll need CONFIG_FW_LOADER?
>>
>
> Yes, thanks. How about this patch?
>
Here is an updated version of this patch.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig
--- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200
+++ linux-mm/arch/i386/Kconfig 2006-07-03 14:07:15.000000000 +0200
@@ -399,9 +399,9 @@ config X86_REBOOTFIXUPS
config MICROCODE
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
+ depends on FW_LOADER
---help---
- If you say Y here and also to "/dev file system support" in the
- 'File systems' section, you will be able to update the microcode on
+ If you say Y here, you will be able to update the microcode on
Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
Pentium III, Pentium 4, Xeon etc. You will obviously need the
actual microcode binary data itself which is not shipped with the
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 12:27 ` 2.6.17-mm6 Michal Piotrowski
@ 2006-07-03 13:28 ` Dmitry Torokhov
0 siblings, 0 replies; 126+ messages in thread
From: Dmitry Torokhov @ 2006-07-03 13:28 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, tigran, linux-kernel, Greg KH
On Monday 03 July 2006 08:27, Michal Piotrowski wrote:
> diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig
> --- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200
> +++ linux-mm/arch/i386/Kconfig 2006-07-03 14:07:15.000000000 +0200
> @@ -399,9 +399,9 @@ config X86_REBOOTFIXUPS
>
> config MICROCODE
> tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
> + depends on FW_LOADER
Wouldn't "select" be better here?
--
Dmitry
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski
@ 2006-07-03 11:00 ` Reuben Farrelly
2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton
` (2 more replies)
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
` (13 subsequent siblings)
15 siblings, 3 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-03 11:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, greg, brice
On 3/07/2006 10:03 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
>
> - A major update to the e1000 driver.
>
> - 1394 updates
audit: initializing netlink socket (disabled)
audit(1151924044.008:1): initialized
SELinux: Registering netfilter hooks
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie0]
Allocate Port Service[0000:00:1c.0:pcie0]
kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
The trace shows up 5 times in quick succession, all traces looking the same.......
Box otherwise boots up OK.
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-03 11:25 ` Andrew Morton
2006-07-03 12:34 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton
2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov
2 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 11:25 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, greg, brice
On Mon, 03 Jul 2006 23:00:34 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>
> On 3/07/2006 10:03 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
> >
> > - A major update to the e1000 driver.
> >
> > - 1394 updates
>
>
> audit: initializing netlink socket (disabled)
> audit(1151924044.008:1): initialized
> SELinux: Registering netfilter hooks
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered (default)
> PCI: Setting latency timer of device 0000:00:1c.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:1c.0:pcie0]
> Allocate Port Service[0000:00:1c.0:pcie0]
Looks like the enumeration of the PCIE devices failed to increment something.
> kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register
> things with the same name in the same directory.
>
> Call Trace:
> [<ffffffff80358298>] kobject_put+0x19/0x21
> [<ffffffff80358741>] kobject_add+0x181/0x1ac
> [<ffffffff803aa378>] device_add+0x88/0x4b9
> [<ffffffff803aa7c2>] device_register+0x19/0x27
> [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
> [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
> [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
> [<ffffffff803612ac>] pci_device_probe+0x4d/0x78
> [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
> [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
> [<ffffffff803ac162>] __driver_attach+0x0/0xb9
> [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
> [<ffffffff803abfbc>] driver_attach+0x1c/0x1e
> [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
> [<ffffffff803ac463>] driver_register+0x9f/0xa6
> [<ffffffff80361497>] __pci_register_driver+0x59/0x7e
> [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
> [<ffffffff80267f3e>] init+0x14e/0x2d0
> [<ffffffff80260a12>] child_rip+0x8/0x12
> [<ffffffff80267df0>] init+0x0/0x2d0
> [<ffffffff80260a0a>] child_rip+0x0/0x12
>
> The trace shows up 5 times in quick succession, all traces looking the same.......
>
> Box otherwise boots up OK.
I'd be supecting the changes in drivers/base/core.c. Does 2.6.17-git19 do
the same thing?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 12:34 ` Reuben Farrelly
0 siblings, 0 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-03 12:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, greg, brice
On 3/07/2006 11:25 p.m., Andrew Morton wrote:
> On Mon, 03 Jul 2006 23:00:34 +1200
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>>
>> On 3/07/2006 10:03 p.m., Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>>>
>>>
>>> - A major update to the e1000 driver.
>>>
>>> - 1394 updates
>>
>> audit: initializing netlink socket (disabled)
>> audit(1151924044.008:1): initialized
>> SELinux: Registering netfilter hooks
>> Initializing Cryptographic API
>> io scheduler noop registered
>> io scheduler anticipatory registered
>> io scheduler deadline registered (default)
>> PCI: Setting latency timer of device 0000:00:1c.0 to 64
>> assign_interrupt_mode Found MSI capability
>> Allocate Port Service[0000:00:1c.0:pcie0]
>> Allocate Port Service[0000:00:1c.0:pcie0]
>
> Looks like the enumeration of the PCIE devices failed to increment something.
>
>> kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register
>> things with the same name in the same directory.
>>
>> Call Trace:
>> [<ffffffff80358298>] kobject_put+0x19/0x21
>> [<ffffffff80358741>] kobject_add+0x181/0x1ac
>> [<ffffffff803aa378>] device_add+0x88/0x4b9
>> [<ffffffff803aa7c2>] device_register+0x19/0x27
>> [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
>> [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
>> [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
>> [<ffffffff803612ac>] pci_device_probe+0x4d/0x78
>> [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
>> [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
>> [<ffffffff803ac162>] __driver_attach+0x0/0xb9
>> [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
>> [<ffffffff803abfbc>] driver_attach+0x1c/0x1e
>> [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
>> [<ffffffff803ac463>] driver_register+0x9f/0xa6
>> [<ffffffff80361497>] __pci_register_driver+0x59/0x7e
>> [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
>> [<ffffffff80267f3e>] init+0x14e/0x2d0
>> [<ffffffff80260a12>] child_rip+0x8/0x12
>> [<ffffffff80267df0>] init+0x0/0x2d0
>> [<ffffffff80260a0a>] child_rip+0x0/0x12
>>
>> The trace shows up 5 times in quick succession, all traces looking the same.......
>>
>> Box otherwise boots up OK.
>
> I'd be supecting the changes in drivers/base/core.c. Does 2.6.17-git19 do
> the same thing?
No. It seems to be fine.
I'll post a dmesg from that too if you like.
Reuben
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 11:39 ` Andrew Morton
2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov
2 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 11:39 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, greg, brice
On Mon, 03 Jul 2006 23:00:34 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
> Allocate Port Service[0000:00:1c.0:pcie0]
> Allocate Port Service[0000:00:1c.0:pcie0]
Could we have the full dmesg please?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 11:41 ` Reuben Farrelly
2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton
2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton
0 siblings, 2 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-03 11:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, greg, brice
On 3/07/2006 11:39 p.m., Andrew Morton wrote:
> On Mon, 03 Jul 2006 23:00:34 +1200
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>> Allocate Port Service[0000:00:1c.0:pcie0]
>> Allocate Port Service[0000:00:1c.0:pcie0]
>
> Could we have the full dmesg please?
Sure:
Bootdata ok (command line is ro root=/dev/md0 panic=60 console=ttyS0,57600)
Linux version 2.6.17-mm6 (root@tornado.reub.net) (gcc version 4.1.1 20060629
(Red Hat 4.1.1-6)) #1 SMP Mon Jul 3 22:47:46 NZST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003f670000 (usable)
BIOS-e820: 000000003f670000 - 000000003f6e9000 (ACPI NVS)
BIOS-e820: 000000003f6e9000 - 000000003f6ec000 (usable)
BIOS-e820: 000000003f6ec000 - 000000003f6ff000 (ACPI data)
BIOS-e820: 000000003f6ff000 - 000000003f700000 (usable)
DMI 2.3 present.
ACPI: RSDP (v000 INTEL ) @ 0x00000000000fe020
ACPI: RSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fde48
ACPI: FADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcf10
ACPI: MADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fce10
ACPI: WDDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f90
ACPI: MCFG (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f10
ACPI: ASF! (v032 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcd10
ACPI: HPET (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6e90
ACPI: SSDT (v001 INTEL CpuPm 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fdc10
ACPI: SSDT (v001 INTEL Cpu0Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fda10
ACPI: SSDT (v001 INTEL Cpu1Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd810
ACPI: SSDT (v001 INTEL Cpu2Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd610
ACPI: SSDT (v001 INTEL Cpu3Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd410
ACPI: TCPA (v001 INTEL TIANO 0x00000002 MSFT 0x01000013) @ 0x000000003f670010
ACPI: DSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x0000000000000000
On node 0 totalpages: 254541
DMA zone: 2433 pages, LIFO batch:0
DMA32 zone: 252108 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 40000000 (gap: 3f700000:c0900000)
Built 1 zonelists. Total pages: 254541
Kernel command line: ro root=/dev/md0 panic=60 console=ttyS0,57600
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
Memory: 1015020k/1039360k available (2582k kernel code, 22812k reserved, 1666k
data, 216k init)
Calibrating delay using timer specific routine.. 6006.43 BogoMIPS (lpj=12012875)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
Freeing SMP alternatives: 28k freed
ACPI: Core revision 20060623
Using local APIC timer interrupts.
result 12500448
Detected 12.500 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 6000.21 BogoMIPS (lpj=12000420)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU1: Thermal monitoring enabled (TM1)
Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03
Brought up 2 CPUs
testing NMI watchdog ... OK.
time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 3000.123 MHz processor.
migration_cost=5
checking if image is initramfs... it is
Freeing initrd memory: 877k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:00:02.0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 *9 10 11 12)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
Intel 82802 RNG detected
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
PCI-GART: No AMD northbridge found.
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:1c.0
IO window: 2000-2fff
MEM window: 48000000-480fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.3
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.5
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: 1000-1fff
MEM window: disabled.
PREFETCH window: disabled.
Device `[PEX0]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.0[A] ->
GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
Device `[PEX2]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.2[C] ->
GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1c.2 to 64
Device `[PEX3]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.3[D] ->
GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1c.3 to 64
Device `[PEX4]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.4[A] ->
GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.4 to 64
Device `[PEX5]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.5[B] ->
GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1151924044.008:1): initialized
SELinux: Registering netfilter hooks
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie0]
Allocate Port Service[0000:00:1c.0:pcie0]
kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie0]
Allocate Port Service[0000:00:1c.2:pcie0]
kobject_add failed for 0000:00:1c.2:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie0]
Allocate Port Service[0000:00:1c.3:pcie0]
kobject_add failed for 0000:00:1c.3:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie0]
Allocate Port Service[0000:00:1c.4:pcie0]
kobject_add failed for 0000:00:1c.4:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
PCI: Setting latency timer of device 0000:00:1c.5 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.5:pcie0]
Allocate Port Service[0000:00:1c.5:pcie0]
kobject_add failed for 0000:00:1c.5:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
Call Trace:
[<ffffffff80358298>] kobject_put+0x19/0x21
[<ffffffff80358741>] kobject_add+0x181/0x1ac
[<ffffffff803aa378>] device_add+0x88/0x4b9
[<ffffffff803aa7c2>] device_register+0x19/0x27
[<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de
[<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86
[<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80
[<ffffffff803612ac>] pci_device_probe+0x4d/0x78
[<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4
[<ffffffff803ac1c9>] __driver_attach+0x67/0xb9
[<ffffffff803ac162>] __driver_attach+0x0/0xb9
[<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79
[<ffffffff803abfbc>] driver_attach+0x1c/0x1e
[<ffffffff803ab61a>] bus_add_driver+0x7a/0x143
[<ffffffff803ac463>] driver_register+0x9f/0xa6
[<ffffffff80361497>] __pci_register_driver+0x59/0x7e
[<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30
[<ffffffff80267f3e>] init+0x14e/0x2d0
[<ffffffff80260a12>] child_rip+0x8/0x12
[<ffffffff80267df0>] init+0x0/0x2d0
[<ffffffff80260a0a>] child_rip+0x0/0x12
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Getting cpuindex for acpiid 0x3
ACPI: Getting cpuindex for acpiid 0x4
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed00000 is busy
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19
0000:06:03.0: ttyS1 at I/O 0x1000 (irq = 19) is a 16550A
0000:06:03.0: ttyS2 at I/O 0x1008 (irq = 19) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 4 RAM disks of 16384K size 1024 blocksize
Intel(R) PRO/1000 Network Driver - version 7.1.9-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
e1000: 0000:01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:13:20:60:b4:23
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH7: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH7: chipset revision 1
ICH7: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x30b0-0x30b7, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
libata version 2.00 loaded.
ahci 0000:00:1f.2: version 2.0
Device `[IDES]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1f.2[B] ->
GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part
ata1: SATA max UDMA/133 cmd 0xFFFFC20000016100 ctl 0x0 bmdma 0x0 irq 314
ata2: SATA max UDMA/133 cmd 0xFFFFC20000016180 ctl 0x0 bmdma 0x0 irq 314
ata3: SATA max UDMA/133 cmd 0xFFFFC20000016200 ctl 0x0 bmdma 0x0 irq 314
ata4: SATA max UDMA/133 cmd 0xFFFFC20000016280 ctl 0x0 bmdma 0x0 irq 314
scsi0 : ahci
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
Losing some ticks... checking if CPU frequency changed.
scsi2 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/133
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
Vendor: ATA Model: ST380817AS Rev: 3.42
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3300622AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST380817AS Rev: 3.42
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 >
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 sdb3
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 >
sd 2:0:0:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
Device `[EHCI]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1d.7[A] ->
GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 23, io mem 0x481a0400
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.17-mm6 ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 23, io base 0x00003080
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.17-mm6 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x00003060
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.17-mm6 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.1
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00003040
usb usb4: new device found, idVendor=0000, idProduct=0000
usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.17-mm6 uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.2
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
usb 2-1: new full speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x00003020
usb usb5: new device found, idVendor=0000, idProduct=0000
usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.17-mm6 uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 2-1: new device found, idVendor=0451, idProduct=2046
usb 2-1: new device strings: Mfr=0, Product=0, SerialNumber=0
usb 2-1: configuration #1 chosen from 1 choice
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 3-2: new full speed USB device using uhci_hcd and address 2
usb 3-2: new device found, idVendor=046d, idProduct=08b0
usb 3-2: new device strings: Mfr=0, Product=0, SerialNumber=1
usb 3-2: SerialNumber: 01402100A5000000
usb 3-2: configuration #1 chosen from 1 choice
usb 2-1.1: new low speed USB device using uhci_hcd and address 3
usb 2-1.1: new device found, idVendor=050d, idProduct=0105
usb 2-1.1: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.1: Product: Belkin OmniView KVM Switch
usb 2-1.1: Manufacturer: Belkin Components
usb 2-1.1: configuration #1 chosen from 1 choice
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input0
input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.0-1.1
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input1
input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.0-1.1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EDAC MC: Ver: 2.0.1 Jul 3 2006
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 3 devices found
Freeing unused kernel memory: 216k freed
md: Autodetecting RAID arrays.
md: invalid raid superblock magic on sda10
md: sda10 has invalid sb, not importing!
md: invalid raid superblock magic on sdc10
md: sdc10 has invalid sb, not importing!
md: autorun ...
md: considering sdc11 ...
md: adding sdc11 ...
md: sdc7 has different UUID to sdc11
md: sdc6 has different UUID to sdc11
md: sdc5 has different UUID to sdc11
md: sdc3 has different UUID to sdc11
md: sdc2 has different UUID to sdc11
md: adding sda11 ...
md: sda7 has different UUID to sdc11
md: sda6 has different UUID to sdc11
md: sda5 has different UUID to sdc11
md: sda3 has different UUID to sdc11
md: sda2 has different UUID to sdc11
md: created md5
md: bind<sda11>
md: bind<sdc11>
md: running: <sdc11><sda11>
raid1: raid set md5 active with 2 out of 2 mirrors
md5: bitmap initialized from disk: read 10/10 pages, set 7 bits, status: 0
created bitmap (153 pages) for device md5
md: considering sdc7 ...
md: adding sdc7 ...
md: sdc6 has different UUID to sdc7
md: sdc5 has different UUID to sdc7
md: sdc3 has different UUID to sdc7
md: sdc2 has different UUID to sdc7
md: adding sda7 ...
md: sda6 has different UUID to sdc7
md: sda5 has different UUID to sdc7
md: sda3 has different UUID to sdc7
md: sda2 has different UUID to sdc7
md: created md4
md: bind<sda7>
md: bind<sdc7>
md: running: <sdc7><sda7>
raid1: raid set md4 active with 2 out of 2 mirrors
md4: bitmap initialized from disk: read 4/4 pages, set 9 bits, status: 0
created bitmap (61 pages) for device md4
md: considering sdc6 ...
md: adding sdc6 ...
md: sdc5 has different UUID to sdc6
md: sdc3 has different UUID to sdc6
md: sdc2 has different UUID to sdc6
md: adding sda6 ...
md: sda5 has different UUID to sdc6
md: sda3 has different UUID to sdc6
md: sda2 has different UUID to sdc6
md: created md3
md: bind<sda6>
md: bind<sdc6>
md: running: <sdc6><sda6>
raid1: raid set md3 active with 2 out of 2 mirrors
md3: bitmap initialized from disk: read 1/1 pages, set 1 bits, status: 0
created bitmap (13 pages) for device md3
md: considering sdc5 ...
md: adding sdc5 ...
md: sdc3 has different UUID to sdc5
md: sdc2 has different UUID to sdc5
md: adding sda5 ...
md: sda3 has different UUID to sdc5
md: sda2 has different UUID to sdc5
md: created md2
md: bind<sda5>
md: bind<sdc5>
md: running: <sdc5><sda5>
raid1: raid set md2 active with 2 out of 2 mirrors
md2: bitmap initialized from disk: read 10/10 pages, set 54 bits, status: 0
created bitmap (150 pages) for device md2
md: considering sdc3 ...
md: adding sdc3 ...
md: sdc2 has different UUID to sdc3
md: adding sda3 ...
md: sda2 has different UUID to sdc3
md: created md1
md: bind<sda3>
md: bind<sdc3>
md: running: <sdc3><sda3>
raid1: raid set md1 active with 2 out of 2 mirrors
md1: bitmap initialized from disk: read 10/10 pages, set 50 bits, status: 0
created bitmap (150 pages) for device md1
md: considering sdc2 ...
md: adding sdc2 ...
md: adding sda2 ...
md: created md0
md: bind<sda2>
md: bind<sdc2>
md: running: <sdc2><sda2>
raid1: raid set md0 active with 2 out of 2 mirrors
md0: bitmap initialized from disk: read 12/12 pages, set 41 bits, status: 0
created bitmap (187 pages) for device md0
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.
SELinux: Unregistering netfilter hooks
audit(1151924056.656:2): selinux=0 auid=4294967295
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.00 (18-Jun-2006)
iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66)
Uniform CD-ROM driver Revision: 3.20
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md0, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on md5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: sda8: found reiserfs format "3.6" with standard journal
ReiserFS: sda8: using ordered data mode
ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda8: checking transaction log (sda8)
ReiserFS: sda8: Using r5 hash to sort names
ReiserFS: sdc8: found reiserfs format "3.6" with standard journal
ReiserFS: sdc8: using ordered data mode
ReiserFS: sdc8: journal params: device sdc8, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdc8: checking transaction log (sdc8)
ReiserFS: sdc8: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sdb1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sdb2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 248968k swap on /dev/sda9. Priority:-1 extents:1 across:248968k
Adding 248968k swap on /dev/sdc9. Priority:-2 extents:1 across:248968k
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (4060 buckets, 32480 max) - 288 bytes per conntrack
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
GRE over IPv4 tunneling driver
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
Bluetooth: Core ver 2.8
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.7
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
eth0: no IPv6 routers present
[root@tornado linux]#
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-03 12:10 ` Andrew Morton
2006-07-03 13:36 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton
1 sibling, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 12:10 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, greg, brice
On Mon, 03 Jul 2006 23:41:42 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
> On 3/07/2006 11:39 p.m., Andrew Morton wrote:
> > On Mon, 03 Jul 2006 23:00:34 +1200
> > Reuben Farrelly <reuben-lkml@reub.net> wrote:
> >
> >> Allocate Port Service[0000:00:1c.0:pcie0]
> >> Allocate Port Service[0000:00:1c.0:pcie0]
> >
> > Could we have the full dmesg please?
>
> Sure:
Still stumped. Could we have the dmesg for 2.6.17?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 13:36 ` Reuben Farrelly
0 siblings, 0 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-03 13:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, greg, brice
On 4/07/2006 12:10 a.m., Andrew Morton wrote:
> On Mon, 03 Jul 2006 23:41:42 +1200
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>> On 3/07/2006 11:39 p.m., Andrew Morton wrote:
>>> On Mon, 03 Jul 2006 23:00:34 +1200
>>> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>>>
>>>> Allocate Port Service[0000:00:1c.0:pcie0]
>>>> Allocate Port Service[0000:00:1c.0:pcie0]
>>> Could we have the full dmesg please?
>> Sure:
>
> Still stumped. Could we have the dmesg for 2.6.17?
Here's the 2.6.17-git19 dmesg and an lspci -v. I'm not sure if you need me to
rollback further or not..
[root@tornado ~]# dmesg
Bootdata ok (command line is ro root=/dev/md0 panic=60 console=ttyS0,57600)
Linux version 2.6.17-git19 (root@tornado.reub.net) (gcc version 4.1.1 20060629
(Red Hat 4.1.1-6)) #1 SMP Mon Jul 3 23:58:06 NZST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003f670000 (usable)
BIOS-e820: 000000003f670000 - 000000003f6e9000 (ACPI NVS)
BIOS-e820: 000000003f6e9000 - 000000003f6ec000 (usable)
BIOS-e820: 000000003f6ec000 - 000000003f6ff000 (ACPI data)
BIOS-e820: 000000003f6ff000 - 000000003f700000 (usable)
DMI 2.3 present.
ACPI: RSDP (v000 INTEL ) @ 0x00000000000fe020
ACPI: RSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fde48
ACPI: FADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcf10
ACPI: MADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fce10
ACPI: WDDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f90
ACPI: MCFG (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f10
ACPI: ASF! (v032 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcd10
ACPI: HPET (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6e90
ACPI: SSDT (v001 INTEL CpuPm 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fdc10
ACPI: SSDT (v001 INTEL Cpu0Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fda10
ACPI: SSDT (v001 INTEL Cpu1Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd810
ACPI: SSDT (v001 INTEL Cpu2Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd610
ACPI: SSDT (v001 INTEL Cpu3Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd410
ACPI: TCPA (v001 INTEL TIANO 0x00000002 MSFT 0x01000013) @ 0x000000003f670010
ACPI: DSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x0000000000000000
On node 0 totalpages: 254558
DMA zone: 2450 pages, LIFO batch:0
DMA32 zone: 252108 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 40000000 (gap: 3f700000:c0900000)
Built 1 zonelists. Total pages: 254558
Kernel command line: ro root=/dev/md0 panic=60 console=ttyS0,57600
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 3000.118 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
Memory: 1015088k/1039360k available (2552k kernel code, 22744k reserved, 1640k
data, 204k init)
Calibrating delay using timer specific routine.. 6006.39 BogoMIPS (lpj=12012785)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
Freeing SMP alternatives: 28k freed
ACPI: Core revision 20060623
Using local APIC timer interrupts.
result 12500432
Detected 12.500 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 6000.13 BogoMIPS (lpj=12000263)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU1: Thermal monitoring enabled (TM1)
Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=10
checking if image is initramfs... it is
Freeing initrd memory: 877k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:00:02.0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 *9 10 11 12)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
Intel 82802 RNG detected
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
PCI-GART: No AMD northbridge found.
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:1c.0
IO window: 2000-2fff
MEM window: 48000000-480fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.3
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.5
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: 1000-1fff
MEM window: disabled.
PREFETCH window: disabled.
Device `[PEX0]' is not power manageable<6>GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1c.0 to 64
Device `[PEX2]' is not power manageable<6>GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1c.2 to 64
Device `[PEX3]' is not power manageable<6>GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1c.3 to 64
Device `[PEX4]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.4[A] ->
GSI 17 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1c.4 to 64
Device `[PEX5]' is not power manageable<6>GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1151933576.024:1): initialized
SELinux: Registering netfilter hooks
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie00]
Allocate Port Service[0000:00:1c.2:pcie02]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie00]
Allocate Port Service[0000:00:1c.4:pcie02]
PCI: Setting latency timer of device 0000:00:1c.5 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.5:pcie00]
Allocate Port Service[0000:00:1c.5:pcie02]
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Getting cpuindex for acpiid 0x3
ACPI: Getting cpuindex for acpiid 0x4
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed00000 is busy
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 185
0000:06:03.0: ttyS1 at I/O 0x1000 (irq = 185) is a 16550A
0000:06:03.0: ttyS2 at I/O 0x1008 (irq = 185) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 4 RAM disks of 16384K size 1024 blocksize
Intel(R) PRO/1000 Network Driver - version 7.0.38-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:01:00.0 to 64
e1000: 0000:01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:13:20:60:b4:23
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH7: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 177
ICH7: chipset revision 1
ICH7: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x30b0-0x30b7, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
libata version 2.00 loaded.
ahci 0000:00:1f.2: version 2.0
Device `[IDES]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1f.2[B] ->
GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part
ata1: SATA max UDMA/133 cmd 0xFFFFC20000016100 ctl 0x0 bmdma 0x0 irq 58
ata2: SATA max UDMA/133 cmd 0xFFFFC20000016180 ctl 0x0 bmdma 0x0 irq 58
ata3: SATA max UDMA/133 cmd 0xFFFFC20000016200 ctl 0x0 bmdma 0x0 irq 58
ata4: SATA max UDMA/133 cmd 0xFFFFC20000016280 ctl 0x0 bmdma 0x0 irq 58
scsi0 : ahci
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
scsi2 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/133
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
Losing some ticks... checking if CPU frequency changed.
Vendor: ATA Model: ST380817AS Rev: 3.42
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3300622AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST380817AS Rev: 3.42
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 >
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 sdb3
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 >
sd 2:0:0:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
Device `[EHCI]' is not power manageable<6>GSI 20 sharing vector 0x42 and IRQ 20
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 66
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 66, io mem 0x481a0400
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 66
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 66, io base 0x00003080
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 185, io base 0x00003060
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 177, io base 0x00003040
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 193, io base 0x00003020
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 3-2: new full speed USB device using uhci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
usb 2-1.1: new low speed USB device using uhci_hcd and address 3
usb 2-1.1: configuration #1 chosen from 1 choice
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input0
input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.0-1.1
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input1
input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.0-1.1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EDAC MC: Ver: 2.0.0 Jul 3 2006
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 3 devices found
Freeing unused kernel memory: 204k freed
md: Autodetecting RAID arrays.
md: invalid raid superblock magic on sda10
md: sda10 has invalid sb, not importing!
md: invalid raid superblock magic on sdc10
md: sdc10 has invalid sb, not importing!
md: autorun ...
md: considering sdc11 ...
md: adding sdc11 ...
md: sdc7 has different UUID to sdc11
md: sdc6 has different UUID to sdc11
md: sdc5 has different UUID to sdc11
md: sdc3 has different UUID to sdc11
md: sdc2 has different UUID to sdc11
md: adding sda11 ...
md: sda7 has different UUID to sdc11
md: sda6 has different UUID to sdc11
md: sda5 has different UUID to sdc11
md: sda3 has different UUID to sdc11
md: sda2 has different UUID to sdc11
md: created md5
md: bind<sda11>
md: bind<sdc11>
md: running: <sdc11><sda11>
raid1: raid set md5 active with 2 out of 2 mirrors
md5: bitmap initialized from disk: read 10/10 pages, set 9 bits, status: 0
created bitmap (153 pages) for device md5
md: considering sdc7 ...
md: adding sdc7 ...
md: sdc6 has different UUID to sdc7
md: sdc5 has different UUID to sdc7
md: sdc3 has different UUID to sdc7
md: sdc2 has different UUID to sdc7
md: adding sda7 ...
md: sda6 has different UUID to sdc7
md: sda5 has different UUID to sdc7
md: sda3 has different UUID to sdc7
md: sda2 has different UUID to sdc7
md: created md4
md: bind<sda7>
md: bind<sdc7>
md: running: <sdc7><sda7>
raid1: raid set md4 active with 2 out of 2 mirrors
md4: bitmap initialized from disk: read 4/4 pages, set 6 bits, status: 0
created bitmap (61 pages) for device md4
md: considering sdc6 ...
md: adding sdc6 ...
md: sdc5 has different UUID to sdc6
md: sdc3 has different UUID to sdc6
md: sdc2 has different UUID to sdc6
md: adding sda6 ...
md: sda5 has different UUID to sdc6
md: sda3 has different UUID to sdc6
md: sda2 has different UUID to sdc6
md: created md3
md: bind<sda6>
md: bind<sdc6>
md: running: <sdc6><sda6>
raid1: raid set md3 active with 2 out of 2 mirrors
md3: bitmap initialized from disk: read 1/1 pages, set 2 bits, status: 0
created bitmap (13 pages) for device md3
md: considering sdc5 ...
md: adding sdc5 ...
md: sdc3 has different UUID to sdc5
md: sdc2 has different UUID to sdc5
md: adding sda5 ...
md: sda3 has different UUID to sdc5
md: sda2 has different UUID to sdc5
md: created md2
md: bind<sda5>
md: bind<sdc5>
md: running: <sdc5><sda5>
raid1: raid set md2 active with 2 out of 2 mirrors
md2: bitmap initialized from disk: read 10/10 pages, set 49 bits, status: 0
created bitmap (150 pages) for device md2
md: considering sdc3 ...
md: adding sdc3 ...
md: sdc2 has different UUID to sdc3
md: adding sda3 ...
md: sda2 has different UUID to sdc3
md: created md1
md: bind<sda3>
md: bind<sdc3>
md: running: <sdc3><sda3>
raid1: raid set md1 active with 2 out of 2 mirrors
md1: bitmap initialized from disk: read 10/10 pages, set 54 bits, status: 0
created bitmap (150 pages) for device md1
md: considering sdc2 ...
md: adding sdc2 ...
md: adding sda2 ...
md: created md0
md: bind<sda2>
md: bind<sdc2>
md: running: <sdc2><sda2>
raid1: raid set md0 active with 2 out of 2 mirrors
md0: bitmap initialized from disk: read 12/12 pages, set 44 bits, status: 0
created bitmap (187 pages) for device md0
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.
SELinux: Unregistering netfilter hooks
audit(1151933587.676:2): selinux=0 auid=4294967295
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 185
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66)
Uniform CD-ROM driver Revision: 3.20
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on md0, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: sda8: found reiserfs format "3.6" with standard journal
ReiserFS: sda8: using ordered data mode
ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda8: checking transaction log (sda8)
ReiserFS: sda8: Using r5 hash to sort names
ReiserFS: sdc8: found reiserfs format "3.6" with standard journal
ReiserFS: sdc8: using ordered data mode
ReiserFS: sdc8: journal params: device sdc8, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdc8: checking transaction log (sdc8)
ReiserFS: sdc8: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3 FS on sdb1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sdb2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 248968k swap on /dev/sda9. Priority:-1 extents:1 across:248968k
Adding 248968k swap on /dev/sdc9. Priority:-2 extents:1 across:248968k
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (4060 buckets, 32480 max) - 288 bytes per conntrack
e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
GRE over IPv4 tunneling driver
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
Bluetooth: Core ver 2.8
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.7
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
eth0: no IPv6 routers present
[root@tornado ~]#
[root@tornado ~]# lspci -v
00:00.0 Host bridge: Intel Corporation 945G/GZ/P/PL Express Memory Controller
Hub (rev 02)
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:02.0 VGA compatible controller: Intel Corporation 945G/GZ Express Integrated
Graphics Controller (rev 02) (prog-if 00 [VGA])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at 48100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 30e0 [size=8]
Memory at 40000000 (32-bit, prefetchable) [size=128M]
Memory at 48180000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [d0] Power Management version 2
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
(rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: 48000000-480fffff
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3
(rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4
(rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express
Port 5 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express
Port 6 (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev
01) (prog-if 00 [UHCI])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 66
I/O ports at 3080 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev
01) (prog-if 00 [UHCI])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 185
I/O ports at 3060 [size=32]
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev
01) (prog-if 00 [UHCI])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 177
I/O ports at 3040 [size=32]
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev
01) (prog-if 00 [UHCI])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 193
I/O ports at 3020 [size=32]
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 66
Memory at 481a0400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01
[Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=06, subordinate=06, sec-latency=32
I/O behind bridge: 00001000-00001fff
Capabilities: [50] #0d [0000]
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
Bridge (rev 01)
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: bus master, medium devsel, latency 0, IRQ 177
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at 30b0 [size=16]
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA
Storage Controller AHCI (rev 01) (prog-if 01 [AHCI 1.0])
Subsystem: Intel Corporation Unknown device 544e
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
I/O ports at 30c8 [size=8]
I/O ports at 30ec [size=4]
I/O ports at 30c0 [size=8]
I/O ports at 30e8 [size=4]
I/O ports at 30a0 [size=16]
Memory at 481a0000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [70] Power Management version 2
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
Subsystem: Intel Corporation DeskTop Board D945GTP
Flags: medium devsel, IRQ 185
I/O ports at 3000 [size=32]
01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet
Controller (Copper) (rev 03)
Subsystem: Intel Corporation Unknown device 3094
Flags: bus master, fast devsel, latency 0, IRQ 74
Memory at 48000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 2000 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
Capabilities: [e0] Express Endpoint IRQ 0
06:03.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART)
(rev 01) (prog-if 02 [16550])
Subsystem: Timedia Technology Co Ltd Unknown device 0002
Flags: stepping, medium devsel, IRQ 185
I/O ports at 1000 [size=32]
[root@tornado ~]#
Reuben
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 20:21 ` Andrew Morton
2006-07-03 20:31 ` 2.6.17-mm6 Reuben Farrelly
1 sibling, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 20:21 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, greg, brice
On Mon, 03 Jul 2006 23:41:42 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
> Allocate Port Service[0000:00:1c.0:pcie0]
> Allocate Port Service[0000:00:1c.0:pcie0]
Turns out that we have a rogue patch coming in from the powerpc tree. This
should fix it, thanks.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/hot-fixes/git-powerpc-revert-bogus-vsnprintf-change.patch
--- a/lib/vsprintf.c~git-powerpc-revert-bogus-vsnprintf-change
+++ a/lib/vsprintf.c
@@ -283,12 +283,12 @@ int vsnprintf(char *buf, size_t size, co
}
str = buf;
- end = buf + size - 1;
+ end = buf + size;
/* Make sure end is always >= buf */
- if (end < buf - 1) {
+ if (end < buf) {
end = ((void *)-1);
- size = end - buf + 1;
+ size = end - buf;
}
for (; *fmt ; ++fmt) {
_
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton
2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 12:29 ` Sergey Vlasov
2006-07-03 17:25 ` 2.6.17-mm6 Jeremy Fitzhardinge
2 siblings, 1 reply; 126+ messages in thread
From: Sergey Vlasov @ 2006-07-03 12:29 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel, greg, brice
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
On Mon, 03 Jul 2006 23:00:34 +1200 Reuben Farrelly wrote:
> Allocate Port Service[0000:00:1c.0:pcie0]
> Allocate Port Service[0000:00:1c.0:pcie0]
> kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register
> things with the same name in the same directory.
These names are truncated - they should end with two hex digits:
snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x",
pci_name(parent), get_descriptor_id(port_type, service_type));
Names were truncated at 18 characters, but sizeof(device->bus_id) is 20
currently, so these names should just fit there. I see that snprintf()
was changed recently - maybe there is some off-by-one bug there?
And if you want, you can blame me for such long names:
commit 8c9ad508c8737ca46a4c55b1062d159b86f7cee2
Author: Sergey Vlasov <vsu@altlinux.ru>
Date: Mon Nov 14 20:30:50 2005 +0300
[PATCH] PCIE: make bus_id for PCI Express devices unique
The bus_id string must be unique for all devices of that bus in the
system, not just for devices with the same parent - otherwise multiple
symlinks with identical names appear in /sys/bus/pci_express/devices.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 467a4ce..e4e5f1e 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -238,8 +238,8 @@ static void pcie_device_init(struct pci_
device->driver = NULL;
device->driver_data = NULL;
device->release = release_pcie_device; /* callback to free pcie dev */
- sprintf(&device->bus_id[0], "pcie%02x",
- get_descriptor_id(port_type, service_type));
+ snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x",
+ pci_name(parent), get_descriptor_id(port_type, service_type));
device->parent = &parent->dev;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov
@ 2006-07-03 17:25 ` Jeremy Fitzhardinge
2006-07-03 19:01 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Jeremy Fitzhardinge @ 2006-07-03 17:25 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel, greg, brice
Sergey Vlasov wrote:
> These names are truncated - they should end with two hex digits:
>
> snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x",
> pci_name(parent), get_descriptor_id(port_type, service_type));
>
> Names were truncated at 18 characters, but sizeof(device->bus_id) is 20
> currently, so these names should just fit there. I see that snprintf()
> was changed recently - maybe there is some off-by-one bug there?
>
There was for a while, but it should be OK in -mm6. Perhaps there's a
stray patch hanging around in this kernel?
J
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 17:25 ` 2.6.17-mm6 Jeremy Fitzhardinge
@ 2006-07-03 19:01 ` Andrew Morton
0 siblings, 0 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 19:01 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: vsu, reuben-lkml, linux-kernel, greg, brice
On Mon, 03 Jul 2006 10:25:45 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Sergey Vlasov wrote:
> > These names are truncated - they should end with two hex digits:
> >
> > snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x",
> > pci_name(parent), get_descriptor_id(port_type, service_type));
> >
> > Names were truncated at 18 characters, but sizeof(device->bus_id) is 20
> > currently, so these names should just fit there. I see that snprintf()
> > was changed recently - maybe there is some off-by-one bug there?
> >
Darnit, I was staring at the wrong code so much that I never even noticed that.
> There was for a while, but it should be OK in -mm6. Perhaps there's a
> stray patch hanging around in this kernel?
>
No, it's still wrong.
end = buf + size - 1;
...
end[-1] = '\0';
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-03 12:15 ` Cedric Le Goater
2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
` (12 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Cedric Le Goater @ 2006-07-03 12:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Martin Peschke
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
the statistic infrastructure is required when compiling the ZFCP driver on
zSeries.
thanks,
C.
From: Cedric Le Goater <clg@fr.ibm.com>
Subject: [statistics infrastructure] exploitation zfcp fix
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Cc: Martin Peschke <mp3@de.ibm.com>
---
drivers/scsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
Index: 2.6.17-mm6/drivers/scsi/Kconfig
===================================================================
--- 2.6.17-mm6.orig/drivers/scsi/Kconfig
+++ 2.6.17-mm6/drivers/scsi/Kconfig
@@ -2200,6 +2200,7 @@ config ZFCP
tristate "FCP host bus adapter driver for IBM eServer zSeries"
depends on S390 && QDIO && SCSI
select SCSI_FC_ATTRS
+ select STATISTICS
help
If you want to access SCSI devices attached to your IBM eServer
zSeries by means of Fibre Channel interfaces say Y.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
@ 2006-07-03 12:17 ` Heiko Carstens
2006-07-03 13:08 ` 2.6.17-mm6 Martin Peschke
2006-07-03 13:12 ` 2.6.17-mm6 Cedric Le Goater
0 siblings, 2 replies; 126+ messages in thread
From: Heiko Carstens @ 2006-07-03 12:17 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: Andrew Morton, linux-kernel, Martin Peschke
> the statistic infrastructure is required when compiling the ZFCP driver on
> zSeries.
> ---
> drivers/scsi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: 2.6.17-mm6/drivers/scsi/Kconfig
> ===================================================================
> --- 2.6.17-mm6.orig/drivers/scsi/Kconfig
> +++ 2.6.17-mm6/drivers/scsi/Kconfig
> @@ -2200,6 +2200,7 @@ config ZFCP
> tristate "FCP host bus adapter driver for IBM eServer zSeries"
> depends on S390 && QDIO && SCSI
> select SCSI_FC_ATTRS
> + select STATISTICS
> help
> If you want to access SCSI devices attached to your IBM eServer
> zSeries by means of Fibre Channel interfaces say Y.
That's the wrong approach. We rather need some no-op defines that make
this compile for !CONFIG_STATISTICS. Martin is working on it, I think.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens
@ 2006-07-03 13:08 ` Martin Peschke
2006-07-03 13:12 ` 2.6.17-mm6 Cedric Le Goater
1 sibling, 0 replies; 126+ messages in thread
From: Martin Peschke @ 2006-07-03 13:08 UTC (permalink / raw)
To: Heiko Carstens; +Cc: Cedric Le Goater, Andrew Morton, linux-kernel
Heiko Carstens wrote:
>> the statistic infrastructure is required when compiling the ZFCP driver on
>> zSeries.
>> ---
>> drivers/scsi/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> Index: 2.6.17-mm6/drivers/scsi/Kconfig
>> ===================================================================
>> --- 2.6.17-mm6.orig/drivers/scsi/Kconfig
>> +++ 2.6.17-mm6/drivers/scsi/Kconfig
>> @@ -2200,6 +2200,7 @@ config ZFCP
>> tristate "FCP host bus adapter driver for IBM eServer zSeries"
>> depends on S390 && QDIO && SCSI
>> select SCSI_FC_ATTRS
>> + select STATISTICS
>> help
>> If you want to access SCSI devices attached to your IBM eServer
>> zSeries by means of Fibre Channel interfaces say Y.
>
> That's the wrong approach. We rather need some no-op defines that make
> this compile for !CONFIG_STATISTICS. Martin is working on it, I think.
My fault, sorry.
Heiko is right.
I need to fix include/linux/statistic.h.
I will post the fix tonight.
Martin
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens
2006-07-03 13:08 ` 2.6.17-mm6 Martin Peschke
@ 2006-07-03 13:12 ` Cedric Le Goater
1 sibling, 0 replies; 126+ messages in thread
From: Cedric Le Goater @ 2006-07-03 13:12 UTC (permalink / raw)
To: Heiko Carstens; +Cc: Andrew Morton, linux-kernel, Martin Peschke
Heiko Carstens wrote:
>> the statistic infrastructure is required when compiling the ZFCP driver on
>> zSeries.
>> ---
>> drivers/scsi/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> Index: 2.6.17-mm6/drivers/scsi/Kconfig
>> ===================================================================
>> --- 2.6.17-mm6.orig/drivers/scsi/Kconfig
>> +++ 2.6.17-mm6/drivers/scsi/Kconfig
>> @@ -2200,6 +2200,7 @@ config ZFCP
>> tristate "FCP host bus adapter driver for IBM eServer zSeries"
>> depends on S390 && QDIO && SCSI
>> select SCSI_FC_ATTRS
>> + select STATISTICS
>> help
>> If you want to access SCSI devices attached to your IBM eServer
>> zSeries by means of Fibre Channel interfaces say Y.
>
> That's the wrong approach. We rather need some no-op defines that make
> this compile for !CONFIG_STATISTICS. Martin is working on it, I think.
yes, you're right.
My approach is the shortest path to fix this -mm6 :
statistics-infrastructure-exploitation-zfcp.patch
thanks,
C.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (2 preceding siblings ...)
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
@ 2006-07-03 12:15 ` Cedric Le Goater
2006-07-03 14:09 ` 2.6.17-mm6 Theodore Tso
2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan
` (11 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Cedric Le Goater @ 2006-07-03 12:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Martin Peschke, Theodore Ts'o
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
This patch fixes a minor issue between the statistic infrastructure
patchset and the inode diet patchset.
thanks,
C.
From: Cedric Le Goater <clg@fr.ibm.com>
Subject: [statistics infrastructure] replace inode u.generic_ip with i_private
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Cc: Martin Peschke <mp3@de.ibm.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
---
lib/statistic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: 2.6.17-mm6/lib/statistic.c
===================================================================
--- 2.6.17-mm6.orig/lib/statistic.c
+++ 2.6.17-mm6/lib/statistic.c
@@ -666,7 +666,7 @@ static int statistic_generic_open(struct
struct file *file, struct statistic_interface **interface,
struct statistic_file_private **private)
{
- *interface = inode->u.generic_ip;
+ *interface = inode->i_private;
BUG_ON(!interface);
*private = kzalloc(sizeof(struct statistic_file_private), GFP_KERNEL);
if (unlikely(!*private))
@@ -749,7 +749,7 @@ static ssize_t statistic_generic_write(s
static int statistic_def_close(struct inode *inode, struct file *file)
{
- struct statistic_interface *interface = inode->u.generic_ip;
+ struct statistic_interface *interface = inode->i_private;
struct statistic_file_private *private = file->private_data;
struct sgrb_seg *seg, *seg_nl;
int offset;
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (3 preceding siblings ...)
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
@ 2006-07-03 19:07 ` Alistair John Strachan
2006-07-03 19:37 ` 2.6.17-mm6 Andrew Morton
2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan
` (10 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 19:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 11:03, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17
>-mm6/
Haven't tried an -mm kernel for a while, but I'm getting some linker warnings
(buggy linker)?
[alistair] 20:02 [~] as --version
GNU assembler 2.16.91.0.7 20060317
[alistair] 20:02 [~] gcc --version
gcc (GCC) 4.1.1
SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so
/usr/bin/ld: warning: i386 architecture of input file
`arch/x86_64/ia32/vsyscall-sysenter.o' is incompatible with i386:x86-64
output
SYSCALL arch/x86_64/ia32/vsyscall-syscall.so
/usr/bin/ld: warning: i386 architecture of input file
`arch/x86_64/ia32/vsyscall-syscall.o' is incompatible with i386:x86-64 output
CC kernel/lockdep.o
{standard input}: Assembler messages:
{standard input}:6223: Warning: .space or .fill with negative value, ignored
{standard input}:6682: Warning: .space or .fill with negative value, ignored
{standard input}:7332: Warning: .space or .fill with negative value, ignored
{standard input}:8134: Warning: .space or .fill with negative value, ignored
{standard input}:8305: Warning: .space or .fill with negative value, ignored
LD arch/x86_64/boot/compressed/vmlinux
ld: warning: i386:x86-64 architecture of input file
`arch/x86_64/boot/compressed/head.o' is incompatible with i386 output
I get this last one on mainline too.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 19:37 ` Andrew Morton
2006-07-03 19:43 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 19:37 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel
On Mon, 3 Jul 2006 20:07:11 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17
> >-mm6/
>
> Haven't tried an -mm kernel for a while, but I'm getting some linker warnings
> (buggy linker)?
>
> [alistair] 20:02 [~] as --version
> GNU assembler 2.16.91.0.7 20060317
>
> [alistair] 20:02 [~] gcc --version
> gcc (GCC) 4.1.1
>
> SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so
> /usr/bin/ld: warning: i386 architecture of input file
> `arch/x86_64/ia32/vsyscall-sysenter.o' is incompatible with i386:x86-64
> output
>
> SYSCALL arch/x86_64/ia32/vsyscall-syscall.so
> /usr/bin/ld: warning: i386 architecture of input file
> `arch/x86_64/ia32/vsyscall-syscall.o' is incompatible with i386:x86-64 output
>
> CC kernel/lockdep.o
> {standard input}: Assembler messages:
> {standard input}:6223: Warning: .space or .fill with negative value, ignored
> {standard input}:6682: Warning: .space or .fill with negative value, ignored
> {standard input}:7332: Warning: .space or .fill with negative value, ignored
> {standard input}:8134: Warning: .space or .fill with negative value, ignored
> {standard input}:8305: Warning: .space or .fill with negative value, ignored
>
> LD arch/x86_64/boot/compressed/vmlinux
> ld: warning: i386:x86-64 architecture of input file
> `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output
>
> I get this last one on mainline too.
Perhaps a `make mrproper' is needed?
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 19:37 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 19:43 ` Alistair John Strachan
0 siblings, 0 replies; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 19:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 20:37, Andrew Morton wrote:
[snip]
> > LD arch/x86_64/boot/compressed/vmlinux
> > ld: warning: i386:x86-64 architecture of input file
> > `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output
> >
> > I get this last one on mainline too.
>
> Perhaps a `make mrproper' is needed?
Nah, this was a fresh tree. Did it, tried again, still happening. It's
possible the linker is broken in some way, but I only see this with the
kernel.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (4 preceding siblings ...)
2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 19:27 ` Alistair John Strachan
2006-07-03 19:39 ` 2.6.17-mm6 Andrew Morton
2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki
` (9 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 19:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 11:03, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17
>-mm6/
Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it oopses
horribly. Is there some way to supress an oops flood so I can get a decent
picture of it with vga=extended? Right now I get two useless oopses after the
first (probably useful) one.
The one time I did get it to boot, I get a lockdep problem (possibly already
reported, if so I'm sorry);
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
mount/1095 is trying to acquire lock:
(&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
xfs_ilock+0x67/0xa0
but task is already holding lock:
(&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
xfs_ilock+0x67/0xa0
other info that might help us debug this:
2 locks held by mount/1095:
#0: (&inode->i_mutex){--..}, at: [<ffffffff8026ead5>] mutex_lock+0x25/0x30
#1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
xfs_ilock+0x67/0xa0
stack backtrace:
Call Trace:
[<ffffffff8027479e>] show_trace+0xae/0x280
[<ffffffff80274985>] dump_stack+0x15/0x20
[<ffffffff802afa06>] __lock_acquire+0x936/0xcd0
[<ffffffff802afe28>] lock_acquire+0x88/0xc0
[<ffffffff802abe49>] down_write+0x39/0x50
[<ffffffff80328ef7>] xfs_ilock+0x67/0xa0
[<ffffffff80329b3a>] xfs_iget+0x2da/0x760
[<ffffffff80341804>] xfs_trans_iget+0xc4/0x150
[<ffffffff8032df8e>] xfs_ialloc+0x9e/0x4d0
[<ffffffff803423df>] xfs_dir_ialloc+0x7f/0x2d0
[<ffffffff80348e24>] xfs_create+0x364/0x6d0
[<ffffffff80352e9a>] xfs_vn_mknod+0x16a/0x300
[<ffffffff8035304b>] xfs_vn_create+0xb/0x10
[<ffffffff8023f92d>] vfs_create+0x8d/0xf0
[<ffffffff8021cd42>] open_namei+0x1c2/0x700
[<ffffffff80229e32>] do_filp_open+0x22/0x50
[<ffffffff8021b78a>] do_sys_open+0x5a/0xf0
[<ffffffff80235e5b>] sys_open+0x1b/0x20
[<ffffffff8026894e>] system_call+0x7e/0x83
[<000000337b1ac6e2>]
XFS mounting filesystem sdb1
I'm also getting the same:
kobject_add failed for 0000:00:0b.0:pcie0 with -EEXIST, don't try to register
things with the same name in the same directory.
..that Reuben reported, multiple times.
Otherwise it's all good.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 19:39 ` Andrew Morton
2006-07-03 19:56 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 19:39 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel, Nathan Scott
On Mon, 3 Jul 2006 20:27:21 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17
> >-mm6/
>
> Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it oopses
> horribly. Is there some way to supress an oops flood so I can get a decent
> picture of it with vga=extended? Right now I get two useless oopses after the
> first (probably useful) one.
Try adding `pause_on_oops=100000' to the kernel boot command line.
> The one time I did get it to boot, I get a lockdep problem (possibly already
> reported, if so I'm sorry);
>
> =============================================
> [ INFO: possible recursive locking detected ]
> ---------------------------------------------
> mount/1095 is trying to acquire lock:
> (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> but task is already holding lock:
> (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> other info that might help us debug this:
> 2 locks held by mount/1095:
> #0: (&inode->i_mutex){--..}, at: [<ffffffff8026ead5>] mutex_lock+0x25/0x30
> #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>]
> xfs_ilock+0x67/0xa0
>
> stack backtrace:
>
> Call Trace:
> [<ffffffff8027479e>] show_trace+0xae/0x280
> [<ffffffff80274985>] dump_stack+0x15/0x20
> [<ffffffff802afa06>] __lock_acquire+0x936/0xcd0
> [<ffffffff802afe28>] lock_acquire+0x88/0xc0
> [<ffffffff802abe49>] down_write+0x39/0x50
> [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0
> [<ffffffff80329b3a>] xfs_iget+0x2da/0x760
> [<ffffffff80341804>] xfs_trans_iget+0xc4/0x150
> [<ffffffff8032df8e>] xfs_ialloc+0x9e/0x4d0
> [<ffffffff803423df>] xfs_dir_ialloc+0x7f/0x2d0
> [<ffffffff80348e24>] xfs_create+0x364/0x6d0
> [<ffffffff80352e9a>] xfs_vn_mknod+0x16a/0x300
> [<ffffffff8035304b>] xfs_vn_create+0xb/0x10
> [<ffffffff8023f92d>] vfs_create+0x8d/0xf0
> [<ffffffff8021cd42>] open_namei+0x1c2/0x700
> [<ffffffff80229e32>] do_filp_open+0x22/0x50
> [<ffffffff8021b78a>] do_sys_open+0x5a/0xf0
> [<ffffffff80235e5b>] sys_open+0x1b/0x20
> [<ffffffff8026894e>] system_call+0x7e/0x83
> [<000000337b1ac6e2>]
> XFS mounting filesystem sdb1
That could be deliberate nesting of the same lock in XFS. Or it could be a
false-positive due to an earlier oops.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 19:39 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 19:56 ` Alistair John Strachan
2006-07-03 20:17 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 19:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 20:39, Andrew Morton wrote:
> On Mon, 3 Jul 2006 20:27:21 +0100
>
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.
> > >6.17 -mm6/
> >
> > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it
> > oopses horribly. Is there some way to supress an oops flood so I can get
> > a decent picture of it with vga=extended? Right now I get two useless
> > oopses after the first (probably useful) one.
>
> Try adding `pause_on_oops=100000' to the kernel boot command line.
(Trimmed Nathan)
Helped somewhat, but I'm still missing a bit at the top.
http://devzero.co.uk/~alistair/oops-20060703/
Apologies for the poor quality photos.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 19:56 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 20:17 ` Andrew Morton
2006-07-03 20:36 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 20:17 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel
On Mon, 3 Jul 2006 20:56:28 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Monday 03 July 2006 20:39, Andrew Morton wrote:
> > On Mon, 3 Jul 2006 20:27:21 +0100
> >
> > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.
> > > >6.17 -mm6/
> > >
> > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it
> > > oopses horribly. Is there some way to supress an oops flood so I can get
> > > a decent picture of it with vga=extended? Right now I get two useless
> > > oopses after the first (probably useful) one.
> >
> > Try adding `pause_on_oops=100000' to the kernel boot command line.
>
> (Trimmed Nathan)
>
> Helped somewhat, but I'm still missing a bit at the top.
>
> http://devzero.co.uk/~alistair/oops-20060703/
>
That is irritating. This should get us more info:
--- a/arch/x86_64/kernel/traps.c~a
+++ a/arch/x86_64/kernel/traps.c
@@ -122,12 +122,12 @@ void printk_address(unsigned long addres
symname = kallsyms_lookup(address, &symsize, &offset,
&modname, namebuf);
if (!symname) {
- printk(" [<%016lx>]\n", address);
+ printk(" [<%016lx>] ", address);
return;
}
if (!modname)
modname = delim = "";
- printk(" [<%016lx>] %s%s%s%s+0x%lx/0x%lx\n",
+ printk(" [<%016lx>] %s%s%s%s+0x%lx/0x%lx ",
address, delim, modname, delim, symname, offset, symsize);
}
#else
_
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 20:17 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 20:36 ` Alistair John Strachan
2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 20:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 21:17, Andrew Morton wrote:
> On Mon, 3 Jul 2006 20:56:28 +0100
>
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Monday 03 July 2006 20:39, Andrew Morton wrote:
> > > On Mon, 3 Jul 2006 20:27:21 +0100
> > >
> > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
> > > > >7/2. 6.17 -mm6/
> > > >
> > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times
> > > > it oopses horribly. Is there some way to supress an oops flood so I
> > > > can get a decent picture of it with vga=extended? Right now I get two
> > > > useless oopses after the first (probably useful) one.
> > >
> > > Try adding `pause_on_oops=100000' to the kernel boot command line.
> >
> > (Trimmed Nathan)
> >
> > Helped somewhat, but I'm still missing a bit at the top.
> >
> > http://devzero.co.uk/~alistair/oops-20060703/
>
> That is irritating. This should get us more info:
Indeed, thanks.
Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I still
think I'm missing something at the top, but 3 is the earliest I could snap.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 20:36 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 20:54 ` Andrew Morton
2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 22:10 ` 2.6.17-mm6 Anton Blanchard
0 siblings, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 20:54 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel
On Mon, 3 Jul 2006 21:36:55 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Monday 03 July 2006 21:17, Andrew Morton wrote:
> > On Mon, 3 Jul 2006 20:56:28 +0100
> >
> > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > On Monday 03 July 2006 20:39, Andrew Morton wrote:
> > > > On Mon, 3 Jul 2006 20:27:21 +0100
> > > >
> > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > On Monday 03 July 2006 11:03, Andrew Morton wrote:
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
> > > > > >7/2. 6.17 -mm6/
> > > > >
> > > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times
> > > > > it oopses horribly. Is there some way to supress an oops flood so I
> > > > > can get a decent picture of it with vga=extended? Right now I get two
> > > > > useless oopses after the first (probably useful) one.
> > > >
> > > > Try adding `pause_on_oops=100000' to the kernel boot command line.
> > >
> > > (Trimmed Nathan)
> > >
> > > Helped somewhat, but I'm still missing a bit at the top.
> > >
> > > http://devzero.co.uk/~alistair/oops-20060703/
> >
> > That is irritating. This should get us more info:
>
> Indeed, thanks.
>
> Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I still
> think I'm missing something at the top, but 3 is the earliest I could snap.
>
Getting better.
It would kinda help if pause_on_oops() was actually implemented on x86_64..
--- a/arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit
+++ a/arch/x86_64/kernel/traps.c
@@ -551,11 +551,14 @@ void __kprobes __die(const char * str, s
void die(const char * str, struct pt_regs * regs, long err)
{
- unsigned long flags = oops_begin();
+ unsigned long flags;
+ oops_enter();
+ flags = oops_begin();
handle_BUG(regs);
__die(str, regs, err);
oops_end(flags);
+ oops_exit();
do_exit(SIGSEGV);
}
_
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-03 21:50 ` Alistair John Strachan
2006-07-03 23:31 ` 2.6.17-mm6 Andrew Morton
2006-07-03 22:10 ` 2.6.17-mm6 Anton Blanchard
1 sibling, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-03 21:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 21:54, Andrew Morton wrote:
> On Mon, 3 Jul 2006 21:36:55 +0100
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Monday 03 July 2006 21:17, Andrew Morton wrote:
> > > On Mon, 3 Jul 2006 20:56:28 +0100
> > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > On Monday 03 July 2006 20:39, Andrew Morton wrote:
[snip]
> > > > > Try adding `pause_on_oops=100000' to the kernel boot command line.
> > > >
> > > > (Trimmed Nathan)
> > > >
> > > > Helped somewhat, but I'm still missing a bit at the top.
> > > >
> > > > http://devzero.co.uk/~alistair/oops-20060703/
> > >
> > > That is irritating. This should get us more info:
> >
> > Indeed, thanks.
> >
> > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I
> > still think I'm missing something at the top, but 3 is the earliest I
> > could snap.
>
> Getting better.
>
> It would kinda help if pause_on_oops() was actually implemented on x86_64..
Doesn't help (work?).
[alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6
2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006
[alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6
# testing
title Linux 2.6.17-mm6
root (hd0,0)
kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1
pause_on_oops=100000
I'm fairly sure I booted a kernel with your patch and that should be the right
cmdline flag.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 23:31 ` Andrew Morton
2006-07-04 8:34 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-03 23:31 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel
On Mon, 3 Jul 2006 22:50:02 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Monday 03 July 2006 21:54, Andrew Morton wrote:
> > On Mon, 3 Jul 2006 21:36:55 +0100
> > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > On Monday 03 July 2006 21:17, Andrew Morton wrote:
> > > > On Mon, 3 Jul 2006 20:56:28 +0100
> > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > On Monday 03 July 2006 20:39, Andrew Morton wrote:
> [snip]
> > > > > > Try adding `pause_on_oops=100000' to the kernel boot command line.
> > > > >
> > > > > (Trimmed Nathan)
> > > > >
> > > > > Helped somewhat, but I'm still missing a bit at the top.
> > > > >
> > > > > http://devzero.co.uk/~alistair/oops-20060703/
> > > >
> > > > That is irritating. This should get us more info:
> > >
> > > Indeed, thanks.
> > >
> > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I
> > > still think I'm missing something at the top, but 3 is the earliest I
> > > could snap.
> >
> > Getting better.
> >
> > It would kinda help if pause_on_oops() was actually implemented on x86_64..
>
> Doesn't help (work?).
>
> [alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6
> 2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006
>
> [alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6
> # testing
> title Linux 2.6.17-mm6
> root (hd0,0)
> kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1
> pause_on_oops=100000
>
> I'm fairly sure I booted a kernel with your patch and that should be the right
> cmdline flag.
>
OK, x86_64 is significantly different from x86 in that area (better). Have
a tested version...
diff -puN arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit arch/x86_64/kernel/traps.c
--- a/arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit
+++ a/arch/x86_64/kernel/traps.c
@@ -551,11 +551,14 @@ void __kprobes __die(const char * str, s
void die(const char * str, struct pt_regs * regs, long err)
{
- unsigned long flags = oops_begin();
+ unsigned long flags;
+ oops_enter();
+ flags = oops_begin();
handle_BUG(regs);
__die(str, regs, err);
oops_end(flags);
+ oops_exit();
do_exit(SIGSEGV);
}
diff -puN arch/x86_64/mm/fault.c~x86_64-wire-up-oops_enter-oops_exit arch/x86_64/mm/fault.c
--- a/arch/x86_64/mm/fault.c~x86_64-wire-up-oops_enter-oops_exit
+++ a/arch/x86_64/mm/fault.c
@@ -261,9 +261,11 @@ int unhandled_signal(struct task_struct
static noinline void pgtable_bad(unsigned long address, struct pt_regs *regs,
unsigned long error_code)
{
- unsigned long flags = oops_begin();
+ unsigned long flags;
struct task_struct *tsk;
+ oops_enter();
+ flags = oops_begin();
printk(KERN_ALERT "%s: Corrupted page table at address %lx\n",
current->comm, address);
dump_pagetable(address);
@@ -273,6 +275,7 @@ static noinline void pgtable_bad(unsigne
tsk->thread.error_code = error_code;
__die("Bad pagetable", regs, error_code);
oops_end(flags);
+ oops_exit();
do_exit(SIGKILL);
}
@@ -562,6 +565,7 @@ no_context:
* terminate things with extreme prejudice.
*/
+ oops_enter();
flags = oops_begin();
if (address < PAGE_SIZE)
@@ -578,6 +582,7 @@ no_context:
/* Executive summary in case the body of the oops scrolled away */
printk(KERN_EMERG "CR2: %016lx\n", address);
oops_end(flags);
+ oops_exit();
do_exit(SIGKILL);
/*
_
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-03 23:31 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-04 8:34 ` Alistair John Strachan
2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-04 8:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Tuesday 04 July 2006 00:31, Andrew Morton wrote:
[snip]
> > > > > > Helped somewhat, but I'm still missing a bit at the top.
> > > > > >
> > > > > > http://devzero.co.uk/~alistair/oops-20060703/
> > > > >
> > > > > That is irritating. This should get us more info:
> > > >
> > > > Indeed, thanks.
> > > >
> > > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots.
> > > > I still think I'm missing something at the top, but 3 is the earliest
> > > > I could snap.
> > >
> > > Getting better.
> > >
> > > It would kinda help if pause_on_oops() was actually implemented on
> > > x86_64..
> >
> > Doesn't help (work?).
> >
> > [alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6
> > 2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006
> >
> > [alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6
> > # testing
> > title Linux 2.6.17-mm6
> > root (hd0,0)
> > kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1
> > pause_on_oops=100000
> >
> > I'm fairly sure I booted a kernel with your patch and that should be the
> > right cmdline flag.
>
> OK, x86_64 is significantly different from x86 in that area (better). Have
> a tested version...
This one worked, thanks. Try the same URL again, I've uploaded two better
shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses
that interchange every couple of boots, so I've included both ;-)
I suggest Andi picks up that debugging patch, it worked for me.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-04 8:34 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-04 8:49 ` Andrew Morton
2006-07-04 16:28 ` 2.6.17-mm6 Alistair John Strachan
2006-07-05 20:37 ` 2.6.17-mm6 john stultz
0 siblings, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-04 8:49 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-kernel, Greg KH, john stultz
On Tue, 4 Jul 2006 09:34:14 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > a tested version...
>
> This one worked, thanks. Try the same URL again, I've uploaded two better
> shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses
> that interchange every couple of boots, so I've included both ;-)
OK, that's more like it. Thanks again.
http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
People cc'ed. Help!
Can you send the .config please?
> I suggest Andi picks up that debugging patch, it worked for me.
He'll be hearing from me ;)
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-04 16:28 ` Alistair John Strachan
2006-07-05 20:37 ` 2.6.17-mm6 john stultz
1 sibling, 0 replies; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-04 16:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Greg KH, john stultz
On Tuesday 04 July 2006 09:49, Andrew Morton wrote:
[snip]
> Can you send the .config please?
Uploaded dmesg from a successful boot (slightly chopped, sorry), and the
config for this kernel:
http://devzero.co.uk/~alistair/oops-20060703/config-2.6.17-mm6
http://devzero.co.uk/~alistair/oops-20060703/dmesg
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton
2006-07-04 16:28 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-05 20:37 ` john stultz
2006-07-05 20:46 ` 2.6.17-mm6 Greg KH
1 sibling, 1 reply; 126+ messages in thread
From: john stultz @ 2006-07-05 20:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alistair John Strachan, linux-kernel, Greg KH
On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> On Tue, 4 Jul 2006 09:34:14 +0100
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > a tested version...
> >
> > This one worked, thanks. Try the same URL again, I've uploaded two better
> > shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses
> > that interchange every couple of boots, so I've included both ;-)
>
> OK, that's more like it. Thanks again.
>
> http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
>
> People cc'ed. Help!
Hmmm. No clue on this one from just looking at it.
Greg, do you see anything wrong with the way I'm registering the
timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()?
It looks the same as the other users to me.
I'll look over the config and see if anything sticks out.
thanks
-john
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 20:37 ` 2.6.17-mm6 john stultz
@ 2006-07-05 20:46 ` Greg KH
2006-07-05 22:32 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Greg KH @ 2006-07-05 20:46 UTC (permalink / raw)
To: john stultz; +Cc: Andrew Morton, Alistair John Strachan, linux-kernel
On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > On Tue, 4 Jul 2006 09:34:14 +0100
> > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > a tested version...
> > >
> > > This one worked, thanks. Try the same URL again, I've uploaded two better
> > > shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses
> > > that interchange every couple of boots, so I've included both ;-)
> >
> > OK, that's more like it. Thanks again.
> >
> > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> >
> > People cc'ed. Help!
>
> Hmmm. No clue on this one from just looking at it.
>
> Greg, do you see anything wrong with the way I'm registering the
> timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()?
> It looks the same as the other users to me.
At first glance, no, it looks sane to me.
Are you sure you aren't registering two things with the same name
somehow?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 20:46 ` 2.6.17-mm6 Greg KH
@ 2006-07-05 22:32 ` Alistair John Strachan
2006-07-06 17:31 ` 2.6.17-mm6 john stultz
0 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-05 22:32 UTC (permalink / raw)
To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel
On Wednesday 05 July 2006 21:46, Greg KH wrote:
> On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > On Tue, 4 Jul 2006 09:34:14 +0100
> > >
> > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > a tested version...
> > > >
> > > > This one worked, thanks. Try the same URL again, I've uploaded two
> > > > better shots 6,7 that capture the first oops. Unfortunately, I have a
> > > > pair of oopses that interchange every couple of boots, so I've
> > > > included both ;-)
> > >
> > > OK, that's more like it. Thanks again.
> > >
> > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > >
> > > People cc'ed. Help!
> >
> > Hmmm. No clue on this one from just looking at it.
> >
> > Greg, do you see anything wrong with the way I'm registering the
> > timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()?
> > It looks the same as the other users to me.
>
> At first glance, no, it looks sane to me.
>
> Are you sure you aren't registering two things with the same name
> somehow?
Whatever it is, it doesn't happen every time. Sometimes the kernel boots.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 22:32 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-06 17:31 ` john stultz
2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 2 replies; 126+ messages in thread
From: john stultz @ 2006-07-06 17:31 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: Greg KH, Andrew Morton, linux-kernel
On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote:
> On Wednesday 05 July 2006 21:46, Greg KH wrote:
> > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > > On Tue, 4 Jul 2006 09:34:14 +0100
> > > >
> > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > > a tested version...
> > > > >
> > > > > This one worked, thanks. Try the same URL again, I've uploaded two
> > > > > better shots 6,7 that capture the first oops. Unfortunately, I have a
> > > > > pair of oopses that interchange every couple of boots, so I've
> > > > > included both ;-)
> > > >
> > > > OK, that's more like it. Thanks again.
> > > >
> > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > > >
> > > > People cc'ed. Help!
> > >
> > > Hmmm. No clue on this one from just looking at it.
> > >
> > > Greg, do you see anything wrong with the way I'm registering the
> > > timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()?
> > > It looks the same as the other users to me.
> >
> > At first glance, no, it looks sane to me.
> >
> > Are you sure you aren't registering two things with the same name
> > somehow?
Looking at it, I don't see how that could happen.
> Whatever it is, it doesn't happen every time. Sometimes the kernel boots.
Odd. Does this happen w/ 2.6.18-rc1?
thanks
-john
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 17:31 ` 2.6.17-mm6 john stultz
@ 2006-07-06 19:06 ` Alistair John Strachan
2006-07-06 19:16 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan
1 sibling, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-06 19:06 UTC (permalink / raw)
To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel
On Thursday 06 July 2006 18:31, john stultz wrote:
> On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote:
> > On Wednesday 05 July 2006 21:46, Greg KH wrote:
> > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > > > On Tue, 4 Jul 2006 09:34:14 +0100
> > > > >
> > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > > > a tested version...
> > > > > >
> > > > > > This one worked, thanks. Try the same URL again, I've uploaded
> > > > > > two better shots 6,7 that capture the first oops. Unfortunately,
> > > > > > I have a pair of oopses that interchange every couple of boots,
> > > > > > so I've included both ;-)
> > > > >
> > > > > OK, that's more like it. Thanks again.
> > > > >
> > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > > > >
> > > > > People cc'ed. Help!
> > > >
> > > > Hmmm. No clue on this one from just looking at it.
> > > >
> > > > Greg, do you see anything wrong with the way I'm registering the
> > > > timekeeping .resume hook in
> > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the
> > > > other users to me.
> > >
> > > At first glance, no, it looks sane to me.
> > >
> > > Are you sure you aren't registering two things with the same name
> > > somehow?
>
> Looking at it, I don't see how that could happen.
>
> > Whatever it is, it doesn't happen every time. Sometimes the kernel boots.
>
> Odd. Does this happen w/ 2.6.18-rc1?
Seems to. First time it booted okay, but wouldn't let me log in (worse
than -mm), I got the following:
http://devzero.co.uk/~alistair/oops-20060703/lockup1.jpg
Second time it didn't boot properly, with a similar oops to the others.
I used the following config for 2.6.18-rc1, which should be very similar, but
not identical.
http://devzero.co.uk/~alistair/oops-20060703/config-2.6.18-rc1
I'm about to try a kernel without the lockdep stuff, then I'm going to start
bisection pain.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-06 19:16 ` Alistair John Strachan
0 siblings, 0 replies; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-06 19:16 UTC (permalink / raw)
To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel
On Thursday 06 July 2006 20:06, Alistair John Strachan wrote:
> I'm about to try a kernel without the lockdep stuff, then I'm going to
> start bisection pain.
And it doesn't make any difference; it really does look like a bug in
something else.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 17:31 ` 2.6.17-mm6 john stultz
2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-06 20:02 ` Alistair John Strachan
2006-07-06 20:11 ` 2.6.17-mm6 Greg KH
1 sibling, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-06 20:02 UTC (permalink / raw)
To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel
On Thursday 06 July 2006 18:31, john stultz wrote:
> On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote:
> > On Wednesday 05 July 2006 21:46, Greg KH wrote:
> > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > > > On Tue, 4 Jul 2006 09:34:14 +0100
> > > > >
> > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > > > a tested version...
> > > > > >
> > > > > > This one worked, thanks. Try the same URL again, I've uploaded
> > > > > > two better shots 6,7 that capture the first oops. Unfortunately,
> > > > > > I have a pair of oopses that interchange every couple of boots,
> > > > > > so I've included both ;-)
> > > > >
> > > > > OK, that's more like it. Thanks again.
> > > > >
> > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > > > >
> > > > > People cc'ed. Help!
> > > >
> > > > Hmmm. No clue on this one from just looking at it.
> > > >
> > > > Greg, do you see anything wrong with the way I'm registering the
> > > > timekeeping .resume hook in
> > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the
> > > > other users to me.
> > >
> > > At first glance, no, it looks sane to me.
> > >
> > > Are you sure you aren't registering two things with the same name
> > > somehow?
>
> Looking at it, I don't see how that could happen.
I don't think it's John's code. I commented out the sysfs registration code
from timekeeping_init_device() and the kernel gets further, where it crashes
on kmem_cache_create. SLAB also complains about "losing its name" and
being "of size 0".
This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be
anything you've changed recently? I considered bisectioning -mm, but there's
been a lot of RAID problems and I'm using RAID5.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-06 20:11 ` Greg KH
2006-07-07 20:48 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Greg KH @ 2006-07-06 20:11 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: john stultz, Andrew Morton, linux-kernel
On Thu, Jul 06, 2006 at 09:02:50PM +0100, Alistair John Strachan wrote:
> On Thursday 06 July 2006 18:31, john stultz wrote:
> > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote:
> > > On Wednesday 05 July 2006 21:46, Greg KH wrote:
> > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > > > > On Tue, 4 Jul 2006 09:34:14 +0100
> > > > > >
> > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > > > > a tested version...
> > > > > > >
> > > > > > > This one worked, thanks. Try the same URL again, I've uploaded
> > > > > > > two better shots 6,7 that capture the first oops. Unfortunately,
> > > > > > > I have a pair of oopses that interchange every couple of boots,
> > > > > > > so I've included both ;-)
> > > > > >
> > > > > > OK, that's more like it. Thanks again.
> > > > > >
> > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > > > > >
> > > > > > People cc'ed. Help!
> > > > >
> > > > > Hmmm. No clue on this one from just looking at it.
> > > > >
> > > > > Greg, do you see anything wrong with the way I'm registering the
> > > > > timekeeping .resume hook in
> > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the
> > > > > other users to me.
> > > >
> > > > At first glance, no, it looks sane to me.
> > > >
> > > > Are you sure you aren't registering two things with the same name
> > > > somehow?
> >
> > Looking at it, I don't see how that could happen.
>
> I don't think it's John's code. I commented out the sysfs registration code
> from timekeeping_init_device() and the kernel gets further, where it crashes
> on kmem_cache_create. SLAB also complains about "losing its name" and
> being "of size 0".
>
> This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be
> anything you've changed recently? I considered bisectioning -mm, but there's
> been a lot of RAID problems and I'm using RAID5.
Please bisect 2.6.18-rc1 if you have git, as the problem is there, and
would be good to track down.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 20:11 ` 2.6.17-mm6 Greg KH
@ 2006-07-07 20:48 ` Alistair John Strachan
2006-07-08 16:02 ` 2.6.17-mm6 Alistair John Strachan
0 siblings, 1 reply; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-07 20:48 UTC (permalink / raw)
To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel
On Thursday 06 July 2006 21:11, Greg KH wrote:
> On Thu, Jul 06, 2006 at 09:02:50PM +0100, Alistair John Strachan wrote:
> > On Thursday 06 July 2006 18:31, john stultz wrote:
> > > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote:
> > > > On Wednesday 05 July 2006 21:46, Greg KH wrote:
> > > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote:
> > > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote:
> > > > > > > On Tue, 4 Jul 2006 09:34:14 +0100
> > > > > > >
> > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > > > > > > a tested version...
> > > > > > > >
> > > > > > > > This one worked, thanks. Try the same URL again, I've
> > > > > > > > uploaded two better shots 6,7 that capture the first oops.
> > > > > > > > Unfortunately, I have a pair of oopses that interchange every
> > > > > > > > couple of boots, so I've included both ;-)
> > > > > > >
> > > > > > > OK, that's more like it. Thanks again.
> > > > > > >
> > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg
> > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg
> > > > > > >
> > > > > > > People cc'ed. Help!
> > > > > >
> > > > > > Hmmm. No clue on this one from just looking at it.
> > > > > >
> > > > > > Greg, do you see anything wrong with the way I'm registering the
> > > > > > timekeeping .resume hook in
> > > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as
> > > > > > the other users to me.
> > > > >
> > > > > At first glance, no, it looks sane to me.
> > > > >
> > > > > Are you sure you aren't registering two things with the same name
> > > > > somehow?
> > >
> > > Looking at it, I don't see how that could happen.
> >
> > I don't think it's John's code. I commented out the sysfs registration
> > code from timekeeping_init_device() and the kernel gets further, where it
> > crashes on kmem_cache_create. SLAB also complains about "losing its name"
> > and being "of size 0".
> >
> > This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be
> > anything you've changed recently? I considered bisectioning -mm, but
> > there's been a lot of RAID problems and I'm using RAID5.
>
> Please bisect 2.6.18-rc1 if you have git, as the problem is there, and
> would be good to track down.
I tried this, but it's extremely difficult when the kernel boots successfully
one every four times. I've already been thrown off the scent twice, bringing
my bisection count to 25..
I think I'll try an allnoconfig on this machine, hopefully that will boot,
then I just start enabling things again until it breaks.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 20:48 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-08 16:02 ` Alistair John Strachan
0 siblings, 0 replies; 126+ messages in thread
From: Alistair John Strachan @ 2006-07-08 16:02 UTC (permalink / raw)
To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel
On Friday 07 July 2006 21:48, Alistair John Strachan wrote:
[snip]
> > > I don't think it's John's code. I commented out the sysfs registration
> > > code from timekeeping_init_device() and the kernel gets further, where
> > > it crashes on kmem_cache_create. SLAB also complains about "losing its
> > > name" and being "of size 0".
> > >
> > > This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it
> > > be anything you've changed recently? I considered bisectioning -mm, but
> > > there's been a lot of RAID problems and I'm using RAID5.
> >
> > Please bisect 2.6.18-rc1 if you have git, as the problem is there, and
> > would be good to track down.
>
> I tried this, but it's extremely difficult when the kernel boots
> successfully one every four times. I've already been thrown off the scent
> twice, bringing my bisection count to 25..
>
> I think I'll try an allnoconfig on this machine, hopefully that will boot,
> then I just start enabling things again until it breaks.
Sorry, this turned out to be my fault.
GCC had just recently been upgraded to 4.1.1, which apparently silently
generates bad kernels with the version of H. J. Lu's binutils I had
installed. I figured it out when going back to 2.6.17 didn't help. Why the
crashes were sporadic I will never truly understand.
Going back to GNU binutils 2.17 and rebuilding GCC 4.1.1 fixed it. At least I
learnt how to use Git, which is a truly superb tool. I'm now happily
running -mm6.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton
2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-03 22:10 ` Anton Blanchard
1 sibling, 0 replies; 126+ messages in thread
From: Anton Blanchard @ 2006-07-03 22:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alistair John Strachan, linux-kernel
> Getting better.
>
> It would kinda help if pause_on_oops() was actually implemented on x86_64..
Now you've made me look, it seems x86 has undergone major surgery to its
oops path that most other architectures havent picked up yet.
Anton
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (5 preceding siblings ...)
2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan
@ 2006-07-04 19:53 ` Rafael J. Wysocki
2006-07-04 20:01 ` 2.6.17-mm6 Arjan van de Ven
2006-07-05 21:43 ` 2.6.17-mm6 J.A. Magallón
` (8 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Rafael J. Wysocki @ 2006-07-04 19:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Monday 03 July 2006 12:03, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
>
> - A major update to the e1000 driver.
>
> - 1394 updates
Just found this in dmesg:
=================================
[ INFO: inconsistent lock state ]
---------------------------------
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes:
(&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
{in-hardirq-W} state was registered at:
[<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0
[<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60
[<ffffffff80408c25>] skb_queue_tail+0x25/0x60
[<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394]
[<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394]
[<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394]
[<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394]
[<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394]
[<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394]
[<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70
[<ffffffff80264dd4>] handle_level_irq+0xc4/0x130
[<ffffffff8020c762>] do_IRQ+0x112/0x130
[<ffffffff80209d90>] common_interrupt+0x64/0x65
irq event stamp: 4280
hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37
hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67
softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0
softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50
other info that might help us debug this:
no locks held by nscd/4929.
stack backtrace:
Call Trace:
[<ffffffff8020ab9f>] show_trace+0x9f/0x240
[<ffffffff8020af75>] dump_stack+0x15/0x20
[<ffffffff80249e52>] print_usage_bug+0x272/0x290
[<ffffffff8024a0d7>] mark_lock+0x267/0x5f0
[<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10
[<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0
[<ffffffff804764f4>] _spin_lock_bh+0x34/0x50
[<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
[<ffffffff80457359>] inet_ioctl+0x69/0x70
[<ffffffff804033ac>] sock_ioctl+0x22c/0x270
[<ffffffff802a32b1>] do_ioctl+0x31/0xa0
[<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0
[<ffffffff802a366a>] sys_ioctl+0x6a/0xa0
[<ffffffff8020985a>] system_call+0x7e/0x83
[<00002b2d76ab98a9>]
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki
@ 2006-07-04 20:01 ` Arjan van de Ven
2006-07-05 10:27 ` 2.6.17-mm6 Stefan Richter
0 siblings, 1 reply; 126+ messages in thread
From: Arjan van de Ven @ 2006-07-04 20:01 UTC (permalink / raw)
To: netdev, Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel
this is one for the networking people, and thus netdev
On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote:
> On Monday 03 July 2006 12:03, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
> >
> > - A major update to the e1000 driver.
> >
> > - 1394 updates
>
> Just found this in dmesg:
>
> =================================
> [ INFO: inconsistent lock state ]
> ---------------------------------
> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes:
> (&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
> {in-hardirq-W} state was registered at:
> [<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0
> [<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60
> [<ffffffff80408c25>] skb_queue_tail+0x25/0x60
ok so skb_queue_lock is used in a hardirq context
> [<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394]
> [<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394]
> [<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394]
> [<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394]
> [<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394]
> [<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394]
> [<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70
> [<ffffffff80264dd4>] handle_level_irq+0xc4/0x130
> [<ffffffff8020c762>] do_IRQ+0x112/0x130
> [<ffffffff80209d90>] common_interrupt+0x64/0x65
> irq event stamp: 4280
> hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37
> hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67
> softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0
> softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50
>
> other info that might help us debug this:
> no locks held by nscd/4929.
>
> stack backtrace:
>
> Call Trace:
> [<ffffffff8020ab9f>] show_trace+0x9f/0x240
> [<ffffffff8020af75>] dump_stack+0x15/0x20
> [<ffffffff80249e52>] print_usage_bug+0x272/0x290
> [<ffffffff8024a0d7>] mark_lock+0x267/0x5f0
> [<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10
> [<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0
> [<ffffffff804764f4>] _spin_lock_bh+0x34/0x50
> [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
yet udp_ioctl takes it only for _bh
> [<ffffffff80457359>] inet_ioctl+0x69/0x70
> [<ffffffff804033ac>] sock_ioctl+0x22c/0x270
> [<ffffffff802a32b1>] do_ioctl+0x31/0xa0
> [<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0
> [<ffffffff802a366a>] sys_ioctl+0x6a/0xa0
> [<ffffffff8020985a>] system_call+0x7e/0x83
> [<00002b2d76ab98a9>]
is this a real scenario, or is this a case of "firewire is special and
needs it's own rules"?
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-04 20:01 ` 2.6.17-mm6 Arjan van de Ven
@ 2006-07-05 10:27 ` Stefan Richter
2006-07-05 10:36 ` 2.6.17-mm6 Stefan Richter
0 siblings, 1 reply; 126+ messages in thread
From: Stefan Richter @ 2006-07-05 10:27 UTC (permalink / raw)
To: Arjan van de Ven
Cc: netdev, Rafael J. Wysocki, Andrew Morton, linux-kernel,
Ingo Molnar
On 7/4/2006 10:01 PM, Arjan van de Ven wrote:
> this is one for the networking people, and thus netdev
It's actually ieee1394 using net infrastructure for purposes which ar
unrelated to networking.
Furthermore...
> On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote:
>> On Monday 03 July 2006 12:03, Andrew Morton wrote:
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>> >
>> > - A major update to the e1000 driver.
>> > - 1394 updates
...I believe it is unrelated to the 1394 updates new to -mm6.
>> Just found this in dmesg:
>>
>> =================================
>> [ INFO: inconsistent lock state ]
>> ---------------------------------
>> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
>> nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes:
>> (&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
>> {in-hardirq-W} state was registered at:
>> [<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0
>> [<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60
>> [<ffffffff80408c25>] skb_queue_tail+0x25/0x60
>
> ok so skb_queue_lock is used in a hardirq context
>
>> [<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394]
>> [<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394]
>> [<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394]
>> [<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394]
>> [<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394]
>> [<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394]
>> [<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70
>> [<ffffffff80264dd4>] handle_level_irq+0xc4/0x130
>> [<ffffffff8020c762>] do_IRQ+0x112/0x130
>> [<ffffffff80209d90>] common_interrupt+0x64/0x65
>> irq event stamp: 4280
>> hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37
>> hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67
>> softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0
>> softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50
>>
>> other info that might help us debug this:
>> no locks held by nscd/4929.
>>
>> stack backtrace:
>>
>> Call Trace:
>> [<ffffffff8020ab9f>] show_trace+0x9f/0x240
>> [<ffffffff8020af75>] dump_stack+0x15/0x20
>> [<ffffffff80249e52>] print_usage_bug+0x272/0x290
>> [<ffffffff8024a0d7>] mark_lock+0x267/0x5f0
>> [<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10
>> [<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0
>> [<ffffffff804764f4>] _spin_lock_bh+0x34/0x50
>> [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0
>
> yet udp_ioctl takes it only for _bh
>
>> [<ffffffff80457359>] inet_ioctl+0x69/0x70
>> [<ffffffff804033ac>] sock_ioctl+0x22c/0x270
>> [<ffffffff802a32b1>] do_ioctl+0x31/0xa0
>> [<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0
>> [<ffffffff802a366a>] sys_ioctl+0x6a/0xa0
>> [<ffffffff8020985a>] system_call+0x7e/0x83
>> [<00002b2d76ab98a9>]
>
> is this a real scenario, or is this a case of "firewire is special and
> needs it's own rules"?
Well, firewire is special, but that should already be addressed by this
patch: "lockdep: annotate ieee1394 skb-queue-head locking"
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d378834840907326ac9d448056d957d13cc3718f
Why is there still a lockdep warning?
(Ieee1394 core's usage of the skb_* API is entirely unrelated to
networking; even if eth1394 was used.)
--
Stefan Richter
-=====-=-==- -=== --=-=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 10:27 ` 2.6.17-mm6 Stefan Richter
@ 2006-07-05 10:36 ` Stefan Richter
2006-07-05 11:13 ` 2.6.17-mm6 Ingo Molnar
0 siblings, 1 reply; 126+ messages in thread
From: Stefan Richter @ 2006-07-05 10:36 UTC (permalink / raw)
To: Arjan van de Ven
Cc: netdev, Rafael J. Wysocki, Andrew Morton, linux-kernel,
Ingo Molnar
I wrote:
> (Ieee1394 core's usage of the skb_* API is entirely unrelated to
> networking; even if eth1394 was used.)
PS:
I wonder if it wouldn't be better to migrate ieee1394 core away from
skb_*. I didn't look thoroughly at it yet but the benefit of using this
API appears quite low to me.
We use it to keep track of IEEE 1394 transactions [ = outgoing request
&& (incoming response || expiry)], with completion of transactions often
in-order due to mostly single-threaded usage, but sometimes out-of-order
(may happen regardless of multithreaded or single-threaded usage).
--
Stefan Richter
-=====-=-==- -=== --=-=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 10:36 ` 2.6.17-mm6 Stefan Richter
@ 2006-07-05 11:13 ` Ingo Molnar
0 siblings, 0 replies; 126+ messages in thread
From: Ingo Molnar @ 2006-07-05 11:13 UTC (permalink / raw)
To: Stefan Richter
Cc: Arjan van de Ven, netdev, Rafael J. Wysocki, Andrew Morton,
linux-kernel
* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> I wrote:
> > (Ieee1394 core's usage of the skb_* API is entirely unrelated to
> > networking; even if eth1394 was used.)
>
> PS:
> I wonder if it wouldn't be better to migrate ieee1394 core away from
> skb_*. I didn't look thoroughly at it yet but the benefit of using
> this API appears quite low to me.
yeah, it seems to be the wrong abstraction to use. It's also more
expensive than necessary: e.g. skb-heads have a qlen field that is
maintained in every list op - but the ieee1394 code does not make use of
the queue-length information. Using list.h plus a spinlock should do the
trick?
Ingo
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (6 preceding siblings ...)
2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki
@ 2006-07-05 21:43 ` J.A. Magallón
2006-07-05 22:56 ` 2.6.17-mm6 Andrew Morton
[not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>
` (7 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-05 21:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
>
> - A major update to the e1000 driver.
>
Doesn't find my root drive :(.
Its a SATA drive, on PIIX.
Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know
when did this broke. Under -mm1, the disk is this:
libata version 1.30 loaded.
ata_piix 0000:00:1f.2: version 1.10tj1ac3
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi0 : ata_piix
ata1: ENTER, pcs=0x13 base=0
ata1: LEAVE, pcs=0x13 present_mask=0x1
ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata1.00: configured for UDMA/133
scsi1 : ata_piix
ata2: ENTER, pcs=0x13 base=2
ata2: LEAVE, pcs=0x11 present_mask=0x0
ata2: SATA port has no device.
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
sd 0:0:0:0: Attached scsi disk sda
With -mm6, the kernel doesn't find it. I get this on boot:
kinit: try_name sda,1 = dev(8,1)
kinit: name_to_dev_t(/dev/sda1) = dev(8.1)
kinit: root_dev = dev(8,1)
kinit: failed to identify filesystem /dev/root, trying all
kinit: trying to mount /dev/root on /root with type ext3
kinit: Cannot open root device dev(8,1)
I have tried to get this message from -mm1, but could not get it in any log.
But... I remember to see that the boot message is like:
kinit: try_name sda,1 = sda1(8,1)
^^^^
I have verified I built -mm6 with ext3,sata-piix and so on, all builtin.
Any ideas ?
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 21:43 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-05 22:56 ` Andrew Morton
2006-07-05 23:57 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-05 22:56 UTC (permalink / raw)
To: J.A. Magallón ; +Cc: linux-kernel
"J.A. Magallón" <jamagallon@ono.com> wrote:
>
> On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
> >
> > - A major update to the e1000 driver.
> >
>
> Doesn't find my root drive :(.
>
> Its a SATA drive, on PIIX.
> Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know
> when did this broke. Under -mm1, the disk is this:
>
> libata version 1.30 loaded.
> ata_piix 0000:00:1f.2: version 1.10tj1ac3
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> scsi0 : ata_piix
> ata1: ENTER, pcs=0x13 base=0
> ata1: LEAVE, pcs=0x13 present_mask=0x1
> ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
> ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
> ata1.00: configured for UDMA/133
> scsi1 : ata_piix
> ata2: ENTER, pcs=0x13 base=2
> ata2: LEAVE, pcs=0x11 present_mask=0x0
> ata2: SATA port has no device.
> Vendor: ATA Model: ST3200822AS Rev: 3.01
> Type: Direct-Access ANSI SCSI revision: 05
> SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> sda: sda1 sda2 sda3
> sd 0:0:0:0: Attached scsi disk sda
>
> With -mm6, the kernel doesn't find it. I get this on boot:
>
> kinit: try_name sda,1 = dev(8,1)
> kinit: name_to_dev_t(/dev/sda1) = dev(8.1)
> kinit: root_dev = dev(8,1)
> kinit: failed to identify filesystem /dev/root, trying all
> kinit: trying to mount /dev/root on /root with type ext3
> kinit: Cannot open root device dev(8,1)
>
> I have tried to get this message from -mm1, but could not get it in any log.
> But... I remember to see that the boot message is like:
>
> kinit: try_name sda,1 = sda1(8,1)
> ^^^^
> I have verified I built -mm6 with ext3,sata-piix and so on, all builtin.
>
Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch?
Also, the full dmesg from 2.6.17-mm6 would help, thanks.
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 22:56 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-05 23:57 ` J.A. Magallón
2006-07-06 0:02 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-05 23:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Wed, 5 Jul 2006 15:56:02 -0700, Andrew Morton <akpm@osdl.org> wrote:
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> > >
> > >
> > > - A major update to the e1000 driver.
> > >
> >
> > Doesn't find my root drive :(.
> >
> > Its a SATA drive, on PIIX.
> > Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know
> > when did this broke. Under -mm1, the disk is this:
> >
> > libata version 1.30 loaded.
> > ata_piix 0000:00:1f.2: version 1.10tj1ac3
> > ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> > PCI: Setting latency timer of device 0000:00:1f.2 to 64
> > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> > scsi0 : ata_piix
> > ata1: ENTER, pcs=0x13 base=0
> > ata1: LEAVE, pcs=0x13 present_mask=0x1
> > ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
> > ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
> > ata1.00: configured for UDMA/133
> > scsi1 : ata_piix
> > ata2: ENTER, pcs=0x13 base=2
> > ata2: LEAVE, pcs=0x11 present_mask=0x0
> > ata2: SATA port has no device.
> > Vendor: ATA Model: ST3200822AS Rev: 3.01
> > Type: Direct-Access ANSI SCSI revision: 05
> > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> > sda: Write Protect is off
> > sda: Mode Sense: 00 3a 00 00
> > SCSI device sda: drive cache: write back
> > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> > sda: Write Protect is off
> > sda: Mode Sense: 00 3a 00 00
> > SCSI device sda: drive cache: write back
> > sda: sda1 sda2 sda3
> > sd 0:0:0:0: Attached scsi disk sda
> >
> > With -mm6, the kernel doesn't find it. I get this on boot:
> >
> > kinit: try_name sda,1 = dev(8,1)
> > kinit: name_to_dev_t(/dev/sda1) = dev(8.1)
> > kinit: root_dev = dev(8,1)
> > kinit: failed to identify filesystem /dev/root, trying all
> > kinit: trying to mount /dev/root on /root with type ext3
> > kinit: Cannot open root device dev(8,1)
> >
> > I have tried to get this message from -mm1, but could not get it in any log.
> > But... I remember to see that the boot message is like:
> >
> > kinit: try_name sda,1 = sda1(8,1)
> > ^^^^
> > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin.
> >
>
> Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch?
>
> Also, the full dmesg from 2.6.17-mm6 would help, thanks.
>
It does not reach a point to save the dmesg....
I can pick my digital camera.
Is there a netconsole version for OSX (to attach my ibook and dump dmesg...) ?
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 23:57 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-06 0:02 ` Andrew Morton
2006-07-06 14:36 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 0:02 UTC (permalink / raw)
To: "J.A. =?ISO-8859-1?B?TWFnYWxs824i?= <jamagallon; +Cc: linux-kernel
On Thu, 6 Jul 2006 01:57:06 +0200
"J.A. Magallón" <jamagallon@ono.com> wrote:
>
> > >
> > > With -mm6, the kernel doesn't find it. I get this on boot:
> > >
> > > kinit: try_name sda,1 = dev(8,1)
> > > kinit: name_to_dev_t(/dev/sda1) = dev(8.1)
> > > kinit: root_dev = dev(8,1)
> > > kinit: failed to identify filesystem /dev/root, trying all
> > > kinit: trying to mount /dev/root on /root with type ext3
> > > kinit: Cannot open root device dev(8,1)
> > >
> > > I have tried to get this message from -mm1, but could not get it in any log.
> > > But... I remember to see that the boot message is like:
> > >
> > > kinit: try_name sda,1 = sda1(8,1)
> > > ^^^^
> > > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin.
> > >
> >
> > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch?
> >
> > Also, the full dmesg from 2.6.17-mm6 would help, thanks.
> >
>
> It does not reach a point to save the dmesg....
> I can pick my digital camera.
Full dmesg would be better for this one, please.
> Is there a netconsole version for OSX (to attach my ibook and dump dmesg...) ?
All you need is netcat. google(netcat os-x) looks promising.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 0:02 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 14:36 ` J.A. Magallón
2006-07-06 14:48 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-06 14:36 UTC (permalink / raw)
To: linux-kernel
On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
> On Thu, 6 Jul 2006 01:57:06 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > > >
> > > > With -mm6, the kernel doesn't find it. I get this on boot:
> > > >
> > > > kinit: try_name sda,1 = dev(8,1)
> > > > kinit: name_to_dev_t(/dev/sda1) = dev(8.1)
> > > > kinit: root_dev = dev(8,1)
> > > > kinit: failed to identify filesystem /dev/root, trying all
> > > > kinit: trying to mount /dev/root on /root with type ext3
> > > > kinit: Cannot open root device dev(8,1)
> > > >
> > > > I have tried to get this message from -mm1, but could not get it in any log.
> > > > But... I remember to see that the boot message is like:
> > > >
> > > > kinit: try_name sda,1 = sda1(8,1)
> > > > ^^^^
> > > > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin.
> > > >
> > >
> > > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch?
> > >
> > > Also, the full dmesg from 2.6.17-mm6 would help, thanks.
> > >
> >
> > It does not reach a point to save the dmesg....
> > I can pick my digital camera.
>
> Full dmesg would be better for this one, please.
>
This a shot till I can try to get a full dmesg.
http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
Anyways, what I wanted to point above was that previous kernels talk
about 'sda1(8,1)', and newer use 'dev(8,19)'.
Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 14:36 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-06 14:48 ` J.A. Magallón
2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-06 14:48 UTC (permalink / raw)
To: linux-kernel
On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
>
> This a shot till I can try to get a full dmesg.
>
> http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
>
> Anyways, what I wanted to point above was that previous kernels talk
> about 'sda1(8,1)', and newer use 'dev(8,19)'.
> Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
>
Hey !!. I disabled md and usb to get more useful messages in my screen, and
now I have realized that libata is managing my IDE drive !! And I did not
boot with any 'libata.atapi_enable'....
In -mm1,
sda -> 200Gb sata
hda -> HL-DT-ST DVDRAM GSA-4120B
hdb -> (zip drive)
hdc -> 120Gb ide
hdd -> DVD-ROM
In -mm6,
sda -> (zip drive) ?
sdb -> 120Gb
sdc -> 200Gb
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 14:48 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-06 21:44 ` J.A. Magallón
2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton
2006-07-06 23:26 ` 2.6.17-mm6 (try-3) Randy.Dunlap
0 siblings, 2 replies; 126+ messages in thread
From: J.A. Magallón @ 2006-07-06 21:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
>
> > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >
> >
> > This a shot till I can try to get a full dmesg.
> >
> > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
> >
> > Anyways, what I wanted to point above was that previous kernels talk
> > about 'sda1(8,1)', and newer use 'dev(8,19)'.
> > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
> >
>
> Hey !!. I disabled md and usb to get more useful messages in my screen, and
> now I have realized that libata is managing my IDE drive !! And I did not
> boot with any 'libata.atapi_enable'....
>
> In -mm1,
> sda -> 200Gb sata
> hda -> HL-DT-ST DVDRAM GSA-4120B
> hdb -> (zip drive)
> hdc -> 120Gb ide
> hdd -> DVD-ROM
>
> In -mm6,
>
> sda -> (zip drive) ?
> sdb -> 120Gb
> sdc -> 200Gb
>
Well, booting onto sdc1 let me get to single user mode at least so I got
a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it
full I can provide). Basically it looks like libata 2.0 by default handles
PATA drives. This can break a lot of systems. In my opinion, PATA hosts
should be detected _after_ real sata hosts in the same chipset (now it
looks like its done _before_). What is handled by IDE will break anyways,
but this way at least real SATA will stay at the same /dev/sdX devices.
-mm1:
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
ICH5: IDE controller at PCI slot 0000:00:1f.1
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
-mm6:
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
dmesg-mm1:
libata version 1.30 loaded.
ata_piix 0000:00:1f.2: version 1.10tj1ac3
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi0 : ata_piix
ata1: ENTER, pcs=0x13 base=0
ata1: LEAVE, pcs=0x13 present_mask=0x1
ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata1.00: configured for UDMA/133
scsi1 : ata_piix
ata2: ENTER, pcs=0x13 base=2
ata2: LEAVE, pcs=0x11 present_mask=0x0
ata2: SATA port has no device.
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
sd 0:0:0:0: Attached scsi disk sda
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive
hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide
hdb: No disk in drive
hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
hdb: No disk in drive
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdc: ST3120022A, ATA DISK drive
hdd: TOSHIBA DVD-ROM SD-M1712, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdd: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33)
hdc: max request size: 512KiB
hdc: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hdc: cache flushes supported
hdc: hdc1
EXT3 FS on sda1, internal journal
Adding 2112536k swap on /dev/sda3. Priority:-1 extents:1 across:2112536k
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on hdc1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
dmesg-mm6:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00tj1ac5
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
scsi0 : ata_piix
ata1.00: configured for PIO3
ata1.01: configured for PIO3
Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
Type: CD-ROM ANSI SCSI revision: 05
Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
Type: Direct-Access ANSI SCSI revision: 05
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi1 : ata_piix
ata2.00: configured for UDMA/33
ata2.01: configured for UDMA/33
Vendor: ATA Model: ST3120022A Rev: 3.06
Type: Direct-Access ANSI SCSI revision: 05
Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004
Type: CD-ROM ANSI SCSI revision: 05
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi2 : ata_piix
ata3: ENTER, pcs=0x13 base=0
ata3: LEAVE, pcs=0x13 present_mask=0x1
ata3.00: configured for UDMA/133
scsi3 : ata_piix
ata4: ENTER, pcs=0x13 base=2
ata4: LEAVE, pcs=0x11 present_mask=0x0
ata4: SATA port has no device.
ATA: abnormal status 0x7F on port 0xC807
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
sd 0:0:1:0: Attached scsi removable disk sda
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3
sd 2:0:0:0: Attached scsi disk sdc
...
sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
sr 1:0:1:0: Attached scsi CD-ROM sr1
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
EXT3 FS on sdc1, internal journal
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-06 21:57 ` Andrew Morton
2006-07-07 15:38 ` 2.6.17-mm6 J.A. Magallón
2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox
2006-07-06 23:26 ` 2.6.17-mm6 (try-3) Randy.Dunlap
1 sibling, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 21:57 UTC (permalink / raw)
To: J.A. Magallón ; +Cc: linux-kernel, Alan Cox
"J.A. Magallón" <jamagallon@ono.com> wrote:
>
> On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
>
> > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > >
> > > This a shot till I can try to get a full dmesg.
> > >
> > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
> > >
> > > Anyways, what I wanted to point above was that previous kernels talk
> > > about 'sda1(8,1)', and newer use 'dev(8,19)'.
> > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
> > >
> >
> > Hey !!. I disabled md and usb to get more useful messages in my screen, and
> > now I have realized that libata is managing my IDE drive !! And I did not
> > boot with any 'libata.atapi_enable'....
> >
> > In -mm1,
> > sda -> 200Gb sata
> > hda -> HL-DT-ST DVDRAM GSA-4120B
> > hdb -> (zip drive)
> > hdc -> 120Gb ide
> > hdd -> DVD-ROM
> >
> > In -mm6,
> >
> > sda -> (zip drive) ?
> > sdb -> 120Gb
> > sdc -> 200Gb
> >
>
> Well, booting onto sdc1 let me get to single user mode at least so I got
> a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it
> full I can provide). Basically it looks like libata 2.0 by default handles
> PATA drives. This can break a lot of systems. In my opinion, PATA hosts
> should be detected _after_ real sata hosts in the same chipset (now it
> looks like its done _before_). What is handled by IDE will break anyways,
> but this way at least real SATA will stay at the same /dev/sdX devices.
>
> -mm1:
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> ICH5: IDE controller at PCI slot 0000:00:1f.1
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
>
> -mm6:
>
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
>
Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer.
Alan's the man.
> dmesg-mm1:
>
> libata version 1.30 loaded.
> ata_piix 0000:00:1f.2: version 1.10tj1ac3
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> scsi0 : ata_piix
> ata1: ENTER, pcs=0x13 base=0
> ata1: LEAVE, pcs=0x13 present_mask=0x1
> ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
> ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
> ata1.00: configured for UDMA/133
> scsi1 : ata_piix
> ata2: ENTER, pcs=0x13 base=2
> ata2: LEAVE, pcs=0x11 present_mask=0x0
> ata2: SATA port has no device.
> Vendor: ATA Model: ST3200822AS Rev: 3.01
> Type: Direct-Access ANSI SCSI revision: 05
> SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> sda: sda1 sda2 sda3
> sd 0:0:0:0: Attached scsi disk sda
> ...
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ICH5: IDE controller at PCI slot 0000:00:1f.1
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> ICH5: chipset revision 2
> ICH5: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
> Probing IDE interface ide0...
> hda: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive
> hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Probing IDE interface ide1...
> ide-floppy driver 0.99.newide
> hdb: No disk in drive
> hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
> hdb: No disk in drive
> hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.20
> hdc: ST3120022A, ATA DISK drive
> hdd: TOSHIBA DVD-ROM SD-M1712, ATAPI CD/DVD-ROM drive
> ide1 at 0x170-0x177,0x376 on irq 15
> hdd: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33)
> hdc: max request size: 512KiB
> hdc: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
> hdc: cache flushes supported
> hdc: hdc1
> EXT3 FS on sda1, internal journal
> Adding 2112536k swap on /dev/sda3. Priority:-1 extents:1 across:2112536k
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on sda2, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> kjournald starting. Commit interval 5 seconds
> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> EXT3 FS on hdc1, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
>
> dmesg-mm6:
>
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00tj1ac5
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> scsi0 : ata_piix
> ata1.00: configured for PIO3
> ata1.01: configured for PIO3
> Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
> Type: CD-ROM ANSI SCSI revision: 05
> Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
> Type: Direct-Access ANSI SCSI revision: 05
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi1 : ata_piix
> ata2.00: configured for UDMA/33
> ata2.01: configured for UDMA/33
> Vendor: ATA Model: ST3120022A Rev: 3.06
> Type: Direct-Access ANSI SCSI revision: 05
> Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004
> Type: CD-ROM ANSI SCSI revision: 05
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> scsi2 : ata_piix
> ata3: ENTER, pcs=0x13 base=0
> ata3: LEAVE, pcs=0x13 present_mask=0x1
> ata3.00: configured for UDMA/133
> scsi3 : ata_piix
> ata4: ENTER, pcs=0x13 base=2
> ata4: LEAVE, pcs=0x11 present_mask=0x0
> ata4: SATA port has no device.
> ATA: abnormal status 0x7F on port 0xC807
> Vendor: ATA Model: ST3200822AS Rev: 3.01
> Type: Direct-Access ANSI SCSI revision: 05
> sd 0:0:1:0: Attached scsi removable disk sda
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
> sdb: sdb1
> sd 1:0:0:0: Attached scsi disk sdb
> SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 3a 00 00
> SCSI device sdc: drive cache: write back
> SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
> sdc: Write Protect is off
> sdc: Mode Sense: 00 3a 00 00
> SCSI device sdc: drive cache: write back
> sdc: sdc1 sdc2 sdc3
> sd 2:0:0:0: Attached scsi disk sdc
> ...
> sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> sr 0:0:0:0: Attached scsi CD-ROM sr0
> sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
> sr 1:0:1:0: Attached scsi CD-ROM sr1
> ...
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ide-floppy driver 0.99.newide
> EXT3 FS on sdc1, internal journal
>
> --
> J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
> \ It's better when it's free
> Mandriva Linux release 2007.0 (Cooker) for i586
> Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-07 15:38 ` J.A. Magallón
2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox
1 sibling, 0 replies; 126+ messages in thread
From: J.A. Magallón @ 2006-07-07 15:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Alan Cox
On Thu, 6 Jul 2006 14:57:52 -0700, Andrew Morton <akpm@osdl.org> wrote:
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> > >
> > > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > >
> > > > This a shot till I can try to get a full dmesg.
> > > >
> > > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
> > > >
> > > > Anyways, what I wanted to point above was that previous kernels talk
> > > > about 'sda1(8,1)', and newer use 'dev(8,19)'.
> > > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
> > > >
> > >
> > > Hey !!. I disabled md and usb to get more useful messages in my screen, and
> > > now I have realized that libata is managing my IDE drive !! And I did not
> > > boot with any 'libata.atapi_enable'....
> > >
> > > In -mm1,
> > > sda -> 200Gb sata
> > > hda -> HL-DT-ST DVDRAM GSA-4120B
> > > hdb -> (zip drive)
> > > hdc -> 120Gb ide
> > > hdd -> DVD-ROM
> > >
> > > In -mm6,
> > >
> > > sda -> (zip drive) ?
> > > sdb -> 120Gb
> > > sdc -> 200Gb
> > >
> >
> > Well, booting onto sdc1 let me get to single user mode at least so I got
> > a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it
> > full I can provide). Basically it looks like libata 2.0 by default handles
> > PATA drives. This can break a lot of systems. In my opinion, PATA hosts
> > should be detected _after_ real sata hosts in the same chipset (now it
> > looks like its done _before_). What is handled by IDE will break anyways,
> > but this way at least real SATA will stay at the same /dev/sdX devices.
> >
> > -mm1:
> > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> > ICH5: IDE controller at PCI slot 0000:00:1f.1
> > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
> >
> > -mm6:
> >
> > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> >
>
> Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer.
> Alan's the man.
>
I thought libata.atapi_enabled=0 could make things like before, but:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00tj1ac5
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
scsi0 : ata_piix
ata1.00: configured for PIO3
ata1.01: configured for PIO3
ata1.00: WARNING: ATAPI is disabled, device ignored.
ata1.01: WARNING: ATAPI is disabled, device ignored.
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi1 : ata_piix
ata2.00: configured for UDMA/33
ata2.01: configured for UDMA/33
Vendor: ATA Model: ST3120022A Rev: 3.06
Type: Direct-Access ANSI SCSI revision: 05
ata2.01: WARNING: ATAPI is disabled, device ignored.
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi2 : ata_piix
ata3: ENTER, pcs=0x13 base=0
ata3: LEAVE, pcs=0x13 present_mask=0x1
ata3.00: configured for UDMA/133
scsi3 : ata_piix
ata4: ENTER, pcs=0x13 base=2
ata4: LEAVE, pcs=0x11 present_mask=0x0
ata4: SATA port has no device.
ATA: abnormal status 0x7F on port 0xC807
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 1:0:0:0: Attached scsi disk sda
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
Buses are still there, disks named, but ignored. So old hda becomes sda,
and old sda becomes sdb.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton
2006-07-07 15:38 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-07 16:02 ` Alan Cox
2006-07-07 15:55 ` 2.6.17-mm6 J.A. Magallón
1 sibling, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 16:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: J.A. Magallón , linux-kernel
Ar Iau, 2006-07-06 am 14:57 -0700, ysgrifennodd Andrew Morton:
> > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> >
>
> Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer.
> Alan's the man.
The "mixed" drivers/ide and drivers/scsi setup for the ICH is really
ugly (look at the pci/quirks.c code for it to see just *how* ugly). It
is still present but the default behaviour at the moment is to assume
that you want to use libata for your drives.
For most distros I've tried this doesn't seem to break anything. Some
older distros don't use labels for root searching so need root= passing
the first time to fix it.
That bit of code is really Jeff code but I can certainly put a Kconfig
line and submit a diff to allow users to pick whether their PIIX/ICH
should be handled half and half if Andrew or Jeff think that is wise.
Alan
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 15:55 ` J.A. Magallón
2006-07-07 16:44 ` 2.6.17-mm6 Alan Cox
0 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-07 15:55 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, linux-kernel
On Fri, 07 Jul 2006 17:02:48 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Iau, 2006-07-06 am 14:57 -0700, ysgrifennodd Andrew Morton:
> > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> > > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> > > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> > > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> > >
> >
> > Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer.
> > Alan's the man.
>
> The "mixed" drivers/ide and drivers/scsi setup for the ICH is really
> ugly (look at the pci/quirks.c code for it to see just *how* ugly). It
> is still present but the default behaviour at the moment is to assume
> that you want to use libata for your drives.
>
> For most distros I've tried this doesn't seem to break anything. Some
> older distros don't use labels for root searching so need root= passing
> the first time to fix it.
>
> That bit of code is really Jeff code but I can certainly put a Kconfig
> line and submit a diff to allow users to pick whether their PIIX/ICH
> should be handled half and half if Andrew or Jeff think that is wise.
>
> Alan
>
I think it is enough to change the detection order, first real SATA and then
PATA, so the only drives that change names are the PATA ones.
(it that's easy enough...)
Mmm, I have thought on another thing. RAID devices do not store the /dev
node of pieces on the superblock, just drive IDs, isn't it ?
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-07 15:55 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-07 16:44 ` Alan Cox
2006-07-07 16:34 ` 2.6.17-mm6 Randy.Dunlap
0 siblings, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 16:44 UTC (permalink / raw)
To: J.A. Magallón; +Cc: Andrew Morton, linux-kernel
Ar Gwe, 2006-07-07 am 17:55 +0200, ysgrifennodd J.A. Magallón:
> I think it is enough to change the detection order, first real SATA and then
> PATA, so the only drives that change names are the PATA ones.
> (it that's easy enough...)
The order is determined by the PCI layer code, and of course by what
order you load the modules. Rigidly defined certainities about driver
ordering went out with hotplug.
> Mmm, I have thought on another thing. RAID devices do not store the /dev
> node of pieces on the superblock, just drive IDs, isn't it ?
RAID just works and LVM. I flip Fedora boxes between drivers on a
regular basis without a glitch.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 16:44 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 16:34 ` Randy.Dunlap
2006-07-07 17:09 ` 2.6.17-mm6 Alan Cox
0 siblings, 1 reply; 126+ messages in thread
From: Randy.Dunlap @ 2006-07-07 16:34 UTC (permalink / raw)
To: Alan Cox; +Cc: jamagallon, akpm, linux-kernel
On Fri, 07 Jul 2006 17:44:03 +0100 Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 17:55 +0200, ysgrifennodd J.A. Magallón:
> > I think it is enough to change the detection order, first real SATA and then
> > PATA, so the only drives that change names are the PATA ones.
> > (it that's easy enough...)
>
> The order is determined by the PCI layer code, and of course by what
> order you load the modules. Rigidly defined certainities about driver
> ordering went out with hotplug.
For built-in drivers, the link order matters.
The the libata PATA drivers are sort of "randomly" mixed in
with the SATA drivers.
> > Mmm, I have thought on another thing. RAID devices do not store the /dev
> > node of pieces on the superblock, just drive IDs, isn't it ?
>
> RAID just works and LVM. I flip Fedora boxes between drivers on a
> regular basis without a glitch.
---
~Randy
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 16:34 ` 2.6.17-mm6 Randy.Dunlap
@ 2006-07-07 17:09 ` Alan Cox
2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik
0 siblings, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 17:09 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: jamagallon, akpm, linux-kernel
Ar Gwe, 2006-07-07 am 09:34 -0700, ysgrifennodd Randy.Dunlap:
> For built-in drivers, the link order matters.
> The the libata PATA drivers are sort of "randomly" mixed in
> with the SATA drivers.
Mine are in alphabetical order but some of the early merges shuffled
stuff a bit.
The only case the link order matters here is with the generic and legacy
drivers. No chip specific libata PATA/SATA driver has overlapping PCI
identifiers between two drivers except for Jmicron, and that
distinguishes precisely by the function number.
Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA
with a bridge chip, and in some cases like the ATI this is quite common.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:09 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 17:14 ` Jeff Garzik
2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd
2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox
0 siblings, 2 replies; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 17:14 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Alan Cox wrote:
> Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA
> with a bridge chip, and in some cases like the ATI this is quite common.
Incorrect; what you describe is the core assumption underlying the
"ata_", "pata_", and "sata_" prefixes.
If the user can attached PATA and SATA devices to a controller, its
prefix is ata_
If the user can only attach PATA devices, its prefix is pata_
If the user can only attach SATA devices, its prefix is sata_
For the purposes of this convention, user-attached bridges such as
PATA<->SATA bridges, are ignored.
Most older controllers always fall into pata_, most newer into sata_,
and an odd few ata_
Its a bug if you don't help maintain these assumptions :)
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 17:22 ` David Lloyd
2006-07-07 17:23 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox
1 sibling, 1 reply; 126+ messages in thread
From: David Lloyd @ 2006-07-07 17:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, jamagallon, akpm, linux-kernel
On Fri, 7 Jul 2006, Jeff Garzik wrote:
> Alan Cox wrote:
>> Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA
>> with a bridge chip, and in some cases like the ATI this is quite common.
>
> Incorrect; what you describe is the core assumption underlying the "ata_",
> "pata_", and "sata_" prefixes.
>
> If the user can attached PATA and SATA devices to a controller, its prefix is
> ata_
So sata_promise will change to ata_promise at some point?
- DML
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd
@ 2006-07-07 17:23 ` Jeff Garzik
0 siblings, 0 replies; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 17:23 UTC (permalink / raw)
To: David Lloyd; +Cc: Alan Cox, Randy.Dunlap, jamagallon, akpm, linux-kernel
David Lloyd wrote:
> On Fri, 7 Jul 2006, Jeff Garzik wrote:
>
>> Alan Cox wrote:
>>> Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA
>>> with a bridge chip, and in some cases like the ATI this is quite
>>> common.
>>
>> Incorrect; what you describe is the core assumption underlying the
>> "ata_", "pata_", and "sata_" prefixes.
>>
>> If the user can attached PATA and SATA devices to a controller, its
>> prefix is ata_
>
> So sata_promise will change to ata_promise at some point?
Yes, if breakage can be minimized. Internal symbols have already changed...
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd
@ 2006-07-07 17:44 ` Alan Cox
2006-07-07 17:39 ` 2.6.17-mm6 Jeff Garzik
1 sibling, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 17:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Ar Gwe, 2006-07-07 am 13:14 -0400, ysgrifennodd Jeff Garzik:
> Most older controllers always fall into pata_, most newer into sata_,
> and an odd few ata_
>
> Its a bug if you don't help maintain these assumptions :)
It would be very hard to do so. Almost anything can and (alas) did have
sata bridges nailed to it early on. Almost every later highpoint,
promise and ati chip has been found with SATA bridges attached.
I've tried to follow the convention on the basis of "not usually found
nailed to a SATA bridge chip". If we want to be strict then most of
pata_ is ata_ and the prefix really isn't useful.
Easy move to make and submit but is it actually useful to do so ?
And what about IDE/SATA convertor boards ?
Alan
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 17:39 ` Jeff Garzik
2006-07-07 20:03 ` 2.6.17-mm6 Alan Cox
0 siblings, 1 reply; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 17:39 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 13:14 -0400, ysgrifennodd Jeff Garzik:
>> Most older controllers always fall into pata_, most newer into sata_,
>> and an odd few ata_
>>
>> Its a bug if you don't help maintain these assumptions :)
>
> It would be very hard to do so. Almost anything can and (alas) did have
> sata bridges nailed to it early on. Almost every later highpoint,
> promise and ati chip has been found with SATA bridges attached.
>
> I've tried to follow the convention on the basis of "not usually found
> nailed to a SATA bridge chip". If we want to be strict then most of
> pata_ is ata_ and the prefix really isn't useful.
If there is a SATA receptable -- for plugging in SATA cables --
hardwired onto the controller, it should not be called pata_
Its about what the _user_ knows, and sees.
The user doesn't know about soldered bridge chips. The user knows if he
is plugging a PATA or SATA cable into his controller.
> And what about IDE/SATA convertor boards ?
Covered, in the "for the purposes of" sentence.
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 17:39 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 20:03 ` Alan Cox
2006-07-07 19:59 ` 2.6.17-mm6 Jeff Garzik
0 siblings, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Ar Gwe, 2006-07-07 am 13:39 -0400, ysgrifennodd Jeff Garzik:
> The user doesn't know about soldered bridge chips. The user knows if he
> is plugging a PATA or SATA cable into his controller.
In which case the pata_ prefix isnt much use because people soldered
bridge chips onto just about everything in the first SATA rush, before
they all switched to chips that actually did SATA.
Alan
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 20:03 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 19:59 ` Jeff Garzik
2006-07-07 20:23 ` 2.6.17-mm6 Alan Cox
0 siblings, 1 reply; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 19:59 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 13:39 -0400, ysgrifennodd Jeff Garzik:
>> The user doesn't know about soldered bridge chips. The user knows if he
>> is plugging a PATA or SATA cable into his controller.
>
> In which case the pata_ prefix isnt much use because people soldered
> bridge chips onto just about everything in the first SATA rush, before
> they all switched to chips that actually did SATA.
An easy look at pata_*.c seemed to indicate that at least 20 would
almost certainly remain pata_*.c, maybe even as many as 30.
The circumstances you cite happened, yes, but I think you exaggerate the
renaming. Several soldered bridge solutions are already supported by
libata.
Several do need to be renamed to ata_*.c, though.
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 19:59 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 20:23 ` Alan Cox
2006-07-07 20:14 ` 2.6.17-mm6 Jeff Garzik
0 siblings, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 20:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Ar Gwe, 2006-07-07 am 15:59 -0400, ysgrifennodd Jeff Garzik:
> The circumstances you cite happened, yes, but I think you exaggerate the
> renaming. Several soldered bridge solutions are already supported by
> libata.
>
> Several do need to be renamed to ata_*.c, though.
If we work on the "commonly found" basis then it would be
pata_atiixp
pata_hpt37x
pata_hpt3x2n
pata_pdc2027x
All four commonly are found with SATA bridges, ATIIXP especially.
On the "almost any obscure case basis" would add
pata_ali
pata_sis
pata_via
and depending how far pushed
pata_sil680
and one or two others
Which do you want renamed ?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 20:23 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 20:14 ` Jeff Garzik
2006-07-07 20:42 ` 2.6.17-mm6 Alan Cox
0 siblings, 1 reply; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 20:14 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 15:59 -0400, ysgrifennodd Jeff Garzik:
>> The circumstances you cite happened, yes, but I think you exaggerate the
>> renaming. Several soldered bridge solutions are already supported by
>> libata.
>>
>> Several do need to be renamed to ata_*.c, though.
>
> If we work on the "commonly found" basis then it would be
>
> pata_atiixp
> pata_hpt37x
> pata_hpt3x2n
> pata_pdc2027x
>
> All four commonly are found with SATA bridges, ATIIXP especially.
>
> On the "almost any obscure case basis" would add
>
> pata_ali
> pata_sis
> pata_via
>
> and depending how far pushed
>
> pata_sil680
>
> and one or two others
>
> Which do you want renamed ?
See, out of 37 pata_*.c files, you still have 25+ with pata_ prefix.
Use your judgement, based on the guidelines described: outside of
weirdo pre-production cases, are users going to be plugging PATA cables
or SATA cables into the hardware in question?
I'm a bit surprised to see pata_sis and pata_via: are you certain there
is not confusion based on the fact that newer SiS, ULi and VIA
controllers provide both SATA and PATA on the same controller?
That's a common __known painful__ area of libata. The libata API needs
to be fixed such that port_operations can be vastly different. Right
now, probe_ent requires some attributes to be common across all ports,
when they are not in real life. This leads to improper creation of
if (this port is sata)
...
else
...
code inside hooks, when the libata-with-fixed-API solution looks like
static void pata_doit() { ... }
static void sata_doit() { ... }
static struct ata_port_operations pata_ops = {...};
static struct ata_port_operations sata_ops = {...};
For such cases, PATA support for these _new_ controllers needs to be
added to sata_via.c, sata_uli.c, sata_sis.c, and they should then be
renamed. Or whatever similar renaming/code-shuffle solution brings
about the same end result.
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-07 20:14 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 20:42 ` Alan Cox
2006-07-07 20:37 ` 2.6.17-mm6 Jeff Garzik
0 siblings, 1 reply; 126+ messages in thread
From: Alan Cox @ 2006-07-07 20:42 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik:
> I'm a bit surprised to see pata_sis and pata_via: are you certain there
> is not confusion based on the fact that newer SiS, ULi and VIA
> controllers provide both SATA and PATA on the same controller?
Hard to be sure but it looks like some vendors briefly used marvell
bridges of some form with a few generic PATA chipsets.
Alan
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 20:42 ` 2.6.17-mm6 Alan Cox
@ 2006-07-07 20:37 ` Jeff Garzik
2006-07-07 21:09 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 20:37 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel
Alan Cox wrote:
> Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik:
>> I'm a bit surprised to see pata_sis and pata_via: are you certain there
>> is not confusion based on the fact that newer SiS, ULi and VIA
>> controllers provide both SATA and PATA on the same controller?
>
> Hard to be sure but it looks like some vendors briefly used marvell
> bridges of some form with a few generic PATA chipsets.
Yep. The sata_xxx should cover most of the Marvell-SATA-bridge + PATA
chip controllers already.
Pretty much everybody except Silicon Image used the Marvell bridge for
their first generation SATA.
I've tried hard to make sure that most of these made it into sata_xxx
already.
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 20:37 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 21:09 ` J.A. Magallón
2006-07-07 21:11 ` 2.6.17-mm6 Jeff Garzik
0 siblings, 1 reply; 126+ messages in thread
From: J.A. Magallón @ 2006-07-07 21:09 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel
On Fri, 07 Jul 2006 16:37:44 -0400, Jeff Garzik <jeff@garzik.org> wrote:
> Alan Cox wrote:
> > Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik:
> >> I'm a bit surprised to see pata_sis and pata_via: are you certain there
> >> is not confusion based on the fact that newer SiS, ULi and VIA
> >> controllers provide both SATA and PATA on the same controller?
> >
> > Hard to be sure but it looks like some vendors briefly used marvell
> > bridges of some form with a few generic PATA chipsets.
>
> Yep. The sata_xxx should cover most of the Marvell-SATA-bridge + PATA
> chip controllers already.
>
> Pretty much everybody except Silicon Image used the Marvell bridge for
> their first generation SATA.
>
Dumb view from outside the ATA world: why dont assume all controllers
can do both SATA and PATA, require some {p,s}ata_init(),
{p,s}ata_enumerate_drives() and so on, and provide no-ops as default
for them ? So SATA only can override sata_ ones, same for PATA and
the weird (really ICH5 is so strange ?) ones override both.
So you can decide later about doing
for each controller
pata_init
sata_init
or
for each controller
sata_init
pata_init
or
for each controller
sata_init
for each controller
pata_init
Just an idea. Good designed inheritance is good ;).
AH, and all the drivers could be named as 'ata_xxxx'. Nice.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-07 21:09 ` 2.6.17-mm6 J.A. Magallón
@ 2006-07-07 21:11 ` Jeff Garzik
2006-07-07 21:40 ` 2.6.17-mm6 J.A. Magallón
0 siblings, 1 reply; 126+ messages in thread
From: Jeff Garzik @ 2006-07-07 21:11 UTC (permalink / raw)
To: "J.A. Magallón"; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel
J.A. Magallón wrote:
> for each controller
> sata_init
> for each controller
> pata_init
There is never a 'for each controller' operation.
The current layering is as it should be.
Jeff
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:11 ` 2.6.17-mm6 Jeff Garzik
@ 2006-07-07 21:40 ` J.A. Magallón
0 siblings, 0 replies; 126+ messages in thread
From: J.A. Magallón @ 2006-07-07 21:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel
On Fri, 07 Jul 2006 17:11:55 -0400, Jeff Garzik <jeff@garzik.org> wrote:
> J.A. Magallón wrote:
> > for each controller
> > sata_init
> > for each controller
> > pata_init
>
>
> There is never a 'for each controller' operation.
>
I know, what would happen when a module loads ?
But you could always do something like
ata_piix_init()
{
if (libata.pata_first)
pata_init()
sata_init()
else
sata_init()
pata_init()
}
> The current layering is as it should be.
>
This is what I like of many developers. It's like it is and it's
the best. Until 2.8 opens.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6 (try-3)
2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón
2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 23:26 ` Randy.Dunlap
1 sibling, 0 replies; 126+ messages in thread
From: Randy.Dunlap @ 2006-07-06 23:26 UTC (permalink / raw)
To: jamagallon; +Cc: akpm, lkml, jgarzik
(sorry to spam everyone, but I can't seem to reply to this
message and have it appear on lkml)
On Thu, 6 Jul 2006 23:44:25 +0200 J.A. Magallón wrote:
> On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
>
> > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > >
> > > This a shot till I can try to get a full dmesg.
> > >
> > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
> > >
> > > Anyways, what I wanted to point above was that previous kernels talk
> > > about 'sda1(8,1)', and newer use 'dev(8,19)'.
> > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
> > >
> >
> > Hey !!. I disabled md and usb to get more useful messages in my screen, and
> > now I have realized that libata is managing my IDE drive !! And I did not
> > boot with any 'libata.atapi_enable'....
> >
> > In -mm1,
> > sda -> 200Gb sata
> > hda -> HL-DT-ST DVDRAM GSA-4120B
> > hdb -> (zip drive)
> > hdc -> 120Gb ide
> > hdd -> DVD-ROM
> >
> > In -mm6,
> >
> > sda -> (zip drive) ?
> > sdb -> 120Gb
> > sdc -> 200Gb
> >
>
> Well, booting onto sdc1 let me get to single user mode at least so I got
> a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it
> full I can provide). Basically it looks like libata 2.0 by default handles
> PATA drives. This can break a lot of systems. In my opinion, PATA hosts
> should be detected _after_ real sata hosts in the same chipset (now it
> looks like its done _before_). What is handled by IDE will break anyways,
> but this way at least real SATA will stay at the same /dev/sdX devices.
>
> -mm1:
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> ICH5: IDE controller at PCI slot 0000:00:1f.1
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
>
> -mm6:
>
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
Yep, adding all of the libata-pata drivers mucked up the
/dev/sd* boot order. :(
Perhaps they should follow all of the SATA drivers. ?
---
~Randy
^ permalink raw reply [flat|nested] 126+ messages in thread
[parent not found: <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>]
* Re: 2.6.17-mm6
[not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>
@ 2006-07-05 22:50 ` Andrew Morton
2006-07-05 23:28 ` 2.6.17-mm6 Keith Mannthey
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-05 22:50 UTC (permalink / raw)
To: Keith Mannthey; +Cc: linux-kernel
"Keith Mannthey" <kmannth@gmail.com> wrote:
>
> On 7/3/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
> >
>
> Moving from -mm4 to -mm6 I ran into this while trying to boot....
> <snip>
> Could not allocate 16 bytes percpu data
> Could not allocate 16 bytes percpu data
> sd_mod: Unknown symbol scsi_print_sense_hdr
> sd_mod: Unknown symbol scsi_mode_sense
> sd_mod: Unknown symbol scsi_device_get
> sd_mod: Unknown symbol scsi_get_sense_info_fld
> <snip>
>
> sd_mod (and later aacraid) are built into my initrd and loaded during boot.
>
> I doubled PERCPU_ENOUGH_ROOM to 65536 and was able to boot. I am not
> sure what is eating all the percpu room on the system. I was using
> this config with -mm4 just fine.
>
> I attached the dmesg and .config
>
Looks like we simply ran out. Why?...
patches/genirq-x86_64-irq-make-vector_irq-per-cpu.patch:+DEFINE_PER_CPU(vector_irq_t, vector_irq) = {
patches/mm-implement-swap-prefetching.patch:+static DEFINE_PER_CPU(struct pagevec, lru_add_tail_pvecs) = { 0, };
patches/origin.patch:+static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
patches/origin.patch:+DEFINE_PER_CPU(struct sys_device, device_mce);
patches/origin.patch:+static DEFINE_PER_CPU(struct threshold_bank *, threshold_banks[NR_BANKS]);
patches/origin.patch:+static DEFINE_PER_CPU(struct rq, runqueues);
patches/origin.patch:+DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}};
patches/per-task-delay-accounting-taskstats-interface.patch:+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 };
patches/readahead-state-based-method-aging-accounting.patch:+DEFINE_PER_CPU(unsigned long, readahead_aging);
patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner);
patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]);
patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner);
patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]);
patches/x86_64-mm-add-smp-support-on-i386-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
patches/x86_64-mm-add-smp-support-on-x86_64-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
Per-cpuifying the 2.5 kbyte runqueue struct will have hurt.
[does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why
.data.percpu isn't there]
Are you able to add this, see if we can work out where it all went?
--- a/kernel/module.c~a
+++ a/kernel/module.c
@@ -340,6 +340,9 @@ static void *percpu_modalloc(unsigned lo
unsigned int i;
void *ptr;
+ printk("%s: allocating %lu bytes for module %s (vmlinux:%lu)\n",
+ __FUNCTION__, size, name, block_size(pcpu_size[0]));
+
if (align > SMP_CACHE_BYTES) {
printk(KERN_WARNING "%s: per-cpu alignment %li > %i\n",
name, align, SMP_CACHE_BYTES);
_
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 22:50 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-05 23:28 ` Keith Mannthey
2006-07-05 23:44 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Keith Mannthey @ 2006-07-05 23:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
> "Keith Mannthey" <kmannth@gmail.com> wrote:
> >
> > On 7/3/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> > >
> > >
> >
> > Moving from -mm4 to -mm6 I ran into this while trying to boot....
> > <snip>
> > Could not allocate 16 bytes percpu data
> > Could not allocate 16 bytes percpu data
> > sd_mod: Unknown symbol scsi_print_sense_hdr
> > sd_mod: Unknown symbol scsi_mode_sense
> > sd_mod: Unknown symbol scsi_device_get
> > sd_mod: Unknown symbol scsi_get_sense_info_fld
> > <snip>
> >
> > sd_mod (and later aacraid) are built into my initrd and loaded during boot.
> >
> > I doubled PERCPU_ENOUGH_ROOM to 65536 and was able to boot. I am not
> > sure what is eating all the percpu room on the system. I was using
> > this config with -mm4 just fine.
> >
> > I attached the dmesg and .config
> >
>
> Looks like we simply ran out. Why?...
>
> patches/genirq-x86_64-irq-make-vector_irq-per-cpu.patch:+DEFINE_PER_CPU(vector_irq_t, vector_irq) = {
> patches/mm-implement-swap-prefetching.patch:+static DEFINE_PER_CPU(struct pagevec, lru_add_tail_pvecs) = { 0, };
> patches/origin.patch:+static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
> patches/origin.patch:+DEFINE_PER_CPU(struct sys_device, device_mce);
> patches/origin.patch:+static DEFINE_PER_CPU(struct threshold_bank *, threshold_banks[NR_BANKS]);
> patches/origin.patch:+static DEFINE_PER_CPU(struct rq, runqueues);
> patches/origin.patch:+DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}};
> patches/per-task-delay-accounting-taskstats-interface.patch:+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 };
> patches/readahead-state-based-method-aging-accounting.patch:+DEFINE_PER_CPU(unsigned long, readahead_aging);
> patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner);
> patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]);
> patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner);
> patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]);
> patches/x86_64-mm-add-smp-support-on-i386-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
> patches/x86_64-mm-add-smp-support-on-x86_64-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
>
> Per-cpuifying the 2.5 kbyte runqueue struct will have hurt.
>
> [does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why
> .data.percpu isn't there]
hmm. There is no message from the readelf command but there it dosen't
report any .data.percpu area. The only sections for data are just .data and
.rela.data
> Are you able to add this, see if we can work out where it all went?
I am still booting with the larger percpu size but I see
percpu_modalloc: allocating 16 bytes for module scsi_mod (vmlinux:41600)
percpu_modalloc: allocating 8 bytes for module ipv6 (vmlinux:41600)
from the log. Something built in is eating it.
I am turing off the readhead to see if that helps.
Thanks,
Keith
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-05 23:28 ` 2.6.17-mm6 Keith Mannthey
@ 2006-07-05 23:44 ` Andrew Morton
2006-07-05 23:48 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-05 23:44 UTC (permalink / raw)
To: Keith Mannthey; +Cc: linux-kernel
On Wed, 5 Jul 2006 16:28:39 -0700
"Keith Mannthey" <kmannth@gmail.com> wrote:
> > Per-cpuifying the 2.5 kbyte runqueue struct will have hurt.
> >
> > [does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why
> > .data.percpu isn't there]
>
> hmm. There is no message from the readelf command but there it dosen't
> report any .data.percpu area. The only sections for data are just .data and
> .rela.data
hm.
> > Are you able to add this, see if we can work out where it all went?
>
> I am still booting with the larger percpu size but I see
>
> percpu_modalloc: allocating 16 bytes for module scsi_mod (vmlinux:41600)
> percpu_modalloc: allocating 8 bytes for module ipv6 (vmlinux:41600)
>
> from the log. Something built in is eating it.
Yes, vmlinux got it all.
> I am turing off the readhead to see if that helps.
Use
nm -n vmlinux | grep per_cpu
I get:
00000000c0425780 A __per_cpu_start
00000000c0427980 d per_cpu__cpu_idle_state
00000000c0427a00 D per_cpu__irq_stat
00000000c0427a80 D per_cpu__cpu_16bit_stack
00000000c0427e80 D per_cpu__cpu_gdt_descr
00000000c0427f00 D per_cpu__cpu_tlbstate
00000000c0427f80 D per_cpu__cpu_state
00000000c0427f84 d per_cpu__perfctr_nmi_owner
00000000c0427f88 d per_cpu__evntsel_nmi_owner
00000000c0427f94 d per_cpu__nmi_watchdog_ctlblk
00000000c0427fc0 D per_cpu__current_kprobe
00000000c0427fe0 D per_cpu__kprobe_ctlblk
00000000c0428080 D per_cpu__mmu_gathers
00000000c0428880 d per_cpu__runqueues
00000000c0429240 d per_cpu__cpu_domains
00000000c0429320 d per_cpu__core_domains
00000000c0429400 d per_cpu__phys_domains
00000000c04294e0 D per_cpu__kstat
00000000c04298dc D per_cpu__process_counts
00000000c04298e0 d per_cpu__cpu_profile_hits
00000000c04298e8 d per_cpu__cpu_profile_flip
00000000c04298ec d per_cpu__tasklet_vec
00000000c04298f0 d per_cpu__tasklet_hi_vec
00000000c04298f4 d per_cpu__ksoftirqd
00000000c04298f8 d per_cpu__tvec_bases
00000000c0429900 D per_cpu__rcu_data
00000000c0429940 D per_cpu__rcu_bh_data
00000000c0429980 d per_cpu__rcu_tasklet
00000000c04299a0 d per_cpu__hrtimer_bases
00000000c0429a38 d per_cpu__kprobe_instance
00000000c0429a3c d per_cpu__touch_timestamp
00000000c0429a40 d per_cpu__print_timestamp
00000000c0429a44 d per_cpu__watchdog_task
00000000c0429a60 d per_cpu__ratelimits.18951
00000000c0429a80 d per_cpu__committed_space
00000000c0429aa0 d per_cpu__lru_add_pvecs
00000000c0429ae0 d per_cpu__lru_add_active_pvecs
00000000c0429b20 D per_cpu__vm_event_states
00000000c0429bc0 d per_cpu__reap_work
00000000c0429c00 d per_cpu__bh_lrus
00000000c0429c20 d per_cpu__bh_accounting
00000000c0429c40 d per_cpu__fdtable_defer_list
00000000c0429ca8 D per_cpu__avc_cache_stats
00000000c0429cc0 d per_cpu__blk_cpu_done
00000000c0429cc8 d per_cpu__blk_trace_cpu_offset
00000000c0429ce0 D per_cpu__radix_tree_preloads
00000000c0429d00 d per_cpu__trickle_count
00000000c0429d04 d per_cpu__proc_event_counts
00000000c0429d20 d per_cpu__loopback_stats
00000000c0429d80 d per_cpu__sockets_in_use
00000000c0429e00 D per_cpu__softnet_data
00000000c042a300 D per_cpu__netdev_rx_stat
00000000c042a310 d per_cpu__net_rand_state
00000000c042a380 d per_cpu__flow_tables
00000000c042a400 d per_cpu__flow_hash_info
00000000c042a480 d per_cpu__flow_flush_tasklets
00000000c042a4a0 d per_cpu__rt_cache_stat
00000000c042a4e0 d per_cpu____icmp_socket
00000000c042a4e4 A __per_cpu_end
Which is 19k.
<wonders what happened to the first 8.5k>
If we have any 2-D arrays in there (something dimensioned by NR_CPUS) then
we'll have a big problem.
I guess a medium-term fix would be to add a boot parameter to override
PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
for the benefit of the tiny minority of kernels which are hand-built with
lots of drivers in vmlinux.
But first let's find out where it all went.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 23:44 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-05 23:48 ` Andrew Morton
2006-07-06 0:05 ` 2.6.17-mm6 Keith Mannthey
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-05 23:48 UTC (permalink / raw)
To: kmannth, linux-kernel
On Wed, 5 Jul 2006 16:44:57 -0700
Andrew Morton <akpm@osdl.org> wrote:
> I guess a medium-term fix would be to add a boot parameter to override
> PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
> for the benefit of the tiny minority of kernels which are hand-built with
> lots of drivers in vmlinux.
>
That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded
modules, so if vmlinux blows it all then `modprobe the-same-stuff' will
blow it as well.
> But first let's find out where it all went.
I agree with that person.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-05 23:48 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 0:05 ` Keith Mannthey
2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Keith Mannthey @ 2006-07-06 0:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 5 Jul 2006 16:44:57 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > I guess a medium-term fix would be to add a boot parameter to override
> > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
> > for the benefit of the tiny minority of kernels which are hand-built with
> > lots of drivers in vmlinux.
I am not really loading alot of drivers. I am building with a ton of driver.
>
> That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded
> modules, so if vmlinux blows it all then `modprobe the-same-stuff' will
> blow it as well.
>
> > But first let's find out where it all went.
>
> I agree with that person.
:)
This is what I get it is diffrent that yours for sure. I am a little
confused by the large offset change near the start.....?
elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu
000000000c5ef91b A __crc_per_cpu__vm_event_states
0000000023898563 A __crc_per_cpu__softnet_data
0000000026d8eb30 A __crc_per_cpu__kstat
ffffffff802645ae t lru_add_drain_per_cpu
ffffffff80386818 t flow_cache_flush_per_cpu
ffffffff8041e010 r __ksymtab_per_cpu__kstat
ffffffff8041f6f0 r __ksymtab_per_cpu__vm_event_states
ffffffff80424e80 r __ksymtab_per_cpu__softnet_data
ffffffff804288f0 r __kcrctab_per_cpu__kstat
ffffffff80429460 r __kcrctab_per_cpu__vm_event_states
ffffffff8042c028 r __kcrctab_per_cpu__softnet_data
ffffffff8042e550 r __kstrtab_per_cpu__kstat
ffffffff80430f10 r __kstrtab_per_cpu__vm_event_states
ffffffff8043a3b0 r __kstrtab_per_cpu__softnet_data
ffffffff8062b91c T setup_per_cpu_areas
ffffffff80636921 T setup_per_cpu_pageset
ffffffff80658000 A __per_cpu_start
ffffffff80658000 D per_cpu__init_tss
ffffffff8065a080 d per_cpu__idle_state
ffffffff8065a084 d per_cpu__cpu_idle_state
ffffffff8065a0a0 D per_cpu__vector_irq
ffffffff8065a4a0 D per_cpu__device_mce
ffffffff8065a518 d per_cpu__next_check
ffffffff8065a520 d per_cpu__threshold_banks
ffffffff8065a550 d per_cpu__bank_map
ffffffff8065a580 d per_cpu__flush_state
ffffffff8065a600 D per_cpu__cpu_state
ffffffff8065a620 d per_cpu__perfctr_nmi_owner
ffffffff8065a624 d per_cpu__evntsel_nmi_owner
ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk
ffffffff8065a660 d per_cpu__last_irq_sum
ffffffff8065a668 d per_cpu__alert_counter
ffffffff8065a670 d per_cpu__nmi_touch
ffffffff8065a680 D per_cpu__current_kprobe
ffffffff8065a6a0 D per_cpu__kprobe_ctlblk
ffffffff8065a7e0 D per_cpu__mmu_gathers
ffffffff8065b7e0 d per_cpu__runqueues
ffffffff8065ca60 d per_cpu__cpu_domains
ffffffff8065cae0 d per_cpu__core_domains
ffffffff8065cb60 d per_cpu__phys_domains
ffffffff8065cbe0 d per_cpu__node_domains
ffffffff8065cc60 d per_cpu__allnodes_domains
ffffffff8065cce0 D per_cpu__kstat
ffffffff80661120 D per_cpu__process_counts
ffffffff80661130 d per_cpu__cpu_profile_hits
ffffffff80661140 d per_cpu__cpu_profile_flip
ffffffff80661148 d per_cpu__tasklet_vec
ffffffff80661150 d per_cpu__tasklet_hi_vec
ffffffff80661158 d per_cpu__ksoftirqd
ffffffff80661160 d per_cpu__tvec_bases
ffffffff80661180 D per_cpu__rcu_data
ffffffff80661200 D per_cpu__rcu_bh_data
ffffffff80661280 d per_cpu__rcu_tasklet
ffffffff806612c0 d per_cpu__hrtimer_bases
ffffffff80661340 d per_cpu__kprobe_instance
ffffffff80661348 d per_cpu__taskstats_seqnum
ffffffff80661360 d per_cpu__ratelimits.18857
ffffffff80661380 d per_cpu__committed_space
ffffffff806613a0 d per_cpu__lru_add_pvecs
ffffffff80661420 d per_cpu__lru_add_active_pvecs
ffffffff806614a0 d per_cpu__lru_add_tail_pvecs
ffffffff80661520 D per_cpu__vm_event_states
ffffffff80661640 d per_cpu__reap_work
ffffffff806616a0 d per_cpu__reap_node
ffffffff806616c0 d per_cpu__bh_lrus
ffffffff80661700 d per_cpu__bh_accounting
ffffffff80661720 d per_cpu__fdtable_defer_list
ffffffff806617c0 d per_cpu__blk_cpu_done
ffffffff806617e0 D per_cpu__radix_tree_preloads
ffffffff80661860 d per_cpu__trickle_count
ffffffff80661864 d per_cpu__proc_event_counts
ffffffff80661880 d per_cpu__loopback_stats
ffffffff80661980 d per_cpu__sockets_in_use
ffffffff80661a00 D per_cpu__softnet_data
ffffffff80662000 D per_cpu__netdev_rx_stat
ffffffff80662010 d per_cpu__net_rand_state
ffffffff80662080 d per_cpu__flow_tables
ffffffff80662100 d per_cpu__flow_hash_info
ffffffff80662180 d per_cpu__flow_flush_tasklets
ffffffff806621c0 d per_cpu__rt_cache_stat
ffffffff80662200 d per_cpu____icmp_socket
ffffffff80662208 A __per_cpu_end
Thanks,
Keith
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 0:05 ` 2.6.17-mm6 Keith Mannthey
@ 2006-07-06 0:25 ` Andrew Morton
2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman
2006-07-12 3:55 ` 2.6.17-mm6 Steven Rostedt
0 siblings, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 0:25 UTC (permalink / raw)
To: Keith Mannthey
Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman
On Wed, 5 Jul 2006 17:05:49 -0700
"Keith Mannthey" <kmannth@gmail.com> wrote:
> On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
> > On Wed, 5 Jul 2006 16:44:57 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> > > I guess a medium-term fix would be to add a boot parameter to override
> > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
> > > for the benefit of the tiny minority of kernels which are hand-built with
> > > lots of drivers in vmlinux.
>
> I am not really loading alot of drivers. I am building with a ton of driver.
> >
> > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded
> > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will
> > blow it as well.
> >
> > > But first let's find out where it all went.
> >
> > I agree with that person.
> :)
>
> This is what I get it is diffrent that yours for sure. I am a little
> confused by the large offset change near the start.....?
Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output
looks OK though.
> elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu
>...
> ffffffff80658000 A __per_cpu_start It starts here
> ffffffff80658000 D per_cpu__init_tss 8k
> ffffffff8065a080 d per_cpu__idle_state
> ffffffff8065a084 d per_cpu__cpu_idle_state
> ffffffff8065a0a0 D per_cpu__vector_irq
> ffffffff8065a4a0 D per_cpu__device_mce
> ffffffff8065a518 d per_cpu__next_check
> ffffffff8065a520 d per_cpu__threshold_banks
> ffffffff8065a550 d per_cpu__bank_map
> ffffffff8065a580 d per_cpu__flush_state
> ffffffff8065a600 D per_cpu__cpu_state
> ffffffff8065a620 d per_cpu__perfctr_nmi_owner
> ffffffff8065a624 d per_cpu__evntsel_nmi_owner
> ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk
> ffffffff8065a660 d per_cpu__last_irq_sum
> ffffffff8065a668 d per_cpu__alert_counter
> ffffffff8065a670 d per_cpu__nmi_touch
> ffffffff8065a680 D per_cpu__current_kprobe
> ffffffff8065a6a0 D per_cpu__kprobe_ctlblk
> ffffffff8065a7e0 D per_cpu__mmu_gathers 4k
> ffffffff8065b7e0 d per_cpu__runqueues 5k
> ffffffff8065ca60 d per_cpu__cpu_domains
> ffffffff8065cae0 d per_cpu__core_domains
> ffffffff8065cb60 d per_cpu__phys_domains
> ffffffff8065cbe0 d per_cpu__node_domains
> ffffffff8065cc60 d per_cpu__allnodes_domains
> ffffffff8065cce0 D per_cpu__kstat wham - 17.5k
> ffffffff80661120 D per_cpu__process_counts
> ffffffff80661130 d per_cpu__cpu_profile_hits
> ffffffff80661140 d per_cpu__cpu_profile_flip
> ffffffff80661148 d per_cpu__tasklet_vec
> ffffffff80661150 d per_cpu__tasklet_hi_vec
> ffffffff80661158 d per_cpu__ksoftirqd
> ffffffff80661160 d per_cpu__tvec_bases
> ffffffff80661180 D per_cpu__rcu_data
> ffffffff80661200 D per_cpu__rcu_bh_data
> ffffffff80661280 d per_cpu__rcu_tasklet
> ffffffff806612c0 d per_cpu__hrtimer_bases
> ffffffff80661340 d per_cpu__kprobe_instance
> ffffffff80661348 d per_cpu__taskstats_seqnum
> ffffffff80661360 d per_cpu__ratelimits.18857
> ffffffff80661380 d per_cpu__committed_space
> ffffffff806613a0 d per_cpu__lru_add_pvecs
> ffffffff80661420 d per_cpu__lru_add_active_pvecs
> ffffffff806614a0 d per_cpu__lru_add_tail_pvecs
> ffffffff80661520 D per_cpu__vm_event_states
> ffffffff80661640 d per_cpu__reap_work
> ffffffff806616a0 d per_cpu__reap_node
> ffffffff806616c0 d per_cpu__bh_lrus
> ffffffff80661700 d per_cpu__bh_accounting
> ffffffff80661720 d per_cpu__fdtable_defer_list
> ffffffff806617c0 d per_cpu__blk_cpu_done
> ffffffff806617e0 D per_cpu__radix_tree_preloads
> ffffffff80661860 d per_cpu__trickle_count
> ffffffff80661864 d per_cpu__proc_event_counts
> ffffffff80661880 d per_cpu__loopback_stats
> ffffffff80661980 d per_cpu__sockets_in_use
> ffffffff80661a00 D per_cpu__softnet_data
> ffffffff80662000 D per_cpu__netdev_rx_stat
> ffffffff80662010 d per_cpu__net_rand_state
> ffffffff80662080 d per_cpu__flow_tables
> ffffffff80662100 d per_cpu__flow_hash_info
> ffffffff80662180 d per_cpu__flow_flush_tasklets
> ffffffff806621c0 d per_cpu__rt_cache_stat
> ffffffff80662200 d per_cpu____icmp_socket
> ffffffff80662208 A __per_cpu_end
So you've been hit by the expansion of NR_IRQS which bloats kernel_stat
which gobbles per-cpu data.
In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion)
NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became
two-dimensional. It's now O(NR_CPUS^2).
I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a
showstopper if the ia64 guys try the same trick.
I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or
dynamically allocate it with alloc_percpu().
(cc's people, runs away)
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 5:42 ` Eric W. Biederman
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
2006-07-06 17:16 ` 2.6.17-mm6 Andi Kleen
2006-07-12 3:55 ` 2.6.17-mm6 Steven Rostedt
1 sibling, 2 replies; 126+ messages in thread
From: Eric W. Biederman @ 2006-07-06 5:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner,
Protasevich, Natalie
Andrew Morton <akpm@osdl.org> writes:
> On Wed, 5 Jul 2006 17:05:49 -0700
> "Keith Mannthey" <kmannth@gmail.com> wrote:
>
>> On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
>> > On Wed, 5 Jul 2006 16:44:57 -0700
>> > Andrew Morton <akpm@osdl.org> wrote:
>> >
>> > > I guess a medium-term fix would be to add a boot parameter to override
>> > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
>> > > for the benefit of the tiny minority of kernels which are hand-built with
>> > > lots of drivers in vmlinux.
>>
>> I am not really loading alot of drivers. I am building with a ton of driver.
>> >
>> > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded
>> > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will
>> > blow it as well.
>> >
>> > > But first let's find out where it all went.
>> >
>> > I agree with that person.
>> :)
>>
>> This is what I get it is diffrent that yours for sure. I am a little
>> confused by the large offset change near the start.....?
>
> Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output
> looks OK though.
>
>> elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu
>>...
>> ffffffff80658000 A __per_cpu_start It starts here
>> ffffffff80658000 D per_cpu__init_tss 8k
>> ffffffff8065a080 d per_cpu__idle_state
>> ffffffff8065a084 d per_cpu__cpu_idle_state
>> ffffffff8065a0a0 D per_cpu__vector_irq
>> ffffffff8065a4a0 D per_cpu__device_mce
>> ffffffff8065a518 d per_cpu__next_check
>> ffffffff8065a520 d per_cpu__threshold_banks
>> ffffffff8065a550 d per_cpu__bank_map
>> ffffffff8065a580 d per_cpu__flush_state
>> ffffffff8065a600 D per_cpu__cpu_state
>> ffffffff8065a620 d per_cpu__perfctr_nmi_owner
>> ffffffff8065a624 d per_cpu__evntsel_nmi_owner
>> ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk
>> ffffffff8065a660 d per_cpu__last_irq_sum
>> ffffffff8065a668 d per_cpu__alert_counter
>> ffffffff8065a670 d per_cpu__nmi_touch
>> ffffffff8065a680 D per_cpu__current_kprobe
>> ffffffff8065a6a0 D per_cpu__kprobe_ctlblk
>> ffffffff8065a7e0 D per_cpu__mmu_gathers 4k
>> ffffffff8065b7e0 d per_cpu__runqueues 5k
>> ffffffff8065ca60 d per_cpu__cpu_domains
>> ffffffff8065cae0 d per_cpu__core_domains
>> ffffffff8065cb60 d per_cpu__phys_domains
>> ffffffff8065cbe0 d per_cpu__node_domains
>> ffffffff8065cc60 d per_cpu__allnodes_domains
>> ffffffff8065cce0 D per_cpu__kstat wham - 17.5k
>> ffffffff80661120 D per_cpu__process_counts
>> ffffffff80661130 d per_cpu__cpu_profile_hits
>> ffffffff80661140 d per_cpu__cpu_profile_flip
>> ffffffff80661148 d per_cpu__tasklet_vec
>> ffffffff80661150 d per_cpu__tasklet_hi_vec
>> ffffffff80661158 d per_cpu__ksoftirqd
>> ffffffff80661160 d per_cpu__tvec_bases
>> ffffffff80661180 D per_cpu__rcu_data
>> ffffffff80661200 D per_cpu__rcu_bh_data
>> ffffffff80661280 d per_cpu__rcu_tasklet
>> ffffffff806612c0 d per_cpu__hrtimer_bases
>> ffffffff80661340 d per_cpu__kprobe_instance
>> ffffffff80661348 d per_cpu__taskstats_seqnum
>> ffffffff80661360 d per_cpu__ratelimits.18857
>> ffffffff80661380 d per_cpu__committed_space
>> ffffffff806613a0 d per_cpu__lru_add_pvecs
>> ffffffff80661420 d per_cpu__lru_add_active_pvecs
>> ffffffff806614a0 d per_cpu__lru_add_tail_pvecs
>> ffffffff80661520 D per_cpu__vm_event_states
>> ffffffff80661640 d per_cpu__reap_work
>> ffffffff806616a0 d per_cpu__reap_node
>> ffffffff806616c0 d per_cpu__bh_lrus
>> ffffffff80661700 d per_cpu__bh_accounting
>> ffffffff80661720 d per_cpu__fdtable_defer_list
>> ffffffff806617c0 d per_cpu__blk_cpu_done
>> ffffffff806617e0 D per_cpu__radix_tree_preloads
>> ffffffff80661860 d per_cpu__trickle_count
>> ffffffff80661864 d per_cpu__proc_event_counts
>> ffffffff80661880 d per_cpu__loopback_stats
>> ffffffff80661980 d per_cpu__sockets_in_use
>> ffffffff80661a00 D per_cpu__softnet_data
>> ffffffff80662000 D per_cpu__netdev_rx_stat
>> ffffffff80662010 d per_cpu__net_rand_state
>> ffffffff80662080 d per_cpu__flow_tables
>> ffffffff80662100 d per_cpu__flow_hash_info
>> ffffffff80662180 d per_cpu__flow_flush_tasklets
>> ffffffff806621c0 d per_cpu__rt_cache_stat
>> ffffffff80662200 d per_cpu____icmp_socket
>> ffffffff80662208 A __per_cpu_end
>
> So you've been hit by the expansion of NR_IRQS which bloats kernel_stat
> which gobbles per-cpu data.
>
> In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion)
> NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became
> two-dimensional. It's now O(NR_CPUS^2).
Hmm. Perhaps it is a good thing I didn't push it to it's limit
of 244*NR_CPUS.
> I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a
> showstopper if the ia64 guys try the same trick.
I think the unisys boxes are about 128 sockets. So 128 or 256 is the
max at the moment. I'm not certain where things are heading. Big
specialized boxes seem to be giving way to smaller systems. Yet the
amount that you can do with commodity hardware is getting larger,
so I suspect it will likely be a wash. The worst case scenario
is that sgi will build a chipset supporting 32K cpus that works with
both Xeons and Itaniums.
> I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or
> dynamically allocate it with alloc_percpu().
Hmm. It might make sense to have a NR_CPUS array in each irq_desc.
We already have a per cpu bit map so that should only make the irq
array about 32 times bigger, but it would take it out of the
per_cpu area.
To get to 17k that took a 128 cpu build. 128 cpus looks reasonable
for a build for the maximum number of cpus.
On x86_64 when we have more than 8 cpus (aka cores) all of the
moving between cpus is done is software which means we are
not too likely to move between cpus. In any sane configuration
an irq will stay on the same cpu or the same couple of cpus
so we get good locality effects (especially NUMA locality),
so there might be something we can take advantage of there.
Possibly we might want to just live with this for now.
But a data structure that ultimately consumes 244*NR_CPUS*NR_CPUS*4
bytes looks excessive.
32*NR_CPUS has been the expected number of irq sources for a long time
but previously we forced sharing of the irq number after a point.
So I think that is a fairly reasonable number. Although 8*NR_CPUS may
be more reasonable. But the bottom line is that the more cpus we have
the interrupts we can handle and quite likely the more interrupts we
will need to handle to keep the system busy.
So NR_IRQS should scale with the number of cpus.
So I suspect that we need to de-percpuify kernel_stat.irqs.
Possibly setup a set of counters that hold the count on the current
cpu and the total count across also cpus, and we update the count
whenever we migrate the cpu. Possibly we could hold counts for the last
2 or 3 cpus.
I don't know how realistic it is to assume that an irq will be bound
to a cpu on all architectures. So we might have to do it dynamically.
I'm tempted to suggest adding the following to irq_desc.
unsigned int last_cpu_count;
unsigned int last_cpu;
And just rely on those and the total irq count we already seem
to have in the irq_count field of struct irq_desc, for the statistics.
That would allow us to see where an irq is occurring and how frequently
without bloating things up. Of course that is lossy.
> (cc's people, runs away)
(throws out ideas, runs after Andrew)
Eric
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman
@ 2006-07-06 5:59 ` Andrew Morton
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
` (2 more replies)
2006-07-06 17:16 ` 2.6.17-mm6 Andi Kleen
1 sibling, 3 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 5:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich
On Wed, 05 Jul 2006 23:42:00 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:
> So I suspect that we need to de-percpuify kernel_stat.irqs.
I think so. We do:
struct irq_desc *desc = irq_desc + irq;
kstat_this_cpu.irqs[irq]++;
followed immediately by
spin_lock(&desc->lock);
false optimisation, or what?
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 6:31 ` Andrew Morton
2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 16:49 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 6:40 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 7:38 ` 2.6.17-mm6 vmstat breakage Mike Galbraith
2 siblings, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 6:31 UTC (permalink / raw)
To: ebiederm, kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich
On Wed, 5 Jul 2006 22:59:05 -0700
Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 05 Jul 2006 23:42:00 -0600
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> > So I suspect that we need to de-percpuify kernel_stat.irqs.
>
> I think so.
Maybe not. If we do this, we lose the pretty CPUn columns in
/proc/interrupts. That /proc/interrupts display requires that we maintain
NR_CPUS*NR_IRQS counters.
Given that a large NR_IRQs space will be sparsely populated, we should
dynamically allocate the NR_CPUS storage for each active IRQ, as you say.
That involves putting it into the irq_desc (as good a place as any). And a
rather large number of trivial edits. I guess we do this only for genirq?
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 7:18 ` Eric W. Biederman
2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar
2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven
2006-07-06 16:49 ` 2.6.17-mm6 Eric W. Biederman
1 sibling, 2 replies; 126+ messages in thread
From: Eric W. Biederman @ 2006-07-06 7:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich
Andrew Morton <akpm@osdl.org> writes:
> On Wed, 5 Jul 2006 22:59:05 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
>> On Wed, 05 Jul 2006 23:42:00 -0600
>> ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>> > So I suspect that we need to de-percpuify kernel_stat.irqs.
>>
>> I think so.
>
> Maybe not. If we do this, we lose the pretty CPUn columns in
> /proc/interrupts. That /proc/interrupts display requires that we maintain
> NR_CPUS*NR_IRQS counters.
Yes. Although at least part of that display is per architecture
so we may be able to get away with a little more.
> Given that a large NR_IRQs space will be sparsely populated, we should
> dynamically allocate the NR_CPUS storage for each active IRQ, as you say.
To some extent. Although with MSI-X there is the potential we could use
all of them. (But probably not).
Natalie has a firmer grasp on what is common that I do.
But I think the big Unisys boxes were running 1-2 active irqs per
cpu, and I believe some large IBM boxes were worse.
What is scary is that at 1K cpus if we wind up using all of the irqs
we start consuming 1Gig of RAM. At only 128 cpus we are still in the 2M-15M
territory, so that isn't too scary. The point is that after a certain
put the memory usage for all of those counters goes insane.
So I'm not certain how safe it is to leave something that explodes that badly
in there.
We at least need a big fat scary comment and probably something like
#if (NR_IRQS*NR_CPUS) > 1000000
#error ouch! NR_IRQS*NR_CPUS too large.
#endif
> That involves putting it into the irq_desc (as good a place as any). And a
> rather large number of trivial edits. I guess we do this only for genirq?
Probably. The potential has always been there, but it clearly wasn't
unlocked until just recently.
If we find a cheap solution then we can do something.
As a short term thing I am tempted to say just:
#define NR_IRQS (256 + (NR_CPUS*8))
Which would reduce kstat_irqs to 5k, and would relieve the immediate
symptoms.
Eric
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman
@ 2006-07-06 7:25 ` Ingo Molnar
2006-07-06 8:21 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven
1 sibling, 1 reply; 126+ messages in thread
From: Ingo Molnar @ 2006-07-06 7:25 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andrew Morton, kmannth, linux-kernel, tglx, Natalie.Protasevich
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> What is scary is that at 1K cpus if we wind up using all of the irqs
> we start consuming 1Gig of RAM. At only 128 cpus we are still in the
> 2M-15M territory, so that isn't too scary. The point is that after a
> certain put the memory usage for all of those counters goes insane.
we just need to move kernel_stat.irqs out of the per-cpu area and
alloc_percpu() a counter pointer for each IRQ that is truly set up. If
someone ends up using more than say 10,000 irqs we can reconsider. With
10K irqs we'd have 10MB of stat counter footprint - that's reasonable.
Ingo
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar
@ 2006-07-06 8:21 ` Eric W. Biederman
2006-07-06 8:26 ` 2.6.17-mm6 Ingo Molnar
0 siblings, 1 reply; 126+ messages in thread
From: Eric W. Biederman @ 2006-07-06 8:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, kmannth, linux-kernel, tglx, Natalie.Protasevich
Ingo Molnar <mingo@elte.hu> writes:
> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> What is scary is that at 1K cpus if we wind up using all of the irqs
>> we start consuming 1Gig of RAM. At only 128 cpus we are still in the
>> 2M-15M territory, so that isn't too scary. The point is that after a
>> certain put the memory usage for all of those counters goes insane.
>
> we just need to move kernel_stat.irqs out of the per-cpu area and
> alloc_percpu() a counter pointer for each IRQ that is truly set up. If
> someone ends up using more than say 10,000 irqs we can reconsider. With
> 10K irqs we'd have 10MB of stat counter footprint - that's reasonable.
Hmm. at 10,000 IRQs and 128 cpus I got about 5MB. But close enough.
I'm convinced at least for now.
The case I have seen are sparsely populated irqs.
And we really do need the high IRQ counts because the potential irqs
really do go up at 15 or so IRQs per cpu.
Still if we are doing this generically let's please put in a
big fat comment describing the situation, and maybe a compile warning,
if things get too big.
Eric
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar
@ 2006-07-06 7:31 ` Arjan van de Ven
2006-07-06 16:37 ` 2.6.17-mm6 Valdis.Kletnieks
1 sibling, 1 reply; 126+ messages in thread
From: Arjan van de Ven @ 2006-07-06 7:31 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andrew Morton, kmannth, linux-kernel, mingo, tglx,
Natalie.Protasevich
On Thu, 2006-07-06 at 01:18 -0600, Eric W. Biederman wrote:
Hi,
> Andrew Morton <akpm@osdl.org> writes:
>
> > On Wed, 5 Jul 2006 22:59:05 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> >> On Wed, 05 Jul 2006 23:42:00 -0600
> >> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >>
> >> > So I suspect that we need to de-percpuify kernel_stat.irqs.
> >>
> >> I think so.
> >
> > Maybe not. If we do this, we lose the pretty CPUn columns in
> > /proc/interrupts. That /proc/interrupts display requires that we maintain
> > NR_CPUS*NR_IRQS counters.
>
> Yes. Although at least part of that display is per architecture
> so we may be able to get away with a little more.
irqbalance uses the per column data for it's work.. please don't kill
the information or format.
Also if you have 1 number per irq, you keep bouncing that cacheline
around *all the time* if your irq policy is set to rotating (as many
chipsets do by default unless the OS overrides it)
Greetings,
Arjan van de Ven
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven
@ 2006-07-06 16:37 ` Valdis.Kletnieks
0 siblings, 0 replies; 126+ messages in thread
From: Valdis.Kletnieks @ 2006-07-06 16:37 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Eric W. Biederman, Andrew Morton, kmannth, linux-kernel, mingo,
tglx, Natalie.Protasevich
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On Thu, 06 Jul 2006 09:31:15 +0200, Arjan van de Ven said:
> On Thu, 2006-07-06 at 01:18 -0600, Eric W. Biederman wrote:
w
> > Yes. Although at least part of that display is per architecture
> > so we may be able to get away with a little more.
>
> irqbalance uses the per column data for it's work.. please don't kill
> the information or format.
Does irqbalance have a snowball's chance of doing anything sane on the
moby-CPU moby-IRQ boxes under discussion here? How well does it do when
faced with 10K IRQs on 1K CPUs?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman
@ 2006-07-06 16:49 ` Eric W. Biederman
1 sibling, 0 replies; 126+ messages in thread
From: Eric W. Biederman @ 2006-07-06 16:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich
Andrew Morton <akpm@osdl.org> writes:
> Maybe not. If we do this, we lose the pretty CPUn columns in
> /proc/interrupts. That /proc/interrupts display requires that we maintain
> NR_CPUS*NR_IRQS counters.
>
> Given that a large NR_IRQs space will be sparsely populated, we should
> dynamically allocate the NR_CPUS storage for each active IRQ, as you say.
>
> That involves putting it into the irq_desc (as good a place as any). And a
> rather large number of trivial edits. I guess we do this only for genirq?
Actually I rechecked. There is one alpha box that defines
NR_IRQS to be 32K. Which should hit this same problem if anyone
ever compiles it.
So this may actually seems to be an issue independent of genirq.
Eric
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 6:40 ` Eric W. Biederman
2006-07-06 7:38 ` 2.6.17-mm6 vmstat breakage Mike Galbraith
2 siblings, 0 replies; 126+ messages in thread
From: Eric W. Biederman @ 2006-07-06 6:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich
Andrew Morton <akpm@osdl.org> writes:
> On Wed, 05 Jul 2006 23:42:00 -0600
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> So I suspect that we need to de-percpuify kernel_stat.irqs.
>
> I think so. We do:
>
> struct irq_desc *desc = irq_desc + irq;
>
> kstat_this_cpu.irqs[irq]++;
>
> followed immediately by
>
> spin_lock(&desc->lock);
>
> false optimisation, or what?
As an optimization I can't think of a reason.
It is kind of interesting to report that information by cpu.
in /proc/interrupts (see show_interrupts).
But except for understanding system behavior I can't think of a reason
for reporting that information.
It was useful information to have when debugging the irq migration code.
Eric
^ permalink raw reply [flat|nested] 126+ messages in thread
* 2.6.17-mm6 vmstat breakage
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
2006-07-06 6:40 ` 2.6.17-mm6 Eric W. Biederman
@ 2006-07-06 7:38 ` Mike Galbraith
2006-07-06 8:24 ` Andrew Morton
2 siblings, 1 reply; 126+ messages in thread
From: Mike Galbraith @ 2006-07-06 7:38 UTC (permalink / raw)
To: lkml
Greetings,
My single P4/HT box is showing incorrect pgpgin pgpgout numbers with
this kernel. While disk throughput for dd if=/dev/hdc of=/dev=null
bs=4096 count=1000000 produces about 57MB/S (up ~14% over 2.6.17 btw),
vmstat (procps version 3.2.5) is only showing about 7MB/S.
Looking at the numbers in /proc/vmstat, it looks kinda like pgpgin might
be pages instead of the KB it used to be, with some added >>=1 action on
the side. At any rate, the numbers below are horse-pookey ;-)
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 1 3820 9400 810128 46052 0 0 7040 0 1163 1283 2 7 48 44
1 1 3820 9220 810288 46156 0 0 7040 0 1151 1335 3 6 48 45
1 1 3820 9280 810176 46204 0 0 7168 0 1156 1207 1 7 48 44
2 1 3820 9408 810048 46068 0 0 7168 0 1160 1192 1 6 49 46
-Mike
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6 vmstat breakage
2006-07-06 7:38 ` 2.6.17-mm6 vmstat breakage Mike Galbraith
@ 2006-07-06 8:24 ` Andrew Morton
0 siblings, 0 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-06 8:24 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-kernel
On Thu, 06 Jul 2006 09:38:43 +0200
Mike Galbraith <efault@gmx.de> wrote:
> Greetings,
>
> My single P4/HT box is showing incorrect pgpgin pgpgout numbers with
> this kernel. While disk throughput for dd if=/dev/hdc of=/dev=null
> bs=4096 count=1000000 produces about 57MB/S (up ~14% over 2.6.17 btw),
> vmstat (procps version 3.2.5) is only showing about 7MB/S.
>
> Looking at the numbers in /proc/vmstat, it looks kinda like pgpgin might
> be pages instead of the KB it used to be, with some added >>=1 action on
> the side. At any rate, the numbers below are horse-pookey ;-)
>
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy id wa
> 1 1 3820 9400 810128 46052 0 0 7040 0 1163 1283 2 7 48 44
> 1 1 3820 9220 810288 46156 0 0 7040 0 1151 1335 3 6 48 45
> 1 1 3820 9280 810176 46204 0 0 7168 0 1156 1207 1 7 48 44
> 2 1 3820 9408 810048 46068 0 0 7168 0 1160 1192 1 6 49 46
>
2.6.18-rc1 has the same bug.
--- a/include/linux/vmstat.h~count_vm_events-fix
+++ a/include/linux/vmstat.h
@@ -57,7 +57,7 @@ static inline void __count_vm_events(enu
static inline void count_vm_events(enum vm_event_item item, long delta)
{
- get_cpu_var(vm_event_states.event[item])++;
+ get_cpu_var(vm_event_states.event[item]) += delta;
put_cpu();
}
_
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-06 17:16 ` Andi Kleen
1 sibling, 0 replies; 126+ messages in thread
From: Andi Kleen @ 2006-07-06 17:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner,
Protasevich, Natalie, akpm
ebiederm@xmission.com (Eric W. Biederman) writes:
> Andrew Morton <akpm@osdl.org> writes:
>
> > On Wed, 5 Jul 2006 17:05:49 -0700
> > "Keith Mannthey" <kmannth@gmail.com> wrote:
> >
> >> On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
> >> > On Wed, 5 Jul 2006 16:44:57 -0700
> >> > Andrew Morton <akpm@osdl.org> wrote:
> >> >
> >> > > I guess a medium-term fix would be to add a boot parameter to override
> >> > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
> >> > > for the benefit of the tiny minority of kernels which are hand-built with
> >> > > lots of drivers in vmlinux.
> >>
> >> I am not really loading alot of drivers. I am building with a ton of driver.
> >> >
> >> > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded
> >> > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will
> >> > blow it as well.
> >> >
> >> > > But first let's find out where it all went.
> >> >
> >> > I agree with that person.
> >> :)
> >>
> >> This is what I get it is diffrent that yours for sure. I am a little
> >> confused by the large offset change near the start.....?
> >
> > Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output
> > looks OK though.
> >
> >> elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu
> >>...
> >> ffffffff80658000 A __per_cpu_start It starts here
> >> ffffffff80658000 D per_cpu__init_tss 8k
> >> ffffffff8065a080 d per_cpu__idle_state
> >> ffffffff8065a084 d per_cpu__cpu_idle_state
> >> ffffffff8065a0a0 D per_cpu__vector_irq
> >> ffffffff8065a4a0 D per_cpu__device_mce
> >> ffffffff8065a518 d per_cpu__next_check
> >> ffffffff8065a520 d per_cpu__threshold_banks
> >> ffffffff8065a550 d per_cpu__bank_map
> >> ffffffff8065a580 d per_cpu__flush_state
> >> ffffffff8065a600 D per_cpu__cpu_state
> >> ffffffff8065a620 d per_cpu__perfctr_nmi_owner
> >> ffffffff8065a624 d per_cpu__evntsel_nmi_owner
> >> ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk
> >> ffffffff8065a660 d per_cpu__last_irq_sum
> >> ffffffff8065a668 d per_cpu__alert_counter
> >> ffffffff8065a670 d per_cpu__nmi_touch
> >> ffffffff8065a680 D per_cpu__current_kprobe
> >> ffffffff8065a6a0 D per_cpu__kprobe_ctlblk
> >> ffffffff8065a7e0 D per_cpu__mmu_gathers 4k
> >> ffffffff8065b7e0 d per_cpu__runqueues 5k
> >> ffffffff8065ca60 d per_cpu__cpu_domains
> >> ffffffff8065cae0 d per_cpu__core_domains
> >> ffffffff8065cb60 d per_cpu__phys_domains
> >> ffffffff8065cbe0 d per_cpu__node_domains
> >> ffffffff8065cc60 d per_cpu__allnodes_domains
> >> ffffffff8065cce0 D per_cpu__kstat wham - 17.5k
> >> ffffffff80661120 D per_cpu__process_counts
> >> ffffffff80661130 d per_cpu__cpu_profile_hits
> >> ffffffff80661140 d per_cpu__cpu_profile_flip
> >> ffffffff80661148 d per_cpu__tasklet_vec
> >> ffffffff80661150 d per_cpu__tasklet_hi_vec
> >> ffffffff80661158 d per_cpu__ksoftirqd
> >> ffffffff80661160 d per_cpu__tvec_bases
> >> ffffffff80661180 D per_cpu__rcu_data
> >> ffffffff80661200 D per_cpu__rcu_bh_data
> >> ffffffff80661280 d per_cpu__rcu_tasklet
> >> ffffffff806612c0 d per_cpu__hrtimer_bases
> >> ffffffff80661340 d per_cpu__kprobe_instance
> >> ffffffff80661348 d per_cpu__taskstats_seqnum
> >> ffffffff80661360 d per_cpu__ratelimits.18857
> >> ffffffff80661380 d per_cpu__committed_space
> >> ffffffff806613a0 d per_cpu__lru_add_pvecs
> >> ffffffff80661420 d per_cpu__lru_add_active_pvecs
> >> ffffffff806614a0 d per_cpu__lru_add_tail_pvecs
> >> ffffffff80661520 D per_cpu__vm_event_states
> >> ffffffff80661640 d per_cpu__reap_work
> >> ffffffff806616a0 d per_cpu__reap_node
> >> ffffffff806616c0 d per_cpu__bh_lrus
> >> ffffffff80661700 d per_cpu__bh_accounting
> >> ffffffff80661720 d per_cpu__fdtable_defer_list
> >> ffffffff806617c0 d per_cpu__blk_cpu_done
> >> ffffffff806617e0 D per_cpu__radix_tree_preloads
> >> ffffffff80661860 d per_cpu__trickle_count
> >> ffffffff80661864 d per_cpu__proc_event_counts
> >> ffffffff80661880 d per_cpu__loopback_stats
> >> ffffffff80661980 d per_cpu__sockets_in_use
> >> ffffffff80661a00 D per_cpu__softnet_data
> >> ffffffff80662000 D per_cpu__netdev_rx_stat
> >> ffffffff80662010 d per_cpu__net_rand_state
> >> ffffffff80662080 d per_cpu__flow_tables
> >> ffffffff80662100 d per_cpu__flow_hash_info
> >> ffffffff80662180 d per_cpu__flow_flush_tasklets
> >> ffffffff806621c0 d per_cpu__rt_cache_stat
> >> ffffffff80662200 d per_cpu____icmp_socket
> >> ffffffff80662208 A __per_cpu_end
> >
> > So you've been hit by the expansion of NR_IRQS which bloats kernel_stat
> > which gobbles per-cpu data.
> >
> > In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion)
> > NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became
> > two-dimensional. It's now O(NR_CPUS^2).
>
> Hmm. Perhaps it is a good thing I didn't push it to it's limit
> of 244*NR_CPUS.
Clearly it just needs to be dynamically allocated and only
for interrupts that are actually used.
e.g. a 2 level array scheme?
Just need to make sure the memory overhead for small systems stays reasonable.
>
> > I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a
> > showstopper if the ia64 guys try the same trick.
>
> I think the unisys boxes are about 128 sockets.
64 I thought. Newisys also plans 64 socket boxes.
> So 128 or 256 is the
> max at the moment. I'm not certain where things are heading. Big
> specialized boxes seem to be giving way to smaller systems. Yet the
> amount that you can do with commodity hardware is getting larger,
> so I suspect it will likely be a wash. The worst case scenario
> is that sgi will build a chipset supporting 32K cpus that works with
> both Xeons and Itaniums.
Currently x86 has a 8 bit APIC limit. So 255 is max.
But at some point I expect it will be broken, not with sockets
but with multicores and threads.
On the other hand it might be reasonable to size the NR_CPUs
only by sockets. The would lower the memory requirements.
>
> I'm tempted to suggest adding the following to irq_desc.
> unsigned int last_cpu_count;
> unsigned int last_cpu;
Add all the statistics to irq_desc?
-Andi
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton
2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman
@ 2006-07-12 3:55 ` Steven Rostedt
1 sibling, 0 replies; 126+ messages in thread
From: Steven Rostedt @ 2006-07-12 3:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner,
Eric W. Biederman
On Wed, 2006-07-05 at 17:25 -0700, Andrew Morton wrote:
> On Wed, 5 Jul 2006 17:05:49 -0700
> "Keith Mannthey" <kmannth@gmail.com> wrote:
>
> > On 7/5/06, Andrew Morton <akpm@osdl.org> wrote:
> > > On Wed, 5 Jul 2006 16:44:57 -0700
> > > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > > I guess a medium-term fix would be to add a boot parameter to override
> > > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just
> > > > for the benefit of the tiny minority of kernels which are hand-built with
> > > > lots of drivers in vmlinux.
> >
[snip]
>
> So you've been hit by the expansion of NR_IRQS which bloats kernel_stat
> which gobbles per-cpu data.
>
> In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion)
> NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became
> two-dimensional. It's now O(NR_CPUS^2).
>
> I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a
> showstopper if the ia64 guys try the same trick.
>
> I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or
> dynamically allocate it with alloc_percpu().
And people wondered why I'm fighting for the robust per_cpu variables.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114785997413023&w=2
Yes there's still problems with this. But if I ever get some more time
to work on it, I would like to solve those issues. Having that
PERCPU_ENOUGH_ROOM laying around in the kernel is just disgusting ;)
Sorry, for the noise, I have another 2288 more LKML emails to read :)
-- Steve
^ permalink raw reply [flat|nested] 126+ messages in thread
* [-mm patch] drivers/edac/: make code static
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (8 preceding siblings ...)
[not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>
@ 2006-07-06 20:36 ` Adrian Bunk
2006-07-06 20:37 ` [-mm patch] fs/ocfs2/inode.c:ocfs2_refresh_inode(): remove unused variable Adrian Bunk
` (5 subsequent siblings)
15 siblings, 0 replies; 126+ messages in thread
From: Adrian Bunk @ 2006-07-06 20:36 UTC (permalink / raw)
To: Andrew Morton, norsk5; +Cc: linux-kernel, bluesmoke-devel
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/edac/edac_mc.c | 25 +++++++++++--------------
drivers/edac/edac_mc.h | 8 --------
drivers/edac/k8_edac.c | 2 +-
3 files changed, 12 insertions(+), 23 deletions(-)
--- linux-2.6.17-mm6-full/drivers/edac/edac_mc.h.old 2006-07-06 19:31:37.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/edac/edac_mc.h 2006-07-06 19:32:43.000000000 +0200
@@ -406,19 +406,11 @@
#endif /* CONFIG_PCI */
-#ifdef CONFIG_EDAC_DEBUG
-void edac_mc_dump_channel(struct channel_info *chan);
-void edac_mc_dump_mci(struct mem_ctl_info *mci);
-void edac_mc_dump_csrow(struct csrow_info *csrow);
-#endif /* CONFIG_EDAC_DEBUG */
-
extern struct mem_ctl_info * edac_mc_find(int idx);
extern int edac_mc_add_mc(struct mem_ctl_info *mci,int mc_idx);
extern struct mem_ctl_info * edac_mc_del_mc(struct device *dev);
extern int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci,
unsigned long page);
-extern void edac_mc_scrub_block(unsigned long page, unsigned long offset,
- u32 size);
/*
* The no info errors are used when error overflows are reported.
--- linux-2.6.17-mm6-full/drivers/edac/edac_mc.c.old 2006-07-06 18:43:39.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/edac/edac_mc.c 2006-07-06 19:33:01.000000000 +0200
@@ -177,7 +177,7 @@
};
#define MEMCTRL_ATTR(_name,_mode,_show,_store) \
-struct memctrl_dev_attribute attr_##_name = { \
+static struct memctrl_dev_attribute attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.value = &_name, \
.show = _show, \
@@ -185,7 +185,7 @@
};
#define MEMCTRL_STRING_ATTR(_name,_data,_mode,_show,_store) \
-struct memctrl_dev_attribute attr_##_name = { \
+static struct memctrl_dev_attribute attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.value = _data, \
.show = _show, \
@@ -333,7 +333,7 @@
};
#define EDAC_PCI_ATTR(_name,_mode,_show,_store) \
-struct edac_pci_dev_attribute edac_pci_attr_##_name = { \
+static struct edac_pci_dev_attribute edac_pci_attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.value = &_name, \
.show = _show, \
@@ -341,7 +341,7 @@
};
#define EDAC_PCI_STRING_ATTR(_name,_data,_mode,_show,_store) \
-struct edac_pci_dev_attribute edac_pci_attr_##_name = { \
+static struct edac_pci_dev_attribute edac_pci_attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.value = _data, \
.show = _show, \
@@ -712,7 +712,7 @@
};
#define CSROWDEV_ATTR(_name,_mode,_show,_store,_private) \
-struct csrowdev_attribute attr_##_name = { \
+static struct csrowdev_attribute attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.show = _show, \
.store = _store, \
@@ -1005,7 +1005,7 @@
};
#define MCIDEV_ATTR(_name,_mode,_show,_store) \
-struct mcidev_attribute mci_attr_##_name = { \
+static struct mcidev_attribute mci_attr_##_name = { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.show = _show, \
.store = _store, \
@@ -1155,7 +1155,7 @@
#ifdef CONFIG_EDAC_DEBUG
-void edac_mc_dump_channel(struct channel_info *chan)
+static void edac_mc_dump_channel(struct channel_info *chan)
{
debugf4("\tchannel = %p\n", chan);
debugf4("\tchannel->chan_idx = %d\n", chan->chan_idx);
@@ -1163,9 +1163,8 @@
debugf4("\tchannel->label = '%s'\n", chan->label);
debugf4("\tchannel->csrow = %p\n\n", chan->csrow);
}
-EXPORT_SYMBOL_GPL(edac_mc_dump_channel);
-void edac_mc_dump_csrow(struct csrow_info *csrow)
+static void edac_mc_dump_csrow(struct csrow_info *csrow)
{
debugf4("\tcsrow = %p\n", csrow);
debugf4("\tcsrow->csrow_idx = %d\n", csrow->csrow_idx);
@@ -1179,9 +1178,8 @@
debugf4("\tcsrow->channels = %p\n", csrow->channels);
debugf4("\tcsrow->mci = %p\n\n", csrow->mci);
}
-EXPORT_SYMBOL_GPL(edac_mc_dump_csrow);
-void edac_mc_dump_mci(struct mem_ctl_info *mci)
+static void edac_mc_dump_mci(struct mem_ctl_info *mci)
{
debugf3("\tmci = %p\n", mci);
debugf3("\tmci->mtype_cap = %lx\n", mci->mtype_cap);
@@ -1195,7 +1193,6 @@
mci->mod_name, mci->ctl_name);
debugf3("\tpvt_info = %p\n\n", mci->pvt_info);
}
-EXPORT_SYMBOL_GPL(edac_mc_dump_mci);
#endif /* CONFIG_EDAC_DEBUG */
@@ -1511,7 +1508,8 @@
}
EXPORT_SYMBOL_GPL(edac_mc_del_mc);
-void edac_mc_scrub_block(unsigned long page, unsigned long offset, u32 size)
+static void edac_mc_scrub_block(unsigned long page, unsigned long offset,
+ u32 size)
{
struct page *pg;
void *virt_addr;
@@ -1540,7 +1538,6 @@
if (PageHighMem(pg))
local_irq_restore(flags);
}
-EXPORT_SYMBOL_GPL(edac_mc_scrub_block);
/* FIXME - should return -1 */
int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci, unsigned long page)
--- linux-2.6.17-mm6-full/drivers/edac/k8_edac.c.old 2006-07-06 19:33:15.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/edac/k8_edac.c 2006-07-06 19:33:39.000000000 +0200
@@ -1864,7 +1864,7 @@
.id_table = k8_pci_tbl,
};
-int __init k8_init(void)
+static int __init k8_init(void)
{
return pci_module_init(&k8_driver);
}
^ permalink raw reply [flat|nested] 126+ messages in thread* [-mm patch] fs/ocfs2/inode.c:ocfs2_refresh_inode(): remove unused variable
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (9 preceding siblings ...)
2006-07-06 20:36 ` [-mm patch] drivers/edac/: make code static Adrian Bunk
@ 2006-07-06 20:37 ` Adrian Bunk
2006-07-06 20:43 ` Mark Fasheh
2006-07-06 20:37 ` [-mm patch] reiserfs: warn about the useless nolargeio option Adrian Bunk
` (4 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Adrian Bunk @ 2006-07-06 20:37 UTC (permalink / raw)
To: Andrew Morton, Theodore Ts'o
Cc: linux-kernel, mark.fasheh, kurt.hackel, ocfs2-devel
On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm5:
>...
> +inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
>...
> Misc updates.
>...
This patch removes a no longer used variable.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm6-full/fs/ocfs2/inode.c.old 2006-07-06 21:10:23.000000000 +0200
+++ linux-2.6.17-mm6-full/fs/ocfs2/inode.c 2006-07-06 21:13:44.000000000 +0200
@@ -1163,8 +1163,6 @@
void ocfs2_refresh_inode(struct inode *inode,
struct ocfs2_dinode *fe)
{
- struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
-
spin_lock(&OCFS2_I(inode)->ip_lock);
OCFS2_I(inode)->ip_clusters = le32_to_cpu(fe->i_clusters);
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [-mm patch] fs/ocfs2/inode.c:ocfs2_refresh_inode(): remove unused variable
2006-07-06 20:37 ` [-mm patch] fs/ocfs2/inode.c:ocfs2_refresh_inode(): remove unused variable Adrian Bunk
@ 2006-07-06 20:43 ` Mark Fasheh
0 siblings, 0 replies; 126+ messages in thread
From: Mark Fasheh @ 2006-07-06 20:43 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Theodore Ts'o, linux-kernel, kurt.hackel,
ocfs2-devel
On Thu, Jul 06, 2006 at 10:37:08PM +0200, Adrian Bunk wrote:
> On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-mm5:
> >...
> > +inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
> >...
> > Misc updates.
> >...
>
> This patch removes a no longer used variable.
Ahh, the osb was only used to set i_blksize, which of course the inode-diet
patches removed. Looks fine to me - thanks Adrian.
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
^ permalink raw reply [flat|nested] 126+ messages in thread
* [-mm patch] reiserfs: warn about the useless nolargeio option
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (10 preceding siblings ...)
2006-07-06 20:37 ` [-mm patch] fs/ocfs2/inode.c:ocfs2_refresh_inode(): remove unused variable Adrian Bunk
@ 2006-07-06 20:37 ` Adrian Bunk
2006-07-07 0:35 ` Hans Reiser
2006-07-06 20:37 ` [-mm patch] drivers/net/e1000/: possible cleanups Adrian Bunk
` (3 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Adrian Bunk @ 2006-07-06 20:37 UTC (permalink / raw)
To: Andrew Morton, Theodore Ts'o; +Cc: linux-kernel, reiserfs-dev
On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm5:
>...
> +inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
>...
> Misc updates.
>...
Since the nolargeio option no longer has any effect, print a warning
instead of setting a write-only variable.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/reiserfs/super.c | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
--- linux-2.6.17-mm6-full/fs/reiserfs/super.c.old 2006-07-06 21:48:48.000000000 +0200
+++ linux-2.6.17-mm6-full/fs/reiserfs/super.c 2006-07-06 21:51:48.000000000 +0200
@@ -721,12 +721,6 @@
{NULL, 0, 0},
};
-int reiserfs_default_io_size = 128 * 1024; /* Default recommended I/O size is 128k.
- There might be broken applications that are
- confused by this. Use nolargeio mount option
- to get usual i/o size = PAGE_SIZE.
- */
-
/* proceed only one option from a list *cur - string containing of mount options
opts - array of options which are accepted
opt_arg - if option is found and requires an argument and if it is specifed
@@ -955,19 +949,8 @@
}
if (c == 'w') {
- char *p = NULL;
- int val = simple_strtoul(arg, &p, 0);
-
- if (*p != '\0') {
- reiserfs_warning(s,
- "reiserfs_parse_options: non-numeric value %s for nolargeio option",
- arg);
- return 0;
- }
- if (val)
- reiserfs_default_io_size = PAGE_SIZE;
- else
- reiserfs_default_io_size = 128 * 1024;
+ reiserfs_warning(s, "reiserfs: nolargeio option is no longer supported");
+ return 0;
}
if (c == 'j') {
^ permalink raw reply [flat|nested] 126+ messages in thread* [-mm patch] drivers/net/e1000/: possible cleanups
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (11 preceding siblings ...)
2006-07-06 20:37 ` [-mm patch] reiserfs: warn about the useless nolargeio option Adrian Bunk
@ 2006-07-06 20:37 ` Adrian Bunk
2006-07-06 20:47 ` Auke Kok
2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly
` (2 subsequent siblings)
15 siblings, 1 reply; 126+ messages in thread
From: Adrian Bunk @ 2006-07-06 20:37 UTC (permalink / raw)
To: Andrew Morton, cramerj, john.ronciak, jesse.brandeburg,
jeffrey.t.kirsher, auke-jan.h.kok
Cc: linux-kernel, jgarzik, netdev
On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm5:
>...
> git-e1000.patch
>...
> git trees.
>...
This patch contains the following possible cleanups:
- make needlessly global functions static
- #if 0 the following unused global functions:
- e1000_hw.c: e1000_mc_addr_list_update()
- e1000_hw.c: e1000_read_reg_io()
- e1000_hw.c: e1000_enable_pciex_master()
- e1000_hw.c: e1000_ife_disable_dynamic_power_down()
- e1000_hw.c: e1000_ife_enable_dynamic_power_down()
- e1000_hw.c: e1000_write_ich8_word()
- e1000_hw.c: e1000_duplex_reversal()
- e1000_main.c: e1000_io_read()
Please review which of these changes do make sense and which do
conflict with pending patches.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/e1000/e1000_hw.c | 89 ++++++++++++++++++++++++---------
drivers/net/e1000/e1000_hw.h | 32 -----------
drivers/net/e1000/e1000_main.c | 2
3 files changed, 67 insertions(+), 56 deletions(-)
--- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.h.old 2006-07-06 21:17:20.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.h 2006-07-06 21:57:18.000000000 +0200
@@ -323,13 +323,8 @@
int32_t e1000_phy_hw_reset(struct e1000_hw *hw);
int32_t e1000_phy_reset(struct e1000_hw *hw);
void e1000_phy_powerdown_workaround(struct e1000_hw *hw);
-int32_t e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw);
-int32_t e1000_init_lcd_from_nvm_config_region(struct e1000_hw *hw, uint32_t cnf_base_addr, uint32_t cnf_size);
-int32_t e1000_init_lcd_from_nvm(struct e1000_hw *hw);
int32_t e1000_phy_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info);
int32_t e1000_validate_mdi_setting(struct e1000_hw *hw);
-int32_t e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t *data);
-int32_t e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data);
/* EEPROM Functions */
int32_t e1000_init_eeprom_params(struct e1000_hw *hw);
@@ -400,13 +395,8 @@
int32_t e1000_write_eeprom(struct e1000_hw *hw, uint16_t reg, uint16_t words, uint16_t *data);
int32_t e1000_read_part_num(struct e1000_hw *hw, uint32_t * part_num);
int32_t e1000_read_mac_addr(struct e1000_hw * hw);
-int32_t e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask);
-void e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask);
-void e1000_release_software_flag(struct e1000_hw *hw);
-int32_t e1000_get_software_flag(struct e1000_hw *hw);
/* Filters (multicast, vlan, receive) */
-void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t * mc_addr_list, uint32_t mc_addr_count, uint32_t pad, uint32_t rar_used_count);
uint32_t e1000_hash_mc_addr(struct e1000_hw *hw, uint8_t * mc_addr);
void e1000_mta_set(struct e1000_hw *hw, uint32_t hash_value);
void e1000_rar_set(struct e1000_hw *hw, uint8_t * mc_addr, uint32_t rar_index);
@@ -431,31 +421,9 @@
void e1000_read_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
/* Port I/O is only supported on 82544 and newer */
-uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port);
-uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset);
void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value);
-void e1000_enable_pciex_master(struct e1000_hw *hw);
int32_t e1000_disable_pciex_master(struct e1000_hw *hw);
-int32_t e1000_get_software_semaphore(struct e1000_hw *hw);
-void e1000_release_software_semaphore(struct e1000_hw *hw);
int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
-int32_t e1000_set_pci_ex_no_snoop(struct e1000_hw *hw, uint32_t no_snoop);
-
-int32_t e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index,
- uint8_t *data);
-int32_t e1000_verify_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
- uint8_t byte);
-int32_t e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
- uint8_t byte);
-int32_t e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index,
- uint16_t *data);
-int32_t e1000_read_ich8_data(struct e1000_hw *hw, uint32_t index,
- uint32_t size, uint16_t *data);
-int32_t e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
- uint16_t words, uint16_t *data);
-int32_t e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
- uint16_t words, uint16_t *data);
-int32_t e1000_erase_ich8_4k_segment(struct e1000_hw *hw, uint32_t segment);
#define E1000_READ_REG_IO(a, reg) \
--- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.c.old 2006-07-06 21:16:17.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.c 2006-07-06 21:39:03.000000000 +0200
@@ -105,6 +105,33 @@
uint16_t duplex);
static int32_t e1000_configure_kmrn_for_1000(struct e1000_hw *hw);
+static int32_t e1000_erase_ich8_4k_segment(struct e1000_hw *hw,
+ uint32_t segment);
+static int32_t e1000_get_software_flag(struct e1000_hw *hw);
+static int32_t e1000_get_software_semaphore(struct e1000_hw *hw);
+static int32_t e1000_init_lcd_from_nvm(struct e1000_hw *hw);
+static int32_t e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw);
+static int32_t e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
+ uint16_t words, uint16_t *data);
+static int32_t e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index,
+ uint8_t* data);
+static int32_t e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index,
+ uint16_t *data);
+static int32_t e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
+ uint16_t *data);
+static void e1000_release_software_flag(struct e1000_hw *hw);
+static void e1000_release_software_semaphore(struct e1000_hw *hw);
+static int32_t e1000_set_pci_ex_no_snoop(struct e1000_hw *hw,
+ uint32_t no_snoop);
+static int32_t e1000_verify_write_ich8_byte(struct e1000_hw *hw,
+ uint32_t index, uint8_t byte);
+static int32_t e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
+ uint16_t words, uint16_t *data);
+static int32_t e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
+ uint8_t data);
+static int32_t e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
+ uint16_t data);
+
/* IGP cable length table */
static const
uint16_t e1000_igp_cable_length_table[IGP01E1000_AGC_LENGTH_TABLE_SIZE] =
@@ -3233,7 +3260,7 @@
return data;
}
-int32_t
+static int32_t
e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask)
{
uint32_t swfw_sync = 0;
@@ -3277,7 +3304,7 @@
return E1000_SUCCESS;
}
-void
+static void
e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask)
{
uint32_t swfw_sync;
@@ -3575,7 +3602,7 @@
return E1000_SUCCESS;
}
-int32_t
+static int32_t
e1000_read_kmrn_reg(struct e1000_hw *hw,
uint32_t reg_addr,
uint16_t *data)
@@ -3608,7 +3635,7 @@
return E1000_SUCCESS;
}
-int32_t
+static int32_t
e1000_write_kmrn_reg(struct e1000_hw *hw,
uint32_t reg_addr,
uint16_t data)
@@ -3839,7 +3866,7 @@
*
* hw - struct containing variables accessed by shared code
******************************************************************************/
-int32_t
+static int32_t
e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw)
{
int32_t ret_val;
@@ -4086,7 +4113,7 @@
* hw - Struct containing variables accessed by shared code
* phy_info - PHY information structure
******************************************************************************/
-int32_t
+static int32_t
e1000_phy_ife_get_info(struct e1000_hw *hw,
struct e1000_phy_info *phy_info)
{
@@ -5643,6 +5670,7 @@
* for the first 15 multicast addresses, and hashes the rest into the
* multicast table.
*****************************************************************************/
+#if 0
void
e1000_mc_addr_list_update(struct e1000_hw *hw,
uint8_t *mc_addr_list,
@@ -5719,6 +5747,7 @@
}
DEBUGOUT("MC Update Complete\n");
}
+#endif /* 0 */
/******************************************************************************
* Hashes an address to determine its location in the multicast table
@@ -6587,6 +6616,7 @@
* hw - Struct containing variables accessed by shared code
* offset - offset to read from
*****************************************************************************/
+#if 0
uint32_t
e1000_read_reg_io(struct e1000_hw *hw,
uint32_t offset)
@@ -6597,6 +6627,7 @@
e1000_io_write(hw, io_addr, offset);
return e1000_io_read(hw, io_data);
}
+#endif /* 0 */
/******************************************************************************
* Writes a value to one of the devices registers using port I/O (as opposed to
@@ -7909,6 +7940,7 @@
* returns: - none.
*
***************************************************************************/
+#if 0
void
e1000_enable_pciex_master(struct e1000_hw *hw)
{
@@ -7923,6 +7955,7 @@
ctrl &= ~E1000_CTRL_GIO_MASTER_DISABLE;
E1000_WRITE_REG(hw, CTRL, ctrl);
}
+#endif /* 0 */
/*******************************************************************************
*
@@ -8148,7 +8181,7 @@
* E1000_SUCCESS at any other case.
*
***************************************************************************/
-int32_t
+static int32_t
e1000_get_software_semaphore(struct e1000_hw *hw)
{
int32_t timeout = hw->eeprom.word_size + 1;
@@ -8183,7 +8216,7 @@
* hw: Struct containing variables accessed by shared code
*
***************************************************************************/
-void
+static void
e1000_release_software_semaphore(struct e1000_hw *hw)
{
uint32_t swsm;
@@ -8265,7 +8298,7 @@
* returns: E1000_SUCCESS
*
*****************************************************************************/
-int32_t
+static int32_t
e1000_set_pci_ex_no_snoop(struct e1000_hw *hw, uint32_t no_snoop)
{
uint32_t gcr_reg = 0;
@@ -8306,7 +8339,7 @@
* hw: Struct containing variables accessed by shared code
*
***************************************************************************/
-int32_t
+static int32_t
e1000_get_software_flag(struct e1000_hw *hw)
{
int32_t timeout = PHY_CFG_TIMEOUT;
@@ -8345,7 +8378,7 @@
* hw: Struct containing variables accessed by shared code
*
***************************************************************************/
-void
+static void
e1000_release_software_flag(struct e1000_hw *hw)
{
uint32_t extcnf_ctrl;
@@ -8369,6 +8402,7 @@
* hw: Struct containing variables accessed by shared code
*
***************************************************************************/
+#if 0
int32_t
e1000_ife_disable_dynamic_power_down(struct e1000_hw *hw)
{
@@ -8388,6 +8422,7 @@
return ret_val;
}
+#endif /* 0 */
/***************************************************************************
*
@@ -8397,6 +8432,7 @@
* hw: Struct containing variables accessed by shared code
*
***************************************************************************/
+#if 0
int32_t
e1000_ife_enable_dynamic_power_down(struct e1000_hw *hw)
{
@@ -8416,6 +8452,7 @@
return ret_val;
}
+#endif /* 0 */
/******************************************************************************
* Reads a 16 bit word or words from the EEPROM using the ICH8's flash access
@@ -8426,7 +8463,7 @@
* data - word read from the EEPROM
* words - number of words to read
*****************************************************************************/
-int32_t
+static int32_t
e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset, uint16_t words,
uint16_t *data)
{
@@ -8482,7 +8519,7 @@
* words - number of words to write
* data - words to write to the EEPROM
*****************************************************************************/
-int32_t
+static int32_t
e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset, uint16_t words,
uint16_t *data)
{
@@ -8529,7 +8566,7 @@
*
* hw - The pointer to the hw structure
****************************************************************************/
-int32_t
+static int32_t
e1000_ich8_cycle_init(struct e1000_hw *hw)
{
union ich8_hws_flash_status hsfsts;
@@ -8596,7 +8633,7 @@
*
* hw - The pointer to the hw structure
****************************************************************************/
-int32_t
+static int32_t
e1000_ich8_flash_cycle(struct e1000_hw *hw, uint32_t timeout)
{
union ich8_hws_flash_ctrl hsflctl;
@@ -8631,7 +8668,7 @@
* size - Size of data to read, 1=byte 2=word
* data - Pointer to the word to store the value read.
*****************************************************************************/
-int32_t
+static int32_t
e1000_read_ich8_data(struct e1000_hw *hw, uint32_t index,
uint32_t size, uint16_t* data)
{
@@ -8710,7 +8747,7 @@
* size - Size of data to read, 1=byte 2=word
* data - The byte(s) to write to the NVM.
*****************************************************************************/
-int32_t
+static int32_t
e1000_write_ich8_data(struct e1000_hw *hw, uint32_t index, uint32_t size,
uint16_t data)
{
@@ -8785,7 +8822,7 @@
* index - The index of the byte to read.
* data - Pointer to a byte to store the value read.
*****************************************************************************/
-int32_t
+static int32_t
e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t* data)
{
int32_t status = E1000_SUCCESS;
@@ -8808,7 +8845,7 @@
* index - The index of the byte to write.
* byte - The byte to write to the NVM.
*****************************************************************************/
-int32_t
+static int32_t
e1000_verify_write_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t byte)
{
int32_t error = E1000_SUCCESS;
@@ -8839,7 +8876,7 @@
* index - The index of the byte to read.
* data - The byte to write to the NVM.
*****************************************************************************/
-int32_t
+static int32_t
e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t data)
{
int32_t status = E1000_SUCCESS;
@@ -8857,7 +8894,7 @@
* index - The starting byte index of the word to read.
* data - Pointer to a word to store the value read.
*****************************************************************************/
-int32_t
+static int32_t
e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index, uint16_t *data)
{
int32_t status = E1000_SUCCESS;
@@ -8872,6 +8909,7 @@
* index - The starting byte index of the word to read.
* data - The word to write to the NVM.
*****************************************************************************/
+#if 0
int32_t
e1000_write_ich8_word(struct e1000_hw *hw, uint32_t index, uint16_t data)
{
@@ -8879,6 +8917,7 @@
status = e1000_write_ich8_data(hw, index, 2, data);
return status;
}
+#endif /* 0 */
/******************************************************************************
* Erases the bank specified. Each bank is a 4k block. Segments are 0 based.
@@ -8887,7 +8926,7 @@
* hw - pointer to e1000_hw structure
* segment - 0 for first segment, 1 for second segment, etc.
*****************************************************************************/
-int32_t
+static int32_t
e1000_erase_ich8_4k_segment(struct e1000_hw *hw, uint32_t segment)
{
union ich8_hws_flash_status hsfsts;
@@ -8984,6 +9023,7 @@
* hw: Struct containing variables accessed by shared code
*
*****************************************************************************/
+#if 0
int32_t
e1000_duplex_reversal(struct e1000_hw *hw)
{
@@ -9012,8 +9052,9 @@
return ret_val;
}
+#endif /* 0 */
-int32_t
+static int32_t
e1000_init_lcd_from_nvm_config_region(struct e1000_hw *hw,
uint32_t cnf_base_addr, uint32_t cnf_size)
{
@@ -9047,7 +9088,7 @@
}
-int32_t
+static int32_t
e1000_init_lcd_from_nvm(struct e1000_hw *hw)
{
uint32_t reg_data, cnf_base_addr, cnf_size, ret_val, loop;
--- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_main.c.old 2006-07-06 21:57:45.000000000 +0200
+++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_main.c 2006-07-06 21:58:01.000000000 +0200
@@ -4387,11 +4387,13 @@
pci_write_config_word(adapter->pdev, reg, *value);
}
+#if 0
uint32_t
e1000_io_read(struct e1000_hw *hw, unsigned long port)
{
return inl(port);
}
+#endif /* 0 */
void
e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [-mm patch] drivers/net/e1000/: possible cleanups
2006-07-06 20:37 ` [-mm patch] drivers/net/e1000/: possible cleanups Adrian Bunk
@ 2006-07-06 20:47 ` Auke Kok
2006-07-07 7:35 ` Adrian Bunk
0 siblings, 1 reply; 126+ messages in thread
From: Auke Kok @ 2006-07-06 20:47 UTC (permalink / raw)
To: cramerj
Cc: john.ronciak, jesse.brandeburg, jeffrey.t.kirsher, auke-jan.h.kok,
linux-kernel
Adrian Bunk wrote:
> On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
>> ...
>> Changes since 2.6.17-mm5:
>> ...
>> git-e1000.patch
>> ...
>> git trees.
>> ...
>
> This patch contains the following possible cleanups:
> - make needlessly global functions static
I'm fine with those
> - #if 0 the following unused global functions:
> - e1000_hw.c: e1000_mc_addr_list_update()
> - e1000_hw.c: e1000_read_reg_io()
> - e1000_hw.c: e1000_enable_pciex_master()
> - e1000_hw.c: e1000_ife_disable_dynamic_power_down()
> - e1000_hw.c: e1000_ife_enable_dynamic_power_down()
> - e1000_hw.c: e1000_write_ich8_word()
> - e1000_hw.c: e1000_duplex_reversal()
> - e1000_main.c: e1000_io_read()
I'm wondering if we should not remove those alltogether, or are we preferring
to keep the #if 0'd now?
Cheers,
Auke
below the entire patch.
> Please review which of these changes do make sense and which do
> conflict with pending patches.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/net/e1000/e1000_hw.c | 89 ++++++++++++++++++++++++---------
> drivers/net/e1000/e1000_hw.h | 32 -----------
> drivers/net/e1000/e1000_main.c | 2
> 3 files changed, 67 insertions(+), 56 deletions(-)
>
> --- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.h.old 2006-07-06 21:17:20.000000000 +0200
> +++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.h 2006-07-06 21:57:18.000000000 +0200
> @@ -323,13 +323,8 @@
> int32_t e1000_phy_hw_reset(struct e1000_hw *hw);
> int32_t e1000_phy_reset(struct e1000_hw *hw);
> void e1000_phy_powerdown_workaround(struct e1000_hw *hw);
> -int32_t e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw);
> -int32_t e1000_init_lcd_from_nvm_config_region(struct e1000_hw *hw, uint32_t cnf_base_addr, uint32_t cnf_size);
> -int32_t e1000_init_lcd_from_nvm(struct e1000_hw *hw);
> int32_t e1000_phy_get_info(struct e1000_hw *hw, struct e1000_phy_info *phy_info);
> int32_t e1000_validate_mdi_setting(struct e1000_hw *hw);
> -int32_t e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t *data);
> -int32_t e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr, uint16_t data);
>
> /* EEPROM Functions */
> int32_t e1000_init_eeprom_params(struct e1000_hw *hw);
> @@ -400,13 +395,8 @@
> int32_t e1000_write_eeprom(struct e1000_hw *hw, uint16_t reg, uint16_t words, uint16_t *data);
> int32_t e1000_read_part_num(struct e1000_hw *hw, uint32_t * part_num);
> int32_t e1000_read_mac_addr(struct e1000_hw * hw);
> -int32_t e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask);
> -void e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask);
> -void e1000_release_software_flag(struct e1000_hw *hw);
> -int32_t e1000_get_software_flag(struct e1000_hw *hw);
>
> /* Filters (multicast, vlan, receive) */
> -void e1000_mc_addr_list_update(struct e1000_hw *hw, uint8_t * mc_addr_list, uint32_t mc_addr_count, uint32_t pad, uint32_t rar_used_count);
> uint32_t e1000_hash_mc_addr(struct e1000_hw *hw, uint8_t * mc_addr);
> void e1000_mta_set(struct e1000_hw *hw, uint32_t hash_value);
> void e1000_rar_set(struct e1000_hw *hw, uint8_t * mc_addr, uint32_t rar_index);
> @@ -431,31 +421,9 @@
> void e1000_read_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
> void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
> /* Port I/O is only supported on 82544 and newer */
> -uint32_t e1000_io_read(struct e1000_hw *hw, unsigned long port);
> -uint32_t e1000_read_reg_io(struct e1000_hw *hw, uint32_t offset);
> void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value);
> -void e1000_enable_pciex_master(struct e1000_hw *hw);
> int32_t e1000_disable_pciex_master(struct e1000_hw *hw);
> -int32_t e1000_get_software_semaphore(struct e1000_hw *hw);
> -void e1000_release_software_semaphore(struct e1000_hw *hw);
> int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
> -int32_t e1000_set_pci_ex_no_snoop(struct e1000_hw *hw, uint32_t no_snoop);
> -
> -int32_t e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index,
> - uint8_t *data);
> -int32_t e1000_verify_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
> - uint8_t byte);
> -int32_t e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
> - uint8_t byte);
> -int32_t e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index,
> - uint16_t *data);
> -int32_t e1000_read_ich8_data(struct e1000_hw *hw, uint32_t index,
> - uint32_t size, uint16_t *data);
> -int32_t e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
> - uint16_t words, uint16_t *data);
> -int32_t e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
> - uint16_t words, uint16_t *data);
> -int32_t e1000_erase_ich8_4k_segment(struct e1000_hw *hw, uint32_t segment);
>
>
> #define E1000_READ_REG_IO(a, reg) \
> --- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.c.old 2006-07-06 21:16:17.000000000 +0200
> +++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_hw.c 2006-07-06 21:39:03.000000000 +0200
> @@ -105,6 +105,33 @@
> uint16_t duplex);
> static int32_t e1000_configure_kmrn_for_1000(struct e1000_hw *hw);
>
> +static int32_t e1000_erase_ich8_4k_segment(struct e1000_hw *hw,
> + uint32_t segment);
> +static int32_t e1000_get_software_flag(struct e1000_hw *hw);
> +static int32_t e1000_get_software_semaphore(struct e1000_hw *hw);
> +static int32_t e1000_init_lcd_from_nvm(struct e1000_hw *hw);
> +static int32_t e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw);
> +static int32_t e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
> + uint16_t words, uint16_t *data);
> +static int32_t e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index,
> + uint8_t* data);
> +static int32_t e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index,
> + uint16_t *data);
> +static int32_t e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
> + uint16_t *data);
> +static void e1000_release_software_flag(struct e1000_hw *hw);
> +static void e1000_release_software_semaphore(struct e1000_hw *hw);
> +static int32_t e1000_set_pci_ex_no_snoop(struct e1000_hw *hw,
> + uint32_t no_snoop);
> +static int32_t e1000_verify_write_ich8_byte(struct e1000_hw *hw,
> + uint32_t index, uint8_t byte);
> +static int32_t e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
> + uint16_t words, uint16_t *data);
> +static int32_t e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
> + uint8_t data);
> +static int32_t e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
> + uint16_t data);
> +
> /* IGP cable length table */
> static const
> uint16_t e1000_igp_cable_length_table[IGP01E1000_AGC_LENGTH_TABLE_SIZE] =
> @@ -3233,7 +3260,7 @@
> return data;
> }
>
> -int32_t
> +static int32_t
> e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask)
> {
> uint32_t swfw_sync = 0;
> @@ -3277,7 +3304,7 @@
> return E1000_SUCCESS;
> }
>
> -void
> +static void
> e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask)
> {
> uint32_t swfw_sync;
> @@ -3575,7 +3602,7 @@
> return E1000_SUCCESS;
> }
>
> -int32_t
> +static int32_t
> e1000_read_kmrn_reg(struct e1000_hw *hw,
> uint32_t reg_addr,
> uint16_t *data)
> @@ -3608,7 +3635,7 @@
> return E1000_SUCCESS;
> }
>
> -int32_t
> +static int32_t
> e1000_write_kmrn_reg(struct e1000_hw *hw,
> uint32_t reg_addr,
> uint16_t data)
> @@ -3839,7 +3866,7 @@
> *
> * hw - struct containing variables accessed by shared code
> ******************************************************************************/
> -int32_t
> +static int32_t
> e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw)
> {
> int32_t ret_val;
> @@ -4086,7 +4113,7 @@
> * hw - Struct containing variables accessed by shared code
> * phy_info - PHY information structure
> ******************************************************************************/
> -int32_t
> +static int32_t
> e1000_phy_ife_get_info(struct e1000_hw *hw,
> struct e1000_phy_info *phy_info)
> {
> @@ -5643,6 +5670,7 @@
> * for the first 15 multicast addresses, and hashes the rest into the
> * multicast table.
> *****************************************************************************/
> +#if 0
> void
> e1000_mc_addr_list_update(struct e1000_hw *hw,
> uint8_t *mc_addr_list,
> @@ -5719,6 +5747,7 @@
> }
> DEBUGOUT("MC Update Complete\n");
> }
> +#endif /* 0 */
>
> /******************************************************************************
> * Hashes an address to determine its location in the multicast table
> @@ -6587,6 +6616,7 @@
> * hw - Struct containing variables accessed by shared code
> * offset - offset to read from
> *****************************************************************************/
> +#if 0
> uint32_t
> e1000_read_reg_io(struct e1000_hw *hw,
> uint32_t offset)
> @@ -6597,6 +6627,7 @@
> e1000_io_write(hw, io_addr, offset);
> return e1000_io_read(hw, io_data);
> }
> +#endif /* 0 */
>
> /******************************************************************************
> * Writes a value to one of the devices registers using port I/O (as opposed to
> @@ -7909,6 +7940,7 @@
> * returns: - none.
> *
> ***************************************************************************/
> +#if 0
> void
> e1000_enable_pciex_master(struct e1000_hw *hw)
> {
> @@ -7923,6 +7955,7 @@
> ctrl &= ~E1000_CTRL_GIO_MASTER_DISABLE;
> E1000_WRITE_REG(hw, CTRL, ctrl);
> }
> +#endif /* 0 */
>
> /*******************************************************************************
> *
> @@ -8148,7 +8181,7 @@
> * E1000_SUCCESS at any other case.
> *
> ***************************************************************************/
> -int32_t
> +static int32_t
> e1000_get_software_semaphore(struct e1000_hw *hw)
> {
> int32_t timeout = hw->eeprom.word_size + 1;
> @@ -8183,7 +8216,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> ***************************************************************************/
> -void
> +static void
> e1000_release_software_semaphore(struct e1000_hw *hw)
> {
> uint32_t swsm;
> @@ -8265,7 +8298,7 @@
> * returns: E1000_SUCCESS
> *
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_set_pci_ex_no_snoop(struct e1000_hw *hw, uint32_t no_snoop)
> {
> uint32_t gcr_reg = 0;
> @@ -8306,7 +8339,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> ***************************************************************************/
> -int32_t
> +static int32_t
> e1000_get_software_flag(struct e1000_hw *hw)
> {
> int32_t timeout = PHY_CFG_TIMEOUT;
> @@ -8345,7 +8378,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> ***************************************************************************/
> -void
> +static void
> e1000_release_software_flag(struct e1000_hw *hw)
> {
> uint32_t extcnf_ctrl;
> @@ -8369,6 +8402,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> ***************************************************************************/
> +#if 0
> int32_t
> e1000_ife_disable_dynamic_power_down(struct e1000_hw *hw)
> {
> @@ -8388,6 +8422,7 @@
>
> return ret_val;
> }
> +#endif /* 0 */
>
> /***************************************************************************
> *
> @@ -8397,6 +8432,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> ***************************************************************************/
> +#if 0
> int32_t
> e1000_ife_enable_dynamic_power_down(struct e1000_hw *hw)
> {
> @@ -8416,6 +8452,7 @@
>
> return ret_val;
> }
> +#endif /* 0 */
>
> /******************************************************************************
> * Reads a 16 bit word or words from the EEPROM using the ICH8's flash access
> @@ -8426,7 +8463,7 @@
> * data - word read from the EEPROM
> * words - number of words to read
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset, uint16_t words,
> uint16_t *data)
> {
> @@ -8482,7 +8519,7 @@
> * words - number of words to write
> * data - words to write to the EEPROM
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset, uint16_t words,
> uint16_t *data)
> {
> @@ -8529,7 +8566,7 @@
> *
> * hw - The pointer to the hw structure
> ****************************************************************************/
> -int32_t
> +static int32_t
> e1000_ich8_cycle_init(struct e1000_hw *hw)
> {
> union ich8_hws_flash_status hsfsts;
> @@ -8596,7 +8633,7 @@
> *
> * hw - The pointer to the hw structure
> ****************************************************************************/
> -int32_t
> +static int32_t
> e1000_ich8_flash_cycle(struct e1000_hw *hw, uint32_t timeout)
> {
> union ich8_hws_flash_ctrl hsflctl;
> @@ -8631,7 +8668,7 @@
> * size - Size of data to read, 1=byte 2=word
> * data - Pointer to the word to store the value read.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_read_ich8_data(struct e1000_hw *hw, uint32_t index,
> uint32_t size, uint16_t* data)
> {
> @@ -8710,7 +8747,7 @@
> * size - Size of data to read, 1=byte 2=word
> * data - The byte(s) to write to the NVM.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_write_ich8_data(struct e1000_hw *hw, uint32_t index, uint32_t size,
> uint16_t data)
> {
> @@ -8785,7 +8822,7 @@
> * index - The index of the byte to read.
> * data - Pointer to a byte to store the value read.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t* data)
> {
> int32_t status = E1000_SUCCESS;
> @@ -8808,7 +8845,7 @@
> * index - The index of the byte to write.
> * byte - The byte to write to the NVM.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_verify_write_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t byte)
> {
> int32_t error = E1000_SUCCESS;
> @@ -8839,7 +8876,7 @@
> * index - The index of the byte to read.
> * data - The byte to write to the NVM.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index, uint8_t data)
> {
> int32_t status = E1000_SUCCESS;
> @@ -8857,7 +8894,7 @@
> * index - The starting byte index of the word to read.
> * data - Pointer to a word to store the value read.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index, uint16_t *data)
> {
> int32_t status = E1000_SUCCESS;
> @@ -8872,6 +8909,7 @@
> * index - The starting byte index of the word to read.
> * data - The word to write to the NVM.
> *****************************************************************************/
> +#if 0
> int32_t
> e1000_write_ich8_word(struct e1000_hw *hw, uint32_t index, uint16_t data)
> {
> @@ -8879,6 +8917,7 @@
> status = e1000_write_ich8_data(hw, index, 2, data);
> return status;
> }
> +#endif /* 0 */
>
> /******************************************************************************
> * Erases the bank specified. Each bank is a 4k block. Segments are 0 based.
> @@ -8887,7 +8926,7 @@
> * hw - pointer to e1000_hw structure
> * segment - 0 for first segment, 1 for second segment, etc.
> *****************************************************************************/
> -int32_t
> +static int32_t
> e1000_erase_ich8_4k_segment(struct e1000_hw *hw, uint32_t segment)
> {
> union ich8_hws_flash_status hsfsts;
> @@ -8984,6 +9023,7 @@
> * hw: Struct containing variables accessed by shared code
> *
> *****************************************************************************/
> +#if 0
> int32_t
> e1000_duplex_reversal(struct e1000_hw *hw)
> {
> @@ -9012,8 +9052,9 @@
>
> return ret_val;
> }
> +#endif /* 0 */
>
> -int32_t
> +static int32_t
> e1000_init_lcd_from_nvm_config_region(struct e1000_hw *hw,
> uint32_t cnf_base_addr, uint32_t cnf_size)
> {
> @@ -9047,7 +9088,7 @@
> }
>
>
> -int32_t
> +static int32_t
> e1000_init_lcd_from_nvm(struct e1000_hw *hw)
> {
> uint32_t reg_data, cnf_base_addr, cnf_size, ret_val, loop;
> --- linux-2.6.17-mm6-full/drivers/net/e1000/e1000_main.c.old 2006-07-06 21:57:45.000000000 +0200
> +++ linux-2.6.17-mm6-full/drivers/net/e1000/e1000_main.c 2006-07-06 21:58:01.000000000 +0200
> @@ -4387,11 +4387,13 @@
> pci_write_config_word(adapter->pdev, reg, *value);
> }
>
> +#if 0
> uint32_t
> e1000_io_read(struct e1000_hw *hw, unsigned long port)
> {
> return inl(port);
> }
> +#endif /* 0 */
>
> void
> e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: [-mm patch] drivers/net/e1000/: possible cleanups
2006-07-06 20:47 ` Auke Kok
@ 2006-07-07 7:35 ` Adrian Bunk
0 siblings, 0 replies; 126+ messages in thread
From: Adrian Bunk @ 2006-07-07 7:35 UTC (permalink / raw)
To: Auke Kok
Cc: cramerj, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher,
auke-jan.h.kok, linux-kernel
On Thu, Jul 06, 2006 at 01:47:33PM -0700, Auke Kok wrote:
> Adrian Bunk wrote:
> >On Mon, Jul 03, 2006 at 03:03:55AM -0700, Andrew Morton wrote:
> >>...
> >>Changes since 2.6.17-mm5:
> >>...
> >> git-e1000.patch
> >>...
> >> git trees.
> >>...
> >
> >This patch contains the following possible cleanups:
> >- make needlessly global functions static
>
> I'm fine with those
>
> >- #if 0 the following unused global functions:
> > - e1000_hw.c: e1000_mc_addr_list_update()
> > - e1000_hw.c: e1000_read_reg_io()
> > - e1000_hw.c: e1000_enable_pciex_master()
> > - e1000_hw.c: e1000_ife_disable_dynamic_power_down()
> > - e1000_hw.c: e1000_ife_enable_dynamic_power_down()
> > - e1000_hw.c: e1000_write_ich8_word()
> > - e1000_hw.c: e1000_duplex_reversal()
> > - e1000_main.c: e1000_io_read()
>
> I'm wondering if we should not remove those alltogether, or are we
> preferring to keep the #if 0'd now?
#if 0 is the compromise between not bloating the kernel binary with
unused code and not immediately removing the currently unused code.
If you as a maintainer of this driver say you want a patch to remove
these unused functions I can also send this patch.
> Cheers,
>
> Auke
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (12 preceding siblings ...)
2006-07-06 20:37 ` [-mm patch] drivers/net/e1000/: possible cleanups Adrian Bunk
@ 2006-07-07 9:17 ` Reuben Farrelly
2006-07-07 9:35 ` 2.6.17-mm6 Andrew Morton
2006-07-07 15:24 ` 2.6.17-mm6 Reuben Farrelly
2006-07-08 20:20 ` 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error Adrian Bunk
15 siblings, 1 reply; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-07 9:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Neil Brown
On 3/07/2006 10:03 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
>
> - A major update to the e1000 driver.
>
> - 1394 updates
This release has been working quite well after some initial hiccups (see -mm
hotfix), but a couple of hours ago another bad thing (tm) happened.
At the time I was moving 100G of data from one partition on a non-raid partition
to a new RAID-1 md that I had created earlier. Both are ext3 partitions.
The word "barrier" of course comes to mind again, I'm not sure NeilB is the
culprit this time either but I've cc'd him in just in case.
The file copy went on happily for quite a while (maybe 10 mins or so) under very
high IO load before blowing up as below. The terminal was spewing out constant
traces but hopefully the right ones are here as these are the first few (if not,
I have copied a bit more).
sh-3.1# mv /store-old/* /store/
Unable to handle kernel paging request at ffff81043e345490 RIP:
[<ffffffff802620f2>] memcpy+0x12/0xb0
PGD 8063 PUD 0
Oops: 0000 [1] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0
RSP: 0018:ffff81003ed31828 EFLAGS: 00010002
RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001
RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18
RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000
R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00
R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000
0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8
ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200
Call Trace:
[<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538
[<ffffffff802b96c6>] __kmalloc+0x86/0x96
[<ffffffff802ae460>] __kzalloc+0xf/0x2f
[<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a
[<ffffffff802230e4>] mempool_alloc+0x44/0xfb
[<ffffffff8041d1c4>] wait_barrier+0x20/0xfc
[<ffffffff802bd143>] __bio_clone+0x84/0xa2
[<ffffffff8041e072>] make_request+0xf2/0x611
[<ffffffff802a97d8>] mempool_alloc_slab+0x11/0x13
[<ffffffff8021c387>] generic_make_request+0x20d/0x256
[<ffffffff8027f831>] __wake_up_common+0x41/0x71
[<ffffffff80234c11>] submit_bio+0xd7/0xe6
[<ffffffff8021aa6c>] submit_bh+0x100/0x126
[<ffffffff8021c5ad>] __block_write_full_page+0x1dd/0x2ea
[<ffffffff80310550>] ext3_get_block+0x0/0xf0
[<ffffffff80310550>] ext3_get_block+0x0/0xf0
[<ffffffff80217007>] block_write_full_page+0xa7/0xb0
[<ffffffff80311df2>] ext3_ordered_writepage+0xfa/0x1aa
[<ffffffff8021cdc6>] mpage_writepages+0x1f6/0x3ce
[<ffffffff80311cf8>] ext3_ordered_writepage+0x0/0x1aa
[<ffffffff80262fb5>] thread_return+0x0/0xcc
[<ffffffff8025e345>] do_writepages+0x35/0x40
[<ffffffff80231264>] __writeback_single_inode+0x1d4/0x3b0
[<ffffffff802ccbbb>] generic_sync_sb_inodes+0x20b/0x300
[<ffffffff80220cf5>] sync_sb_inodes+0x25/0x30
[<ffffffff8025312d>] writeback_inodes+0x8d/0xd9
[<ffffffff802ab723>] background_writeout+0x8f/0xc7
[<ffffffff80259370>] pdflush+0x0/0x1e2
[<ffffffff802594a7>] pdflush+0x137/0x1e2
[<ffffffff802ab694>] background_writeout+0x0/0xc7
[<ffffffff80259370>] pdflush+0x0/0x1e2
[<ffffffff80234163>] kthread+0xd3/0x100
[<ffffffff80260a02>] child_rip+0x8/0x12
[<ffffffff80234090>] kthread+0x0/0x100
[<ffffffff802609fa>] child_rip+0x0/0x12
Code: 4c 8b 1e 4c 8b 46 08 4c 89 1f 4c 89 47 08 4c 8b 4e 10 4c 8b
RIP [<ffffffff802620f2>] memcpy+0x12/0xb0
RSP <ffff81003ed31828>
CR2: ffff81043e345490
<1>Unable to handle kernel paging request at ffff81003f800000 RIP:
[<ffffffff80262114>] memcpy+0x34/0xb0
PGD 8063 PUD 9063 PMD 0
Oops: 0000 [2] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 0
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 6, comm: events/0 Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80262114>] [<ffffffff80262114>] memcpy+0x34/0xb0
RSP: 0018:ffff810037f51db8 EFLAGS: 00010003
RAX: ffff81003f660018 RBX: ffff81003f660018 RCX: 0000000003ff9807
RDX: 00000007fffffee0 RSI: ffff81003f7fffd8 RDI: ffff81003f7ffcd8
RBP: ffff810037f51dc8 R08: ffffffffffffffff R09: ffffffffffffffff
R10: ffffffffffffffff R11: ffffffffffffffff R12: ffff81003f660000
R13: 0000000000000060 R14: 0000000000000000 R15: ffff81003f6eadc0
FS: 0000000000000000(0000) GS:ffffffff8068a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff81003f800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process events/0 (pid: 6, threadinfo ffff810037f50000, task ffff810037fef800)
Stack: ffff81003f660018 ffffffff80222b5e ffff810037f51e08 ffffffff802b93b8
ffff81003f6ff140 ffff81003f6eadc0 ffff81003f6ff140 ffff810037ffe3c0
0000000000000000 0000000000000292 ffff810037f51e28 ffffffff802b9d83
Call Trace:
[<ffffffff80222b5e>] memmove+0xe/0x3f
[<ffffffff802b93b8>] drain_array+0xe8/0x100
[<ffffffff802b9d83>] cache_reap+0xb2/0x12f
[<ffffffff8024f488>] run_workqueue+0xb7/0x109
[<ffffffff802b9cd1>] cache_reap+0x0/0x12f
[<ffffffff8024bab0>] worker_thread+0x120/0x159
[<ffffffff80280dbb>] default_wake_function+0x0/0xf
[<ffffffff8024b990>] worker_thread+0x0/0x159
[<ffffffff80234163>] kthread+0xd3/0x100
[<ffffffff80260a02>] child_rip+0x8/0x12
[<ffffffff80234090>] kthread+0x0/0x100
[<ffffffff802609fa>] child_rip+0x0/0x12
Code: 4c 8b 46 28 4c 89 5f 20 4c 89 47 28 4c 8b 4e 30 4c 8b 56 38
RIP [<ffffffff80262114>] memcpy+0x34/0xb0
RSP <ffff810037f51db8>
CR2: ffff81003f800000
<0>general protection fault: 0000 [3] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff802b8f37>] [<ffffffff802b8f37>] __cache_free+0x25/0x118
RSP: 0018:ffff81003ed31568 EFLAGS: 00010092
RAX: 0000000000000001 RBX: ffff81003f6e9cc0 RCX: ffff810037f98238
RDX: 0000000000000000 RSI: ffff81003f25e140 RDI: ffff81003f6e9cc0
RBP: ffff81003ed315a8 R08: ffff810001fa62d0 R09: ffff810001fa62e0
R10: ffff810001fa62d0 R11: 000000000000137b R12: ffd9fe7e6ffffebb
R13: ffff81003f25e140 R14: ffff810037f2b8f0 R15: ffff810037f2b968
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 00000000000000a5 0000000000000009 0000000000000000 0000000000000046
ffff810037f2b840 ffff81003f25e140 ffff810037f2b8f0 ffff810037f2b968
ffff81003ed315c8 ffffffff80207527 0000000000000000 ffff810001fa6080
Call Trace:
[<ffffffff80207527>] kmem_cache_free+0x7f/0x88
[<ffffffff80283573>] __cleanup_sighand+0x20/0x22
[<ffffffff80217bb1>] release_task+0x241/0x315
[<ffffffff80215c5b>] do_exit+0x8ba/0x94b
[<ffffffff8039a6f2>] unblank_screen+0xb/0xd
[<ffffffff8020ac17>] do_page_fault+0x7a7/0x893
[<ffffffff80294909>] autoremove_wake_function+0x11/0x48
[<ffffffff8027f831>] __wake_up_common+0x41/0x71
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff802620f2>] memcpy+0x12/0xb0
[<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538
[<ffffffff802b96c6>] __kmalloc+0x86/0x96
[<ffffffff802ae460>] __kzalloc+0xf/0x2f
[<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a
[<ffffffff802230e4>] mempool_alloc+0x44/0xfb
[<ffffffff8041d1c4>] wait_barrier+0x20/0xfc
[<ffffffff802bd143>] __bio_clone+0x84/0xa2
[<ffffffff8041e072>] make_request+0xf2/0x611
[<ffffffff802a97d8>] mempool_alloc_slab+0x11/0x13
[<ffffffff8021c387>] generic_make_request+0x20d/0x256
[<ffffffff8027f831>] __wake_up_common+0x41/0x71
[<ffffffff80234c11>] submit_bio+0xd7/0xe6
[<ffffffff8021aa6c>] submit_bh+0x100/0x126
[<ffffffff8021c5ad>] __block_write_full_page+0x1dd/0x2ea
[<ffffffff80310550>] ext3_get_block+0x0/0xf0
[<ffffffff80310550>] ext3_get_block+0x0/0xf0
[<ffffffff80217007>] block_write_full_page+0xa7/0xb0
[<ffffffff80311df2>] ext3_ordered_writepage+0xfa/0x1aa
[<ffffffff8021cdc6>] mpage_writepages+0x1f6/0x3ce
[<ffffffff80311cf8>] ext3_ordered_writepage+0x0/0x1aa
[<ffffffff80262fb5>] thread_return+0x0/0xcc
[<ffffffff8025e345>] do_writepages+0x35/0x40
[<ffffffff80231264>] __writeback_single_inode+0x1d4/0x3b0
[<ffffffff802ccbbb>] generic_sync_sb_inodes+0x20b/0x300
[<ffffffff80220cf5>] sync_sb_inodes+0x25/0x30
[<ffffffff8025312d>] writeback_inodes+0x8d/0xd9
[<ffffffff802ab723>] background_writeout+0x8f/0xc7
[<ffffffff80259370>] pdflush+0x0/0x1e2
[<ffffffff802594a7>] pdflush+0x137/0x1e2
[<ffffffff802ab694>] background_writeout+0x0/0xc7
[<ffffffff80259370>] pdflush+0x0/0x1e2
[<ffffffff80234163>] kthread+0xd3/0x100
[<ffffffff80260a02>] child_rip+0x8/0x12
[<ffffffff80234090>] kthread+0x0/0x100
[<ffffffff802609fa>] child_rip+0x0/0x12
Code: 41 8b 14 24 41 3b 54 24 04 73 13 89 d0 49 89 74 c4 18 8d 42
RIP [<ffffffff802b8f37>] __cache_free+0x25/0x118
RSP <ffff81003ed31568>
<1>Unable to handle kernel paging request at ffffffffffff4e87 RIP:
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
PGD 203027 PUD 1deb067 PMD 0
Oops: 0000 [4] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff8029144a>] [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
RSP: 0018:ffff81003f617ed0 EFLAGS: 00010216
RAX: ffffffffffff4e7f RBX: ffff81003f60c000 RCX: ffff81003f6eb780
RDX: 0000000000000001 RSI: ffff810001dfa440 RDI: ffff810001dfa440
RBP: ffff81003f617ed0 R08: ffff810001dfa0e0 R09: ffff810001df9900
R10: 0000000000000000 R11: 00000000ffffffff R12: ffff81003f617ee0
R13: 0000000000000100 R14: ffffffff8029141e R15: 000000000000000a
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffffffff4e87 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: ffff81003f617f10 ffffffff8028afd9 ffff81003f617ee0 ffff81003f617ee0
0000000000000001 ffffffff8068a410 ffffffff806dd020 0000000000000001
ffff81003f617f50 ffffffff80211f6e 0000000000000001 0000000000000046
Call Trace:
<IRQ> [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [5] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f617c18 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f617c58 R08: 0000000000009bb3 R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 0000000000009951 0000000000000001 000000003f617c58 ffff81003f617f28
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f617ca8 ffffffff80269049 ffffffff805759c7 ffff81003f617e28
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [6] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f617958 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f617998 R08: 000000000000a46d R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000a00f 0000000000000001 000000003f617998 ffff81003f617c70
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f6179e8 ffffffff80269049 ffffffff805759c7 ffff81003f617b68
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [7] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f617698 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f6176d8 R08: 000000000000af1b R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000a8c9 0000000000000001 000000003f6176d8 ffff81003f6179b0
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f617728 ffffffff80269049 ffffffff805759c7 ffff81003f6178a8
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [8] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f6173d8 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f617418 R08: 000000000000bbbd R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000b377 0000000000000001 000000003f617418 ffff81003f6176f0
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f617468 ffffffff80269049 ffffffff805759c7 ffff81003f6175e8
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [9] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f617118 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f617158 R08: 000000000000ca53 R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000c019 0000000000000001 000000003f617158 ffff81003f617430
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f6171a8 ffffffff80269049 ffffffff805759c7 ffff81003f617328
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [10] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f616e58 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f616e98 R08: 000000000000dadd R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000ceaf 0000000000000001 000000003f616e98 ffff81003f617170
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f616ee8 ffffffff80269049 ffffffff805759c7 ffff81003f617068
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [11] SMP
last sysfs file: /kernel/uevent_seqnum
CPU 1
Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2
RSP: 0018:ffff81003f616b98 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08
RBP: ffff81003f616bd8 R08: 000000000000ed5c R09: 00000000ffffffff
R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd
R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0
Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
Stack: 000000000000df3a 0000000000000001 000000003f616bd8 ffff81003f616eb0
000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000
ffff81003f616c28 ffffffff80269049 ffffffff805759c7 ffff81003f616da8
Call Trace:
<IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff80217237>] release_console_sem+0x1e7/0x23f
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff80268f00>] show_trace+0x180/0x1c2
[<ffffffff80268f0c>] show_trace+0x18c/0x1c2
[<ffffffff80269049>] _show_stack+0xe9/0xf8
[<ffffffff802690e4>] show_registers+0x8c/0x101
[<ffffffff802691f9>] __die+0xa0/0xe3
[<ffffffff8020abf0>] do_page_fault+0x780/0x893
[<ffffffff8027fe48>] task_rq_lock+0x3c/0x71
[<ffffffff80280480>] find_busiest_group+0x260/0x6e0
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff80260849>] error_exit+0x0/0x84
[<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37
[<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37
[<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0
[<ffffffff80211f6e>] __do_softirq+0x63/0xe5
[<ffffffff80260d52>] call_softirq+0x1e/0x28
[<ffffffff8026a723>] do_softirq+0x34/0x8b
[<ffffffff80287418>] irq_exit+0x48/0x4a
[<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55
[<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80268f00>] show_trace+0x180/0x1c2
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6
2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-07 9:35 ` Andrew Morton
2006-07-07 21:15 ` 2.6.17-mm6 Reuben Farrelly
0 siblings, 1 reply; 126+ messages in thread
From: Andrew Morton @ 2006-07-07 9:35 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, neilb
On Fri, 07 Jul 2006 21:17:03 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>
> On 3/07/2006 10:03 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
> >
> >
> > - A major update to the e1000 driver.
> >
> > - 1394 updates
>
> This release has been working quite well after some initial hiccups (see -mm
> hotfix), but a couple of hours ago another bad thing (tm) happened.
>
> At the time I was moving 100G of data from one partition on a non-raid partition
> to a new RAID-1 md that I had created earlier. Both are ext3 partitions.
>
> The word "barrier" of course comes to mind again, I'm not sure NeilB is the
> culprit this time either but I've cc'd him in just in case.
>
> The file copy went on happily for quite a while (maybe 10 mins or so) under very
> high IO load before blowing up as below. The terminal was spewing out constant
> traces but hopefully the right ones are here as these are the first few (if not,
> I have copied a bit more).
>
Yes, the very first oops is by far the most important to capture.
You can add pause_on_oops=100000 to the kernel boot command line to make
the machine freeze after outputting the first oops. That'll certainly
prevent the oops messages from getting to the log files, but it will also
prevent it from scolling away or swamping your log device.
> sh-3.1# mv /store-old/* /store/
> Unable to handle kernel paging request at ffff81043e345490 RIP:
> [<ffffffff802620f2>] memcpy+0x12/0xb0
> PGD 8063 PUD 0
> Oops: 0000 [1] SMP
> last sysfs file: /kernel/uevent_seqnum
> CPU 1
> Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
> Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
> RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0
> RSP: 0018:ffff81003ed31828 EFLAGS: 00010002
> RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001
> RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18
> RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000
> R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00
> R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010
> FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0
> Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
> Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000
> 0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8
> ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200
> Call Trace:
> [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538
> [<ffffffff802b96c6>] __kmalloc+0x86/0x96
> [<ffffffff802ae460>] __kzalloc+0xf/0x2f
> [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a
> [<ffffffff802230e4>] mempool_alloc+0x44/0xfb
The core slab data structures were wrecked. For kmalloc(), no less.
Something secretly destroyed your kernel, and it could be anything. Nice.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 9:35 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-07 21:15 ` Reuben Farrelly
2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton
0 siblings, 1 reply; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-07 21:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 7/07/2006 9:35 p.m., Andrew Morton wrote:
> On Fri, 07 Jul 2006 21:17:03 +1200
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>>
>> On 3/07/2006 10:03 p.m., Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>>>
>>>
>>> - A major update to the e1000 driver.
>>>
>>> - 1394 updates
>> This release has been working quite well after some initial hiccups (see -mm
>> hotfix), but a couple of hours ago another bad thing (tm) happened.
>>
>> At the time I was moving 100G of data from one partition on a non-raid partition
>> to a new RAID-1 md that I had created earlier. Both are ext3 partitions.
>>
>> The word "barrier" of course comes to mind again, I'm not sure NeilB is the
>> culprit this time either but I've cc'd him in just in case.
>>
>> The file copy went on happily for quite a while (maybe 10 mins or so) under very
>> high IO load before blowing up as below. The terminal was spewing out constant
>> traces but hopefully the right ones are here as these are the first few (if not,
>> I have copied a bit more).
>>
>
> Yes, the very first oops is by far the most important to capture.
>
> You can add pause_on_oops=100000 to the kernel boot command line to make
> the machine freeze after outputting the first oops. That'll certainly
> prevent the oops messages from getting to the log files, but it will also
> prevent it from scolling away or swamping your log device.
>
>
>> sh-3.1# mv /store-old/* /store/
>> Unable to handle kernel paging request at ffff81043e345490 RIP:
>> [<ffffffff802620f2>] memcpy+0x12/0xb0
>> PGD 8063 PUD 0
>> Oops: 0000 [1] SMP
>> last sysfs file: /kernel/uevent_seqnum
>> CPU 1
>> Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk
>> Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2
>> RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0
>> RSP: 0018:ffff81003ed31828 EFLAGS: 00010002
>> RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001
>> RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18
>> RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000
>> R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00
>> R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010
>> FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0
>> Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840)
>> Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000
>> 0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8
>> ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200
>> Call Trace:
>> [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538
>> [<ffffffff802b96c6>] __kmalloc+0x86/0x96
>> [<ffffffff802ae460>] __kzalloc+0xf/0x2f
>> [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a
>> [<ffffffff802230e4>] mempool_alloc+0x44/0xfb
>
> The core slab data structures were wrecked. For kmalloc(), no less.
> Something secretly destroyed your kernel, and it could be anything. Nice.
Having now turned on slab debugging, is it possibly related to this message
which appeared in my log when I booting up earlier?
Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1
extents:1 across:497972k
Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30.
Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480
max) - 288 bytes per conntrack
Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096
Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000
Mbps Full Duplex
Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:15 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-07 21:38 ` Andrew Morton
2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh
2006-07-07 23:08 ` 2.6.17-mm6 Reuben Farrelly
0 siblings, 2 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-07 21:38 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>
> >
> > The core slab data structures were wrecked. For kmalloc(), no less.
> > Something secretly destroyed your kernel, and it could be anything. Nice.
>
> Having now turned on slab debugging, is it possibly related to this message
> which appeared in my log when I booting up earlier?
>
> Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
> Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1
> extents:1 across:497972k
> Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
> Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30.
> Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480
> max) - 288 bytes per conntrack
> Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096
> Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
> Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000
> Mbps Full Duplex
> Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver
>
Yikes! Until we fix that there's no point in looking at anything else.
CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
implement the damn thing :(
So if this is repeatable it would be of some value if you can work out what
causes it - start by disabling netfilter.
But to fix it for real we'll probably need to twiddle thumbs until an x86
person can hit it.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-07 21:42 ` Martin Bligh
2006-07-07 23:06 ` 2.6.17-mm6 Andrew Morton
2006-07-08 3:46 ` 2.6.17-mm6 Badari Pulavarty
2006-07-07 23:08 ` 2.6.17-mm6 Reuben Farrelly
1 sibling, 2 replies; 126+ messages in thread
From: Martin Bligh @ 2006-07-07 21:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Reuben Farrelly, linux-kernel
> Yikes! Until we fix that there's no point in looking at anything else.
>
> CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
> implement the damn thing :(
I have an implementation, but there's some bug in it I never fixed. If
you want it, I'll update it and send it out ... maybe you can spot the
bug ;-(
M.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh
@ 2006-07-07 23:06 ` Andrew Morton
2006-07-08 3:46 ` 2.6.17-mm6 Badari Pulavarty
1 sibling, 0 replies; 126+ messages in thread
From: Andrew Morton @ 2006-07-07 23:06 UTC (permalink / raw)
To: Martin Bligh; +Cc: reuben-lkml, linux-kernel
Martin Bligh <mbligh@mbligh.org> wrote:
>
>
> > Yikes! Until we fix that there's no point in looking at anything else.
> >
> > CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
> > implement the damn thing :(
>
> I have an implementation, but there's some bug in it I never fixed. If
> you want it, I'll update it and send it out ... maybe you can spot the
> bug ;-(
>
My bug-spotting rate doesn't seem so good lately. But if the thing doesn't
break the kernel when configged off then sure, let's put it in -mm with a
big doesnt-work-yet warning on it and hopefully some clever person like
Chuck will come along and fix it.
That being said, we don't seem to be getting a lot of value from
DEBUG_PAGEALLOC any more. I guess we fixed a pile of long-standing
problems when it first went in and the reintroduction rate is low.
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh
2006-07-07 23:06 ` 2.6.17-mm6 Andrew Morton
@ 2006-07-08 3:46 ` Badari Pulavarty
1 sibling, 0 replies; 126+ messages in thread
From: Badari Pulavarty @ 2006-07-08 3:46 UTC (permalink / raw)
To: Martin Bligh; +Cc: Andrew Morton, Reuben Farrelly, linux-kernel
Martin Bligh wrote:
>
>> Yikes! Until we fix that there's no point in looking at anything else.
>>
>> CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64
>> doesn't
>> implement the damn thing :(
>
> I have an implementation, but there's some bug in it I never fixed. If
> you want it, I'll update it and send it out ... maybe you can spot the
> bug ;-(
>
Please send it out. I will take a look (not that I can fix it :)
Thanks,
Badari
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton
2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh
@ 2006-07-07 23:08 ` Reuben Farrelly
1 sibling, 0 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-07 23:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 8/07/2006 9:38 a.m., Andrew Morton wrote:
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>>
>>> The core slab data structures were wrecked. For kmalloc(), no less.
>>> Something secretly destroyed your kernel, and it could be anything. Nice.
>> Having now turned on slab debugging, is it possibly related to this message
>> which appeared in my log when I booting up earlier?
>>
>> Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
>> Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1
>> extents:1 across:497972k
>> Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
>> Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30.
>> Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480
>> max) - 288 bytes per conntrack
>> Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096
>> Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
>> Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000
>> Mbps Full Duplex
>> Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver
>>
>
> Yikes! Until we fix that there's no point in looking at anything else.
>
> CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't
> implement the damn thing :(
>
> So if this is repeatable it would be of some value if you can work out what
> causes it - start by disabling netfilter.
It hasn't come back after a quick reboot, but I'll be more vigilant than usual
for it. With that warning above and the nasty crash before that which maybe
related, I'm thinking that it's not just a one-off thing.
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (13 preceding siblings ...)
2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-07 15:24 ` Reuben Farrelly
2006-07-08 20:20 ` 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error Adrian Bunk
15 siblings, 0 replies; 126+ messages in thread
From: Reuben Farrelly @ 2006-07-07 15:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev
On 3/07/2006 10:03 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
>
>
> - A major update to the e1000 driver.
>
> - 1394 updates
Some minor breakage in the e1000...
Fedora Core release 5.90 (Test)
Kernel 2.6.17-mm6 on an x86_64
tornado.reub.net login: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH <a>
TDT <1c>
next_to_use <1c>
next_to_clean <8>
buffer_info[next_to_clean]
time_stamp <100027f1a>
next_to_watch <a>
jiffies <1000281d4>
next_to_watch.status <0>
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH <a>
TDT <1c>
next_to_use <1c>
next_to_clean <8>
buffer_info[next_to_clean]
time_stamp <100027f1a>
next_to_watch <a>
jiffies <1000283c8>
next_to_watch.status <0>
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH <a>
TDT <1c>
next_to_use <1c>
next_to_clean <8>
buffer_info[next_to_clean]
time_stamp <100027f1a>
next_to_watch <a>
jiffies <1000285bc>
next_to_watch.status <0>
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH <a>
TDT <1c>
next_to_use <1c>
next_to_clean <8>
buffer_info[next_to_clean]
time_stamp <100027f1a>
next_to_watch <a>
jiffies <1000287b0>
next_to_watch.status <0>
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH <a>
TDT <1c>
next_to_use <1c>
next_to_clean <8>
buffer_info[next_to_clean]
time_stamp <100027f1a>
next_to_watch <a>
jiffies <1000289a4>
next_to_watch.status <0>
A look through my switch logs and kernel logs over the last few days shows these
messages and layer 2/link down disconnections every few hours or so, but of very
short duration (I hadn't noticed until now).
This output above was under virtually no load.
Both the e1000 and switch port on the other end are doing RX and TX flow control.
The controller is a built in chip on an Intel D945GNT board.
01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet
Controller (Copper) (rev 03)
Subsystem: Intel Corporation Unknown device 3094
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 313
Region 0: Memory at 48000000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at 2000 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4142
Capabilities: [e0] Express Endpoint IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <512ns, L1 <64us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0
Link: Latency L0s <128ns, L1 <64us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
[root@tornado log]# ethtool -i eth0
driver: e1000
version: 7.1.9-k2-NAPI
firmware-version: 1.0-5
bus-info: 0000:01:00.0
[root@tornado log]#
Where can I go from here to help debug this further?
reuben
^ permalink raw reply [flat|nested] 126+ messages in thread* 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
` (14 preceding siblings ...)
2006-07-07 15:24 ` 2.6.17-mm6 Reuben Farrelly
@ 2006-07-08 20:20 ` Adrian Bunk
2006-07-09 18:52 ` Serge E. Hallyn
15 siblings, 1 reply; 126+ messages in thread
From: Adrian Bunk @ 2006-07-08 20:20 UTC (permalink / raw)
To: Andrew Morton, Serge E. Hallyn, Sam Vilain, Kirill Korotaev; +Cc: linux-kernel
namespaces-utsname-sysctl-hack.patch and ipc-namespace-sysctls.patch
cause the following compile error with CONFIG_PROC_FS=n:
<-- snip -->
...
CC kernel/sysctl.o
kernel/sysctl.c:107: warning: #proc_do_ipc_string# used but never defined
kernel/sysctl.c:150: warning: #proc_do_utsns_string# used but never defined
kernel/sysctl.c:2465: warning: #proc_do_uts_string# defined but not used
...
LD .tmp_vmlinux1
kernel/built-in.o:(.data+0x938): undefined reference to `proc_do_utsns_string'
kernel/built-in.o:(.data+0x964): undefined reference to `proc_do_utsns_string'
kernel/built-in.o:(.data+0x990): undefined reference to `proc_do_utsns_string'
kernel/built-in.o:(.data+0x9bc): undefined reference to `proc_do_utsns_string'
kernel/built-in.o:(.data+0x9e8): undefined reference to `proc_do_utsns_string'
kernel/built-in.o:(.data+0xc24): undefined reference to `proc_do_ipc_string'
kernel/built-in.o:(.data+0xc50): undefined reference to `proc_do_ipc_string'
kernel/built-in.o:(.data+0xc7c): undefined reference to `proc_do_ipc_string'
kernel/built-in.o:(.data+0xca8): undefined reference to `proc_do_ipc_string'
kernel/built-in.o:(.data+0xcd4): undefined reference to `proc_do_ipc_string'
kernel/built-in.o:(.data+0xd00): more undefined references to `proc_do_ipc_string' follow
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error
2006-07-08 20:20 ` 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error Adrian Bunk
@ 2006-07-09 18:52 ` Serge E. Hallyn
2006-07-09 23:33 ` Adrian Bunk
0 siblings, 1 reply; 126+ messages in thread
From: Serge E. Hallyn @ 2006-07-09 18:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Serge E. Hallyn, Sam Vilain, Kirill Korotaev,
linux-kernel
Quoting Adrian Bunk (bunk@stusta.de):
> namespaces-utsname-sysctl-hack.patch and ipc-namespace-sysctls.patch
> cause the following compile error with CONFIG_PROC_FS=n:
>
> <-- snip -->
>
> ...
> CC kernel/sysctl.o
> kernel/sysctl.c:107: warning: #proc_do_ipc_string# used but never defined
> kernel/sysctl.c:150: warning: #proc_do_utsns_string# used but never defined
> kernel/sysctl.c:2465: warning: #proc_do_uts_string# defined but not used
> ...
> LD .tmp_vmlinux1
> kernel/built-in.o:(.data+0x938): undefined reference to `proc_do_utsns_string'
> kernel/built-in.o:(.data+0x964): undefined reference to `proc_do_utsns_string'
> kernel/built-in.o:(.data+0x990): undefined reference to `proc_do_utsns_string'
> kernel/built-in.o:(.data+0x9bc): undefined reference to `proc_do_utsns_string'
> kernel/built-in.o:(.data+0x9e8): undefined reference to `proc_do_utsns_string'
> kernel/built-in.o:(.data+0xc24): undefined reference to `proc_do_ipc_string'
> kernel/built-in.o:(.data+0xc50): undefined reference to `proc_do_ipc_string'
> kernel/built-in.o:(.data+0xc7c): undefined reference to `proc_do_ipc_string'
> kernel/built-in.o:(.data+0xca8): undefined reference to `proc_do_ipc_string'
> kernel/built-in.o:(.data+0xcd4): undefined reference to `proc_do_ipc_string'
> kernel/built-in.o:(.data+0xd00): more undefined references to `proc_do_ipc_string' follow
> make: *** [.tmp_vmlinux1] Error 1
Does the below patch fix this for you? Took me awhile to get a valid
CONFIG_PROC_FS=n .config, and I'm having other -mm s390 build failures
which I'll look into tomorrow, but this seems to fix the problem.
thanks,
-serge
From: Serge Hallyn <serue@us.ibm.com>
Subject: [PATCH] namespaces: fix compilation when !CONFIG_PROC_FS
The proc_do_uts_string function was misnamed when !CONFIG_PROC_FS. The
proc_do_ipc_string function was not defined if !CONFIG_PROC_FS.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
kernel/sysctl.c | 27 +++++++++++++++------------
1 files changed, 15 insertions(+), 12 deletions(-)
488d4b4675744109a40f5a0a7d73075176cd281a
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5c4d19d..11e71c3 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -142,13 +142,8 @@ extern int max_lock_depth;
static int parse_table(int __user *, int, void __user *, size_t __user *, void __user *, size_t,
ctl_table *, void **);
-#ifndef CONFIG_UTS_NS
static int proc_do_uts_string(ctl_table *table, int write, struct file *filp,
void __user *buffer, size_t *lenp, loff_t *ppos);
-#else
-static int proc_do_utsns_string(ctl_table *table, int write, struct file *filp,
- void __user *buffer, size_t *lenp, loff_t *ppos);
-#endif
static ctl_table root_table[];
static struct ctl_table_header root_table_header =
@@ -291,7 +286,7 @@ static ctl_table kern_table[] = {
/* could maybe use __NEW_UTS_LEN here? */
.maxlen = FIELD_SIZEOF(struct new_utsname, sysname),
.mode = 0444,
- .proc_handler = &proc_do_utsns_string,
+ .proc_handler = &proc_do_uts_string,
.strategy = &sysctl_string,
},
{
@@ -300,7 +295,7 @@ static ctl_table kern_table[] = {
.data = NULL,
.maxlen = FIELD_SIZEOF(struct new_utsname, release),
.mode = 0444,
- .proc_handler = &proc_do_utsns_string,
+ .proc_handler = &proc_do_uts_string,
.strategy = &sysctl_string,
},
{
@@ -309,7 +304,7 @@ static ctl_table kern_table[] = {
.data = NULL,
.maxlen = FIELD_SIZEOF(struct new_utsname, version),
.mode = 0444,
- .proc_handler = &proc_do_utsns_string,
+ .proc_handler = &proc_do_uts_string,
.strategy = &sysctl_string,
},
{
@@ -318,7 +313,7 @@ static ctl_table kern_table[] = {
.data = NULL,
.maxlen = FIELD_SIZEOF(struct new_utsname, nodename),
.mode = 0644,
- .proc_handler = &proc_do_utsns_string,
+ .proc_handler = &proc_do_uts_string,
.strategy = &sysctl_string,
},
{
@@ -327,7 +322,7 @@ static ctl_table kern_table[] = {
.data = NULL,
.maxlen = FIELD_SIZEOF(struct new_utsname, domainname),
.mode = 0644,
- .proc_handler = &proc_do_utsns_string,
+ .proc_handler = &proc_do_uts_string,
.strategy = &sysctl_string,
},
#endif /* !CONFIG_UTS_NS */
@@ -1791,7 +1786,7 @@ static int proc_do_uts_string(ctl_table
return r;
}
#else /* !CONFIG_UTS_NS */
-static int proc_do_utsns_string(ctl_table *table, int write, struct file *filp,
+static int proc_do_uts_string(ctl_table *table, int write, struct file *filp,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
int r;
@@ -2461,11 +2456,19 @@ int proc_dostring(ctl_table *table, int
}
static int proc_do_uts_string(ctl_table *table, int write, struct file *filp,
- void __user *buffer, size_t *lenp, loff_t *ppos)
+ void __user *buffer, size_t *lenp, loff_t *ppos)
{
return -ENOSYS;
}
+#ifdef CONFIG_SYSVIPC
+static int proc_do_ipc_string(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ return -ENOSYS;
+}
+#endif
+
int proc_dointvec(ctl_table *table, int write, struct file *filp,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
--
1.1.6
^ permalink raw reply related [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error
2006-07-09 18:52 ` Serge E. Hallyn
@ 2006-07-09 23:33 ` Adrian Bunk
2006-07-10 14:22 ` Serge E. Hallyn
2006-07-10 15:08 ` Serge E. Hallyn
0 siblings, 2 replies; 126+ messages in thread
From: Adrian Bunk @ 2006-07-09 23:33 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Andrew Morton, Sam Vilain, Kirill Korotaev, linux-kernel
On Sun, Jul 09, 2006 at 01:52:28PM -0500, Serge E. Hallyn wrote:
> Quoting Adrian Bunk (bunk@stusta.de):
> > namespaces-utsname-sysctl-hack.patch and ipc-namespace-sysctls.patch
> > cause the following compile error with CONFIG_PROC_FS=n:
> >
> > <-- snip -->
> >
> > ...
> > CC kernel/sysctl.o
> > kernel/sysctl.c:107: warning: #proc_do_ipc_string# used but never defined
> > kernel/sysctl.c:150: warning: #proc_do_utsns_string# used but never defined
> > kernel/sysctl.c:2465: warning: #proc_do_uts_string# defined but not used
> > ...
> > LD .tmp_vmlinux1
> > kernel/built-in.o:(.data+0x938): undefined reference to `proc_do_utsns_string'
> > kernel/built-in.o:(.data+0x964): undefined reference to `proc_do_utsns_string'
> > kernel/built-in.o:(.data+0x990): undefined reference to `proc_do_utsns_string'
> > kernel/built-in.o:(.data+0x9bc): undefined reference to `proc_do_utsns_string'
> > kernel/built-in.o:(.data+0x9e8): undefined reference to `proc_do_utsns_string'
> > kernel/built-in.o:(.data+0xc24): undefined reference to `proc_do_ipc_string'
> > kernel/built-in.o:(.data+0xc50): undefined reference to `proc_do_ipc_string'
> > kernel/built-in.o:(.data+0xc7c): undefined reference to `proc_do_ipc_string'
> > kernel/built-in.o:(.data+0xca8): undefined reference to `proc_do_ipc_string'
> > kernel/built-in.o:(.data+0xcd4): undefined reference to `proc_do_ipc_string'
> > kernel/built-in.o:(.data+0xd00): more undefined references to `proc_do_ipc_string' follow
> > make: *** [.tmp_vmlinux1] Error 1
>
> Does the below patch fix this for you? Took me awhile to get a valid
I can confirm this patch fixes the compilation for me.
> CONFIG_PROC_FS=n .config, and I'm having other -mm s390 build failures
> which I'll look into tomorrow, but this seems to fix the problem.
CONFIG_EMBEDDED=y is required for CONFIG_PROC_FS=n, but apart from this
there was no problem for me.
Did you observe any other problems (besides a small ATM compile error
Dave has just merged my patch for) with CONFIG_PROC_FS=n?
> thanks,
> -serge
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 126+ messages in thread* Re: 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error
2006-07-09 23:33 ` Adrian Bunk
@ 2006-07-10 14:22 ` Serge E. Hallyn
2006-07-10 15:08 ` Serge E. Hallyn
1 sibling, 0 replies; 126+ messages in thread
From: Serge E. Hallyn @ 2006-07-10 14:22 UTC (permalink / raw)
To: Adrian Bunk
Cc: Serge E. Hallyn, Andrew Morton, Sam Vilain, Kirill Korotaev,
linux-kernel
Quoting Adrian Bunk (bunk@stusta.de):
> On Sun, Jul 09, 2006 at 01:52:28PM -0500, Serge E. Hallyn wrote:
> CONFIG_EMBEDDED=y is required for CONFIG_PROC_FS=n, but apart from this
> there was no problem for me.
ok, that's what I finally ended up trying. Tried other things first as
I wasn't sure 'embedded' and 's390' would mix well :) but it went
fine.
> Did you observe any other problems (besides a small ATM compile error
> Dave has just merged my patch for) with CONFIG_PROC_FS=n?
Only in s390-specific drivers:
kernel/built-in.o(.text+0x198c0): In function `get_signal_to_deliver':
: undefined reference to `arch_vma_name'
drivers/s390/built-in.o(.text+0x5ed8c): In function
`zfcp_ccw_set_online':
: undefined reference to `statistic_create'
drivers/s390/built-in.o(.text+0x5ee20): In function
`zfcp_ccw_set_online':
: undefined reference to `statistic_remove'
drivers/s390/built-in.o(.text+0x5eef0): In function
`zfcp_ccw_set_offline':
: undefined reference to `statistic_remove'
drivers/s390/built-in.o(.text+0x66a02): In function `zfcp_erp_thread':
: undefined reference to `statistic_add'
drivers/s390/built-in.o(.text+0x66a96): In function `zfcp_erp_thread':
: undefined reference to `statistic_add'
drivers/s390/built-in.o(.text+0x68e08): In function
`zfcp_qdio_response_handler':
: undefined reference to `statistic_add'
drivers/s390/built-in.o(.text+0x690aa): In function
`zfcp_qdio_sbals_from_sg':
: undefined reference to `statistic_add'
drivers/s390/built-in.o(.text+0x693a6): In function
`zfcp_qdio_sbals_from_scsicmnd':
: undefined reference to `statistic_add'
drivers/s390/built-in.o(.text+0x69690): more undefined references to
`statistic_add' follow
make: *** [.tmp_vmlinux1] Error 1
These might be fixed in 2.6.18-rc1-mm1, haven't had a chance to check.
thanks,
-serge
^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: 2.6.17-mm6: kernel/sysctl.c: PROC_FS=n compile error
2006-07-09 23:33 ` Adrian Bunk
2006-07-10 14:22 ` Serge E. Hallyn
@ 2006-07-10 15:08 ` Serge E. Hallyn
1 sibling, 0 replies; 126+ messages in thread
From: Serge E. Hallyn @ 2006-07-10 15:08 UTC (permalink / raw)
To: Adrian Bunk
Cc: Serge E. Hallyn, Andrew Morton, Sam Vilain, Kirill Korotaev,
linux-kernel
Quoting Adrian Bunk (bunk@stusta.de):
> On Sun, Jul 09, 2006 at 01:52:28PM -0500, Serge E. Hallyn wrote:
> > Quoting Adrian Bunk (bunk@stusta.de):
> > > namespaces-utsname-sysctl-hack.patch and ipc-namespace-sysctls.patch
> > > cause the following compile error with CONFIG_PROC_FS=n:
> > >
> > > <-- snip -->
> > >
> > > ...
> > > CC kernel/sysctl.o
> > > kernel/sysctl.c:107: warning: #proc_do_ipc_string# used but never defined
> > > kernel/sysctl.c:150: warning: #proc_do_utsns_string# used but never defined
> > > kernel/sysctl.c:2465: warning: #proc_do_uts_string# defined but not used
> > > ...
> > > LD .tmp_vmlinux1
> > > kernel/built-in.o:(.data+0x938): undefined reference to `proc_do_utsns_string'
> > > kernel/built-in.o:(.data+0x964): undefined reference to `proc_do_utsns_string'
> > > kernel/built-in.o:(.data+0x990): undefined reference to `proc_do_utsns_string'
> > > kernel/built-in.o:(.data+0x9bc): undefined reference to `proc_do_utsns_string'
> > > kernel/built-in.o:(.data+0x9e8): undefined reference to `proc_do_utsns_string'
> > > kernel/built-in.o:(.data+0xc24): undefined reference to `proc_do_ipc_string'
> > > kernel/built-in.o:(.data+0xc50): undefined reference to `proc_do_ipc_string'
> > > kernel/built-in.o:(.data+0xc7c): undefined reference to `proc_do_ipc_string'
> > > kernel/built-in.o:(.data+0xca8): undefined reference to `proc_do_ipc_string'
> > > kernel/built-in.o:(.data+0xcd4): undefined reference to `proc_do_ipc_string'
> > > kernel/built-in.o:(.data+0xd00): more undefined references to `proc_do_ipc_string' follow
> > > make: *** [.tmp_vmlinux1] Error 1
> >
> > Does the below patch fix this for you? Took me awhile to get a valid
>
> I can confirm this patch fixes the compilation for me.
>
> > CONFIG_PROC_FS=n .config, and I'm having other -mm s390 build failures
> > which I'll look into tomorrow, but this seems to fix the problem.
>
> CONFIG_EMBEDDED=y is required for CONFIG_PROC_FS=n, but apart from this
> there was no problem for me.
>
> Did you observe any other problems (besides a small ATM compile error
> Dave has just merged my patch for) with CONFIG_PROC_FS=n?
Ok, CONFIG_PROC_FS=n hides the fs/proc/task_mmu.c:arch_vma_name()
definition, and only i386 and powerpc have their own versions.
2.6.18-rc1-mm1's kernel/signal.c uses arch_vma_name() in print_vma().
-serge
^ permalink raw reply [flat|nested] 126+ messages in thread
