* Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-14 11:11 ` Jiri Slaby
2006-11-14 11:54 ` 2.6.19-rc5-mm2 Jiri Slaby
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
` (33 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Jiri Slaby @ 2006-11-14 11:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> Presently at
Maybe too early, but:
> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
404 not found
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
550 failed to change dir
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
2006-11-14 11:11 ` 2.6.19-rc5-mm2 Jiri Slaby
@ 2006-11-14 11:31 ` Reuben Farrelly
2006-11-14 17:00 ` 2.6.19-rc5-mm2 Gautham R Shenoy
2006-11-14 12:46 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
` (32 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Reuben Farrelly @ 2006-11-14 11:31 UTC (permalink / raw)
To: Andrew Morton, davej; +Cc: linux-kernel
On 14/11/2006 8:41 PM, Andrew Morton wrote:
> Presently at
>
> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
Oops:
(davej cc'd - I think it's his specialty)
Linux version 2.6.19-rc5-mm2 (root@tornado.reub.net) (gcc version 4.1.1 20061108
(Red Hat 4.1.1-35)) #1 SMP Tue Nov 14 21:56:04 EST 2006
Command line: ro root=/dev/md0 panic=60 console=ttyS0,57600
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003f66d000 (usable)
BIOS-e820: 000000003f66d000 - 000000003f6e8000 (ACPI NVS)
BIOS-e820: 000000003f6e8000 - 000000003f6ec000 (usable)
BIOS-e820: 000000003f6ec000 - 000000003f6ff000 (ACPI data)
BIOS-e820: 000000003f6ff000 - 000000003f700000 (usable)
end_pfn_map = 259840
DMI 2.3 present.
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[4] active PFN ranges
0: 0 -> 159
0: 256 -> 259693
0: 259816 -> 259820
0: 259839 -> 259840
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1
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, 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)
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000e0000
Nosave address range: 00000000000e0000 - 0000000000100000
Nosave address range: 000000003f66d000 - 000000003f6e8000
Nosave address range: 000000003f6ec000 - 000000003f6ff000
Allocating PCI resources starting at 40000000 (gap: 3f700000:c0900000)
PERCPU: Allocating 33920 bytes of per cpu data
Built 1 zonelists. Total pages: 253902
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
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 8192
... CHAINHASH_SIZE: 4096
memory used by lock dependency info: 1328 kB
per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
Memory: 1011700k/1039360k available (2635k kernel code, 25964k reserved, 1784k
data, 240k init)
Calibrating delay using timer specific routine.. 6007.58 BogoMIPS (lpj=12015160)
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 20060707
Using local APIC timer interrupts.
result 12500426
Detected 12.500 MHz APIC timer.
lockdep: not fixing up alternatives.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 5999.97 BogoMIPS (lpj=11999958)
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.112 MHz processor.
migration_cost=9
checking if image is initramfs... it is
Freeing initrd memory: 1238k 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)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0500-053f claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
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)
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)
intel_rng: FWH not detected
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
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, 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: 48100000-481fffff
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: 48000000-480fffff
PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
IPv4 FIB: Using LC-trie version 0.407
TCP established hash table entries: 65536 (order: 9, 3670016 bytes)
TCP bind hash table entries: 32768 (order: 8, 1835008 bytes)
TCP: Hash tables configured (established 65536 bind 32768)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1163502407.084:1): initialized
SELinux: Registering netfilter hooks
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Sleep Button (CM) as /class/input/input1
ACPI: Sleep Button (CM) [SLPB]
ACPI: Getting cpuindex for acpiid 0x3
ACPI: Getting cpuindex for acpiid 0x4
Real Time Clock Driver v1.12ac
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.3.15-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:76:ce:4a:2c
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
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 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 31/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-6, max UDMA/133, 156301488 sectors: LBA48 NCQ (depth 31/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi2 : ahci
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 31/32)
ata3.00: ata3: dev 0 multi count 16
ata3.00: configured for UDMA/133
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA ST3300622AS 3.AA PQ: 0 ANSI: 5
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
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
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access ATA ST380817AS 3.42 PQ: 0 ANSI: 5
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write back
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
scsi 2:0:0:0: Direct-Access ATA ST3300622AS 3.AA PQ: 0 ANSI: 5
SCSI device sdc: 586072368 512-byte hdwr sectors (300069 MB)
sdc: Write Protect is off
SCSI device sdc: drive cache: write back
SCSI device sdc: 586072368 512-byte hdwr sectors (300069 MB)
sdc: Write Protect is off
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 2:0:0:0: Attached scsi generic sg2 type 0
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x30B0 irq 14
ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x30B8 irq 15
scsi4 : ata_piix
ata5.00: ATAPI, max UDMA/66
ata5.00: configured for UDMA/66
scsi5 : ata_piix
ata6: port disabled. ignoring.
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: (BMDMA stat 0x24)
ata5.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: (BMDMA stat 0x24)
ata5.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: (BMDMA stat 0x24)
ata5.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: limiting speed to UDMA/44
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: (BMDMA stat 0x24)
ata5.00: tag 0 cmd 0xa0 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/44
ata5: EH complete
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
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
ehci_hcd 0000:00:1d.7: irq 23, io mem 0x482a0400
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
USB Universal Host Controller Interface driver v3.0
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.19-rc5-mm2 ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
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
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
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.19-rc5-mm2 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
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
ACPI: PCI Interrupt 0000:00:1d.2[C] -> <6>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.19-rc5-mm2 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
GSI 18 (level, low) -> IRQ 18
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
ACPI: PCI Interrupt 0000:00:1d.3[D] -> <6>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.19-rc5-mm2 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
GSI 16 (level, low) -> IRQ 16
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 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.19-rc5-mm2 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-2: new full speed USB device using uhci_hcd and address 2
usbcore: registered new interface driver libusual
usbcore: registered new interface driver hiddev
usb 2-2: new device found, idVendor=0451, idProduct=2046
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
md: raid1 personality registered for level 1
EDAC MC: Ver: 2.0.1 Nov 14 2006
usb 2-2: new device strings: Mfr=0, Product=0, SerialNumber=0
TCP bic registered
NET: Registered protocol family 1
usb 2-2: configuration #1 chosen from 1 choice
hub 2-2:1.0: USB hub found
NET: Registered protocol family 17
------------[ cut here ]------------
kernel BUG at drivers/cpufreq/cpufreq_userspace.c:138!
invalid opcode: 0000 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.19-rc5-mm2 #1
RIP: 0010:[<ffffffff80435299>] [<ffffffff80435299>]
cpufreq_governor_userspace+0x4e/0x1aa
RSP: 0000:ffff81003f61fb40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff81003ef4a0d8 RCX: 0000000000000003
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81003ef4a0d8
RBP: ffff81003f61fb60 R08: 0000000000000002 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000000
R13: 00000000ffffffea R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff80652000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff81003f61e000, task ffff810037ff0040)
Stack: ffff81003f61fb60 ffff81003ef4a0d8 0000000000000001 ffff81003ef4a0d8
ffff81003f61fb90 ffffffff80433b11 ffffffff805d0e80 ffff81003f61fc20
0000000000000000 ffff81003ef4a0d8 ffff81003f61fbc0 ffffffff80434278
Call Trace:
[<ffffffff80433b11>] __cpufreq_governor+0x51/0x9b
[<ffffffff80434278>] __cpufreq_set_policy+0xf8/0x13b
[<ffffffff804343e9>] cpufreq_set_policy+0x3c/0x93
[<ffffffff80435125>] cpufreq_add_dev+0x315/0x427
[<ffffffff803b6f87>] sysdev_driver_register+0x87/0xdb
[<ffffffff80434a8e>] cpufreq_register_driver+0x9e/0x120
[<ffffffff806837b2>] acpi_cpufreq_init+0xbe/0xc9
[<ffffffff802666c0>] init+0x160/0x31c
[<ffffffff8025deb8>] child_rip+0xa/0x12
Code: 0f 0b eb fe 48 c7 c7 20 13 5d 80 e8 a6 c8 e2 ff 48 8d bb 28
RIP [<ffffffff80435299>] cpufreq_governor_userspace+0x4e/0x1aa
RSP <ffff81003f61fb40>
<0>Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 60 seconds..
I've put the full config up at
http://www.reub.net/files/kernel/configs/2.6.19-rc5-mm1-brokencpufreq
Disable cpufreq in the config and the kernel otherwise boots and works fine.
Reuben
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
@ 2006-11-14 17:00 ` Gautham R Shenoy
2006-11-14 20:58 ` 2.6.19-rc5-mm2 Mattia Dongili
0 siblings, 1 reply; 204+ messages in thread
From: Gautham R Shenoy @ 2006-11-14 17:00 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: Andrew Morton, davej, linux-kernel
On Tue, Nov 14, 2006 at 10:31:40PM +1100, Reuben Farrelly wrote:
Hi Reuben,
> Oops:
>
> (davej cc'd - I think it's his specialty)
>
[snip]
> ------------[ cut here ]------------
> kernel BUG at drivers/cpufreq/cpufreq_userspace.c:138!
> invalid opcode: 0000 [1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.19-rc5-mm2 #1
> RIP: 0010:[<ffffffff80435299>] [<ffffffff80435299>]
> cpufreq_governor_userspace+0x4e/0x1aa
> RSP: 0000:ffff81003f61fb40 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff81003ef4a0d8 RCX: 0000000000000003
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81003ef4a0d8
> RBP: ffff81003f61fb60 R08: 0000000000000002 R09: 0000000000000001
> R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000000
> R13: 00000000ffffffea R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffffff80652000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> Process swapper (pid: 1, threadinfo ffff81003f61e000, task ffff810037ff0040)
> Stack: ffff81003f61fb60 ffff81003ef4a0d8 0000000000000001 ffff81003ef4a0d8
> ffff81003f61fb90 ffffffff80433b11 ffffffff805d0e80 ffff81003f61fc20
> 0000000000000000 ffff81003ef4a0d8 ffff81003f61fbc0 ffffffff80434278
> Call Trace:
> [<ffffffff80433b11>] __cpufreq_governor+0x51/0x9b
> [<ffffffff80434278>] __cpufreq_set_policy+0xf8/0x13b
> [<ffffffff804343e9>] cpufreq_set_policy+0x3c/0x93
> [<ffffffff80435125>] cpufreq_add_dev+0x315/0x427
> [<ffffffff803b6f87>] sysdev_driver_register+0x87/0xdb
> [<ffffffff80434a8e>] cpufreq_register_driver+0x9e/0x120
> [<ffffffff806837b2>] acpi_cpufreq_init+0xbe/0xc9
> [<ffffffff802666c0>] init+0x160/0x31c
> [<ffffffff8025deb8>] child_rip+0xa/0x12
>
>
Hmmm.. The BUG indicates policy->cur i.e current frequency is 0.
In this scenario, policy->cur variable was last set inside
acpi_cpufreq_cpu_init when cpufreq_add_dev made a call to
cpufreq_driver->init(policy).
Are you able to reproduce this with 2.6.19-rc5-mm1?
Because AFAICS, there ain't many changes w.r.t x86_64 acpi-cpufreq
from 2.6.19-rc5-mm1 to 2.6.19-rc5-mm2.
>
> I've put the full config up at
> http://www.reub.net/files/kernel/configs/2.6.19-rc5-mm1-brokencpufreq
I hope the name 2.6.19-rc5-'mm1'-brokencpufreq is by mistake :-)
> Disable cpufreq in the config and the kernel otherwise boots and works fine.
>
> Reuben
regards,
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-14 17:00 ` 2.6.19-rc5-mm2 Gautham R Shenoy
@ 2006-11-14 20:58 ` Mattia Dongili
2006-11-15 10:34 ` 2.6.19-rc5-mm2 Gautham R Shenoy
0 siblings, 1 reply; 204+ messages in thread
From: Mattia Dongili @ 2006-11-14 20:58 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Reuben Farrelly, Andrew Morton, davej, linux-kernel,
venkatesh.pallipadi, CPUFreq Mailing List
On Tue, Nov 14, 2006 at 10:30:53PM +0530, Gautham R Shenoy wrote:
> On Tue, Nov 14, 2006 at 10:31:40PM +1100, Reuben Farrelly wrote:
>
> Hi Reuben,
>
> > Oops:
> >
> > (davej cc'd - I think it's his specialty)
> >
>
> [snip]
>
> > ------------[ cut here ]------------
> > kernel BUG at drivers/cpufreq/cpufreq_userspace.c:138!
> > invalid opcode: 0000 [1] SMP
> > last sysfs file:
> > CPU 0
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.19-rc5-mm2 #1
> > RIP: 0010:[<ffffffff80435299>] [<ffffffff80435299>]
> > cpufreq_governor_userspace+0x4e/0x1aa
> > RSP: 0000:ffff81003f61fb40 EFLAGS: 00010246
> > RAX: 0000000000000000 RBX: ffff81003ef4a0d8 RCX: 0000000000000003
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81003ef4a0d8
> > RBP: ffff81003f61fb60 R08: 0000000000000002 R09: 0000000000000001
> > R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000000
> > R13: 00000000ffffffea R14: 0000000000000000 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:ffffffff80652000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> > Process swapper (pid: 1, threadinfo ffff81003f61e000, task ffff810037ff0040)
> > Stack: ffff81003f61fb60 ffff81003ef4a0d8 0000000000000001 ffff81003ef4a0d8
> > ffff81003f61fb90 ffffffff80433b11 ffffffff805d0e80 ffff81003f61fc20
> > 0000000000000000 ffff81003ef4a0d8 ffff81003f61fbc0 ffffffff80434278
> > Call Trace:
> > [<ffffffff80433b11>] __cpufreq_governor+0x51/0x9b
> > [<ffffffff80434278>] __cpufreq_set_policy+0xf8/0x13b
> > [<ffffffff804343e9>] cpufreq_set_policy+0x3c/0x93
> > [<ffffffff80435125>] cpufreq_add_dev+0x315/0x427
> > [<ffffffff803b6f87>] sysdev_driver_register+0x87/0xdb
> > [<ffffffff80434a8e>] cpufreq_register_driver+0x9e/0x120
> > [<ffffffff806837b2>] acpi_cpufreq_init+0xbe/0xc9
> > [<ffffffff802666c0>] init+0x160/0x31c
> > [<ffffffff8025deb8>] child_rip+0xa/0x12
> >
> >
>
> Hmmm.. The BUG indicates policy->cur i.e current frequency is 0.
>
> In this scenario, policy->cur variable was last set inside
> acpi_cpufreq_cpu_init when cpufreq_add_dev made a call to
> cpufreq_driver->init(policy).
>
> Are you able to reproduce this with 2.6.19-rc5-mm1?
>
> Because AFAICS, there ain't many changes w.r.t x86_64 acpi-cpufreq
> from 2.6.19-rc5-mm1 to 2.6.19-rc5-mm2.
maybe this helps? mostly guessing here, but when cpufreq_userspace is
the default governor we may hit this path and leave policy->cur
unset.
diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 18f4715..94e6e86 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
- get_cur_freq_on_cpu(cpu);
+ policy->cur = get_cur_freq_on_cpu(cpu);
break;
default:
break;
--
mattia
:wq!
^ permalink raw reply related [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-14 20:58 ` 2.6.19-rc5-mm2 Mattia Dongili
@ 2006-11-15 10:34 ` Gautham R Shenoy
2006-11-15 10:42 ` 2.6.19-rc5-mm2 Reuben Farrelly
0 siblings, 1 reply; 204+ messages in thread
From: Gautham R Shenoy @ 2006-11-15 10:34 UTC (permalink / raw)
To: Gautham R Shenoy, Reuben Farrelly, Andrew Morton, davej,
linux-kernel, venkatesh.pallipadi, CPUFreq Mailing List
Hi,
On Tue, Nov 14, 2006 at 09:58:29PM +0100, Mattia Dongili wrote:
>
> maybe this helps? mostly guessing here, but when cpufreq_userspace is
> the default governor we may hit this path and leave policy->cur
> unset.
I doubt if that's causing the problem. My reasons are:
- Reuben's config shows his system to be a x64_64. So if I am not
mistaken, the correct file look for would be
arch/ia64/kernel/cpufreq/acpi-cpufreq.c.
- The fix provided by you deals with the state of a
driver(hardware) specific variable data->cpu_feature while the
governors like userspace/performance/powersave/ondemand are
driver(hardware) independent.
Nevertheless, it could be a valid fix for i386 acpi_cpufreq considering
that policy->cur is not being initialized if
data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.
Please check with Dave Jones or Venkatesh Pallipadi.
Thanks
gautham.
>
> diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> index 18f4715..94e6e86 100644
> --- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> +++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> @@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
> break;
> case ACPI_ADR_SPACE_FIXED_HARDWARE:
> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> - get_cur_freq_on_cpu(cpu);
> + policy->cur = get_cur_freq_on_cpu(cpu);
> break;
> default:
> break;
>
> --
> mattia
> :wq!
> -
> 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/
>
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-15 10:34 ` 2.6.19-rc5-mm2 Gautham R Shenoy
@ 2006-11-15 10:42 ` Reuben Farrelly
0 siblings, 0 replies; 204+ messages in thread
From: Reuben Farrelly @ 2006-11-15 10:42 UTC (permalink / raw)
To: ego
Cc: Andrew Morton, davej, linux-kernel, venkatesh.pallipadi,
CPUFreq Mailing List
Hi,
On 15/11/2006 9:34 PM, Gautham R Shenoy wrote:
> Hi,
>
> On Tue, Nov 14, 2006 at 09:58:29PM +0100, Mattia Dongili wrote:
>> maybe this helps? mostly guessing here, but when cpufreq_userspace is
>> the default governor we may hit this path and leave policy->cur
>> unset.
>
> I doubt if that's causing the problem. My reasons are:
Yes. I just tried with the one-liner from Mattia as below, and unfortunately it
made no difference. The crash was the same..
Unfortunately I didn't get to test out 2.6.19-rc5-mm1 as there was some issue
with it unable to mount my ext3/raid-1 root (fixed in -rc5-mm2), that I didn't
have time to get to the bottom of.
So there is a chance that this cpufreq problem is not new to -rc5-mm2.
Reuben
> - Reuben's config shows his system to be a x64_64. So if I am not
> mistaken, the correct file look for would be
> arch/ia64/kernel/cpufreq/acpi-cpufreq.c.
>
> - The fix provided by you deals with the state of a
> driver(hardware) specific variable data->cpu_feature while the
> governors like userspace/performance/powersave/ondemand are
> driver(hardware) independent.
>
> Nevertheless, it could be a valid fix for i386 acpi_cpufreq considering
> that policy->cur is not being initialized if
> data->cpu_feature == ACPI_ADR_SPACE_FIXED_HARDWARE.
>
> Please check with Dave Jones or Venkatesh Pallipadi.
>
> Thanks
> gautham.
>
>> diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> index 18f4715..94e6e86 100644
>> --- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> +++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> @@ -706,7 +706,7 @@ static int acpi_cpufreq_cpu_init(struct
>> break;
>> case ACPI_ADR_SPACE_FIXED_HARDWARE:
>> acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
>> - get_cur_freq_on_cpu(cpu);
>> + policy->cur = get_cur_freq_on_cpu(cpu);
>> break;
>> default:
>> break;
>>
>> --
>> mattia
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
2006-11-14 11:11 ` 2.6.19-rc5-mm2 Jiri Slaby
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
@ 2006-11-14 12:46 ` Mariusz Kozlowski
2006-11-14 13:07 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
2006-11-14 16:41 ` 2.6.19-rc5-mm2 Andrew Morton
2006-11-14 13:50 ` 2.6.19-rc5-mm2 Eric Dumazet
` (31 subsequent siblings)
34 siblings, 2 replies; 204+ messages in thread
From: Mariusz Kozlowski @ 2006-11-14 12:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]
Hello,
On every box I tried I got this warning:
$ make
scripts/kconfig/conf -s arch/i386/Kconfig
Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET
Second thing: the same thing as with 2.6.19-rc5-mm1 happens:
> > > > LD .tmp_vmlinux1
> > > > arch/x86_64/kernel/built-in.o(.init.text+0x31b7): In function
> > > > `alternative_instructions': arch/i386/kernel/alternative.c:437:
undefined
> > > > reference to `__stop_parainstructions'
> > > >
arch/x86_64/kernel/built-in.o(.init.text+0x31be):arch/i386/kernel/alterna
> > > >tive.c:437: undefined reference to `__start_parainstructions' make: ***
> > > > [.tmp_vmlinux1] Error 1
> > >
> > > Thanks. Please send me the .config and I'll see if it's still
happening.
> >
> > Please find .config attached.
>
> Thanks. The paravirt patches have churned a bit recently and we appear to
> have fixed this one.
Here it goes:
LD .tmp_vmlinux1
arch/x86_64/kernel/built-in.o(.init.text+0x328f): In function
`alternative_instructions':
arch/i386/kernel/alternative.c:437: undefined reference to
`__stop_parainstructions'
arch/x86_64/kernel/built-in.o(.init.text+0x3296):arch/i386/kernel/alternative.c:437:
undefined reference to `__start_parainstructions'
make: *** [.tmp_vmlinux1] Error 1
Linux p15198998 2.6.14.3-051207a #1 SMP Wed Dec 7 12:17:16 CET 2005 x86_64
x86_64 x86_64 GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
binutils 2.15.94.0.2.2
util-linux 2.12q
mount 2.12q
module-init-tools 3.2-pre1
e2fsprogs 1.36
jfsutils 1.1.7
reiserfsprogs 3.6.18
xfsprogs 2.6.25
quota-tools 3.12.
Linux C Library x 1 root root 1446783 Jun 11
2005 /lib64/tls/libc.so.6
Dynamic linker (ldd) 2.3.4
Linux C++ Library 5.0.7
Procps 3.2.5
Net-tools 1.60
Kbd 1.12
Sh-utils 5.3.0
udev 053
Modules Loaded thermal fan sg ide_cd cdrom dm_mod
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3200+
stepping : 2
cpu MHz : 1000.045
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm
bogomips : 2002.26
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Config attached ('allmodconfig' + CONFIG_KVM=n).
--
Regards,
Mariusz Kozlowski
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 70259 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19-rc5-mm2
# Tue Nov 14 12:05:13 2006
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
CONFIG_IPC_NS=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_UTS_NS=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_KEVENT=y
CONFIG_KEVENT_USER_STAT=y
CONFIG_KEVENT_TIMER=y
CONFIG_KEVENT_POLL=y
CONFIG_KEVENT_SOCKET=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_TASK_XACCT=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=m
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_L1_CACHE_BYTES=128
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_INTERNODE_CACHE_BYTES=128
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_NODES_SHIFT=6
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NUMA_EMU=y
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
CONFIG_DISCONTIGMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_DISCONTIGMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_NEED_MULTIPLE_NODES=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_ADAPTIVE_READAHEAD=y
CONFIG_READAHEAD_ALLOW_OVERHEADS=y
CONFIG_DEBUG_READAHEAD=y
CONFIG_READAHEAD_HIT_FEEDBACK=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y
CONFIG_NR_CPUS=8
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR_ALL=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_REORDER=y
CONFIG_K8_NB=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
CONFIG_GENERIC_PENDING_IRQ=y
#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PM_DEBUG=y
CONFIG_DISABLE_CONSOLE_SUSPEND=y
CONFIG_PM_SYSFS_DEPRECATED=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_SUSPEND_SMP=y
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_SLEEP_PROC_SLEEP=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_HOTKEY=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=m
CONFIG_ACPI_BAY=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_NUMA=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_SONY=m
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
CONFIG_ACPI_SBS=m
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
#
# CPUFreq processor drivers
#
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_ACPI_CPUFREQ=m
#
# shared options
#
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
CONFIG_X86_P4_CLOCKMOD=m
CONFIG_X86_SPEEDSTEP_LIB=m
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE=y
CONFIG_PCIEAER=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MULTITHREAD_PROBE=y
CONFIG_PCI_DEBUG=y
CONFIG_HT_IRQ=y
#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
CONFIG_PCMCIA_DEBUG=y
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_PCCARD_NONSTATIC=m
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
CONFIG_HOTPLUG_PCI_SHPC=m
CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE=y
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=m
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_NETDEBUG=y
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=m
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_XFRM_SUB_POLICY=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_MULTIPATH_CACHED=y
CONFIG_IP_ROUTE_MULTIPATH_RR=m
CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_DRR=m
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_SECMARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=m
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_NETBIOS_NS=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_PPTP=m
CONFIG_IP_NF_H323=m
CONFIG_IP_NF_SIP=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_NAT_PPTP=m
CONFIG_IP_NF_NAT_H323=m
CONFIG_IP_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# DECnet: Netfilter Configuration
#
CONFIG_DECNET_NF_GRABULATOR=m
#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y
#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
CONFIG_IP_DCCP_CCID2_DEBUG=y
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
#
# DCCP Kernel Hacking
#
CONFIG_IP_DCCP_DEBUG=y
CONFIG_NET_DCCPPROBE=m
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
#
# TIPC Configuration (EXPERIMENTAL)
#
CONFIG_TIPC=m
CONFIG_TIPC_ADVANCED=y
CONFIG_TIPC_ZONES=3
CONFIG_TIPC_CLUSTERS=1
CONFIG_TIPC_NODES=255
CONFIG_TIPC_SLAVE_NODES=0
CONFIG_TIPC_PORTS=8191
CONFIG_TIPC_LOG=0
CONFIG_TIPC_DEBUG=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=y
CONFIG_LLC2=m
CONFIG_IPX=m
CONFIG_IPX_INTERN=y
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
CONFIG_ECONET=m
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NET_TCPPROBE=m
CONFIG_HAMRADIO=y
#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m
#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_YAM=m
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y
#
# Infrared-port device drivers
#
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_TOIM3232_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m
#
# Old SIR device drivers
#
#
# Old Serial dongle support
#
#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m
CONFIG_MCS_FIR=m
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
CONFIG_IEEE80211_DEBUG=y
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
CONFIG_WIRELESS_EXT=y
CONFIG_FIB_RULES=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_DEBUG_DRIVER=y
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=0
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_MAP_BANK_WIDTH_8=y
CONFIG_MTD_MAP_BANK_WIDTH_16=y
CONFIG_MTD_MAP_BANK_WIDTH_32=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_I4=y
CONFIG_MTD_CFI_I8=y
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
CONFIG_MTD_OBSOLETE_CHIPS=y
CONFIG_MTD_SHARP=m
#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0x0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_AMD76XROM=m
CONFIG_MTD_ICHXROM=m
CONFIG_MTD_ESB2ROM=m
CONFIG_MTD_SCB2_FLASH=m
CONFIG_MTD_NETtel=m
CONFIG_MTD_DILNETPC=m
CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000
CONFIG_MTD_L440GX=m
CONFIG_MTD_PCI=m
CONFIG_MTD_PLATRAM=m
#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
CONFIG_MTD_PMC551_BUGFIX=y
CONFIG_MTD_PMC551_DEBUG=y
CONFIG_MTD_DATAFLASH=m
CONFIG_MTD_M25P80=m
CONFIG_MTD_SLRAM=m
CONFIG_MTD_PHRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m
#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCECC=m
CONFIG_MTD_DOCPROBE_ADVANCED=y
CONFIG_MTD_DOCPROBE_ADDRESS=0x0000
CONFIG_MTD_DOCPROBE_HIGH=y
CONFIG_MTD_DOCPROBE_55AA=y
#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED=y
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0x0
CONFIG_MTD_NAND_DISKONCHIP_PROBE_HIGH=y
CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y
CONFIG_MTD_NAND_NANDSIM=m
#
# OneNAND Flash Device Drivers
#
CONFIG_MTD_ONENAND=m
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_OTP=y
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=m
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_DEBUG=y
#
# Protocols
#
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
CONFIG_ATA_OVER_ETH=m
#
# Misc devices
#
CONFIG_IBM_ASM=m
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
CONFIG_MSI_LAPTOP=m
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=m
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=m
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
CONFIG_BLK_DEV_IDE_SATA=y
CONFIG_BLK_DEV_HD_IDE=y
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=m
CONFIG_BLK_DEV_OPTI621=m
CONFIG_BLK_DEV_RZ1000=m
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_IDEDMA_FORCED=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
CONFIG_BLK_DEV_AEC62XX=m
CONFIG_BLK_DEV_ALI15X3=m
CONFIG_WDC_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=m
CONFIG_BLK_DEV_ATIIXP=m
CONFIG_BLK_DEV_CMD64X=m
CONFIG_BLK_DEV_TRIFLEX=m
CONFIG_BLK_DEV_CY82C693=m
CONFIG_BLK_DEV_CS5520=m
CONFIG_BLK_DEV_CS5530=m
CONFIG_BLK_DEV_HPT34X=m
CONFIG_HPT34X_AUTODMA=y
CONFIG_BLK_DEV_HPT366=m
CONFIG_BLK_DEV_JMICRON=m
CONFIG_BLK_DEV_SC1200=m
CONFIG_BLK_DEV_PIIX=m
CONFIG_BLK_DEV_IT821X=m
CONFIG_BLK_DEV_NS87415=m
CONFIG_BLK_DEV_PDC202XX_OLD=m
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=m
CONFIG_BLK_DEV_SVWKS=m
CONFIG_BLK_DEV_SIIMAGE=m
CONFIG_BLK_DEV_SIS5513=m
CONFIG_BLK_DEV_SLC90E66=m
CONFIG_BLK_DEV_TRM290=m
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_HD=y
#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_LIBSAS_DEBUG=y
#
# SCSI low-level drivers
#
CONFIG_ISCSI_TCP=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=5000
CONFIG_AIC79XX_ENABLE_RD_STRM=y
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=m
CONFIG_AIC94XX_DEBUG=y
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
CONFIG_SCSI_IZIP_EPP16=y
CONFIG_SCSI_IZIP_SLOW_CTR=y
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_SRP=m
#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=m
CONFIG_SATA_AHCI=m
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=m
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SX4=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIL24=m
CONFIG_SATA_SIS=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
CONFIG_SATA_ACPI=y
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_CMD64X=m
CONFIG_PATA_CS5520=m
CONFIG_PATA_CS5530=m
CONFIG_PATA_CYPRESS=m
CONFIG_PATA_EFAR=m
CONFIG_ATA_GENERIC=m
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
CONFIG_PATA_IT821X=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_TRIFLEX=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_MPIIX=m
CONFIG_PATA_OLDPIIX=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NS87410=m
CONFIG_PATA_OPTI=m
CONFIG_PATA_OPTIDMA=m
CONFIG_PATA_PCMCIA=m
CONFIG_PATA_PDC_OLD=m
CONFIG_PATA_RADISYS=m
CONFIG_PATA_RZ1000=m
CONFIG_PATA_SC1200=m
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_VIA=m
CONFIG_PATA_WINBOND=m
CONFIG_PATA_PLATFORM=m
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m
#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m
#
# Subsystem Options
#
CONFIG_IEEE1394_VERBOSEDEBUG=y
CONFIG_IEEE1394_OUI_DB=y
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
CONFIG_IEEE1394_EXPORT_FULL_API=y
#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_NET_SB1000=m
#
# ARCnet devices
#
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_CAP=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_PCI=m
#
# PHY device support
#
CONFIG_PHYLIB=m
#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_FIXED_PHY=m
CONFIG_FIXED_MII_10_FDX=y
CONFIG_FIXED_MII_100_FDX=y
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
CONFIG_TULIP_MWI=y
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
CONFIG_TULIP_NAPI_HW_MITIGATION=y
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
CONFIG_HP100=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_PCNET32_NAPI=y
CONFIG_AMD8111_ETH=m
CONFIG_AMD8111E_NAPI=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
CONFIG_B44=m
CONFIG_FORCEDETH=m
CONFIG_FORCEDETH_NAPI=y
CONFIG_DGRS=m
CONFIG_EEPRO100=m
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
CONFIG_8139_OLD_RX_RESET=y
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_SUNDANCE_MMIO=y
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
CONFIG_E1000_DISABLE_PACKET_SPLIT=y
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=m
CONFIG_SKY2=m
CONFIG_SK98LIN=m
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=m
CONFIG_BNX2=m
CONFIG_QLA3XXX=m
#
# Ethernet (10000 Mbit)
#
CONFIG_CHELSIO_T1=m
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_S2IO=m
CONFIG_S2IO_NAPI=y
CONFIG_MYRI10GE=m
CONFIG_NETXEN_NIC=m
#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMOL=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_ABYSS=m
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y
#
# Obsolete Wireless cards support (pre-802.11)
#
CONFIG_STRIP=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m
#
# Wireless 802.11 Frequency Hopping cards support
#
CONFIG_PCMCIA_RAYCS=m
#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
CONFIG_IPW2100_DEBUG=y
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
CONFIG_IPW2200_DEBUG=y
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m
#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_PCMCIA_WL3501=m
#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
CONFIG_USB_ZD1201=m
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
CONFIG_HOSTAP_PLX=m
CONFIG_HOSTAP_PCI=m
CONFIG_HOSTAP_CS=m
CONFIG_BCM43XX=m
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_DMA=y
CONFIG_BCM43XX_PIO=y
CONFIG_BCM43XX_DMA_AND_PIO_MODE=y
# CONFIG_BCM43XX_DMA_MODE is not set
# CONFIG_BCM43XX_PIO_MODE is not set
CONFIG_ZD1211RW=m
CONFIG_ZD1211RW_DEBUG=y
CONFIG_ACX=m
CONFIG_ACX_PCI=y
CONFIG_ACX_USB=y
CONFIG_NET_WIRELESS=y
#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
CONFIG_ARCNET_COM20020_CS=m
#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_LANMEDIA=m
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
CONFIG_HDLC_RAW_ETH=m
CONFIG_HDLC_CISCO=m
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m
CONFIG_HDLC_X25=m
CONFIG_PCI200SYN=m
CONFIG_WANXL=m
CONFIG_PC300=m
CONFIG_PC300_MLPPP=y
#
# Cyclades-PC300 MLPPP support is disabled.
#
#
# Refer to the file README.mlppp, provided by PC300 package.
#
CONFIG_FARSYNC=m
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
CONFIG_DSCC4_PCI_RST=y
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_WAN_ROUTER_DRIVERS=y
CONFIG_CYCLADES_SYNC=m
CONFIG_CYCLOMX_X25=y
CONFIG_LAPBETHER=m
CONFIG_X25_ASY=m
CONFIG_SBNI=m
CONFIG_SBNI_MULTILINE=y
#
# ATM drivers
#
CONFIG_ATM_DUMMY=m
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
CONFIG_ATM_ENI_DEBUG=y
CONFIG_ATM_ENI_TUNE_BURST=y
CONFIG_ATM_ENI_BURST_TX_16W=y
CONFIG_ATM_ENI_BURST_TX_8W=y
CONFIG_ATM_ENI_BURST_TX_4W=y
CONFIG_ATM_ENI_BURST_TX_2W=y
CONFIG_ATM_ENI_BURST_RX_16W=y
CONFIG_ATM_ENI_BURST_RX_8W=y
CONFIG_ATM_ENI_BURST_RX_4W=y
CONFIG_ATM_ENI_BURST_RX_2W=y
CONFIG_ATM_FIRESTREAM=m
CONFIG_ATM_ZATM=m
CONFIG_ATM_ZATM_DEBUG=y
CONFIG_ATM_IDT77252=m
CONFIG_ATM_IDT77252_DEBUG=y
CONFIG_ATM_IDT77252_RCV_ALL=y
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
CONFIG_ATM_AMBASSADOR_DEBUG=y
CONFIG_ATM_HORIZON=m
CONFIG_ATM_HORIZON_DEBUG=y
CONFIG_ATM_IA=m
CONFIG_ATM_IA_DEBUG=y
CONFIG_ATM_FORE200E_MAYBE=m
CONFIG_ATM_FORE200E_PCA=y
CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
CONFIG_ATM_FORE200E_USE_TASKLET=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_FORE200E=m
CONFIG_ATM_HE=m
CONFIG_ATM_HE_USE_SUNI=y
CONFIG_FDDI=y
CONFIG_DEFXX=m
CONFIG_SKFP=m
CONFIG_HIPPI=y
CONFIG_ROADRUNNER=m
CONFIG_ROADRUNNER_LARGE_RINGS=y
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NET_FC=y
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
CONFIG_ISDN=m
#
# Old ISDN4Linux
#
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
CONFIG_ISDN_X25=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m
#
# ISDN4Linux hardware drivers
#
#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m
#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8
#
# HiSax supported cards
#
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
CONFIG_HISAX_DEBUG=y
#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m
#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
CONFIG_HISAX_HFCUSB=m
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_HISAX_HDLC=y
#
# Active cards
#
#
# Siemens Gigaset
#
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_DEBUG=y
CONFIG_GIGASET_UNDOCREQ=y
#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m
#
# CAPI hardware drivers
#
#
# Active AVM cards
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
#
# Active Eicon DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m
#
# Telephony Support
#
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_TSDEV=m
CONFIG_INPUT_TSDEV_SCREEN_X=240
CONFIG_INPUT_TSDEV_SCREEN_Y=320
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=m
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_I8042=m
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=m
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
CONFIG_CYZ_INTR=y
CONFIG_DIGIEPCA=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_MOXA_SMARTIO_NEW=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
CONFIG_SPECIALIX=m
CONFIG_SPECIALIX_RTSCTS=y
CONFIG_SX=m
CONFIG_RIO=m
CONFIG_RIO_OLDPCI=y
CONFIG_STALDRV=y
CONFIG_NOZOMI=m
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m
#
# IPMI
#
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
CONFIG_I6300ESB_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_SC1200_WDT=m
CONFIG_PC87413_WDT=m
CONFIG_60XX_WDT=m
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_SMSC37B787_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_SBC_EPX_C3_WATCHDOG=m
#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y
#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_DTLK=m
CONFIG_R3964=m
CONFIG_APPLICOM=m
#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=m
CONFIG_AGP_SIS=m
CONFIG_AGP_VIA=m
CONFIG_DRM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
#
# TPM devices
#
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_OCORES=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m
#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_BITBANG=m
CONFIG_SPI_BUTTERFLY=m
#
# SPI Protocol Masters
#
#
# Dallas's 1-wire bus
#
CONFIG_W1=m
CONFIG_W1_CON=y
#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_MATROX=m
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m
#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
#
# Hardware Monitoring support
#
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM70=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
CONFIG_HWMON_DEBUG_CHIP=y
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
#
# Video Capture Adapters
#
#
# Video Capture Adapters
#
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA7111=m
CONFIG_VIDEO_SAA7114=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m
CONFIG_VIDEO_CX25840=m
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m
CONFIG_VIDEO_VIVI=m
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_OSS=m
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CAFE_CCIC=m
#
# V4L USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_29XXX=y
CONFIG_VIDEO_PVRUSB2_24XXX=y
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DEBUGIFC=y
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_ZC0301=m
CONFIG_USB_PWC=m
CONFIG_USB_PWC_DEBUG=y
#
# Radio Adapters
#
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_USB_DSBR=m
#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m
CONFIG_DVB_CORE_ATTACH=y
#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
CONFIG_DVB_USB_DEBUG=y
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y
CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=50
#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
CONFIG_DVB_B2C2_FLEXCOP_DEBUG=y
#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m
#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m
#
# Supported DVB Frontends
#
#
# Customise DVB Frontends
#
CONFIG_DVB_FE_CUSTOMISE=y
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_TDA10086=m
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m
#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
#
# Tuners/PLL support
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUNER_MT2060=m
#
# Miscellaneous devices
#
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_TUA6100=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_USB_DABUSB=m
#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=m
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_CIRRUS=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_CYBER2000=m
CONFIG_FB_ARC=m
CONFIG_FB_VGA16=m
CONFIG_FB_HGA=m
CONFIG_FB_HGA_ACCEL=y
CONFIG_FB_S1D13XXX=m
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
CONFIG_FB_RIVA_DEBUG=y
CONFIG_FB_INTEL=m
CONFIG_FB_INTEL_DEBUG=y
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_DEBUG=y
CONFIG_FB_ATY128=m
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_VOODOO1=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_TRIDENT_ACCEL=y
CONFIG_FB_GEODE=y
CONFIG_FB_GEODE_GX=m
CONFIG_FB_GEODE_GX1=m
CONFIG_FB_VIRTUAL=m
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_FONT_6x11=y
CONFIG_FONT_7x14=y
CONFIG_FONT_PEARL_8x8=y
CONFIG_FONT_ACORN_8x8=y
CONFIG_FONT_MINI_4x6=y
CONFIG_FONT_SUN8x16=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONT_10x18=y
#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_LCD_DEVICE=y
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_DETECT=y
CONFIG_SND_PCM_XRUN_DEBUG=y
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
#
# PCI devices
#
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
CONFIG_SND_BT87X_OVERCLOCK=y
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_AC97_POWER_SAVE=y
#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
#
# PCMCIA devices
#
CONFIG_SND_VXPOCKET=m
CONFIG_SND_PDAUDIOCF=m
#
# SoC audio support
#
CONFIG_SND_SOC=m
#
# SoC Platforms
#
#
# SoC Audio for the Atmel AT91
#
#
# SoC Audio for the Intel PXA2xx
#
#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
CONFIG_OSS_OBSOLETE_DRIVER=y
CONFIG_SOUND_BT878=m
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
CONFIG_SOUND_FUSION=m
CONFIG_SOUND_ES1371=m
CONFIG_SOUND_ICH=m
CONFIG_SOUND_TRIDENT=m
CONFIG_SOUND_MSNDCLAS=m
CONFIG_MSNDCLAS_INIT_FILE="/etc/sound/msndinit.bin"
CONFIG_MSNDCLAS_PERM_FILE="/etc/sound/msndperm.bin"
CONFIG_SOUND_MSNDPIN=m
CONFIG_MSNDPIN_INIT_FILE="/etc/sound/pndspini.bin"
CONFIG_MSNDPIN_PERM_FILE="/etc/sound/pndsperm.bin"
CONFIG_SOUND_VIA82CXXX=m
CONFIG_MIDI_VIA82CXXX=y
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_AD1816=m
CONFIG_SOUND_AD1889=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_PAS=m
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
CONFIG_SOUND_SB=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0x0
CONFIG_AEDSP16_MSS=y
# CONFIG_AEDSP16_SBPRO is not set
CONFIG_AEDSP16_MPU401=y
CONFIG_SOUND_TVMIXER=m
CONFIG_SOUND_KAHLUA=m
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
CONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_MULTITHREAD_PROBE=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_CS=m
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_LIBUSUAL=y
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDINPUT_POWERBOOK=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_ACECAD=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_TOUCHSCREEN=m
CONFIG_USB_TOUCHSCREEN_EGALAX=y
CONFIG_USB_TOUCHSCREEN_PANJIT=y
CONFIG_USB_TOUCHSCREEN_3M=y
CONFIG_USB_TOUCHSCREEN_ITM=y
CONFIG_USB_TOUCHSCREEN_ETURBO=y
CONFIG_USB_TOUCHSCREEN_GUNZE=y
CONFIG_USB_YEALINK=m
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m
CONFIG_USB_ATI_REMOTE2=m
CONFIG_USB_KEYSPAN_REMOTE=m
CONFIG_USB_APPLETOUCH=m
#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET_MII=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y
#
# USB port drivers
#
CONFIG_USB_USS720=m
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_QUATECH_ESU100=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_PHIDGET=m
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETMOTORCONTROL=m
CONFIG_USB_PHIDGETSERVO=m
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
CONFIG_USB_TEST=m
CONFIG_USB_GOTEMP=m
#
# USB DSL modem support
#
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
#
# USB Gadget Support
#
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_SELECTED=y
CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_NET2280=m
# CONFIG_USB_GADGET_PXA2XX is not set
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_LH7A40X is not set
# CONFIG_USB_GADGET_OMAP is not set
# CONFIG_USB_GADGET_AT91 is not set
# CONFIG_USB_GADGET_DUMMY_HCD is not set
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_GADGETFS=m
CONFIG_USB_FILE_STORAGE=m
CONFIG_USB_FILE_STORAGE_TEST=y
CONFIG_USB_G_SERIAL=m
CONFIG_USB_MIDI_GADGET=m
#
# MMC/SD Card support
#
CONFIG_MMC=m
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=m
CONFIG_MMC_SDHCI=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
#
# LED devices
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
#
# LED drivers
#
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
#
# InfiniBand support
#
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
CONFIG_INFINIBAND_IPATH=m
CONFIG_INFINIBAND_AMSO1100=m
CONFIG_INFINIBAND_AMSO1100_DEBUG=y
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_ISER=m
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=m
#
# Reporting subsystems
#
CONFIG_EDAC_DEBUG=y
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_K8=m
CONFIG_EDAC_POLL=y
#
# Real Time Clock
#
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
#
# RTC drivers
#
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_RS5C348=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_M48T86=m
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_DRV_MAX6902=m
CONFIG_RTC_DRV_V3020=m
#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
CONFIG_NET_DMA=y
#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m
#
# Auxiliary Display support
#
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
CONFIG_KVM=n
#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4DEV_FS=m
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=m
CONFIG_REISER4_FS=m
CONFIG_REISER4_DEBUG=y
CONFIG_REISERFS_FS=m
CONFIG_REISERFS_CHECK=y
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
CONFIG_JFS_DEBUG=y
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_NOLOCK=m
CONFIG_GFS2_FS_LOCKING_DLM=m
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_DEBUG_MASKLOG=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y
#
# Caches
#
CONFIG_FSCACHE=y
CONFIG_CACHEFILES=m
CONFIG_CACHEFILES_DEBUG=y
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
CONFIG_NTFS_DEBUG=y
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
#
CONFIG_ADFS_FS=m
CONFIG_ADFS_FS_RW=y
CONFIG_AFFS_FS=m
CONFIG_ECRYPT_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
CONFIG_BEFS_DEBUG=y
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS_FS=m
CONFIG_JFFS_FS_VERBOSE=0
CONFIG_JFFS_PROC_FS=y
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_SUMMARY=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_FS_WRITE=y
CONFIG_UFS_DEBUG=y
#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_FSCACHE=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
CONFIG_CIFS_STATS2=y
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_DEBUG2=y
CONFIG_CIFS_EXPERIMENTAL=y
CONFIG_CIFS_UPCALL=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
CONFIG_CODA_FS_OLD_API=y
CONFIG_AFS_FS=m
CONFIG_AFS_FSCACHE=y
CONFIG_RXRPC=m
CONFIG_9P_FS=m
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
CONFIG_ACORN_PARTITION_CUMANA=y
CONFIG_ACORN_PARTITION_EESOX=y
CONFIG_ACORN_PARTITION_ICS=y
CONFIG_ACORN_PARTITION_ADFS=y
CONFIG_ACORN_PARTITION_POWERTEC=y
CONFIG_ACORN_PARTITION_RISCIX=y
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
CONFIG_LDM_DEBUG=y
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Distributed Lock Manager
#
CONFIG_DLM=m
CONFIG_DLM_TCP=y
# CONFIG_DLM_SCTP is not set
CONFIG_DLM_DEBUG=y
#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_KPROBES=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_PAGE_OWNER=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_LIST=y
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
CONFIG_STACK_UNWIND=y
CONFIG_PROFILE_LIKELY=y
CONFIG_FORCED_INLINING=y
CONFIG_DEBUG_SYNCHRO_TEST=m
CONFIG_RCU_TORTURE_TEST=m
CONFIG_LKDTM=m
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_DEBUG_RODATA=y
CONFIG_IOMMU_DEBUG=y
CONFIG_IOMMU_LEAK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_INTEGRITY=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_FS_CAPABILITIES=y
CONFIG_SECURITY_ROOTPLUG=m
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX=y
CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE=19
CONFIG_SECURITY_SLIM=y
CONFIG_SECURITY_SLIM_BOOTPARAM=y
CONFIG_SECURITY_SLIM_BOOTPARAM_VALUE=1
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=m
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_TEST=m
#
# Hardware crypto devices
#
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 12:46 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
@ 2006-11-14 13:07 ` Mariusz Kozlowski
2006-11-14 16:41 ` 2.6.19-rc5-mm2 Andrew Morton
1 sibling, 0 replies; 204+ messages in thread
From: Mariusz Kozlowski @ 2006-11-14 13:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hello,
Not sure if this is important. On 2 boxes I've seen a bunch of similar
warnings. Please see the log:
http://tuxland.pl/misc/2.6.19-rc5-mm2-report.txt (211kB)
both boxes used 'allmodconfig' configuration. This is from one of them:
Linux orion 2.6.19-rc5-mm2 #1 PREEMPT Tue Nov 14 11:14:35 CET 2006 i686
Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
Gnu C 4.1.1
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
pcmciautils 014
pcmcia-cs 3.2.9
nfs-utils 1.0.6
Linux C Library > libc.2.4
Dynamic linker (ldd) 2.4
Procps 3.2.6
Net-tools 1.60
Kbd 1.12
Sh-utils 6.4
udev 087
wireless-tools 29
Modules Loaded orinoco_cs orinoco hermes pcmcia firmware_class 8139too
yenta_socket rsrc_nonstatic pcmcia_core
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping : 9
cpu MHz : 2392.531
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4786.53
clflush size : 64
--
Regards,
Mariusz Kozlowski
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-14 12:46 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
2006-11-14 13:07 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
@ 2006-11-14 16:41 ` Andrew Morton
2006-11-14 17:09 ` 2.6.19-rc5-mm2 Andrew Morton
1 sibling, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-14 16:41 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: linux-kernel, Rusty Russell
On Tue, 14 Nov 2006 13:46:51 +0100
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> On every box I tried I got this warning:
>
> $ make
> scripts/kconfig/conf -s arch/i386/Kconfig
> Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET
yup. The GFS guys have since fixed that.
> Second thing: the same thing as with 2.6.19-rc5-mm1 happens:
>
> > > > > LD .tmp_vmlinux1
> > > > > arch/x86_64/kernel/built-in.o(.init.text+0x31b7): In function
> > > > > `alternative_instructions': arch/i386/kernel/alternative.c:437:
> undefined
> > > > > reference to `__stop_parainstructions'
> > > > >
> arch/x86_64/kernel/built-in.o(.init.text+0x31be):arch/i386/kernel/alterna
> > > > >tive.c:437: undefined reference to `__start_parainstructions' make: ***
> > > > > [.tmp_vmlinux1] Error 1
> > > >
> > > > Thanks. Please send me the .config and I'll see if it's still
> happening.
> > >
> > > Please find .config attached.
> >
> > Thanks. The paravirt patches have churned a bit recently and we appear to
> > have fixed this one.
>
> Here it goes:
>
> LD .tmp_vmlinux1
> arch/x86_64/kernel/built-in.o(.init.text+0x328f): In function
> `alternative_instructions':
> arch/i386/kernel/alternative.c:437: undefined reference to
> `__stop_parainstructions'
> arch/x86_64/kernel/built-in.o(.init.text+0x3296):arch/i386/kernel/alternative.c:437:
> undefined reference to `__start_parainstructions'
> make: *** [.tmp_vmlinux1] Error 1
Strange, I don't get that with your .config. I guess it's a binutils
difference.
This should fix it:
diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
--- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
+++ a/arch/i386/kernel/alternative.c
@@ -381,10 +381,7 @@ void apply_paravirt(struct paravirt_patc
extern struct paravirt_patch __start_parainstructions[],
__stop_parainstructions[];
#else
-void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
-{
-}
-extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
+#define apply_paravirt(start, end) do { } while (0)
#endif /* CONFIG_PARAVIRT */
void __init alternative_instructions(void)
_
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 16:41 ` 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-14 17:09 ` Andrew Morton
2006-11-14 19:23 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-14 17:09 UTC (permalink / raw)
To: Mariusz Kozlowski, linux-kernel, Rusty Russell
On Tue, 14 Nov 2006 08:41:30 -0800
Andrew Morton <akpm@osdl.org> wrote:
> This should fix it:
>
>
> diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
> --- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
> +++ a/arch/i386/kernel/alternative.c
> @@ -381,10 +381,7 @@ void apply_paravirt(struct paravirt_patc
> extern struct paravirt_patch __start_parainstructions[],
> __stop_parainstructions[];
> #else
> -void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
> -{
> -}
> -extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
> +#define apply_paravirt(start, end) do { } while (0)
> #endif /* CONFIG_PARAVIRT */
>
> void __init alternative_instructions(void)
hm, but that breaks x86. Maybe this..
arch/i386/kernel/alternative.c | 5 -----
include/asm-i386/alternative.h | 4 ++++
include/asm-x86_64/alternative.h | 4 ++++
3 files changed, 8 insertions(+), 5 deletions(-)
diff -puN arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for arch/i386/kernel/alternative.c
--- a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
+++ a/arch/i386/kernel/alternative.c
@@ -380,11 +380,6 @@ void apply_paravirt(struct paravirt_patc
}
extern struct paravirt_patch __start_parainstructions[],
__stop_parainstructions[];
-#else
-void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end)
-{
-}
-extern struct paravirt_patch *__start_parainstructions, *__stop_parainstructions;
#endif /* CONFIG_PARAVIRT */
void __init alternative_instructions(void)
diff -puN include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for include/asm-i386/alternative.h
--- a/include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
+++ a/include/asm-i386/alternative.h
@@ -119,6 +119,10 @@ static inline void alternatives_smp_swit
#endif
struct paravirt_patch;
+#ifdef CONFIG_PARAVIRT
void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end);
+#else
+#define apply_paravirt(start, end) do { } while (0)
+#endif
#endif /* _I386_ALTERNATIVE_H */
diff -puN include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-for include/asm-x86_64/alternative.h
--- a/include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
+++ a/include/asm-x86_64/alternative.h
@@ -134,6 +134,10 @@ static inline void alternatives_smp_swit
#endif
struct paravirt_patch;
+#ifdef CONFIG_PARAVIRT
void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch *end);
+#else
+#define apply_paravirt(start, end) do { } while (0)
+#endif
#endif /* _X86_64_ALTERNATIVE_H */
_
Unpleasant duplication there. Perhaps we should have linux/alternative.h
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 17:09 ` 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-14 19:23 ` Mariusz Kozlowski
0 siblings, 0 replies; 204+ messages in thread
From: Mariusz Kozlowski @ 2006-11-14 19:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Rusty Russell
> hm, but that breaks x86. Maybe this..
>
>
> arch/i386/kernel/alternative.c | 5 -----
> include/asm-i386/alternative.h | 4 ++++
> include/asm-x86_64/alternative.h | 4 ++++
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff -puN
> arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-for
> arch/i386/kernel/alternative.c ---
> a/arch/i386/kernel/alternative.c~fix-x86_64-mm-patch-inline-replacements-fo
>r +++ a/arch/i386/kernel/alternative.c
> @@ -380,11 +380,6 @@ void apply_paravirt(struct paravirt_patc
> }
> extern struct paravirt_patch __start_parainstructions[],
> __stop_parainstructions[];
> -#else
> -void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end) -{
> -}
> -extern struct paravirt_patch *__start_parainstructions,
> *__stop_parainstructions; #endif /* CONFIG_PARAVIRT */
>
> void __init alternative_instructions(void)
> diff -puN
> include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-for
> include/asm-i386/alternative.h ---
> a/include/asm-i386/alternative.h~fix-x86_64-mm-patch-inline-replacements-fo
>r +++ a/include/asm-i386/alternative.h
> @@ -119,6 +119,10 @@ static inline void alternatives_smp_swit
> #endif
>
> struct paravirt_patch;
> +#ifdef CONFIG_PARAVIRT
> void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end); +#else
> +#define apply_paravirt(start, end) do { } while (0)
> +#endif
>
> #endif /* _I386_ALTERNATIVE_H */
> diff -puN
> include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-fo
>r include/asm-x86_64/alternative.h ---
> a/include/asm-x86_64/alternative.h~fix-x86_64-mm-patch-inline-replacements-
>for +++ a/include/asm-x86_64/alternative.h
> @@ -134,6 +134,10 @@ static inline void alternatives_smp_swit
> #endif
>
> struct paravirt_patch;
> +#ifdef CONFIG_PARAVIRT
> void apply_paravirt(struct paravirt_patch *start, struct paravirt_patch
> *end); +#else
> +#define apply_paravirt(start, end) do { } while (0)
> +#endif
>
> #endif /* _X86_64_ALTERNATIVE_H */
> _
>
>
> Unpleasant duplication there. Perhaps we should have linux/alternative.h
Thanks. It compiled fine with this patch.
--
Regards,
Mariusz Kozlowski
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (2 preceding siblings ...)
2006-11-14 12:46 ` 2.6.19-rc5-mm2 Mariusz Kozlowski
@ 2006-11-14 13:50 ` Eric Dumazet
2006-11-14 18:33 ` Adrian Bunk
` (30 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Eric Dumazet @ 2006-11-14 13:50 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar; +Cc: linux-kernel, tglx
On Tuesday 14 November 2006 10:41, Andrew Morton wrote:
> Presently at
>
> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.
>6.19-rc5-mm2/
Hi all
I noticed a slowdown (3%) on a io micro-benchmark on my machine with
2.6.19-rc5-mm2
It appears time-uninline-jiffiesh.patch is sub-optimal at least for current
compilers (tested gcc-4.0.4 here)
May I suggest :
1) make sure jiffies_to_usecs() is defined before being used in
timespec_trunc() : Compiler will just optimize away not *needed* code.
OR :
2) Revert to inline versions of four functions jiffies_to_msecs(),
jiffies_to_usecs(), msecs_to_jiffies() and usecs_to_jiffies() .
IMHO there is litle gain to call a function just to perform so basic
arithmetics, that sometime compiler can perform at compilation time.
OR
3) replace
(jiffies_to_usecs(1) * 1000)
by
(NSEC_PER_SEC / HZ)
With current patch, timespec_trunc() is not anymore a tail function.
struct timespec timespec_trunc(struct timespec t, unsigned gran)
{
if (gran <= jiffies_to_usecs(1) * 1000) {
Much better here to have :
if (gran < SOME_CONSTANT)
Thank you
Eric
^ permalink raw reply [flat|nested] 204+ messages in thread* [Cluster-devel] [-mm patch] fix the DLM dependencies.
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-14 18:33 ` Adrian Bunk
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
` (33 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 18:33 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> - A nasty Kconfig warning comes out during the build. It's due to
> git-gfs2-nmw.patch.
>...
So let's fix it. ;-)
cu
Adrian
<-- snip -->
Kconfig said:
Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET
Due to the "depends on IPV6 || IPV6=n" it's not really a circular
dependency, but there's another bug that anyway should be fixed:
The "select IP_SCTP" ignored the dependency of IP_SCTP on INET.
Considering that:
- there's no way to use DLM with INET=n and
- INET=n being a mostly pathological case
this patch fixes both this bug and the "recursive dependency" warning by
letting DLM depend on INET again.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 18:41:35.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 18:44:12.000000000 +0100
@@ -1,5 +1,5 @@
menu "Distributed Lock Manager"
- depends on EXPERIMENTAL
+ depends on EXPERIMENTAL && INET
config DLM
tristate "Distributed Lock Manager (DLM)"
@@ -20,7 +20,6 @@ choice
config DLM_TCP
bool "TCP/IP"
- select INET
config DLM_SCTP
bool "SCTP"
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] fix the DLM dependencies.
@ 2006-11-14 18:33 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 18:33 UTC (permalink / raw)
To: Andrew Morton, Steven Whitehouse, pcaulfie, teigland
Cc: linux-kernel, cluster-devel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> - A nasty Kconfig warning comes out during the build. It's due to
> git-gfs2-nmw.patch.
>...
So let's fix it. ;-)
cu
Adrian
<-- snip -->
Kconfig said:
Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET
Due to the "depends on IPV6 || IPV6=n" it's not really a circular
dependency, but there's another bug that anyway should be fixed:
The "select IP_SCTP" ignored the dependency of IP_SCTP on INET.
Considering that:
- there's no way to use DLM with INET=n and
- INET=n being a mostly pathological case
this patch fixes both this bug and the "recursive dependency" warning by
letting DLM depend on INET again.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 18:41:35.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 18:44:12.000000000 +0100
@@ -1,5 +1,5 @@
menu "Distributed Lock Manager"
- depends on EXPERIMENTAL
+ depends on EXPERIMENTAL && INET
config DLM
tristate "Distributed Lock Manager (DLM)"
@@ -20,7 +20,6 @@ choice
config DLM_TCP
bool "TCP/IP"
- select INET
config DLM_SCTP
bool "SCTP"
^ permalink raw reply [flat|nested] 204+ messages in thread
* [Cluster-devel] [-mm patch] fix the DLM dependencies, part 2
2006-11-14 18:33 ` Adrian Bunk
@ 2006-11-14 22:56 ` Adrian Bunk
-1 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 22:56 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > - A nasty Kconfig warning comes out during the build. It's due to
> > git-gfs2-nmw.patch.
> >...
>
> So let's fix it. ;-)
>...
And let's also fix another bug...
<-- snip -->
IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
@@ -5,6 +5,7 @@ config DLM
tristate "Distributed Lock Manager (DLM)"
depends on IPV6 || IPV6=n
select CONFIGFS_FS
+ select IP_SCTP if DLM_SCTP
help
A general purpose distributed lock manager for kernel or userspace
applications.
@@ -23,7 +24,6 @@ config DLM_TCP
config DLM_SCTP
bool "SCTP"
- select IP_SCTP
endchoice
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] fix the DLM dependencies, part 2
@ 2006-11-14 22:56 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 22:56 UTC (permalink / raw)
To: Andrew Morton, Steven Whitehouse, pcaulfie, teigland
Cc: linux-kernel, cluster-devel
On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > - A nasty Kconfig warning comes out during the build. It's due to
> > git-gfs2-nmw.patch.
> >...
>
> So let's fix it. ;-)
>...
And let's also fix another bug...
<-- snip -->
IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
@@ -5,6 +5,7 @@ config DLM
tristate "Distributed Lock Manager (DLM)"
depends on IPV6 || IPV6=n
select CONFIGFS_FS
+ select IP_SCTP if DLM_SCTP
help
A general purpose distributed lock manager for kernel or userspace
applications.
@@ -23,7 +24,6 @@ config DLM_TCP
config DLM_SCTP
bool "SCTP"
- select IP_SCTP
endchoice
^ permalink raw reply [flat|nested] 204+ messages in thread
* [Cluster-devel] Re: [-mm patch] fix the DLM dependencies, part 2
2006-11-14 22:56 ` Adrian Bunk
@ 2006-11-15 10:11 ` Patrick Caulfield
-1 siblings, 0 replies; 204+ messages in thread
From: Patrick Caulfield @ 2006-11-15 10:11 UTC (permalink / raw)
To: cluster-devel.redhat.com
Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
>> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>>> ...
>>> - A nasty Kconfig warning comes out during the build. It's due to
>>> git-gfs2-nmw.patch.
>>> ...
>> So let's fix it. ;-)
>> ...
>
> And let's also fix another bug...
>
>
> <-- snip -->
>
>
> IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> @@ -5,6 +5,7 @@ config DLM
> tristate "Distributed Lock Manager (DLM)"
> depends on IPV6 || IPV6=n
> select CONFIGFS_FS
> + select IP_SCTP if DLM_SCTP
> help
> A general purpose distributed lock manager for kernel or userspace
> applications.
> @@ -23,7 +24,6 @@ config DLM_TCP
>
> config DLM_SCTP
> bool "SCTP"
> - select IP_SCTP
>
> endchoice
Thanks Adrian. I need to read the kconfig docs a little more closely :)
Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.
--
patrick
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] fix the DLM dependencies, part 2
@ 2006-11-15 10:11 ` Patrick Caulfield
0 siblings, 0 replies; 204+ messages in thread
From: Patrick Caulfield @ 2006-11-15 10:11 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Steven Whitehouse, teigland, linux-kernel,
cluster-devel
Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
>> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>>> ...
>>> - A nasty Kconfig warning comes out during the build. It's due to
>>> git-gfs2-nmw.patch.
>>> ...
>> So let's fix it. ;-)
>> ...
>
> And let's also fix another bug...
>
>
> <-- snip -->
>
>
> IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> @@ -5,6 +5,7 @@ config DLM
> tristate "Distributed Lock Manager (DLM)"
> depends on IPV6 || IPV6=n
> select CONFIGFS_FS
> + select IP_SCTP if DLM_SCTP
> help
> A general purpose distributed lock manager for kernel or userspace
> applications.
> @@ -23,7 +24,6 @@ config DLM_TCP
>
> config DLM_SCTP
> bool "SCTP"
> - select IP_SCTP
>
> endchoice
Thanks Adrian. I need to read the kconfig docs a little more closely :)
Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.
--
patrick
^ permalink raw reply [flat|nested] 204+ messages in thread
* [Cluster-devel] Re: [-mm patch] fix the DLM dependencies, part 2
2006-11-15 10:11 ` Patrick Caulfield
@ 2006-11-15 10:23 ` Adrian Bunk
-1 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-15 10:23 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Wed, Nov 15, 2006 at 10:11:35AM +0000, Patrick Caulfield wrote:
> Adrian Bunk wrote:
> > On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> >> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >>> ...
> >>> - A nasty Kconfig warning comes out during the build. It's due to
> >>> git-gfs2-nmw.patch.
> >>> ...
> >> So let's fix it. ;-)
> >> ...
> >
> > And let's also fix another bug...
> >
> >
> > <-- snip -->
> >
> >
> > IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> > --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> > +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> > @@ -5,6 +5,7 @@ config DLM
> > tristate "Distributed Lock Manager (DLM)"
> > depends on IPV6 || IPV6=n
> > select CONFIGFS_FS
> > + select IP_SCTP if DLM_SCTP
> > help
> > A general purpose distributed lock manager for kernel or userspace
> > applications.
> > @@ -23,7 +24,6 @@ config DLM_TCP
> >
> > config DLM_SCTP
> > bool "SCTP"
> > - select IP_SCTP
> >
> > endchoice
>
> Thanks Adrian. I need to read the kconfig docs a little more closely :)
>
> Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
> copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.
As long as you select IP_SCTP, the "depends on IPV6 || IPV6=n" can't go:
Otherwise, the illegal configuration DLM=y, IP_SCTP=y, IPV6=m would
become possible.
> patrick
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] 204+ messages in thread* Re: [-mm patch] fix the DLM dependencies, part 2
@ 2006-11-15 10:23 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-15 10:23 UTC (permalink / raw)
To: Patrick Caulfield
Cc: Andrew Morton, Steven Whitehouse, teigland, linux-kernel,
cluster-devel
On Wed, Nov 15, 2006 at 10:11:35AM +0000, Patrick Caulfield wrote:
> Adrian Bunk wrote:
> > On Tue, Nov 14, 2006 at 07:33:24PM +0100, Adrian Bunk wrote:
> >> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >>> ...
> >>> - A nasty Kconfig warning comes out during the build. It's due to
> >>> git-gfs2-nmw.patch.
> >>> ...
> >> So let's fix it. ;-)
> >> ...
> >
> > And let's also fix another bug...
> >
> >
> > <-- snip -->
> >
> >
> > IPV6=m, DLM=m, DLM_SCTP=y mustn't result in IP_SCTP=y.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> > --- linux-2.6.19-rc5-mm2/fs/dlm/Kconfig.old 2006-11-14 22:25:01.000000000 +0100
> > +++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig 2006-11-14 22:25:19.000000000 +0100
> > @@ -5,6 +5,7 @@ config DLM
> > tristate "Distributed Lock Manager (DLM)"
> > depends on IPV6 || IPV6=n
> > select CONFIGFS_FS
> > + select IP_SCTP if DLM_SCTP
> > help
> > A general purpose distributed lock manager for kernel or userspace
> > applications.
> > @@ -23,7 +24,6 @@ config DLM_TCP
> >
> > config DLM_SCTP
> > bool "SCTP"
> > - select IP_SCTP
> >
> > endchoice
>
> Thanks Adrian. I need to read the kconfig docs a little more closely :)
>
> Incidentally, I think the 'depends on IPV6 || IPV6=n' can go too; it's in a patch I sent to Steve and it's basically just a line
> copied from SCTP which is obsoleted by these other changes and the addition of the TCP transport.
As long as you select IP_SCTP, the "depends on IPV6 || IPV6=n" can't go:
Otherwise, the illegal configuration DLM=y, IP_SCTP=y, IPV6=m would
become possible.
> patrick
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] 204+ messages in thread
* Boot failure with ext2 and initrds
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (4 preceding siblings ...)
2006-11-14 18:33 ` Adrian Bunk
@ 2006-11-14 18:49 ` Mel Gorman
2006-11-14 19:08 ` Martin Bligh
2006-11-14 19:11 ` Hugh Dickins
2006-11-14 20:02 ` 2.6.19-rc5-mm2: no help text for FAULT_INJECTION Adrian Bunk
` (28 subsequent siblings)
34 siblings, 2 replies; 204+ messages in thread
From: Mel Gorman @ 2006-11-14 18:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On (14/11/06 01:41), Andrew Morton didst pronounce:
>
> Presently at
>
> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>
Am seeing errors with systems using ext2. First machine is a plan old x86
using initramfs. Console output looks like;
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Starting udev
Creating devices
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
Second machine is a numaq with an ext2 root filesystem
hecking root file system...
fsck 1.37 (21-Mar-2005)
e2fsck 1.37 (21-Mar-2005)
/dev/sda1: clean, 310908/2240224 files, 2189096/4480119 blocks (check in
3 mounts)
System time was Tue Nov 14 17:06:21 UTC 2006.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Tue Nov 14 17:06:23 UTC 2006.
Cleaning up ifupdown...done.
Calculating module dependencies... done.
Loading modules...
All modules loaded.
Creating device-mapper devices...done.
Checking all file systems...
fsck 1.37 (21-Mar-2005)
Setting kernel variables ...
... done.
Mounting local filesystems...
Unable to find swap-space signature
Cleaning /tmp /var/run /var/lock.
Running 0dns-down to make sure resolv.conf is ok...done.
Setting up networking...done.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces...BUG: soft lockup detected on CPU#3!
[<c0139233>] softlockup_tick+0x9e/0xac
[<c0124a16>] update_process_times+0x4b/0x77
[<c0132438>] handle_update_profile+0x1c/0x2a
[<c010d45a>] local_apic_timer_interrupt+0x43/0x48
[<c010d486>] smp_apic_timer_interrupt+0x27/0x36
[<c0103598>] apic_timer_interrupt+0x28/0x30
[<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
[<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
[<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
[<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
[<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
[<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
[<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
[<c0181c89>] alloc_buffer_head+0x38/0x3e
[<c017f2ef>] alloc_page_buffers+0x6f/0xb2
[<c01b6cb9>] ext2_get_block+0x3d/0x51
[<c0180162>] __block_prepare_write+0x186/0x41b
[<c0180c3c>] block_prepare_write+0x31/0x3f
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c013d470>] generic_file_buffered_write+0x227/0x62a
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c0173936>] file_update_time+0x3e/0xbc
[<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
[<c013b957>] find_get_page+0x22/0x43
[<c013e1d2>] generic_file_aio_write+0x69/0xd1
[<c01616a9>] do_sync_write+0xda/0x117
[<c012e45d>] autoremove_wake_function+0x0/0x4b
[<c011201c>] do_page_fault+0x394/0x6c8
[<c0161787>] vfs_write+0xa1/0x167
[<c0161909>] sys_write+0x4b/0x71
[<c0102b40>] syscall_call+0x7/0xb
[<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
=======================
BUG: soft lockup detected on CPU#3!
[<c0139233>] softlockup_tick+0x9e/0xac
[<c0124a16>] update_process_times+0x4b/0x77
[<c0132438>] handle_update_profile+0x1c/0x2a
[<c010d45a>] local_apic_timer_interrupt+0x43/0x48
[<c010d486>] smp_apic_timer_interrupt+0x27/0x36
[<c0103598>] apic_timer_interrupt+0x28/0x30
[<c01b3b79>] ext2_try_to_allocate+0xd4/0x152
[<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
[<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
[<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
[<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
[<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
[<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
[<c0181c89>] alloc_buffer_head+0x38/0x3e
[<c017f2ef>] alloc_page_buffers+0x6f/0xb2
[<c01b6cb9>] ext2_get_block+0x3d/0x51
[<c0180162>] __block_prepare_write+0x186/0x41b
[<c0180c3c>] block_prepare_write+0x31/0x3f
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c013d470>] generic_file_buffered_write+0x227/0x62a
[<c01b6c7c>] ext2_get_block+0x0/0x51
[<c0173936>] file_update_time+0x3e/0xbc
[<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
[<c013b957>] find_get_page+0x22/0x43
[<c013e1d2>] generic_file_aio_write+0x69/0xd1
[<c01616a9>] do_sync_write+0xda/0x117
[<c012e45d>] autoremove_wake_function+0x0/0x4b
[<c011201c>] do_page_fault+0x394/0x6c8
[<c0161787>] vfs_write+0xa1/0x167
[<c0161909>] sys_write+0x4b/0x71
[<c0102b40>] syscall_call+0x7/0xb
[<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
(message repeats a lot)
I've not investigated yet what patches might be at fault.
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-14 18:49 ` Boot failure with ext2 and initrds Mel Gorman
@ 2006-11-14 19:08 ` Martin Bligh
2006-11-14 19:11 ` Hugh Dickins
1 sibling, 0 replies; 204+ messages in thread
From: Martin Bligh @ 2006-11-14 19:08 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, val_henson, cmm
Mel Gorman wrote:
> On (14/11/06 01:41), Andrew Morton didst pronounce:
>> Presently at
>>
>> http://userweb.kernel.org/~akpm/2.6.19-rc5-mm2/
>>
>> and will appear later at
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>>
>
> Am seeing errors with systems using ext2. First machine is a plan old x86
> using initramfs. Console output looks like;
Probably from the ext2 reservations stuff. Any chance you could back out:
ext2-reservations.patch
ext2-reservations-fix.patch
ext2-reservations-sequential-read-regression-fix.patch
ext2-reservations-filesystem-bogus-ENOSPC-with-reservation-fix.patch
ext2-reservations-ext3_clear_inode-avoid-kfree-null.patch
ext2-reservations-multile-block-allocate-little-endian-fixes.patch
ext2-reservations-mark-group-descriptors-dirty-during-allocation.patch
ext2-reservations-nuke-noisy-printk.patch
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
and see if it goes away?
Else I shall pray that Val or Mingming is smarter than I am and can
see what went wrong ;-)
Thanks,
M.
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> Starting udev
> Creating devices
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
> EXT2-fs error (device ram0): ext2_new_blocks: Allocating block in system zone - blocks from 0, length 0
> EXT2-fs error (device ram0): ext2_new_blocks: block(0) >= blocks count(5164) - block_group = 0, es == dff00400
>
> Second machine is a numaq with an ext2 root filesystem
>
> hecking root file system...
> fsck 1.37 (21-Mar-2005)
> e2fsck 1.37 (21-Mar-2005)
> /dev/sda1: clean, 310908/2240224 files, 2189096/4480119 blocks (check in
> 3 mounts)
> System time was Tue Nov 14 17:06:21 UTC 2006.
> Setting the System Clock using the Hardware Clock as reference...
> System Clock set. System local time is now Tue Nov 14 17:06:23 UTC 2006.
> Cleaning up ifupdown...done.
> Calculating module dependencies... done.
> Loading modules...
> All modules loaded.
> Creating device-mapper devices...done.
> Checking all file systems...
> fsck 1.37 (21-Mar-2005)
> Setting kernel variables ...
> ... done.
> Mounting local filesystems...
> Unable to find swap-space signature
> Cleaning /tmp /var/run /var/lock.
> Running 0dns-down to make sure resolv.conf is ok...done.
> Setting up networking...done.
> Setting up IP spoofing protection: rp_filter.
> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> [<c0139233>] softlockup_tick+0x9e/0xac
> [<c0124a16>] update_process_times+0x4b/0x77
> [<c0132438>] handle_update_profile+0x1c/0x2a
> [<c010d45a>] local_apic_timer_interrupt+0x43/0x48
> [<c010d486>] smp_apic_timer_interrupt+0x27/0x36
> [<c0103598>] apic_timer_interrupt+0x28/0x30
> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> [<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
> [<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
> [<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
> [<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
> [<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
> [<c0181c89>] alloc_buffer_head+0x38/0x3e
> [<c017f2ef>] alloc_page_buffers+0x6f/0xb2
> [<c01b6cb9>] ext2_get_block+0x3d/0x51
> [<c0180162>] __block_prepare_write+0x186/0x41b
> [<c0180c3c>] block_prepare_write+0x31/0x3f
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c013d470>] generic_file_buffered_write+0x227/0x62a
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c0173936>] file_update_time+0x3e/0xbc
> [<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
> [<c013b957>] find_get_page+0x22/0x43
> [<c013e1d2>] generic_file_aio_write+0x69/0xd1
> [<c01616a9>] do_sync_write+0xda/0x117
> [<c012e45d>] autoremove_wake_function+0x0/0x4b
> [<c011201c>] do_page_fault+0x394/0x6c8
> [<c0161787>] vfs_write+0xa1/0x167
> [<c0161909>] sys_write+0x4b/0x71
> [<c0102b40>] syscall_call+0x7/0xb
> [<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
> =======================
> BUG: soft lockup detected on CPU#3!
> [<c0139233>] softlockup_tick+0x9e/0xac
> [<c0124a16>] update_process_times+0x4b/0x77
> [<c0132438>] handle_update_profile+0x1c/0x2a
> [<c010d45a>] local_apic_timer_interrupt+0x43/0x48
> [<c010d486>] smp_apic_timer_interrupt+0x27/0x36
> [<c0103598>] apic_timer_interrupt+0x28/0x30
> [<c01b3b79>] ext2_try_to_allocate+0xd4/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> [<c01b42c6>] ext2_new_blocks+0x28d/0x4b3
> [<c01b667a>] ext2_alloc_blocks+0x4b/0xcd
> [<c01b674a>] ext2_alloc_branch+0x4e/0x1ae
> [<c01b36a8>] ext2_init_block_alloc_info+0x26/0x6d
> [<c01b6b9b>] ext2_get_blocks+0x23c/0x31d
> [<c0181c89>] alloc_buffer_head+0x38/0x3e
> [<c017f2ef>] alloc_page_buffers+0x6f/0xb2
> [<c01b6cb9>] ext2_get_block+0x3d/0x51
> [<c0180162>] __block_prepare_write+0x186/0x41b
> [<c0180c3c>] block_prepare_write+0x31/0x3f
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c013d470>] generic_file_buffered_write+0x227/0x62a
> [<c01b6c7c>] ext2_get_block+0x0/0x51
> [<c0173936>] file_update_time+0x3e/0xbc
> [<c013e08e>] __generic_file_aio_write_nolock+0x538/0x563
> [<c013b957>] find_get_page+0x22/0x43
> [<c013e1d2>] generic_file_aio_write+0x69/0xd1
> [<c01616a9>] do_sync_write+0xda/0x117
> [<c012e45d>] autoremove_wake_function+0x0/0x4b
> [<c011201c>] do_page_fault+0x394/0x6c8
> [<c0161787>] vfs_write+0xa1/0x167
> [<c0161909>] sys_write+0x4b/0x71
> [<c0102b40>] syscall_call+0x7/0xb
> [<c0330033>] __mutex_lock_interruptible_slowpath+0x7f/0x94
> (message repeats a lot)
>
> I've not investigated yet what patches might be at fault.
> -
> 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] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 18:49 ` Boot failure with ext2 and initrds Mel Gorman
2006-11-14 19:08 ` Martin Bligh
@ 2006-11-14 19:11 ` Hugh Dickins
2006-11-14 19:21 ` Martin Bligh
2006-11-14 19:31 ` Andrew Morton
1 sibling, 2 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-14 19:11 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel
On Tue, 14 Nov 2006, Mel Gorman wrote:
> 2.6.19-rc5-mm2
>
> Am seeing errors with systems using ext2. First machine is a plan old x86
> using initramfs. Console output looks like;
> ...
> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> ...
> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>
> I've not investigated yet what patches might be at fault.
I expect you'll find it's
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
which gets stuck in a loop there for me too: back it out and all seems fine.
It's not obvious which part of the patch is to blame: mostly it's
cleanup, but a few variables do change size: I'm currently narrowing
down to where a fix is needed.
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:11 ` Hugh Dickins
@ 2006-11-14 19:21 ` Martin Bligh
2006-11-14 20:20 ` Hugh Dickins
2006-11-14 19:31 ` Andrew Morton
1 sibling, 1 reply; 204+ messages in thread
From: Martin Bligh @ 2006-11-14 19:21 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Mel Gorman, Andrew Morton, linux-kernel
Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Mel Gorman wrote:
>> 2.6.19-rc5-mm2
>>
>> Am seeing errors with systems using ext2. First machine is a plan old x86
>> using initramfs. Console output looks like;
>> ...
>> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
>> ...
>> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
>> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>>
>> I've not investigated yet what patches might be at fault.
>
> I expect you'll find it's
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> which gets stuck in a loop there for me too: back it out and all seems fine.
>
> It's not obvious which part of the patch is to blame: mostly it's
> cleanup, but a few variables do change size: I'm currently narrowing
> down to where a fix is needed.
Humpf. that was meant to be one of those "so obvious I can't screw it
up" patches.
typedef unsigned long ext2_fsblk_t;
typedef int ext2_grpblk_t;
in ext2_alloc_blocks we do change from "unsigned long long" to
"unsigned long" for new_blocks[], but akpm thinks that was garbage
before (same for ext2_alloc_branch's current_block)
The ext2_grpblk_t ones all look innocuous.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:21 ` Martin Bligh
@ 2006-11-14 20:20 ` Hugh Dickins
2006-11-14 20:30 ` Martin Bligh
0 siblings, 1 reply; 204+ messages in thread
From: Hugh Dickins @ 2006-11-14 20:20 UTC (permalink / raw)
To: Martin Bligh; +Cc: Mel Gorman, Andrew Morton, linux-kernel
On Tue, 14 Nov 2006, Martin Bligh wrote:
> Hugh Dickins wrote:
> > I expect you'll find it's
> > ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> > which gets stuck in a loop there for me too: back it out and all seems fine.
> >
> > It's not obvious which part of the patch is to blame: mostly it's
> > cleanup, but a few variables do change size: I'm currently narrowing
> > down to where a fix is needed.
>
> Humpf. that was meant to be one of those "so obvious I can't screw it
> up" patches.
Never underestimate yourself, Martin ;)
>
> typedef unsigned long ext2_fsblk_t;
> typedef int ext2_grpblk_t;
>
> in ext2_alloc_blocks we do change from "unsigned long long" to
> "unsigned long" for new_blocks[], but akpm thinks that was garbage
> before (same for ext2_alloc_branch's current_block)
Yes, I agree, those particular changes looked just fine,
and indeed they're not to blame.
>
> The ext2_grpblk_t ones all look innocuous.
Yes, those all looked like no-ops. The guilty party is ext2_new_blocks:
i386, x86_64 and ppc64 are now happily building on ext2s with this patch
below (I've been lazy, could have deleted your "E2FSBLK" addition too).
But I haven't attempted to correlate it with the loops seen (with OOMs
too on the x86_64, no idea why, but they've likewise melted away with
this patch). And I'm dubious whether it's the _right_ fix: the whole
mess of ints, unsigned longs and __u32s looks tricky to me, not some-
thing to sort out in a hurry - I'm only working with small filesystems
here (looped on a tmpfs file). (And if ret_block really should be an
ext2_fsblk_t there, shouldn't ext2_new_blocks return an ext2_fsblk_t
rather than an int?)
I see Andrew's sent me an alternative patch to try, I'll give that
a whirl now; and see if just making ext2_new_blocks return an
ext2_fsblk_t would do it too.
Hugh
--- 2.6.19-rc5-mm2/fs/ext2/balloc.c 2006-11-14 12:10:07.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-14 19:34:06.000000000 +0000
@@ -1155,7 +1155,7 @@ int ext2_new_blocks(struct inode *inode,
struct buffer_head *gdp_bh;
int group_no;
int goal_group;
- ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
+ int ret_block; /* filesystem-wide allocated block */
int bgi; /* blockgroup iteration index */
int target_block;
int performed_allocation = 0;
@@ -1320,7 +1320,7 @@ allocated:
if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
ext2_error(sb, "ext2_new_blocks",
- "block("E2FSBLK") >= blocks count(%d) - "
+ "block(%d) >= blocks count(%d) - "
"block_group = %d, es == %p ", ret_block,
le32_to_cpu(es->s_blocks_count), group_no, es);
goto out;
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-14 20:20 ` Hugh Dickins
@ 2006-11-14 20:30 ` Martin Bligh
0 siblings, 0 replies; 204+ messages in thread
From: Martin Bligh @ 2006-11-14 20:30 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Mel Gorman, Andrew Morton, linux-kernel
> Never underestimate yourself, Martin ;)
Thanks ;-)
> Yes, those all looked like no-ops. The guilty party is ext2_new_blocks:
> i386, x86_64 and ppc64 are now happily building on ext2s with this patch
> below (I've been lazy, could have deleted your "E2FSBLK" addition too).
Yup, we started throwing away the error return code ;-(
> But I haven't attempted to correlate it with the loops seen (with OOMs
> too on the x86_64, no idea why, but they've likewise melted away with
> this patch). And I'm dubious whether it's the _right_ fix: the whole
> mess of ints, unsigned longs and __u32s looks tricky to me, not some-
> thing to sort out in a hurry - I'm only working with small filesystems
> here (looped on a tmpfs file). (And if ret_block really should be an
> ext2_fsblk_t there, shouldn't ext2_new_blocks return an ext2_fsblk_t
> rather than an int?)
I was trying to harmonize it with what ext3 code does, but as Andrew
understands this code a thousand times better than I, hopefully it's
all fixed properly ;-)
> I see Andrew's sent me an alternative patch to try, I'll give that
> a whirl now; and see if just making ext2_new_blocks return an
> ext2_fsblk_t would do it too.
M.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:11 ` Hugh Dickins
2006-11-14 19:21 ` Martin Bligh
@ 2006-11-14 19:31 ` Andrew Morton
2006-11-14 21:18 ` Hugh Dickins
` (3 more replies)
1 sibling, 4 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-14 19:31 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Mel Gorman, Martin J. Bligh, linux-kernel
On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
Hugh Dickins <hugh@veritas.com> wrote:
> On Tue, 14 Nov 2006, Mel Gorman wrote:
> > 2.6.19-rc5-mm2
> >
> > Am seeing errors with systems using ext2. First machine is a plan old x86
> > using initramfs. Console output looks like;
> > ...
> > Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> > ...
> > [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> > [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> >
> > I've not investigated yet what patches might be at fault.
>
> I expect you'll find it's
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> which gets stuck in a loop there for me too: back it out and all seems fine.
>
> It's not obvious which part of the patch is to blame: mostly it's
> cleanup, but a few variables do change size: I'm currently narrowing
> down to where a fix is needed.
>
Doing s/-Wall/-W/ tends to shake out bugs in this stuff.
The below might help.
Sorry, I tested this well, then the cleanup patch was merged and I didn't
get onto retesting :(
From: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
fs/ext2/balloc.c | 33 +++++++++++++++------------------
1 files changed, 15 insertions(+), 18 deletions(-)
diff -puN fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix fs/ext2/balloc.c
--- a/fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
+++ a/fs/ext2/balloc.c
@@ -1155,9 +1155,10 @@ int ext2_new_blocks(struct inode *inode,
struct buffer_head *gdp_bh;
int group_no;
int goal_group;
+ ext2_grpblk_t grp_target_blk; /* blockgroup relative goal block */
+ ext2_grpblk_t grp_alloc_blk; /* blockgroup-relative allocated block*/
ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
int bgi; /* blockgroup iteration index */
- int target_block;
int performed_allocation = 0;
ext2_grpblk_t free_blocks; /* number of free blocks in a group */
struct super_block *sb;
@@ -1230,14 +1231,15 @@ retry_alloc:
my_rsv = NULL;
if (free_blocks > 0) {
- ret_block = ((goal - le32_to_cpu(es->s_first_data_block)) %
+ grp_target_blk = ((goal - le32_to_cpu(es->s_first_data_block)) %
EXT2_BLOCKS_PER_GROUP(sb));
bitmap_bh = read_block_bitmap(sb, group_no);
if (!bitmap_bh)
goto io_error;
- ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
- bitmap_bh, ret_block, my_rsv, &num);
- if (ret_block >= 0)
+ grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
+ bitmap_bh, grp_target_blk,
+ my_rsv, &num);
+ if (grp_alloc_blk >= 0)
goto allocated;
}
@@ -1273,9 +1275,9 @@ retry_alloc:
/*
* try to allocate block(s) from this group, without a goal(-1).
*/
- ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
+ grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
bitmap_bh, -1, my_rsv, &num);
- if (ret_block >= 0)
+ if (grp_alloc_blk >= 0)
goto allocated;
}
/*
@@ -1299,25 +1301,20 @@ allocated:
ext2_debug("using block group %d(%d)\n",
group_no, gdp->bg_free_blocks_count);
- target_block = ret_block + group_no * EXT2_BLOCKS_PER_GROUP(sb)
- + le32_to_cpu(es->s_first_data_block);
+ ret_block = grp_alloc_blk + ext2_group_first_block_no(sb, group_no);
- if (in_range(le32_to_cpu(gdp->bg_block_bitmap), target_block, num) ||
- in_range(le32_to_cpu(gdp->bg_inode_bitmap), target_block, num) ||
- in_range(target_block, le32_to_cpu(gdp->bg_inode_table),
+ if (in_range(le32_to_cpu(gdp->bg_block_bitmap), ret_block, num) ||
+ in_range(le32_to_cpu(gdp->bg_inode_bitmap), ret_block, num) ||
+ in_range(ret_block, le32_to_cpu(gdp->bg_inode_table),
EXT2_SB(sb)->s_itb_per_group) ||
- in_range(target_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
+ in_range(ret_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
EXT2_SB(sb)->s_itb_per_group))
ext2_error(sb, "ext2_new_blocks",
"Allocating block in system zone - "
- "blocks from %u, length %lu", target_block, num);
+ "blocks from %u, length %lu", ret_block, num);
performed_allocation = 1;
-
- /* ret_block was blockgroup-relative. Now it becomes fs-relative */
- ret_block = target_block;
-
if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
ext2_error(sb, "ext2_new_blocks",
"block("E2FSBLK") >= blocks count(%d) - "
_
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-14 19:31 ` Andrew Morton
@ 2006-11-14 21:18 ` Hugh Dickins
2006-11-14 21:19 ` Martin Bligh
2006-11-15 14:17 ` Hugh Dickins
2006-11-14 21:19 ` Mel Gorman
` (2 subsequent siblings)
3 siblings, 2 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-14 21:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mel Gorman, Martin J. Bligh, linux-kernel
On Tue, 14 Nov 2006, Andrew Morton wrote:
>
> The below might help.
Indeed it does (with Martin's E2FSBLK warning fix),
seems to be running well on all machines now.
(Of course, my ext2_fsblk_t ext2_new_blocks() notion did not pan out,
for same reason as the original: that ret_block was expected signed.)
Thanks,
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-14 21:18 ` Hugh Dickins
@ 2006-11-14 21:19 ` Martin Bligh
2006-11-15 14:17 ` Hugh Dickins
1 sibling, 0 replies; 204+ messages in thread
From: Martin Bligh @ 2006-11-14 21:19 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andrew Morton, Mel Gorman, linux-kernel
Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Andrew Morton wrote:
>> The below might help.
>
> Indeed it does (with Martin's E2FSBLK warning fix),
> seems to be running well on all machines now.
>
> (Of course, my ext2_fsblk_t ext2_new_blocks() notion did not pan out,
> for same reason as the original: that ret_block was expected signed.)
Whilst I've got all the smart people looking at this ...
/*max window size: 1024(direct blocks) + 3([t,d]indirect blocks) */
#define EXT2_MAX_RESERVE_BLOCKS 1027
Is that wrong? If it's meaning one triple, one double, and one single
indirect block, surely it can span a boundary, so we need (potentially)
two of each?
M.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 21:18 ` Hugh Dickins
2006-11-14 21:19 ` Martin Bligh
@ 2006-11-15 14:17 ` Hugh Dickins
2006-11-15 15:32 ` Martin J. Bligh
2006-11-16 5:45 ` Andrew Morton
1 sibling, 2 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-15 14:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mel Gorman, Martin J. Bligh, linux-kernel
On Tue, 14 Nov 2006, Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Andrew Morton wrote:
> >
> > The below might help.
>
> Indeed it does (with Martin's E2FSBLK warning fix),
> seems to be running well on all machines now.
i386 and ppc64 still doing builds, but after an hour on x86_64,
an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
alternating between ext2_rsv_window_add and rsv_window_remove.
Send me a patch and I'll try it...
ext2_try_to_allocate_with_rsv+0x288
ext2_new_blocks+0x21e
ext2_get_blocks+0x398
ext2_get_block+0x46
__block_prepare_write+0x171
block_prepare_write+0x39
ext2_prepare_write+0x2c
generic_file_buffered_write+0x2b0
__generic_file_aio_write_nolock+0x4bc
generic_file_aio_write+0x6d
do_sync_write+0xf9
vfs_write+0xc8
sys_write+0x51
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-15 14:17 ` Hugh Dickins
@ 2006-11-15 15:32 ` Martin J. Bligh
2006-11-15 15:56 ` Hugh Dickins
2006-11-16 5:45 ` Andrew Morton
1 sibling, 1 reply; 204+ messages in thread
From: Martin J. Bligh @ 2006-11-15 15:32 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Andrew Morton, Mel Gorman, linux-kernel
Hugh Dickins wrote:
> On Tue, 14 Nov 2006, Hugh Dickins wrote:
>> On Tue, 14 Nov 2006, Andrew Morton wrote:
>>> The below might help.
>> Indeed it does (with Martin's E2FSBLK warning fix),
>> seems to be running well on all machines now.
>
> i386 and ppc64 still doing builds, but after an hour on x86_64,
> an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> alternating between ext2_rsv_window_add and rsv_window_remove.
Ugh. What test are you doing? kernel compile in a tight loop forever?
Andrew, do you want to drop the set for now, and we can try and
debug it outside of -mm? No reason to break your tree if we don't
have to ...
> Send me a patch and I'll try it...
>
> ext2_try_to_allocate_with_rsv+0x288
> ext2_new_blocks+0x21e
> ext2_get_blocks+0x398
> ext2_get_block+0x46
> __block_prepare_write+0x171
> block_prepare_write+0x39
> ext2_prepare_write+0x2c
> generic_file_buffered_write+0x2b0
> __generic_file_aio_write_nolock+0x4bc
> generic_file_aio_write+0x6d
> do_sync_write+0xf9
> vfs_write+0xc8
> sys_write+0x51
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-15 15:32 ` Martin J. Bligh
@ 2006-11-15 15:56 ` Hugh Dickins
0 siblings, 0 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-15 15:56 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, Mel Gorman, linux-kernel
On Wed, 15 Nov 2006, Martin J. Bligh wrote:
> Hugh Dickins wrote:
> >
> > i386 and ppc64 still doing builds, but after an hour on x86_64,
> > an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> > alternating between ext2_rsv_window_add and rsv_window_remove.
>
> Ugh. What test are you doing? kernel compile in a tight loop forever?
That kind of thing, yes: my usual test, two repeated make -j20s of
a smallish kernel in 512MB RAM + 1or2GB swap, one in a tmpfs and
one in an ext2 backed by a looped tmpfs file. (When things go
badly wrong, little harm befalls the hard disk.)
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-15 14:17 ` Hugh Dickins
2006-11-15 15:32 ` Martin J. Bligh
@ 2006-11-16 5:45 ` Andrew Morton
2006-11-16 6:39 ` Andrew Morton
2006-11-16 6:55 ` Mingming Cao
1 sibling, 2 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 5:45 UTC (permalink / raw)
To: Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org, Mingming Cao
On Wed, 15 Nov 2006 14:17:01 +0000 (GMT)
Hugh Dickins <hugh@veritas.com> wrote:
> On Tue, 14 Nov 2006, Hugh Dickins wrote:
> > On Tue, 14 Nov 2006, Andrew Morton wrote:
> > >
> > > The below might help.
> >
> > Indeed it does (with Martin's E2FSBLK warning fix),
> > seems to be running well on all machines now.
>
> i386 and ppc64 still doing builds, but after an hour on x86_64,
> an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> alternating between ext2_rsv_window_add and rsv_window_remove.
> Send me a patch and I'll try it...
>
> ext2_try_to_allocate_with_rsv+0x288
> ext2_new_blocks+0x21e
> ext2_get_blocks+0x398
> ext2_get_block+0x46
> __block_prepare_write+0x171
> block_prepare_write+0x39
> ext2_prepare_write+0x2c
> generic_file_buffered_write+0x2b0
> __generic_file_aio_write_nolock+0x4bc
> generic_file_aio_write+0x6d
> do_sync_write+0xf9
> vfs_write+0xc8
> sys_write+0x51
OK, I have a theory.
This must have been the seventeenth damn time I've stared at
find_next_zero_bit() wondering what the damn return value is and wondering
how any even slightly non-sadistic person could write a damn function like
that and not damn well document it.
int find_next_zero_bit(const unsigned long *addr, int size, int offset)
It returns the offset of the first zero bit relative to addr.
ext3's bitmap_search_next_usable_block() assumed that find_next_zero_bit()
returns the offset of the first zero bit relative to (addr+offset).
The while loop in ext3's bitmap_search_next_usable_block() serendipitously
covered that bug up.
ext2's bitmap_search_next_usable_block() doesn't need that while loop, so
ext3's benign bug became ext2's fatal bug.
So...
--- a/fs/ext2/balloc.c~a
+++ a/fs/ext2/balloc.c
@@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
ext2_grpblk_t next;
next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
- if (next >= maxblocks)
+ if (next >= start + maxblocks)
return -1;
return next;
}
_
Anyway, I think that's the bug. Or a bug, at least. If so, the cause of
this bug is inadequate code commenting, pure and simple. And ext3 and ext4
need fixing.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 5:45 ` Andrew Morton
@ 2006-11-16 6:39 ` Andrew Morton
2006-11-16 6:55 ` Mingming Cao
1 sibling, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 6:39 UTC (permalink / raw)
To: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org, Mingming Cao
On Wed, 15 Nov 2006 21:45:34 -0800
Andrew Morton <akpm@osdl.org> wrote:
> --- a/fs/ext2/balloc.c~a
> +++ a/fs/ext2/balloc.c
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> - if (next >= maxblocks)
> + if (next >= start + maxblocks)
> return -1;
> return next;
> }
> _
>
> Anyway, I think that's the bug.
Changed my mind. Drat.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 5:45 ` Andrew Morton
2006-11-16 6:39 ` Andrew Morton
@ 2006-11-16 6:55 ` Mingming Cao
2006-11-16 7:22 ` Andrew Morton
1 sibling, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-16 6:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
Andrew Morton wrote:
> On Wed, 15 Nov 2006 14:17:01 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
>
>
>>On Tue, 14 Nov 2006, Hugh Dickins wrote:
>>
>>>On Tue, 14 Nov 2006, Andrew Morton wrote:
>>>
>>>>The below might help.
>>>
>>>Indeed it does (with Martin's E2FSBLK warning fix),
>>>seems to be running well on all machines now.
>>
>>i386 and ppc64 still doing builds, but after an hour on x86_64,
>>an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
>>alternating between ext2_rsv_window_add and rsv_window_remove.
>>Send me a patch and I'll try it...
>>
>>ext2_try_to_allocate_with_rsv+0x288
>>ext2_new_blocks+0x21e
>>ext2_get_blocks+0x398
>>ext2_get_block+0x46
>>__block_prepare_write+0x171
>>block_prepare_write+0x39
>>ext2_prepare_write+0x2c
>>generic_file_buffered_write+0x2b0
>>__generic_file_aio_write_nolock+0x4bc
>>generic_file_aio_write+0x6d
>>do_sync_write+0xf9
>>vfs_write+0xc8
>>sys_write+0x51
>
>
> OK, I have a theory.
>
> This must have been the seventeenth damn time I've stared at
> find_next_zero_bit() wondering what the damn return value is and wondering
> how any even slightly non-sadistic person could write a damn function like
> that and not damn well document it.
>
> int find_next_zero_bit(const unsigned long *addr, int size, int offset)
>
> It returns the offset of the first zero bit relative to addr.
>
> ext3's bitmap_search_next_usable_block() assumed that find_next_zero_bit()
> returns the offset of the first zero bit relative to (addr+offset).
>
> The while loop in ext3's bitmap_search_next_usable_block() serendipitously
> covered that bug up.
>
> ext2's bitmap_search_next_usable_block() doesn't need that while loop, so
> ext3's benign bug became ext2's fatal bug.
>
> So...
>
> --- a/fs/ext2/balloc.c~a
> +++ a/fs/ext2/balloc.c
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> - if (next >= maxblocks)
> + if (next >= start + maxblocks)
> return -1;
> return next;
> }
> _
>
> Anyway, I think that's the bug. Or a bug, at least. If so, the cause of
> this bug is inadequate code commenting, pure and simple. And ext3 and ext4
> need fixing.
>
Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
number of the range to search, not the lengh of the range. maxblocks
get passed to ext2_find_next_zero_bit(), where it expecting to take the
_size_ of the range to search instead...
Something like this: (this is not a patch)
@@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
ext2_grpblk_t next;
- next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
+ next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1,
start);
if (next >= maxblocks)
return -1;
return next;
}
Mingming
Yes, it's quite confusing and probably we should replace it a better
name......
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 6:55 ` Mingming Cao
@ 2006-11-16 7:22 ` Andrew Morton
2006-11-16 8:49 ` Mingming Cao
2006-11-16 12:34 ` Russell King
0 siblings, 2 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 7:22 UTC (permalink / raw)
To: Mingming Cao
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Wed, 15 Nov 2006 22:55:43 -0800
Mingming Cao <cmm@us.ibm.com> wrote:
> Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> number of the range to search, not the lengh of the range. maxblocks
> get passed to ext2_find_next_zero_bit(), where it expecting to take the
> _size_ of the range to search instead...
>
> Something like this: (this is not a patch)
> @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> ext2_grpblk_t next;
>
> - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> if (next >= maxblocks)
> return -1;
> return next;
> }
yes, the `size' arg to find_next_zero_bit() represents the number of bits
to scan at `offset'.
So I think your change is correctish. But we don't want the "+ 1", do we?
If we're right then this bug could cause the code to scan off the end of the
bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
btw, how come try_to_extend_reservation() uses spin_trylock?
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 7:22 ` Andrew Morton
@ 2006-11-16 8:49 ` Mingming Cao
2006-11-16 9:13 ` Andrew Morton
2006-11-16 12:34 ` Russell King
1 sibling, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-16 8:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > _size_ of the range to search instead...
> >
> > Something like this: (this is not a patch)
> > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > ext2_grpblk_t next;
> >
> > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > if (next >= maxblocks)
> > return -1;
> > return next;
> > }
>
> yes, the `size' arg to find_next_zero_bit() represents the number of bits
> to scan at `offset'.
>
> So I think your change is correctish. But we don't want the "+ 1", do we?
>
I think we still need the "+1", maxblocks here is the ending block of
the reservation window, so the number of bits to scan =end-start+1.
> If we're right then this bug could cause the code to scan off the end of the
> bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
>
Yeah.. at first I thought it might be related, then, thinked it over,
the bug only makes the bits to scan larger, so if find_next_zero_bit()
returns something off the end of bitmap, that is fine, it just
indicating that there is no free bit left in the rest of bitmap, which
is expected behavior. So bitmap_search_next_usable_block() fail is the
expected. It will move on to next block group and try to create a new
reservation window there.
That does not explain the repeated reservation window add and remove
behavior Huge has reported.
> btw, how come try_to_extend_reservation() uses spin_trylock?
Since locks are all allocated from reservation window, when ext3
multiple blocks allocation was added, we added try_to_extend_reservation
() to ext3, which trying to extend the reservation window size to at
least match the number of blocks to allocate. So we have better chance
to allocating multiple blocks from the window at a time.
Since all the multiple block allocation is based on best effort basis,
the same applied to try_to_extend_reservation(). It seems no need to
wait for the reservation tree lock if it's not avaible at that moment.
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 8:49 ` Mingming Cao
@ 2006-11-16 9:13 ` Andrew Morton
2006-11-16 9:37 ` Alex Tomas
` (2 more replies)
0 siblings, 3 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 9:13 UTC (permalink / raw)
To: cmm
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006 00:49:20 -0800
Mingming Cao <cmm@us.ibm.com> wrote:
> On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > number of the range to search, not the lengh of the range. maxblocks
> > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > _size_ of the range to search instead...
> > >
> > > Something like this: (this is not a patch)
> > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > ext2_grpblk_t next;
> > >
> > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > if (next >= maxblocks)
> > > return -1;
> > > return next;
> > > }
> >
> > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > to scan at `offset'.
> >
> > So I think your change is correctish. But we don't want the "+ 1", do we?
> >
> I think we still need the "+1", maxblocks here is the ending block of
> the reservation window, so the number of bits to scan =end-start+1.
>
> > If we're right then this bug could cause the code to scan off the end of the
> > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> >
>
> Yeah.. at first I thought it might be related, then, thinked it over,
> the bug only makes the bits to scan larger, so if find_next_zero_bit()
> returns something off the end of bitmap, that is fine, it just
> indicating that there is no free bit left in the rest of bitmap, which
> is expected behavior. So bitmap_search_next_usable_block() fail is the
> expected. It will move on to next block group and try to create a new
> reservation window there.
I wonder why it's never oopsed. Perhaps there's always a zero in there for
some reason.
> That does not explain the repeated reservation window add and remove
> behavior Huge has reported.
I spent quite some time comparing with ext3. I'm a bit stumped and I'm
suspecting that the simplistic porting the code is now OK, but something's
just wrong.
I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
gone infinite. I don't see why, but more staring is needed.
What lock protects the fields in struct ext[234]_reserve_window from being
concurrently modified by two CPUs? None, it seems. Ditto
ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
for pageout over a file hole. If we end up with a zero- or negative-sized
window then odd things might happen.
> > btw, how come try_to_extend_reservation() uses spin_trylock?
>
> Since locks are all allocated from reservation window, when ext3
> multiple blocks allocation was added, we added try_to_extend_reservation
> () to ext3, which trying to extend the reservation window size to at
> least match the number of blocks to allocate. So we have better chance
> to allocating multiple blocks from the window at a time.
>
> Since all the multiple block allocation is based on best effort basis,
> the same applied to try_to_extend_reservation(). It seems no need to
> wait for the reservation tree lock if it's not avaible at that moment.
>
I suspect that was not a good idea - it has added rather different
behaviour in the once-in-a-million case.
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-16 9:13 ` Andrew Morton
@ 2006-11-16 9:37 ` Alex Tomas
2006-11-16 9:48 ` Andrew Morton
2006-11-16 16:26 ` Hugh Dickins
2006-11-16 20:15 ` Mingming Cao
2 siblings, 1 reply; 204+ messages in thread
From: Alex Tomas @ 2006-11-16 9:37 UTC (permalink / raw)
To: Andrew Morton
Cc: cmm, Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
>>>>> Andrew Morton (AM) writes:
AM> What lock protects the fields in struct ext[234]_reserve_window from being
AM> concurrently modified by two CPUs? None, it seems. Ditto
AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
AM> for pageout over a file hole. If we end up with a zero- or negative-sized
AM> window then odd things might happen.
truncate_mutex?
thanks, Alex
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 9:37 ` Alex Tomas
@ 2006-11-16 9:48 ` Andrew Morton
2006-11-16 9:49 ` Andrew Morton
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 9:48 UTC (permalink / raw)
To: Alex Tomas
Cc: cmm, Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006 12:37:17 +0300
Alex Tomas <alex@clusterfs.com> wrote:
> >>>>> Andrew Morton (AM) writes:
>
> AM> What lock protects the fields in struct ext[234]_reserve_window from being
> AM> concurrently modified by two CPUs? None, it seems. Ditto
> AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> AM> for pageout over a file hole. If we end up with a zero- or negative-sized
> AM> window then odd things might happen.
>
> truncate_mutex?
>
yes. hmm.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 9:48 ` Andrew Morton
@ 2006-11-16 9:49 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 9:49 UTC (permalink / raw)
To: Alex Tomas, cmm, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006 01:48:09 -0800
Andrew Morton <akpm@osdl.org> wrote:
> On Thu, 16 Nov 2006 12:37:17 +0300
> Alex Tomas <alex@clusterfs.com> wrote:
>
> > >>>>> Andrew Morton (AM) writes:
> >
> > AM> What lock protects the fields in struct ext[234]_reserve_window from being
> > AM> concurrently modified by two CPUs? None, it seems. Ditto
> > AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> > AM> for pageout over a file hole. If we end up with a zero- or negative-sized
> > AM> window then odd things might happen.
> >
> > truncate_mutex?
> >
>
> yes. hmm.
by which I mean "ext2 doesn't have a truncate_mutex".
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 9:13 ` Andrew Morton
2006-11-16 9:37 ` Alex Tomas
@ 2006-11-16 16:26 ` Hugh Dickins
2006-11-16 20:15 ` Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-16 16:26 UTC (permalink / raw)
To: Andrew Morton
Cc: cmm, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
>
> > That does not explain the repeated reservation window add and remove
> > behavior Huge has reported.
>
> I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> suspecting that the simplistic porting the code is now OK, but something's
> just wrong.
>
> I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> gone infinite. I don't see why, but more staring is needed.
Just to report that similar tests on three machines have each run
for 20 hours so far without any such infinite loop reoccurring.
Well, I broke off the x86_64 for a couple of hours: wondered if I'd got
confused, forgotten to "rmmod ext2" at one stage, and saw that behaviour
with my simple "ext2fs_blk_t ret_block" patch, rather than your more
extensive patch to ext2_new_blocks() that I'd believed I was testing.
I didn't give it long enough to be conclusive, but the problem didn't
show up with that either, so I've gone back to testing with yours.
I'd have kept the hang around for longer if I'd guessed it would be
hard to reproduce, and that it would be puzzling even to you: sorry.
kdb is in, if it comes again I can peer at it more closely.
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 9:13 ` Andrew Morton
2006-11-16 9:37 ` Alex Tomas
2006-11-16 16:26 ` Hugh Dickins
@ 2006-11-16 20:15 ` Mingming Cao
2006-11-16 21:27 ` Andrew Morton
2 siblings, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-16 20:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
>
> > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <cmm@us.ibm.com> wrote:
> > >
> > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > number of the range to search, not the lengh of the range. maxblocks
> > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > _size_ of the range to search instead...
> > > >
> > > > Something like this: (this is not a patch)
> > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > ext2_grpblk_t next;
> > > >
> > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > if (next >= maxblocks)
> > > > return -1;
> > > > return next;
> > > > }
> > >
> > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > to scan at `offset'.
> > >
> > > So I think your change is correctish. But we don't want the "+ 1", do we?
> > >
> > I think we still need the "+1", maxblocks here is the ending block of
> > the reservation window, so the number of bits to scan =end-start+1.
> >
> > > If we're right then this bug could cause the code to scan off the end of the
> > > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> > >
> >
> > Yeah.. at first I thought it might be related, then, thinked it over,
> > the bug only makes the bits to scan larger, so if find_next_zero_bit()
> > returns something off the end of bitmap, that is fine, it just
> > indicating that there is no free bit left in the rest of bitmap, which
> > is expected behavior. So bitmap_search_next_usable_block() fail is the
> > expected. It will move on to next block group and try to create a new
> > reservation window there.
>
> I wonder why it's never oopsed. Perhaps there's always a zero in there for
> some reason.
>
Why you think it should oopsed? Even if find_next_zero_bit() finds a
zero bit beyond of the end of bitmap, the check next > maxblocks will
catch this and make sure we are not taking a zero bit out of the bitmap
range, so it fails as expected.
> > That does not explain the repeated reservation window add and remove
> > behavior Huge has reported.
>
> I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> suspecting that the simplistic porting the code is now OK, but something's
> just wrong.
>
> I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> gone infinite. I don't see why, but more staring is needed.
>
The loop should not go forever, it will stops when there is no window
with free bit to reserve in the given block group.
> What lock protects the fields in struct ext[234]_reserve_window from being
> concurrently modified by two CPUs? None, it seems. Ditto
> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> for pageout over a file hole. If we end up with a zero- or negative-sized
> window then odd things might happen.
>
Yes, trucate_mutex protect both struct ext[234]_reserve_window and ext
[234]_reserve_window_node, and struct ext[234]_block_alloc_info.
Actually I think truncate_mutex protects all data structures related to
block allocation/mapping structures.
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 20:15 ` Mingming Cao
@ 2006-11-16 21:27 ` Andrew Morton
2006-11-20 16:19 ` Hugh Dickins
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-16 21:27 UTC (permalink / raw)
To: cmm
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006 12:15:16 -0800
Mingming Cao <cmm@us.ibm.com> wrote:
> On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 00:49:20 -0800
> > Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > > Mingming Cao <cmm@us.ibm.com> wrote:
> > > >
> > > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > > number of the range to search, not the lengh of the range. maxblocks
> > > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > > _size_ of the range to search instead...
> > > > >
> > > > > Something like this: (this is not a patch)
> > > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > > ext2_grpblk_t next;
> > > > >
> > > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > > if (next >= maxblocks)
> > > > > return -1;
> > > > > return next;
> > > > > }
> > > >
> > > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > > to scan at `offset'.
> > > >
> > > > So I think your change is correctish. But we don't want the "+ 1", do we?
> > > >
> > > I think we still need the "+1", maxblocks here is the ending block of
> > > the reservation window, so the number of bits to scan =end-start+1.
> > >
> > > > If we're right then this bug could cause the code to scan off the end of the
> > > > bitmap. But it won't explain Hugh's bug, because of the if (next >= maxblocks).
> > > >
> > >
> > > Yeah.. at first I thought it might be related, then, thinked it over,
> > > the bug only makes the bits to scan larger, so if find_next_zero_bit()
> > > returns something off the end of bitmap, that is fine, it just
> > > indicating that there is no free bit left in the rest of bitmap, which
> > > is expected behavior. So bitmap_search_next_usable_block() fail is the
> > > expected. It will move on to next block group and try to create a new
> > > reservation window there.
> >
> > I wonder why it's never oopsed. Perhaps there's always a zero in there for
> > some reason.
> >
>
> Why you think it should oopsed? Even if find_next_zero_bit() finds a
> zero bit beyond of the end of bitmap, the check next > maxblocks will
> catch this and make sure we are not taking a zero bit out of the bitmap
> range, so it fails as expected.
If it can read off the end of the buffer, it can oops. With
CONFIG_DEBUG_PAGEALLOC, especially.
> > > That does not explain the repeated reservation window add and remove
> > > behavior Huge has reported.
> >
> > I spent quite some time comparing with ext3. I'm a bit stumped and I'm
> > suspecting that the simplistic porting the code is now OK, but something's
> > just wrong.
> >
> > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > gone infinite. I don't see why, but more staring is needed.
> >
>
> The loop should not go forever, it will stops when there is no window
> with free bit to reserve in the given block group.
It seems to have done so in Hugh's testing, but there's some question there
now. Although I didn't check to see if there's a significant difference
between Hugh's patch and mine.
> > What lock protects the fields in struct ext[234]_reserve_window from being
> > concurrently modified by two CPUs? None, it seems. Ditto
> > ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
> > for pageout over a file hole. If we end up with a zero- or negative-sized
> > window then odd things might happen.
> >
>
> Yes, trucate_mutex protect both struct ext[234]_reserve_window and ext
> [234]_reserve_window_node, and struct ext[234]_block_alloc_info.
> Actually I think truncate_mutex protects all data structures related to
> block allocation/mapping structures.
Yes. I guess ext2 needs a new mutex for this. Sad.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 21:27 ` Andrew Morton
@ 2006-11-20 16:19 ` Hugh Dickins
2006-11-20 20:54 ` Hugh Dickins
2006-11-21 1:47 ` Mingming Cao
0 siblings, 2 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-20 16:19 UTC (permalink / raw)
To: Andrew Morton
Cc: cmm, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 12:15:16 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
> > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > >
> > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > > gone infinite. I don't see why, but more staring is needed.
> >
> > The loop should not go forever, it will stops when there is no window
> > with free bit to reserve in the given block group.
>
> It seems to have done so in Hugh's testing, but there's some question there
> now. Although I didn't check to see if there's a significant difference
> between Hugh's patch and mine.
After four days of running, the EM64T has at last reproduced the same
hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv,
repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove
(perhaps not in that order).
But somehow I've screwed up, and before I'd extracted any new info,
kdb was spinning on its own kdb_printf_lock, and then the box completely
frozen: nothing for it but to reboot.
Grrrr.
Well: at least this resolves the doubt I raised earlier, whether
I'd been testing with the right ext2 patch. This time was definitely
with your patch not my two-liner: your original patch from Tuesday 14 Nov,
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
Various other patches have come into -mm (one gone) since then, but I've
been running just with that: so far as I can see, none of the later ones
should be important in my case - the filesystem is too small for the
difference between int and ext2_fsblk_t to become important, and
neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout.
I'll do a little staring at the code myself: I'm unlikely to notice
anything you've missed, but there's just a chance staring at it will
direct me to some detail I've jotted down from before.
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-20 16:19 ` Hugh Dickins
@ 2006-11-20 20:54 ` Hugh Dickins
2006-11-21 1:36 ` Mingming Cao
2006-11-21 1:47 ` Mingming Cao
1 sibling, 1 reply; 204+ messages in thread
From: Hugh Dickins @ 2006-11-20 20:54 UTC (permalink / raw)
To: Andrew Morton
Cc: cmm, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Mon, 20 Nov 2006, Hugh Dickins wrote:
>
> I'll do a little staring at the code myself: I'm unlikely to notice
> anything you've missed, but there's just a chance staring at it will
> direct me to some detail I've jotted down from before.
Not found anything relevant, but I keep noticing these lines
in ext2_try_to_allocate_with_rsv(), ext3 and ext4 similar:
} else if (grp_goal > 0 &&
(my_rsv->rsv_end - grp_goal + 1) < *count)
try_to_extend_reservation(my_rsv, sb,
*count-my_rsv->rsv_end + grp_goal - 1);
They're wrong, a no-op in most groups, aren't they? rsv_end is an
absolute block number, whereas grp_goal is group-relative, so the
calculation ought to bring in group_first_block? Or I'm confused.
(Whereas in my hang the grp_goal to ext2_try_to_allocate was -1
when I looked, with group 0 and num 1.)
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-20 20:54 ` Hugh Dickins
@ 2006-11-21 1:36 ` Mingming Cao
0 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-21 1:36 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Mon, 2006-11-20 at 20:54 +0000, Hugh Dickins wrote:
> Not found anything relevant, but I keep noticing these lines
> in ext2_try_to_allocate_with_rsv(), ext3 and ext4 similar:
>
> } else if (grp_goal > 0 &&
> (my_rsv->rsv_end - grp_goal + 1) < *count)
> try_to_extend_reservation(my_rsv, sb,
> *count-my_rsv->rsv_end + grp_goal - 1);
>
> They're wrong, a no-op in most groups, aren't they? rsv_end is an
> absolute block number, whereas grp_goal is group-relative, so the
> calculation ought to bring in group_first_block? Or I'm confused.
>
You are right, thanks. Here are two patches, to fix this bug in ext3/4
and ext2 correspondingly.
Signed-Off-By: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 12 ++++++++----
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 12 ++++++++----
2 files changed, 16 insertions(+), 8 deletions(-)
diff -puN fs/ext3/balloc.c~ext34_extend_reservation_window_fix fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext34_extend_reservation_window_fix 2006-11-20 15:58:11.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-20 15:58:11.000000000 -0800
@@ -1307,10 +1307,14 @@ ext3_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end-grp_goal+1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }
if ((my_rsv->rsv_start > group_last_block) ||
(my_rsv->rsv_end < group_first_block)) {
diff -puN fs/ext4/balloc.c~ext34_extend_reservation_window_fix fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext34_extend_reservation_window_fix 2006-11-20 15:58:11.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-20 15:58:11.000000000 -0800
@@ -1324,10 +1324,14 @@ ext4_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end-grp_goal+1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }
if ((my_rsv->rsv_start > group_last_block) ||
(my_rsv->rsv_end < group_first_block)) {
Sync up ext2 with ext3/4 for the extend reservation window bug.
Signed-Off-By: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext2/balloc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff -puN fs/ext2/balloc.c~ext2_reservation_extend_window_fix fs/ext2/balloc.c
--- linux-2.6.19-rc5/fs/ext2/balloc.c~ext2_reservation_extend_window_fix 2006-11-20 16:05:36.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext2/balloc.c 2006-11-20 16:05:36.000000000 -0800
@@ -1091,10 +1091,14 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0 &&
- (my_rsv->rsv_end - grp_goal + 1) < *count)
- try_to_extend_reservation(my_rsv, sb,
- *count-my_rsv->rsv_end + grp_goal - 1);
+ } else if (grp_goal > 0) {
+ int curr = my_rsv->rsv_end -
+ (grp_goal + group_first_block) + 1;
+
+ if (curr < *count)
+ try_to_extend_reservation(my_rsv, sb,
+ *count - curr);
+ }
if ((my_rsv->rsv_start >=
group_first_block + EXT2_BLOCKS_PER_GROUP(sb))
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-20 16:19 ` Hugh Dickins
2006-11-20 20:54 ` Hugh Dickins
@ 2006-11-21 1:47 ` Mingming Cao
2006-11-21 5:39 ` Hugh Dickins
1 sibling, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-21 1:47 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> On Thu, 16 Nov 2006, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 12:15:16 -0800
> > Mingming Cao <cmm@us.ibm.com> wrote:
> > > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > > >
> > > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > > > gone infinite. I don't see why, but more staring is needed.
> > >
> > > The loop should not go forever, it will stops when there is no window
> > > with free bit to reserve in the given block group.
> >
> > It seems to have done so in Hugh's testing, but there's some question there
> > now. Although I didn't check to see if there's a significant difference
> > between Hugh's patch and mine.
>
> After four days of running, the EM64T has at last reproduced the same
> hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv,
> repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove
> (perhaps not in that order).
>
> But somehow I've screwed up, and before I'd extracted any new info,
> kdb was spinning on its own kdb_printf_lock, and then the box completely
> frozen: nothing for it but to reboot.
>
> Grrrr.
>
> Well: at least this resolves the doubt I raised earlier, whether
> I'd been testing with the right ext2 patch. This time was definitely
> with your patch not my two-liner: your original patch from Tuesday 14 Nov,
> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
>
> Various other patches have come into -mm (one gone) since then, but I've
> been running just with that: so far as I can see, none of the later ones
> should be important in my case - the filesystem is too small for the
> difference between int and ext2_fsblk_t to become important, and
> neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout.
>
So there is only one writer at the moment the hang was happening?
hmm, is the filesystem relatively all being used or reserved, i.e, the
free bits are all being reserved? There is one extreme case that may
cause starvation. If filesystem free blocks are all being reserved, when
a new writer need a free block, it has to go through the entire
filesystems, try to reserve a space, which will repeatly calling
rsv_window_add and rsv_window_remove, since. Finally give up and fall
back to allocation without reservation. But this is all theory, not sure
fits your case here.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-21 1:47 ` Mingming Cao
@ 2006-11-21 5:39 ` Hugh Dickins
2006-11-22 0:43 ` Mingming Cao
0 siblings, 1 reply; 204+ messages in thread
From: Hugh Dickins @ 2006-11-21 5:39 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Mon, 20 Nov 2006, Mingming Cao wrote:
>
> So there is only one writer at the moment the hang was happening?
I expect there were multiple writers when the task which hangs
first entered its ext2_prepare_write (it's a make -j20 build on
that ext2 filesystem); but by the time I come to look at the hang,
there's only that one writer active - everything else would be waiting
on that part of the build to complete (well, your question makes me
realize that I didn't look down the whole "ps" listing to see what
was waiting; but the hanging task is the only one I see running on
on any cpu, each time I break in).
>
> hmm, is the filesystem relatively all being used or reserved, i.e, the
> free bits are all being reserved? There is one extreme case that may
> cause starvation. If filesystem free blocks are all being reserved, when
> a new writer need a free block, it has to go through the entire
> filesystems, try to reserve a space, which will repeatly calling
> rsv_window_add and rsv_window_remove, since. Finally give up and fall
> back to allocation without reservation. But this is all theory, not sure
> fits your case here.
I can understand that there may be a worst case like that: but I hope
it wouldn't take 20 hours to find a free block on a default 340MB ext2
filesystem! And unless something else has gone wrong, this build would
not be filling the filesystem to that extent: it's probably around 80%
full at this stage, and shouldn't get fuller than 98% in the end.
Any suggestions for what I might check, next time it happens?
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-21 5:39 ` Hugh Dickins
@ 2006-11-22 0:43 ` Mingming Cao
2006-11-28 17:38 ` Hugh Dickins
0 siblings, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-22 0:43 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> After four days of running, the EM64T has at last reproduced the same
> hang as it did in an hour before: stuck in
> ext2_try_to_allocate_with_rsv,
> repeatedly ext2_rsv_window_add, ext2_try_to_allocate,
> rsv_window_remove
> (perhaps not in that order).
>
Don't have much clue, still...:(
The logic of the while loop in ext2_try_to_allocate_with_rsv() looks
like:
while (1) {
/*make a new reservation window*/
ret = allocate_new_reservation();
if (ret < 0)
break /*fail*/
/*allocate a block from the reservation window */
ret = ext2_try_to_allocate_with_rsv()
if (ret > 0) {
...
break; /*success*/
}
}
If it stucks in the loop, that means next two things have to be true:
1) ext2_try_to_allocate() keeps failing to allocate a bit from the
window just reserved, every time.
2) we could endlessly create a new reservation window in this block
group.
For (1), when create a new reservation window, we do make sure there are
at least one free bit in the window, so that
ext2_try_to_allocate_with_rsv() could claim that bit. I haven't found
any thing wrong in that part yet;
For (2)the search for the next reservation window should start from the
end block of the old window, and should stop and fail if it reachs the
last block of the block group.
Will continue looking at the code, but so far everything looks just fine
to me.:(
On Tue, 2006-11-21 at 05:39 +0000, Hugh Dickins wrote:
> On Mon, 20 Nov 2006, Mingming Cao wrote:
> >
> > So there is only one writer at the moment the hang was happening?
>
> I expect there were multiple writers when the task which hangs
> first entered its ext2_prepare_write (it's a make -j20 build on
> that ext2 filesystem); but by the time I come to look at the hang,
> there's only that one writer active - everything else would be waiting
> on that part of the build to complete
> (well, your question makes me
> realize that I didn't look down the whole "ps" listing to see what
> was waiting; but the hanging task is the only one I see running on
> on any cpu, each time I break in).
>
A bit confused, did the whole system hang or just the "ld" writer hang
in ext2 block allocation? And what other writers were waiting for? Were
they trying to write to the same file?
> >
> > hmm, is the filesystem relatively all being used or reserved, i.e, the
> > free bits are all being reserved? There is one extreme case that may
> > cause starvation. If filesystem free blocks are all being reserved, when
> > a new writer need a free block, it has to go through the entire
> > filesystems, try to reserve a space, which will repeatly calling
> > rsv_window_add and rsv_window_remove, since. Finally give up and fall
> > back to allocation without reservation. But this is all theory, not sure
> > fits your case here.
>
> I can understand that there may be a worst case like that: but I hope
> it wouldn't take 20 hours to find a free block on a default 340MB ext2
> filesystem! And unless something else has gone wrong, this build would
> not be filling the filesystem to that extent: it's probably around 80%
> full at this stage, and shouldn't get fuller than 98% in the end.
>
> Any suggestions for what I might check, next time it happens?
>
It might be helpful to check the return value of ext2_try_to_allocate(),
to see if it fails. It would be nice if you could check if there any
free bit inside the reservation window.
And could you check the start and end block for every rsv_window_add and
rsv_window_remove, to see if it was keep creating and removing the same
window in the same block group?
And it might be useful to dump the whole filesystem block reservation
tree as well.
Not sure if it worth the effort to test it on ext3. The ext2 block
reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
except the missing truncate_mutex. I understand this might take a few
days to reproduce, so this might not needed now.
Mingming
> Hugh
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-22 0:43 ` Mingming Cao
@ 2006-11-28 17:38 ` Hugh Dickins
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
` (6 more replies)
0 siblings, 7 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:38 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 21 Nov 2006, Mingming Cao wrote:
> On Mon, 2006-11-20 at 16:19 +0000, Hugh Dickins wrote:
> > After four days of running, the EM64T has at last reproduced the same
> > hang as it did in an hour before: stuck in
> > ext2_try_to_allocate_with_rsv,
> > repeatedly ext2_rsv_window_add, ext2_try_to_allocate,
> > rsv_window_remove
> > (perhaps not in that order).
> >
At last it did happen again, on both x86_64 and ppc64.
>
> Don't have much clue, still...:(
Don't worry, KDB helped me work it out, patch follows in a moment.
>
> The logic of the while loop in ext2_try_to_allocate_with_rsv() looks
> like:
Thanks for your clarifications and tips.
> >
> A bit confused, did the whole system hang or just the "ld" writer hang
> in ext2 block allocation? And what other writers were waiting for? Were
> they trying to write to the same file?
The system was pingable, but couldn't do much else. Only the one
"ld" was active on the ext2 filesystem by this time, other tasks of
the make just waiting on it, nothing else was trying to write there.
4 cpus, well, 2*HT: why couldn't I ssh or login? I don't know,
something else to investigate, but that can be quite separate: very
unlikely to be related to the particular ext2 bug which showed it
(that filesystem was just for the test, it's not my root).
Probably stupidly obvious once I've worked it out.
>
> It might be helpful to check the return value of ext2_try_to_allocate(),
> to see if it fails. It would be nice if you could check if there any
> free bit inside the reservation window.
After screwing up last time, I was ultra-paranoid this time, and did
not dare to set any breakpoints: proceeded by repeatedly breaking in
from the keyboard, and the time I happened to catch it on return from
memscan() was revealing.
>
> And could you check the start and end block for every rsv_window_add and
> rsv_window_remove, to see if it was keep creating and removing the same
> window in the same block group?
The same every time it settled on a usable reservation, but a lot of
wasted adds and removes as it works across a fully allocated area of
the bitmap. Not very efficient, all those rb_tree insertions and
removals until it gets to a free area; but I can't judge from this
example how common that would be, may not be worth bothering about.
>
> And it might be useful to dump the whole filesystem block reservation
> tree as well.
Not necessary, I've put just the relevant numbers in the patch comment,
it helped me a lot to see the actual numbers and work it out from there.
>
> Not sure if it worth the effort to test it on ext3. The ext2 block
> reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
> except the missing truncate_mutex. I understand this might take a few
> days to reproduce, so this might not needed now.
Turns out vanilla-ext2 and ext3 and ext4 are safe:
ext3 and ext4 slightly wrong in the same way, but safe.
I'll continue this thread with the bugfix patch 1/6; and five more
(roughly descending order of importance, the latter just cosmetic)
little fs/ext2/balloc.c patches to things I noticed on the way.
Nothing very worrying. Easier to send patches than ask questions:
please check, perhaps my "off-by-one" accusations are wrong, for
example. If you're satisfied they're right, please apply the
same to ext3 and ext4.
Although 1/6 does (I believe: too early for my tests to tell)
fix the bug in a minimal way, I rather think that area needs
cleanup - further comments below my Signed-off-by in 1/6.
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
2006-11-28 17:38 ` Hugh Dickins
@ 2006-11-28 17:40 ` Hugh Dickins
2006-11-28 19:26 ` Mingming Cao
` (2 more replies)
2006-11-28 17:40 ` [PATCH 2/6] ext2 balloc: reset windowsz when full Hugh Dickins
` (5 subsequent siblings)
6 siblings, 3 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:40 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
find the free block guaranteed to be included (unless there's contention).
Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
00, but the premature cutoff implying that the last was found 00).
Is this a problem for mainline ext2? No, because the "size" in its memscan
is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
multiple of 8. Is this a problem for ext3 or ext4? No, because they have
an additional extN_test_allocatable test which rescues them from the error.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
But the bigger question is, why does the my_rsv case come here to
find_next_usable_block at all? Doesn't its 64-bit boundary limit, and its
memscan, blithely ignore what the reservation prepared? It's messy too,
the complement of the memscan being that "i < 7" loop over in
ext2_try_to_allocate. I think this ought to be cleaned up,
in ext2+reservations and ext3 and ext4.
fs/ext2/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -570,7 +570,7 @@ find_next_usable_block(int start, struct
here = 0;
p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;
if (next < maxblocks && next >= here)
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
@ 2006-11-28 19:26 ` Mingming Cao
2006-11-28 20:07 ` Hugh Dickins
2006-11-29 4:14 ` [PATCH 6/12] " Mingming Cao
2006-11-29 4:15 ` [PATCH 12/12] ext3 " Mingming Cao
2 siblings, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 19:26 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> After several days of testing ext2 with reservations, it got caught inside
> ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> find the free block guaranteed to be included (unless there's contention).
>
Hmm, I suspect there is other issue: alloc_new_reservation should not
repeatedly allocating the same window, if ext2_try_to_allocate
repeatedly fails to find a free block in that window.
find_next_reservable_window() takes my_rsv (the old window that he
thinks there is no free block) as a guide to find a window "after" the
end block of my_rsv, so how could this happen?
> Fix the range to find_next_usable_block's memscan: the scan from "here"
> (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> 00, but the premature cutoff implying that the last was found 00).
>
alloc_new_reservation() reserved a window with free block, when come to
the time to claim it, it scans the window again. So it seems that the
range of the the scan is too small:
p = ((char *)bh->b_data) + (here >> 3);
r = memscan(p, 0, (maxblocks - here + 7) >> 3);
next = (r - ((char *)bh->b_data)) << 3;
---------------------> next is -1
if (next < maxblocks && next >= here)
return next;
----------------------> falls to false branch
here = bitmap_search_next_usable_block(here, bh, maxblocks);
return here;
So we failed to find a free byte in the range. That's seems fine to me.
It's only a nice thing to have -- try to allocate a block in a place
where it's neighbors are all free also. If it fails, it will search the
window bit by bit. So I don't understand why it is not being recovered
by bitmap_search_next_usable_block(), which test the bitmap bit by bit?
> Is this a problem for mainline ext2? No, because the "size" in its memscan
> is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> an additional extN_test_allocatable test which rescues them from the error.
>
Hmm, if the error is it prematurely think there is no free block in the
range (bitmap on disk), then even in ext3/4, it will not bother checking
the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
may not has the problem.
> But the bigger question is, why does the my_rsv case come here to
> find_next_usable_block at all?
Because grp_goal is -1?
> Doesn't its 64-bit boundary limit, and its
> memscan, blithely ignore what the reservation prepared?
I agree with you that the double check is urgly. But it's necessary:( If
there to prevent contention: other file make steal that free block we
reserved for this file, in the case filesystem is full of reservation...
> It's messy too,
> the complement of the memscan being that "i < 7" loop over in
> ext2_try_to_allocate. I think this ought to be cleaned up,
> in ext2+reservations and ext3 and ext4.
>
The "i<7" loop there is for non reservation case. Since
find_next_usable_block() could find a free byte, it's trying to avoid
filesystem holes by shifting the start of the free block for at most 7
times.
Thanks!
Mingming
> fs/ext2/balloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -570,7 +570,7 @@ find_next_usable_block(int start, struct
> here = 0;
>
> p = ((char *)bh->b_data) + (here >> 3);
> - r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> + r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
> next = (r - ((char *)bh->b_data)) << 3;
>
> if (next < maxblocks && next >= here)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
2006-11-28 19:26 ` Mingming Cao
@ 2006-11-28 20:07 ` Hugh Dickins
2006-11-29 0:42 ` Mingming Cao
0 siblings, 1 reply; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 20:07 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 28 Nov 2006, Mingming Cao wrote:
> On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> > After several days of testing ext2 with reservations, it got caught inside
> > ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> > on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> > find the free block guaranteed to be included (unless there's contention).
> >
>
> Hmm, I suspect there is other issue: alloc_new_reservation should not
> repeatedly allocating the same window, if ext2_try_to_allocate
> repeatedly fails to find a free block in that window.
> find_next_reservable_window() takes my_rsv (the old window that he
> thinks there is no free block) as a guide to find a window "after" the
> end block of my_rsv, so how could this happen?
Hmmm. I haven't studied that part of the code, but what you say sounds
sensible: that would leave more to be explained, yes. I guess it would
happen if all the rest of the bitmap were either allocated or reserved,
but I don't believe that was the case here: I have noted that the map
was all 00s from offset 0x1ae onwards, plenty unallocated; I've not
recorded the following reservations, but it seems unlikely they covered
the remaining free area (and still covered it even when the remaining
tasks got to the point of just waiting for this one).
>
> > Fix the range to find_next_usable_block's memscan: the scan from "here"
> > (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> > not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> > 00, but the premature cutoff implying that the last was found 00).
> >
>
> alloc_new_reservation() reserved a window with free block, when come to
> the time to claim it, it scans the window again. So it seems that the
> range of the the scan is too small:
The range of the scan is 1 byte too small in this case, yes.
>
> p = ((char *)bh->b_data) + (here >> 3);
> r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> next = (r - ((char *)bh->b_data)) << 3;
>
> ---------------------> next is -1
I don't understand you: next was not -1, it was 0xd08.
> if (next < maxblocks && next >= here)
> return next;
>
> ----------------------> falls to false branch
No, it passed the "next < maxblocks && next >= here" test
(maxblocks being 0xd0e and here being 0xcfe), so returned
pointing to an allocated block - then the caller finds it
cannot set the bit.
>
> here = bitmap_search_next_usable_block(here, bh, maxblocks);
> return here;
>
> So we failed to find a free byte in the range. That's seems fine to me.
> It's only a nice thing to have -- try to allocate a block in a place
> where it's neighbors are all free also. If it fails, it will search the
> window bit by bit. So I don't understand why it is not being recovered
> by bitmap_search_next_usable_block(), which test the bitmap bit by bit?
It already returned, it doesn't reach that line.
>
> > Is this a problem for mainline ext2? No, because the "size" in its memscan
> > is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> > multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> > an additional extN_test_allocatable test which rescues them from the error.
> >
> Hmm, if the error is it prematurely think there is no free block in the
> range (bitmap on disk), then even in ext3/4, it will not bother checking
> the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
> may not has the problem.
In the ext3/4 case, it indeed won't bother to check the jbd copy
(having found this bitmap bit set), it'll fall through to the
bitmap_search_next_usable_block you indicated above,
and that should do the right thing, finding the first
free bit in the area originally reserved.
>
> > But the bigger question is, why does the my_rsv case come here to
> > find_next_usable_block at all?
>
> Because grp_goal is -1?
Well, yes, but my point is that we've got a reservation, and we're
hoping to allocate from it (even though we've given up on the "goal"),
but find_next_usable_block is not respecting it at all - liable to be
allocating out of others' reservations instead.
>
> > Doesn't its 64-bit boundary limit, and its
> > memscan, blithely ignore what the reservation prepared?
>
> I agree with you that the double check is urgly. But it's necessary:( If
> there to prevent contention: other file make steal that free block we
> reserved for this file, in the case filesystem is full of reservation...
I agree it's necessary to recheck the allocation; I disagree that the
64-bit boundary limit and memscan are appropriate when my_rsv is set.
>
> > It's messy too,
> > the complement of the memscan being that "i < 7" loop over in
> > ext2_try_to_allocate. I think this ought to be cleaned up,
> > in ext2+reservations and ext3 and ext4.
> >
> The "i<7" loop there is for non reservation case. Since
> find_next_usable_block() could find a free byte, it's trying to avoid
> filesystem holes by shifting the start of the free block for at most 7
> times.
Yes, the "i<7" loop rightly has a !my_rsv check; my point it that it's
the "other end" of the memscan, which was operating 8-bits at a time,
which lacks any my_rsv check (doesn't even know my_rsv at that level).
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [PATCH 1/6] ext2 balloc: fix _with_rsv freeze
2006-11-28 20:07 ` Hugh Dickins
@ 2006-11-29 0:42 ` Mingming Cao
0 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 0:42 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 20:07 +0000, Hugh Dickins wrote:
> On Tue, 28 Nov 2006, Mingming Cao wrote:
> > On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> > > After several days of testing ext2 with reservations, it got caught inside
> > > ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding
> > > on the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to
> > > find the free block guaranteed to be included (unless there's contention).
> > >
> >
> > Hmm, I suspect there is other issue: alloc_new_reservation should not
> > repeatedly allocating the same window, if ext2_try_to_allocate
> > repeatedly fails to find a free block in that window.
> > find_next_reservable_window() takes my_rsv (the old window that he
> > thinks there is no free block) as a guide to find a window "after" the
> > end block of my_rsv, so how could this happen?
>
> Hmmm. I haven't studied that part of the code, but what you say sounds
> sensible: that would leave more to be explained, yes. I guess it would
> happen if all the rest of the bitmap were either allocated or reserved,
But bitmap_search_next_usable_block() will fail in the case the rest of
bitmap were allocated, and find_next_reservable_space() will fail in the
case the rest of group were all reserved. alloc_new_reservation() should
not create a new window in this case.
> but I don't believe that was the case here: I have noted that the map
> was all 00s from offset 0x1ae onwards, plenty unallocated; I've not
> recorded the following reservations, but it seems unlikely they covered
> the remaining free area (and still covered it even when the remaining
> tasks got to the point of just waiting for this one).
>
> >
> > > Fix the range to find_next_usable_block's memscan: the scan from "here"
> > > (0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes
> > > not 2 (the relevant bytes of bitmap in this case being f7 df ff - none
> > > 00, but the premature cutoff implying that the last was found 00).
> > >
> >
> > alloc_new_reservation() reserved a window with free block, when come to
> > the time to claim it, it scans the window again. So it seems that the
> > range of the the scan is too small:
>
> The range of the scan is 1 byte too small in this case, yes.
>
> >
> > p = ((char *)bh->b_data) + (here >> 3);
> > r = memscan(p, 0, (maxblocks - here + 7) >> 3);
> > next = (r - ((char *)bh->b_data)) << 3;
> >
> > ---------------------> next is -1
>
> I don't understand you: next was not -1, it was 0xd08.
>
> > if (next < maxblocks && next >= here)
> > return next;
> >
> > ----------------------> falls to false branch
>
> No, it passed the "next < maxblocks && next >= here" test
> (maxblocks being 0xd0e and here being 0xcfe), so returned
> pointing to an allocated block - then the caller finds it
> cannot set the bit.
>
Apologies for the confusion. I thought ext2_try_to_allocate() failed
because we could not find a free block in the reserved window (i.e.,
find_next_usable_block() failed)
It seems in this case, find_next_usable_block() incorrectly returns a
bit it *thinks* free, but ext2_try_to_allocate() fails to claim it as
it's being marked as used.
So yes, Acked this fix. Thanks.
> >
> > here = bitmap_search_next_usable_block(here, bh, maxblocks);
> > return here;
> >
> > So we failed to find a free byte in the range. That's seems fine to me.
> > It's only a nice thing to have -- try to allocate a block in a place
> > where it's neighbors are all free also. If it fails, it will search the
> > window bit by bit. So I don't understand why it is not being recovered
> > by bitmap_search_next_usable_block(), which test the bitmap bit by bit?
>
> It already returned, it doesn't reach that line.
>
Yep.
> >
> > > Is this a problem for mainline ext2? No, because the "size" in its memscan
> > > is always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a
> > > multiple of 8. Is this a problem for ext3 or ext4? No, because they have
> > > an additional extN_test_allocatable test which rescues them from the error.
> > >
> > Hmm, if the error is it prematurely think there is no free block in the
> > range (bitmap on disk), then even in ext3/4, it will not bother checking
> > the jbd copy of the bitmap. I am not sure this is the cause that ext3/4
> > may not has the problem.
>
> In the ext3/4 case, it indeed won't bother to check the jbd copy
> (having found this bitmap bit set), it'll fall through to the
> bitmap_search_next_usable_block you indicated above,
> and that should do the right thing, finding the first
> free bit in the area originally reserved.
>
Make sense.
> >
> > > But the bigger question is, why does the my_rsv case come here to
> > > find_next_usable_block at all?
> >
> > Because grp_goal is -1?
>
> Well, yes, but my point is that we've got a reservation, and we're
> hoping to allocate from it (even though we've given up on the "goal"),
> but find_next_usable_block is not respecting it at all - liable to be
> allocating out of others' reservations instead.
>
Okay got your points. I think you are right.:) Well, right now the
window is just a (start,end) pair which pointing to a range that nobody
has reserved, that doesn't include the information about which block is
free even though we did scan the bitmap making sure there is a free
block. So when alloc_new_reservation() successfully create a new
window, so we still relies on find_next_usable() to check for which free
block to use.
It does seem redundant in the reservation case. We could adjust the new
created window start block to the first free block returned from
bitmap_search_next_usable_block(), so that the information of first free
block in the window got passed to ext2_try_to_allocate().
> >
> > > Doesn't its 64-bit boundary limit, and its
> > > memscan, blithely ignore what the reservation prepared?
> >
> > I agree with you that the double check is urgly. But it's necessary:( If
> > there to prevent contention: other file make steal that free block we
> > reserved for this file, in the case filesystem is full of reservation...
>
> I agree it's necessary to recheck the allocation; I disagree that the
> 64-bit boundary limit and memscan are appropriate when my_rsv is set.
>
Okay, I understand your points now:) Quite reasonable. I have the
similar doubts when I first touch this code when implement reservation
code. it's all about allocation policy. Looking at the
ext2_try_to_allocate(), it's the core of ext2/3 block allocation
strategy:
1) if there are some free block near by the goal block(64 bit boundary
limit), then take that block (locality)
2) otherwise, try to place a new block in a contiguous chunk of free
block(memscan for a free byte), so file could be less fragmented
3) otherwise, any free block in the given range of bitmap will work.
The same policy applies to both reservation and non reservation: goal
guided first, then searching for free chunk. the In the following
example, reservation window is (16,39), goal is block 32, blocks 17,
24-31, and 33 are free. Which block should it allocate?
|------------------------------------------------|
|1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 0 1 1 1 1 1 1 |
|------------------------------------------------|
16 24 32 40
In the current code with 64bit boundary limit, it will try to satisfy
locality so block #33 will be allocated. If we skip the 64bit boundary
limit and and memscan, it will go directly pick up block #17, seems less
optimized.
> >
> > > It's messy too,
> > > the complement of the memscan being that "i < 7" loop over in
> > > ext2_try_to_allocate. I think this ought to be cleaned up,
> > > in ext2+reservations and ext3 and ext4.
> > >
> > The "i<7" loop there is for non reservation case. Since
> > find_next_usable_block() could find a free byte, it's trying to avoid
> > filesystem holes by shifting the start of the free block for at most 7
> > times.
>
> Yes, the "i<7" loop rightly has a !my_rsv check; my point it that it's
> the "other end" of the memscan, which was operating 8-bits at a time,
> which lacks any my_rsv check (doesn't even know my_rsv at that level).
>
To me memscan still make sense for reservation case. In above example,
if block #33 is also allocated, since there is no free block nearby
(right side) the goal block, it probably better to allocate block #24,
so that the next allocation will be contiguous if application is doing
sequential allocation.
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 6/12] ext2 balloc: fix _with_rsv freeze
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
2006-11-28 19:26 ` Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:15 ` [PATCH 12/12] ext3 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
Sync up a reservation fix from ext2 in ext3
------------------------------------------------------
Subject: ext2 balloc: fix _with_rsv freeze
From: Hugh Dickins <hugh@veritas.com>
After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on
the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the
free block guaranteed to be included (unless there's contention).
Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes not 2
(the relevant bytes of bitmap in this case being f7 df ff - none 00, but the
premature cutoff implying that the last was found 00).
Is this a problem for mainline ext2? No, because the "size" in its memscan is
always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of
8. Is this a problem for ext3 or ext4? No, because they have an additional
extN_test_allocatable test which rescues them from the error.
--------------------------------------------------
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-fix-_with_rsv-freeze fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-_with_rsv-freeze 2006-11-28 19:36:55.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:55.000000000 -0800
@@ -730,7 +730,7 @@ find_next_usable_block(ext3_grpblk_t sta
here = 0;
p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3) - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;
if (next < maxblocks && next >= start && ext3_test_allocatable(next, bh))
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 12/12] ext3 balloc: fix _with_rsv freeze
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
2006-11-28 19:26 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 6/12] " Mingming Cao
@ 2006-11-29 4:15 ` Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:15 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: fix _with_rsv freeze
From: Hugh Dickins <hugh@veritas.com>
After several days of testing ext2 with reservations, it got caught inside
ext2_try_to_allocate_with_rsv: alloc_new_reservation repeatedly succeeding on
the window [12cff,12d0e], ext2_try_to_allocate repeatedly failing to find the
free block guaranteed to be included (unless there's contention).
Fix the range to find_next_usable_block's memscan: the scan from "here"
(0xcfe) up to (but excluding) "maxblocks" (0xd0e) needs to scan 3 bytes not 2
(the relevant bytes of bitmap in this case being f7 df ff - none 00, but the
premature cutoff implying that the last was found 00).
Is this a problem for mainline ext2? No, because the "size" in its memscan is
always EXT2_BLOCKS_PER_GROUP(sb), which mkfs.ext2 requires to be a multiple of
8. Is this a problem for ext3 or ext4? No, because they have an additional
extN_test_allocatable test which rescues them from the error.
--------------------------------------------------
Sync up a reservation fix from ext2 in ext4
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-_with_rsv-freeze 2006-11-28 19:37:12.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:12.000000000 -0800
@@ -747,7 +747,7 @@ find_next_usable_block(ext4_grpblk_t sta
here = 0;
p = ((char *)bh->b_data) + (here >> 3);
- r = memscan(p, 0, (maxblocks - here + 7) >> 3);
+ r = memscan(p, 0, ((maxblocks + 7) >> 3 - (here >> 3));
next = (r - ((char *)bh->b_data)) << 3;
if (next < maxblocks && next >= start && ext4_test_allocatable(next, bh))
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 2/6] ext2 balloc: reset windowsz when full
2006-11-28 17:38 ` Hugh Dickins
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
@ 2006-11-28 17:40 ` Hugh Dickins
2006-11-28 19:36 ` Mingming Cao
` (2 more replies)
2006-11-28 17:41 ` [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end Hugh Dickins
` (4 subsequent siblings)
6 siblings, 3 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:40 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/ext2/balloc.c | 1 +
1 file changed, 1 insertion(+)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1292,6 +1292,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 2/6] ext2 balloc: reset windowsz when full
2006-11-28 17:40 ` [PATCH 2/6] ext2 balloc: reset windowsz when full Hugh Dickins
@ 2006-11-28 19:36 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 2/12] ext3 balloc: fix off-by-one against grp_goal Mingming Cao
2006-11-29 4:15 ` [PATCH 8/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 19:36 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:40 +0000, Hugh Dickins wrote:
> ext2_new_blocks should reset the reservation window size to 0 when squeezing
> the last blocks out of an almost full filesystem, so the retry doesn't skip
> any groups with less than half that free, reporting ENOSPC too soon.
>
I realize this is a bug when I was looking at the code as well. I was
thinking we should not check for whether the window size is less than
the free blocks counter at all, when the allocation is fall back to non
reservation allocation. But your fix works as well.
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 2/12] ext3 balloc: fix off-by-one against grp_goal
2006-11-28 17:40 ` [PATCH 2/6] ext2 balloc: reset windowsz when full Hugh Dickins
2006-11-28 19:36 ` Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:15 ` [PATCH 8/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against grp_goal
From: Hugh Dickins <hugh@veritas.com>
grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv
should treat it as such.
------------------------------------------------------
Sync up with ext2 reservation fix in ext3
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-grp_goal 2006-11-28 19:36:48.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:48.000000000 -0800
@@ -1271,7 +1271,7 @@ ext3_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT3_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT3_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1307,7 +1307,7 @@ ext3_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;
_
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 8/12] ext4 balloc: fix off-by-one against grp_goal
2006-11-28 17:40 ` [PATCH 2/6] ext2 balloc: reset windowsz when full Hugh Dickins
2006-11-28 19:36 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 2/12] ext3 balloc: fix off-by-one against grp_goal Mingming Cao
@ 2006-11-29 4:15 ` Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:15 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
Subject: ext2 balloc: fix off-by-one against grp_goal
From: Hugh Dickins <hugh@veritas.com>
grp_goal 0 is a genuine goal (unlike -1), so ext2_try_to_allocate_with_rsv
should treat it as such.
------------------------------------------------------
Sync up with ext2 reservation fix in ext4
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-grp_goal fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-grp_goal 2006-11-28 19:37:05.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:05.000000000 -0800
@@ -1288,7 +1288,7 @@ ext4_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT4_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT4_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1324,7 +1324,7 @@ ext4_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end
2006-11-28 17:38 ` Hugh Dickins
2006-11-28 17:40 ` [PATCH 1/6] ext2 balloc: fix _with_rsv freeze Hugh Dickins
2006-11-28 17:40 ` [PATCH 2/6] ext2 balloc: reset windowsz when full Hugh Dickins
@ 2006-11-28 17:41 ` Hugh Dickins
2006-11-28 19:42 ` Mingming Cao
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
` (3 subsequent siblings)
6 siblings, 1 reply; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:41 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
rsv_end is the last block within the reservation,
so alloc_new_reservation should accept start_block == rsv_end as success.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/ext2/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -950,7 +950,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end
2006-11-28 17:41 ` [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end Hugh Dickins
@ 2006-11-28 19:42 ` Mingming Cao
0 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 19:42 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:41 +0000, Hugh Dickins wrote:
> rsv_end is the last block within the reservation,
> so alloc_new_reservation should accept start_block == rsv_end as success.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
Thanks, Acked.
This is not a problem for now, as the default window size is 8 blocks,
and we never shrink the window size. But it could be a issue in the
future, if the reservation window could be dynamically shrink, when it
keep failing to create a new(large) reservation window, or we keep throw
away a just-allocated-window as the application is doing very seeky
random write.
> fs/ext2/balloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -950,7 +950,7 @@ retry:
> * check if the first free block is within the
> * free space we just reserved
> */
> - if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
> + if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
> return 0; /* success */
> /*
> * if the first free bit we found is out of the reservable space
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal
2006-11-28 17:38 ` Hugh Dickins
` (2 preceding siblings ...)
2006-11-28 17:41 ` [PATCH 3/6] ext2 balloc: fix off-by-one against rsv_end Hugh Dickins
@ 2006-11-28 17:42 ` Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
` (4 more replies)
2006-11-28 17:43 ` [PATCH 5/6] ext2 balloc: say rb_entry not list_entry Hugh Dickins
` (2 subsequent siblings)
6 siblings, 5 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:42 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
grp_goal 0 is a genuine goal (unlike -1),
so ext2_try_to_allocate_with_rsv should treat it as such.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/ext2/balloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
}
/*
* grp_goal is a group relative block number (if there is a goal)
- * 0 < grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
+ * 0 <= grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
* first block is a filesystem wide block number
* first block is the block number of the first block in this group
*/
@@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
if (!goal_in_my_reservation(&my_rsv->rsv_window,
grp_goal, group, sb))
grp_goal = -1;
- } else if (grp_goal > 0) {
+ } else if (grp_goal >= 0) {
int curr = my_rsv->rsv_end -
(grp_goal + group_first_block) + 1;
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
@ 2006-11-28 23:30 ` Mingming Cao
2006-11-29 4:13 ` [PATCH 1/12] ext3 balloc: reset windowsz when full Mingming Cao
` (3 subsequent siblings)
4 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 23:30 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:42 +0000, Hugh Dickins wrote:
> grp_goal 0 is a genuine goal (unlike -1),
> so ext2_try_to_allocate_with_rsv should treat it as such.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked.
Thanks,
Mingming
> ---
>
> fs/ext2/balloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -1053,7 +1053,7 @@ ext2_try_to_allocate_with_rsv(struct sup
> }
> /*
> * grp_goal is a group relative block number (if there is a goal)
> - * 0 < grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
> + * 0 <= grp_goal < EXT2_BLOCKS_PER_GROUP(sb)
> * first block is a filesystem wide block number
> * first block is the block number of the first block in this group
> */
> @@ -1089,7 +1089,7 @@ ext2_try_to_allocate_with_rsv(struct sup
> if (!goal_in_my_reservation(&my_rsv->rsv_window,
> grp_goal, group, sb))
> grp_goal = -1;
> - } else if (grp_goal > 0) {
> + } else if (grp_goal >= 0) {
> int curr = my_rsv->rsv_end -
> (grp_goal + group_first_block) + 1;
>
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 1/12] ext3 balloc: reset windowsz when full
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
@ 2006-11-29 4:13 ` Mingming Cao
2006-11-29 5:46 ` Hugh Dickins
2006-11-29 4:14 ` [PATCH 3/12] ext3 balloc: fix off-by-one against rsv_end Mingming Cao
` (2 subsequent siblings)
4 siblings, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:13 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
patches are against ext3, and the rest are aginst ext4.
------------------------------------------------------
Subject: ext2 balloc: reset windowsz when full
From: Hugh Dickins <hugh@veritas.com>
ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.
------------------------------------------------------
Sync up reservation fix from ext2
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3_reset_windowsz_in_full_fs 2006-11-28 19:36:41.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:41.000000000 -0800
@@ -1552,6 +1552,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}
_
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 1/12] ext3 balloc: reset windowsz when full
2006-11-29 4:13 ` [PATCH 1/12] ext3 balloc: reset windowsz when full Mingming Cao
@ 2006-11-29 5:46 ` Hugh Dickins
0 siblings, 0 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-29 5:46 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 28 Nov 2006, Mingming Cao wrote:
> Port a series ext2 balloc patches from Hugh to ext3/4. The first 6
> patches are against ext3, and the rest are aginst ext4.
Thanks for all that, Mingming:
whichever is appropriate, all twelve
Acked-by: Hugh Dickins <hugh@veritas.com>
or
Signed-off-by: Hugh Dickins <hugh@veritas.com>
I'll think about your other mails, those that need further thought,
later on: I need to pin down more accurately the repetitious sequence of
reservations in the mistaken case - maybe it indicated further issues,
maybe not; and I need to consider our different views of the my_rsv
find_next_usable_block.
Hugh
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 3/12] ext3 balloc: fix off-by-one against rsv_end
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
2006-11-29 4:13 ` [PATCH 1/12] ext3 balloc: reset windowsz when full Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 7/12] ext4 balloc: reset windowsz when full Mingming Cao
2006-11-29 4:15 ` [PATCH 9/12] ext4 balloc: fix off-by-one against rsv_end Mingming Cao
4 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against rsv_end
From: Hugh Dickins <hugh@veritas.com>
rsv_end is the last block within the reservation, so alloc_new_reservation
should accept start_block == rsv_end as success.
------------------------------------------------------
Sync up a ext2 reservation fix in ext3
Signed-Off-By: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-rsv_end fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-fix-off-by-one-against-rsv_end 2006-11-28 19:36:58.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:58.000000000 -0800
@@ -1148,7 +1148,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 7/12] ext4 balloc: reset windowsz when full
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
` (2 preceding siblings ...)
2006-11-29 4:14 ` [PATCH 3/12] ext3 balloc: fix off-by-one against rsv_end Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:15 ` [PATCH 9/12] ext4 balloc: fix off-by-one against rsv_end Mingming Cao
4 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: reset windowsz when full
From: Hugh Dickins <hugh@veritas.com>
ext2_new_blocks should reset the reservation window size to 0 when squeezing
the last blocks out of an almost full filesystem, so the retry doesn't skip
any groups with less than half that free, reporting ENOSPC too soon.
------------------------------------------------------
Sync up reservation fix from ext2 in ext4
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/ext4/balloc.c~ext4_reset_windowsz_in_full_fs fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4_reset_windowsz_in_full_fs 2006-11-28 19:37:01.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:01.000000000 -0800
@@ -1566,6 +1566,7 @@ retry_alloc:
*/
if (my_rsv) {
my_rsv = NULL;
+ windowsz = 0;
group_no = goal_group;
goto retry_alloc;
}
_
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 9/12] ext4 balloc: fix off-by-one against rsv_end
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
` (3 preceding siblings ...)
2006-11-29 4:14 ` [PATCH 7/12] ext4 balloc: reset windowsz when full Mingming Cao
@ 2006-11-29 4:15 ` Mingming Cao
4 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:15 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: fix off-by-one against rsv_end
From: Hugh Dickins <hugh@veritas.com>
rsv_end is the last block within the reservation, so alloc_new_reservation
should accept start_block == rsv_end as success.
------------------------------------------------------
Sync up a ext2 reservation fix in ext4
Signed-Off-By: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-rsv_end fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-fix-off-by-one-against-rsv_end 2006-11-28 19:37:15.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:15.000000000 -0800
@@ -1165,7 +1165,7 @@ retry:
* check if the first free block is within the
* free space we just reserved
*/
- if (start_block >= my_rsv->rsv_start && start_block < my_rsv->rsv_end)
+ if (start_block >= my_rsv->rsv_start && start_block <= my_rsv->rsv_end)
return 0; /* success */
/*
* if the first free bit we found is out of the reservable space
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 5/6] ext2 balloc: say rb_entry not list_entry
2006-11-28 17:38 ` Hugh Dickins
` (3 preceding siblings ...)
2006-11-28 17:42 ` [PATCH 4/6] ext2 balloc: fix off-by-one against grp_goal Hugh Dickins
@ 2006-11-28 17:43 ` Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
` (2 more replies)
2006-11-28 17:44 ` [PATCH 6/6] ext2 balloc: use io_error label Hugh Dickins
2006-11-28 21:04 ` Boot failure with ext2 and initrds Mingming Cao
6 siblings, 3 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:43 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
The reservations tree is an rb_tree not a list, so it's less confusing to
use rb_entry() than list_entry() - though they're both just container_of().
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/ext2/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -156,7 +156,7 @@ restart:
printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext2_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext2_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %lu, end: %lu\n",
@@ -753,7 +753,7 @@ static int find_next_reservable_window(
prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext2_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext2_reserve_window_node,rsv_node);
/*
* Reached the last reservation, we can just append to the
@@ -995,7 +995,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext2_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext2_reserve_window_node, rsv_node);
if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 5/6] ext2 balloc: say rb_entry not list_entry
2006-11-28 17:43 ` [PATCH 5/6] ext2 balloc: say rb_entry not list_entry Hugh Dickins
@ 2006-11-28 23:30 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 4/12] ext3 " Mingming Cao
2006-11-29 4:15 ` [PATCH 10/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 23:30 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:43 +0000, Hugh Dickins wrote:
> The reservations tree is an rb_tree not a list, so it's less confusing to
> use rb_entry() than list_entry() - though they're both just container_of().
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
Acked.
Thanks,
Mingming
> fs/ext2/balloc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -156,7 +156,7 @@ restart:
>
> printk("Block Allocation Reservation Windows Map (%s):\n", fn);
> while (n) {
> - rsv = list_entry(n, struct ext2_reserve_window_node, rsv_node);
> + rsv = rb_entry(n, struct ext2_reserve_window_node, rsv_node);
> if (verbose)
> printk("reservation window 0x%p "
> "start: %lu, end: %lu\n",
> @@ -753,7 +753,7 @@ static int find_next_reservable_window(
>
> prev = rsv;
> next = rb_next(&rsv->rsv_node);
> - rsv = list_entry(next,struct ext2_reserve_window_node,rsv_node);
> + rsv = rb_entry(next,struct ext2_reserve_window_node,rsv_node);
>
> /*
> * Reached the last reservation, we can just append to the
> @@ -995,7 +995,7 @@ static void try_to_extend_reservation(st
> if (!next)
> my_rsv->rsv_end += size;
> else {
> - next_rsv = list_entry(next, struct ext2_reserve_window_node, rsv_node);
> + next_rsv = rb_entry(next, struct ext2_reserve_window_node, rsv_node);
>
> if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
> my_rsv->rsv_end += size;
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 4/12] ext3 balloc: say rb_entry not list_entry
2006-11-28 17:43 ` [PATCH 5/6] ext2 balloc: say rb_entry not list_entry Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:15 ` [PATCH 10/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: say rb_entry not list_entry
From: Hugh Dickins <hugh@veritas.com>
The reservations tree is an rb_tree not a list, so it's less confusing to use
rb_entry() than list_entry() - though they're both just container_of().
----------------------------------------------------------
Sync up this fix in ext3
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-say-rb_entry-not-list_entry fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-say-rb_entry-not-list_entry 2006-11-28 19:36:52.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:36:52.000000000 -0800
@@ -144,7 +144,7 @@ restart:
printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext3_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext3_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %lu, end: %lu\n",
@@ -949,7 +949,7 @@ static int find_next_reservable_window(
prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext3_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext3_reserve_window_node,rsv_node);
/*
* Reached the last reservation, we can just append to the
@@ -1193,7 +1193,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext3_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext3_reserve_window_node, rsv_node);
if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;
_
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 10/12] ext4 balloc: say rb_entry not list_entry
2006-11-28 17:43 ` [PATCH 5/6] ext2 balloc: say rb_entry not list_entry Hugh Dickins
2006-11-28 23:30 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 4/12] ext3 " Mingming Cao
@ 2006-11-29 4:15 ` Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:15 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: say rb_entry not list_entry
From: Hugh Dickins <hugh@veritas.com>
The reservations tree is an rb_tree not a list, so it's less confusing to use
rb_entry() than list_entry() - though they're both just container_of().
----------------------------------------------------------
Sync up this fix in ext4
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN fs/ext4/balloc.c~ext4-balloc-say-rb_entry-not-list_entry fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-say-rb_entry-not-list_entry 2006-11-28 19:37:08.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:37:08.000000000 -0800
@@ -165,7 +165,7 @@ restart:
printk("Block Allocation Reservation Windows Map (%s):\n", fn);
while (n) {
- rsv = list_entry(n, struct ext4_reserve_window_node, rsv_node);
+ rsv = rb_entry(n, struct ext4_reserve_window_node, rsv_node);
if (verbose)
printk("reservation window 0x%p "
"start: %llu, end: %llu\n",
@@ -966,7 +966,7 @@ static int find_next_reservable_window(
prev = rsv;
next = rb_next(&rsv->rsv_node);
- rsv = list_entry(next,struct ext4_reserve_window_node,rsv_node);
+ rsv = rb_entry(next,struct ext4_reserve_window_node,rsv_node);
/*
* Reached the last reservation, we can just append to the
@@ -1210,7 +1210,7 @@ static void try_to_extend_reservation(st
if (!next)
my_rsv->rsv_end += size;
else {
- next_rsv = list_entry(next, struct ext4_reserve_window_node, rsv_node);
+ next_rsv = rb_entry(next, struct ext4_reserve_window_node, rsv_node);
if ((next_rsv->rsv_start - my_rsv->rsv_end - 1) >= size)
my_rsv->rsv_end += size;
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH 6/6] ext2 balloc: use io_error label
2006-11-28 17:38 ` Hugh Dickins
` (4 preceding siblings ...)
2006-11-28 17:43 ` [PATCH 5/6] ext2 balloc: say rb_entry not list_entry Hugh Dickins
@ 2006-11-28 17:44 ` Hugh Dickins
2006-11-28 23:31 ` Mingming Cao
` (2 more replies)
2006-11-28 21:04 ` Boot failure with ext2 and initrds Mingming Cao
6 siblings, 3 replies; 204+ messages in thread
From: Hugh Dickins @ 2006-11-28 17:44 UTC (permalink / raw)
To: Mingming Cao
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
ext2_new_blocks has a nice io_error label for setting -EIO,
so goto that in the one place that doesn't already use it.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/ext2/balloc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
+++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
@@ -1258,10 +1258,9 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext2_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
+
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [PATCH 6/6] ext2 balloc: use io_error label
2006-11-28 17:44 ` [PATCH 6/6] ext2 balloc: use io_error label Hugh Dickins
@ 2006-11-28 23:31 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 5/12] ext3 " Mingming Cao
2006-11-29 4:15 ` [PATCH 11/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 23:31 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:44 +0000, Hugh Dickins wrote:
> ext2_new_blocks has a nice io_error label for setting -EIO,
> so goto that in the one place that doesn't already use it.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
Acked,
Mingming
> fs/ext2/balloc.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> --- 2.6.19-rc6-mm2/fs/ext2/balloc.c 2006-11-24 08:18:02.000000000 +0000
> +++ linux/fs/ext2/balloc.c 2006-11-27 19:28:41.000000000 +0000
> @@ -1258,10 +1258,9 @@ retry_alloc:
> if (group_no >= ngroups)
> group_no = 0;
> gdp = ext2_get_group_desc(sb, group_no, &gdp_bh);
> - if (!gdp) {
> - *errp = -EIO;
> - goto out;
> - }
> + if (!gdp)
> + goto io_error;
> +
> free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
> /*
> * skip this group if the number of
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 5/12] ext3 balloc: use io_error label
2006-11-28 17:44 ` [PATCH 6/6] ext2 balloc: use io_error label Hugh Dickins
2006-11-28 23:31 ` Mingming Cao
@ 2006-11-29 4:14 ` Mingming Cao
2006-11-29 4:15 ` [PATCH 11/12] ext4 " Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:14 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: use io_error label
From: Hugh Dickins <hugh@veritas.com>
ext2_new_blocks has a nice io_error label for setting -EIO, so goto that in
the one place that doesn't already use it.
------------------------------------------------------
Fix it in ext3_new_blocks.
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext3/balloc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff -puN fs/ext3/balloc.c~ext3-balloc-use-io_error-label fs/ext3/balloc.c
--- linux-2.6.19-rc5/fs/ext3/balloc.c~ext3-balloc-use-io_error-label 2006-11-28 19:45:51.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext3/balloc.c 2006-11-28 19:45:51.000000000 -0800
@@ -1515,10 +1515,8 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext3_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of
_
^ permalink raw reply [flat|nested] 204+ messages in thread* [PATCH 11/12] ext4 balloc: use io_error label
2006-11-28 17:44 ` [PATCH 6/6] ext2 balloc: use io_error label Hugh Dickins
2006-11-28 23:31 ` Mingming Cao
2006-11-29 4:14 ` [PATCH 5/12] ext3 " Mingming Cao
@ 2006-11-29 4:15 ` Mingming Cao
2 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-29 4:15 UTC (permalink / raw)
To: Andrew Morton, Hugh Dickins
Cc: Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
------------------------------------------------------
Subject: ext2 balloc: use io_error label
From: Hugh Dickins <hugh@veritas.com>
ext2_new_blocks has a nice io_error label for setting -EIO, so goto that in
the one place that doesn't already use it.
------------------------------------------------------
Fix it in ext4_new_blocks.
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
---
linux-2.6.19-rc5-cmm/fs/ext4/balloc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff -puN fs/ext4/balloc.c~ext4-balloc-use-io_error-label fs/ext4/balloc.c
--- linux-2.6.19-rc5/fs/ext4/balloc.c~ext4-balloc-use-io_error-label 2006-11-28 19:42:45.000000000 -0800
+++ linux-2.6.19-rc5-cmm/fs/ext4/balloc.c 2006-11-28 19:43:21.000000000 -0800
@@ -1529,10 +1529,8 @@ retry_alloc:
if (group_no >= ngroups)
group_no = 0;
gdp = ext4_get_group_desc(sb, group_no, &gdp_bh);
- if (!gdp) {
- *errp = -EIO;
- goto out;
- }
+ if (!gdp)
+ goto io_error;
free_blocks = le16_to_cpu(gdp->bg_free_blocks_count);
/*
* skip this group if the number of
_
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-28 17:38 ` Hugh Dickins
` (5 preceding siblings ...)
2006-11-28 17:44 ` [PATCH 6/6] ext2 balloc: use io_error label Hugh Dickins
@ 2006-11-28 21:04 ` Mingming Cao
2006-11-28 22:33 ` Andrew Morton
6 siblings, 1 reply; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 21:04 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 17:38 +0000, Hugh Dickins wrote:
> >
> > And could you check the start and end block for every rsv_window_add and
> > rsv_window_remove, to see if it was keep creating and removing the same
> > window in the same block group?
>
> The same every time it settled on a usable reservation, but a lot of
> wasted adds and removes as it works across a fully allocated area of
> the bitmap. Not very efficient, all those rb_tree insertions and
> removals until it gets to a free area; but I can't judge from this
> example how common that would be, may not be worth bothering about.
>
Yeah, it's not so efficient to add a window before knowing it has a free
block, as rb tree insertion is quit expensive. Actually it used to be
this way: only insert a window to the rb tree when there is a free bit
inside of it. However we need to hold the per-fs reservation lock while
scanning the bitmap:( This badly hurt the performance in some case and
the real time folks complained about it.
So we changed the code to the current way. I think it was not that
inefficient in the case it works across a fully allocated/reserved area,
since bitmap_search_next_usable_block() will skip the fully allocated
area fairly quickly, as it searchs from the beginning of the window till
the last block of the block group (not just the end of the window)
> >
> > And it might be useful to dump the whole filesystem block reservation
> > tree as well.
>
> Not necessary, I've put just the relevant numbers in the patch comment,
> it helped me a lot to see the actual numbers and work it out from there.
>
> >
> > Not sure if it worth the effort to test it on ext3. The ext2 block
> > reservation code in 2.6.19-rc5-mm2 looks pretty much the same as ext3/4,
> > except the missing truncate_mutex. I understand this might take a few
> > days to reproduce, so this might not needed now.
>
> Turns out vanilla-ext2 and ext3 and ext4 are safe:
> ext3 and ext4 slightly wrong in the same way, but safe.
>
Good to know.
> I'll continue this thread with the bugfix patch 1/6; and five more
> (roughly descending order of importance, the latter just cosmetic)
> little fs/ext2/balloc.c patches to things I noticed on the way.
> Nothing very worrying. Easier to send patches than ask questions:
> please check, perhaps my "off-by-one" accusations are wrong, for
> example. If you're satisfied they're right, please apply the
> same to ext3 and ext4.
>
Thanks, I have acked most of them, and will port them to ext3/4 soon.
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-28 21:04 ` Boot failure with ext2 and initrds Mingming Cao
@ 2006-11-28 22:33 ` Andrew Morton
2006-11-28 23:38 ` Mingming Cao
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-28 22:33 UTC (permalink / raw)
To: cmm
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 28 Nov 2006 13:04:53 -0800
Mingming Cao <cmm@us.ibm.com> wrote:
> Thanks, I have acked most of them, and will port them to ext3/4 soon.
You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
unclear?
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-28 22:33 ` Andrew Morton
@ 2006-11-28 23:38 ` Mingming Cao
0 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-28 23:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel,
linux-ext4@vger.kernel.org
On Tue, 2006-11-28 at 14:33 -0800, Andrew Morton wrote:
> On Tue, 28 Nov 2006 13:04:53 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
>
> > Thanks, I have acked most of them, and will port them to ext3/4 soon.
>
> You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
> unclear?
sorry, just acked #4, #5 and #6. I mean to do that before I said so but
they did not go out of my outbox till now ( I was out for a few hours).
#1 looks correct to me now, just thought there are other issues. I will
comment on that one in that thread.
Mingming
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-16 7:22 ` Andrew Morton
2006-11-16 8:49 ` Mingming Cao
@ 2006-11-16 12:34 ` Russell King
2006-11-25 14:59 ` Russell King
1 sibling, 1 reply; 204+ messages in thread
From: Russell King @ 2006-11-16 12:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Mingming Cao, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > _size_ of the range to search instead...
> >
> > Something like this: (this is not a patch)
> > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > ext2_grpblk_t next;
> >
> > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > if (next >= maxblocks)
> > return -1;
> > return next;
> > }
>
> yes, the `size' arg to find_next_zero_bit() represents the number of bits
> to scan at `offset'.
Are you sure? That's not the way it's implemented in many architectures.
find_next_*_bit() has always taken "address, maximum offset, starting offset"
and always has returned "next offset".
Just look at arch/i386/lib/bitops.c:
int find_next_zero_bit(const unsigned long *addr, int size, int offset)
{
unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
int set = 0, bit = offset & 31, res;
...
/*
* No zero yet, search remaining full bytes for a zero
*/
res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
return (offset + set + res);
}
So for the case that "offset" is aligned to a "long" boundary, that gives us:
res = find_first_zero_bit(addr + (offset>>5),
size - 32 * (addr + (offset>>5) - addr));
or:
res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
So, size _excludes_ offset.
Now, considering the return value, "res" above will be relative to
"addr + (offset>>5)". However, we add "offset" on to that, so it's
relative to addr + (offset bits).
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-16 12:34 ` Russell King
@ 2006-11-25 14:59 ` Russell King
2006-11-29 7:40 ` Russell King
0 siblings, 1 reply; 204+ messages in thread
From: Russell King @ 2006-11-25 14:59 UTC (permalink / raw)
To: Andrew Morton, Mingming Cao, Hugh Dickins, Mel Gorman,
Martin J. Bligh, linux-kernel, linux-ext4@vger.kernel.org
On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > number of the range to search, not the lengh of the range. maxblocks
> > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > _size_ of the range to search instead...
> > >
> > > Something like this: (this is not a patch)
> > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > ext2_grpblk_t next;
> > >
> > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > if (next >= maxblocks)
> > > return -1;
> > > return next;
> > > }
> >
> > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > to scan at `offset'.
>
> Are you sure? That's not the way it's implemented in many architectures.
> find_next_*_bit() has always taken "address, maximum offset, starting offset"
> and always has returned "next offset".
>
> Just look at arch/i386/lib/bitops.c:
>
> int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> {
> unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
> int set = 0, bit = offset & 31, res;
> ...
> /*
> * No zero yet, search remaining full bytes for a zero
> */
> res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
> return (offset + set + res);
> }
>
> So for the case that "offset" is aligned to a "long" boundary, that gives us:
>
> res = find_first_zero_bit(addr + (offset>>5),
> size - 32 * (addr + (offset>>5) - addr));
>
> or:
>
> res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
>
> So, size _excludes_ offset.
>
> Now, considering the return value, "res" above will be relative to
> "addr + (offset>>5)". However, we add "offset" on to that, so it's
> relative to addr + (offset bits).
Andrew,
Please respond to the above. If what you say is correct then all
architectures need their bitops fixing to fit ext2's requirements.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-25 14:59 ` Russell King
@ 2006-11-29 7:40 ` Russell King
2006-11-29 8:30 ` Andrew Morton
0 siblings, 1 reply; 204+ messages in thread
From: Russell King @ 2006-11-29 7:40 UTC (permalink / raw)
To: Andrew Morton, Mingming Cao, Hugh Dickins, Mel Gorman,
Martin J. Bligh, linux-kernel, linux-ext4@vger.kernel.org
Yet another attempt to get a response from Andrew. It is rather
important that you DO respond to this.
On Sat, Nov 25, 2006 at 02:59:16PM +0000, Russell King wrote:
> On Thu, Nov 16, 2006 at 12:34:48PM +0000, Russell King wrote:
> > On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <cmm@us.ibm.com> wrote:
> > >
> > > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > > > number of the range to search, not the lengh of the range. maxblocks
> > > > get passed to ext2_find_next_zero_bit(), where it expecting to take the
> > > > _size_ of the range to search instead...
> > > >
> > > > Something like this: (this is not a patch)
> > > > @@ -524,7 +524,7 @@ bitmap_search_next_usable_block(ext2_grp
> > > > ext2_grpblk_t next;
> > > >
> > > > - next = ext2_find_next_zero_bit(bh->b_data, maxblocks, start);
> > > > + next = ext2_find_next_zero_bit(bh->b_data, maxblocks-start + 1, start);
> > > > if (next >= maxblocks)
> > > > return -1;
> > > > return next;
> > > > }
> > >
> > > yes, the `size' arg to find_next_zero_bit() represents the number of bits
> > > to scan at `offset'.
> >
> > Are you sure? That's not the way it's implemented in many architectures.
> > find_next_*_bit() has always taken "address, maximum offset, starting offset"
> > and always has returned "next offset".
> >
> > Just look at arch/i386/lib/bitops.c:
> >
> > int find_next_zero_bit(const unsigned long *addr, int size, int offset)
> > {
> > unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
> > int set = 0, bit = offset & 31, res;
> > ...
> > /*
> > * No zero yet, search remaining full bytes for a zero
> > */
> > res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
> > return (offset + set + res);
> > }
> >
> > So for the case that "offset" is aligned to a "long" boundary, that gives us:
> >
> > res = find_first_zero_bit(addr + (offset>>5),
> > size - 32 * (addr + (offset>>5) - addr));
> >
> > or:
> >
> > res = find_first_zero_bit(addr + (offset>>5), size - (offset & ~31));
> >
> > So, size _excludes_ offset.
> >
> > Now, considering the return value, "res" above will be relative to
> > "addr + (offset>>5)". However, we add "offset" on to that, so it's
> > relative to addr + (offset bits).
>
> Andrew,
>
> Please respond to the above. If what you say is correct then all
> architectures need their bitops fixing to fit ext2's requirements.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
> -
> 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/
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: Boot failure with ext2 and initrds
2006-11-29 7:40 ` Russell King
@ 2006-11-29 8:30 ` Andrew Morton
2006-11-29 9:20 ` Russell King
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-29 8:30 UTC (permalink / raw)
To: Russell King
Cc: Mingming Cao, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Wed, 29 Nov 2006 07:40:00 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> Yet another attempt to get a response from Andrew. It is rather
> important that you DO respond to this.
You can read the code as easily as I can? I'm not really sure what
you're asking - I thought Mingming cleared things up.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-29 8:30 ` Andrew Morton
@ 2006-11-29 9:20 ` Russell King
2006-11-29 9:39 ` Andrew Morton
0 siblings, 1 reply; 204+ messages in thread
From: Russell King @ 2006-11-29 9:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Mingming Cao, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Wed, Nov 29, 2006 at 12:30:36AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 07:40:00 +0000
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> > Yet another attempt to get a response from Andrew. It is rather
> > important that you DO respond to this.
>
> You can read the code as easily as I can?
Sigh. Please don't cut the relevant part of my _first_ email message
where it can be clearly seen that I _have_ read the code and interpreted
it _differently_ from you.
> I'm not really sure what you're asking - I thought Mingming cleared
> things up.
Which message did this happen?
What I'm looking for is confirmation of the semantics of
find_next_zero_bit(), which is a fairly simple question to ask, and
certainly does not justify this rather obtuse and difficult thread.
<extremely frustrated>
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-29 9:20 ` Russell King
@ 2006-11-29 9:39 ` Andrew Morton
2006-11-29 18:16 ` Russell King
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-29 9:39 UTC (permalink / raw)
To: Russell King
Cc: Mingming Cao, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Wed, 29 Nov 2006 09:20:24 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> What I'm looking for is confirmation of the semantics of
> find_next_zero_bit()
What are the existing semantics? I see no documentation in any of the
architectures I've looked at. That's my point.
>From a quick read of fs/ext2/balloc.c
ext2_find_next_zero_bit(base, size, offset)
appears to expect that base is the start of the memory buffer, size is the
number of bits at *base and offset is the bit at which to start the search,
relative to base. If a zero bit is found it will return the offset of that
bit relative to base. It will return some number greater than `size' if no
zero-bit was found.
Whether that's how all the implementors interpreted it is anyone's guess.
Presumably the architectures all do roughly the same thing.
> <extremely frustrated>
Well likewise. It appears that nobody (and about 20 people have
implemented these things) could be bothered getting off ass and documenting
the pathetic thing.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-29 9:39 ` Andrew Morton
@ 2006-11-29 18:16 ` Russell King
0 siblings, 0 replies; 204+ messages in thread
From: Russell King @ 2006-11-29 18:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Mingming Cao, Hugh Dickins, Mel Gorman, Martin J. Bligh,
linux-kernel, linux-ext4@vger.kernel.org
On Wed, Nov 29, 2006 at 01:39:22AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 09:20:24 +0000
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> > What I'm looking for is confirmation of the semantics of
> > find_next_zero_bit()
>
> What are the existing semantics? I see no documentation in any of the
> architectures I've looked at. That's my point.
>
> >From a quick read of fs/ext2/balloc.c
>
> ext2_find_next_zero_bit(base, size, offset)
>
> appears to expect that base is the start of the memory buffer, size is the
> number of bits at *base and offset is the bit at which to start the search,
> relative to base. If a zero bit is found it will return the offset of that
> bit relative to base. It will return some number greater than `size' if no
> zero-bit was found.
Thank you for taking the time to agree with my analysis of x86 and
confirm that what ARM implements is also what is expected - that's
all that I was after. The reason I was after it was because you'd
said in the message I originally replied to:
| yes, the `size' arg to find_next_zero_bit() represents the number of
| bits to scan at `offset'.
which is entirely different from my understanding of what is required of
this function. Hence the confusion caused and the need to clear up
that confusion.
> Whether that's how all the implementors interpreted it is anyone's guess.
> Presumably the architectures all do roughly the same thing.
ARM does exactly the same as x86, since x86 was the only architecture
which existed in Linux when it was originally implemented.
> > <extremely frustrated>
>
> Well likewise. It appears that nobody (and about 20 people have
> implemented these things) could be bothered getting off ass and
> documenting the pathetic thing.
Back in those days it very much was "read the source, luke" and when
porting the kernel that meant the x86 code. Consider the lack of
documentation a case of just following the agreed convention at the
time.
We've since now moved on to a more mature attitude towards documentation,
and decided upon a format that it should take. So yes, it would be nice
if someone would document the entire set of kernel functions which
architectures are expected to provide. That'll probably be a full time
job for someone though, and probably needs someone to be paid to do it.
Or are the janitor folks up for it?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:31 ` Andrew Morton
2006-11-14 21:18 ` Hugh Dickins
@ 2006-11-14 21:19 ` Mel Gorman
2006-11-15 0:25 ` Andy Whitcroft
2006-11-16 9:05 ` Mingming Cao
3 siblings, 0 replies; 204+ messages in thread
From: Mel Gorman @ 2006-11-14 21:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Martin J. Bligh, Linux Kernel Mailing List
On Tue, 14 Nov 2006, Andrew Morton wrote:
> On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
>
>> On Tue, 14 Nov 2006, Mel Gorman wrote:
>>> 2.6.19-rc5-mm2
>>>
>>> Am seeing errors with systems using ext2. First machine is a plan old x86
>>> using initramfs. Console output looks like;
>>> ...
>>> Configuring network interfaces...BUG: soft lockup detected on CPU#3!
>>> ...
>>> [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
>>> [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
>>>
>>> I've not investigated yet what patches might be at fault.
>>
>> I expect you'll find it's
>> ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
>> which gets stuck in a loop there for me too: back it out and all seems fine.
>>
>> It's not obvious which part of the patch is to blame: mostly it's
>> cleanup, but a few variables do change size: I'm currently narrowing
>> down to where a fix is needed.
>>
>
> Doing s/-Wall/-W/ tends to shake out bugs in this stuff.
>
> The below might help.
>
It worked for me on the two problem machines. Thanks
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:31 ` Andrew Morton
2006-11-14 21:18 ` Hugh Dickins
2006-11-14 21:19 ` Mel Gorman
@ 2006-11-15 0:25 ` Andy Whitcroft
2006-11-15 0:58 ` Andrew Morton
2006-11-16 9:05 ` Mingming Cao
3 siblings, 1 reply; 204+ messages in thread
From: Andy Whitcroft @ 2006-11-15 0:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel
Seeing this too. Will try this patch out on the affected machines.
If there are any others you recommend with it. Yell.
-apw
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-15 0:25 ` Andy Whitcroft
@ 2006-11-15 0:58 ` Andrew Morton
2006-11-15 23:54 ` Andy Whitcroft
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-15 0:58 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel
On Wed, 15 Nov 2006 00:25:55 +0000
Andy Whitcroft <apw@shadowen.org> wrote:
> Seeing this too. Will try this patch out on the affected machines.
>
> If there are any others you recommend with it. Yell.
>
There are three, but kernel.org mirroring is taking *hours*, so I stuck
them in http://userweb.kernel.org/~akpm/hot-fixes/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-15 0:58 ` Andrew Morton
@ 2006-11-15 23:54 ` Andy Whitcroft
0 siblings, 0 replies; 204+ messages in thread
From: Andy Whitcroft @ 2006-11-15 23:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel
Andrew Morton wrote:
> On Wed, 15 Nov 2006 00:25:55 +0000
> Andy Whitcroft <apw@shadowen.org> wrote:
>
>> Seeing this too. Will try this patch out on the affected machines.
>>
>> If there are any others you recommend with it. Yell.
>>
>
> There are three, but kernel.org mirroring is taking *hours*, so I stuck
> them in http://userweb.kernel.org/~akpm/hot-fixes/
Yeah, what is it with mirroring over there. Seems to have gone to hell
in a hand basket.
The automatic hotfix pickup seems to have done its thing and the results
should be out on TKO. Generally looking _much_ better.
-apw
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Boot failure with ext2 and initrds
2006-11-14 19:31 ` Andrew Morton
` (2 preceding siblings ...)
2006-11-15 0:25 ` Andy Whitcroft
@ 2006-11-16 9:05 ` Mingming Cao
3 siblings, 0 replies; 204+ messages in thread
From: Mingming Cao @ 2006-11-16 9:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Mel Gorman, Martin J. Bligh, linux-kernel
On Tue, 2006-11-14 at 11:31 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 19:11:22 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
>
> > On Tue, 14 Nov 2006, Mel Gorman wrote:
> > > 2.6.19-rc5-mm2
> > >
> > > Am seeing errors with systems using ext2. First machine is a plan old x86
> > > using initramfs. Console output looks like;
> > > ...
> > > Configuring network interfaces...BUG: soft lockup detected on CPU#3!
> > > ...
> > > [<c01b3b80>] ext2_try_to_allocate+0xdb/0x152
> > > [<c01b3e72>] ext2_try_to_allocate_with_rsv+0x4b/0x1b2
> > >
> > > I've not investigated yet what patches might be at fault.
> >
> > I expect you'll find it's
> > ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3.patch
> > which gets stuck in a loop there for me too: back it out and all seems fine.
> >
> > It's not obvious which part of the patch is to blame: mostly it's
> > cleanup, but a few variables do change size: I'm currently narrowing
> > down to where a fix is needed.
> >
>
> Doing s/-Wall/-W/ tends to shake out bugs in this stuff.
>
> The below might help.
>
> Sorry, I tested this well, then the cleanup patch was merged and I didn't
> get onto retesting :(
>
>
>
> From: Andrew Morton <akpm@osdl.org>
>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> fs/ext2/balloc.c | 33 +++++++++++++++------------------
> 1 files changed, 15 insertions(+), 18 deletions(-)
>
> diff -puN fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix fs/ext2/balloc.c
> --- a/fs/ext2/balloc.c~ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix
> +++ a/fs/ext2/balloc.c
> @@ -1155,9 +1155,10 @@ int ext2_new_blocks(struct inode *inode,
This is different from ext3. Shouldn't the return value from
ext2_new_blocks() a ext2_fsblk_t type?
ext2_alloc_blocks() already thinks that ext2_new_blocks return unsigned
block number.
> struct buffer_head *gdp_bh;
> int group_no;
> int goal_group;
> + ext2_grpblk_t grp_target_blk; /* blockgroup relative goal block */
> + ext2_grpblk_t grp_alloc_blk; /* blockgroup-relative allocated block*/
> ext2_fsblk_t ret_block; /* filesyetem-wide allocated block */
> int bgi; /* blockgroup iteration index */
> - int target_block;
> int performed_allocation = 0;
> ext2_grpblk_t free_blocks; /* number of free blocks in a group */
> struct super_block *sb;
> @@ -1230,14 +1231,15 @@ retry_alloc:
> my_rsv = NULL;
>
> if (free_blocks > 0) {
> - ret_block = ((goal - le32_to_cpu(es->s_first_data_block)) %
> + grp_target_blk = ((goal - le32_to_cpu(es->s_first_data_block)) %
> EXT2_BLOCKS_PER_GROUP(sb));
> bitmap_bh = read_block_bitmap(sb, group_no);
> if (!bitmap_bh)
> goto io_error;
> - ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
> - bitmap_bh, ret_block, my_rsv, &num);
> - if (ret_block >= 0)
> + grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
> + bitmap_bh, grp_target_blk,
> + my_rsv, &num);
> + if (grp_alloc_blk >= 0)
> goto allocated;
> }
>
> @@ -1273,9 +1275,9 @@ retry_alloc:
> /*
> * try to allocate block(s) from this group, without a goal(-1).
> */
> - ret_block = ext2_try_to_allocate_with_rsv(sb, group_no,
> + grp_alloc_blk = ext2_try_to_allocate_with_rsv(sb, group_no,
> bitmap_bh, -1, my_rsv, &num);
> - if (ret_block >= 0)
> + if (grp_alloc_blk >= 0)
> goto allocated;
> }
> /*
> @@ -1299,25 +1301,20 @@ allocated:
> ext2_debug("using block group %d(%d)\n",
> group_no, gdp->bg_free_blocks_count);
>
> - target_block = ret_block + group_no * EXT2_BLOCKS_PER_GROUP(sb)
> - + le32_to_cpu(es->s_first_data_block);
> + ret_block = grp_alloc_blk + ext2_group_first_block_no(sb, group_no);
>
> - if (in_range(le32_to_cpu(gdp->bg_block_bitmap), target_block, num) ||
> - in_range(le32_to_cpu(gdp->bg_inode_bitmap), target_block, num) ||
> - in_range(target_block, le32_to_cpu(gdp->bg_inode_table),
> + if (in_range(le32_to_cpu(gdp->bg_block_bitmap), ret_block, num) ||
> + in_range(le32_to_cpu(gdp->bg_inode_bitmap), ret_block, num) ||
> + in_range(ret_block, le32_to_cpu(gdp->bg_inode_table),
> EXT2_SB(sb)->s_itb_per_group) ||
> - in_range(target_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
> + in_range(ret_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
> EXT2_SB(sb)->s_itb_per_group))
> ext2_error(sb, "ext2_new_blocks",
> "Allocating block in system zone - "
> - "blocks from %u, length %lu", target_block, num);
> + "blocks from %u, length %lu", ret_block, num);
>
> performed_allocation = 1;
>
> -
> - /* ret_block was blockgroup-relative. Now it becomes fs-relative */
> - ret_block = target_block;
> -
> if (ret_block + num - 1 >= le32_to_cpu(es->s_blocks_count)) {
> ext2_error(sb, "ext2_new_blocks",
> "block("E2FSBLK") >= blocks count(%d) - "
> _
>
> -
> 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] 204+ messages in thread
* 2.6.19-rc5-mm2: no help text for FAULT_INJECTION
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (5 preceding siblings ...)
2006-11-14 18:49 ` Boot failure with ext2 and initrds Mel Gorman
@ 2006-11-14 20:02 ` Adrian Bunk
2006-11-14 21:12 ` [PATCH -mm] CONFIG_FAULT_INJECTION help text Akinobu Mita
2006-11-14 22:56 ` 2.6.19-rc5-mm2: warnings in MODPOST and later Adrian Bunk
` (27 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 20:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Akinobu Mita, Don Mullis
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +fault-injection-Kconfig-cleanup.patch
>...
> Fault-injection framework and applications thereof.
>...
The FAULT_INJECTION option lacks a help text.
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] 204+ messages in thread* [PATCH -mm] CONFIG_FAULT_INJECTION help text
2006-11-14 20:02 ` 2.6.19-rc5-mm2: no help text for FAULT_INJECTION Adrian Bunk
@ 2006-11-14 21:12 ` Akinobu Mita
2006-11-14 21:15 ` [PATCH -mm] failslab: remove __GFP_HIGHMEM filtering Akinobu Mita
0 siblings, 1 reply; 204+ messages in thread
From: Akinobu Mita @ 2006-11-14 21:12 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, Don Mullis
On Tue, Nov 14, 2006 at 09:02:49PM +0100, Adrian Bunk wrote:
> The FAULT_INJECTION option lacks a help text.
Thank you for pointing that out.
Subject: [PATCH -mm] CONFIG_FAULT_INJECTION help text
This patch add a help text for CONFIG_FAULT_INJECTION
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
lib/Kconfig.debug | 3 +++
1 file changed, 3 insertions(+)
Index: work-fault-inject/lib/Kconfig.debug
===================================================================
--- work-fault-inject.orig/lib/Kconfig.debug
+++ work-fault-inject/lib/Kconfig.debug
@@ -477,6 +477,9 @@ config FAULT_INJECTION
depends on DEBUG_KERNEL
depends on STACKTRACE
select FRAME_POINTER
+ help
+ Provide fault-injection framework.
+ For more details, see Documentation/fault-injection/.
config FAILSLAB
bool "Fault-injection capability for kmalloc"
^ permalink raw reply [flat|nested] 204+ messages in thread
* [PATCH -mm] failslab: remove __GFP_HIGHMEM filtering
2006-11-14 21:12 ` [PATCH -mm] CONFIG_FAULT_INJECTION help text Akinobu Mita
@ 2006-11-14 21:15 ` Akinobu Mita
0 siblings, 0 replies; 204+ messages in thread
From: Akinobu Mita @ 2006-11-14 21:15 UTC (permalink / raw)
To: Adrian Bunk, Andrew Morton, linux-kernel, Don Mullis
Filtering __GFP_HIGHMEM flag for slab allocations is useless.
Because no one sets __GFP_HIGHMEM for slab allocator, unlike
for page allocator.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Documentation/fault-injection/fault-injection.txt | 2 --
mm/slab.c | 17 ++---------------
2 files changed, 2 insertions(+), 17 deletions(-)
Index: work-fault-inject/mm/slab.c
===================================================================
--- work-fault-inject.orig/mm/slab.c
+++ work-fault-inject/mm/slab.c
@@ -3105,15 +3105,10 @@ static struct failslab_attr {
struct fault_attr attr;
- u32 ignore_gfp_highmem;
u32 ignore_gfp_wait;
-
#ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
-
- struct dentry *ignore_gfp_highmem_file;
struct dentry *ignore_gfp_wait_file;
-
-#endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
+#endif
} failslab = {
.attr = FAULT_ATTR_INITIALIZER,
@@ -3131,8 +3126,6 @@ static int should_failslab(struct kmem_c
return 0;
if (flags & __GFP_NOFAIL)
return 0;
- if (failslab.ignore_gfp_highmem && (flags & __GFP_HIGHMEM))
- return 0;
if (failslab.ignore_gfp_wait && (flags & __GFP_WAIT))
return 0;
@@ -3156,15 +3149,9 @@ static int __init failslab_debugfs(void)
debugfs_create_bool("ignore-gfp-wait", mode, dir,
&failslab.ignore_gfp_wait);
- failslab.ignore_gfp_highmem_file =
- debugfs_create_bool("ignore-gfp-highmem", mode, dir,
- &failslab.ignore_gfp_highmem);
-
- if (!failslab.ignore_gfp_wait_file ||
- !failslab.ignore_gfp_highmem_file) {
+ if (!failslab.ignore_gfp_wait_file) {
err = -ENOMEM;
debugfs_remove(failslab.ignore_gfp_wait_file);
- debugfs_remove(failslab.ignore_gfp_highmem_file);
cleanup_fault_attr_dentries(&failslab.attr);
}
Index: work-fault-inject/Documentation/fault-injection/fault-injection.txt
===================================================================
--- work-fault-inject.orig/Documentation/fault-injection/fault-injection.txt
+++ work-fault-inject/Documentation/fault-injection/fault-injection.txt
@@ -86,7 +86,6 @@ configuration of fault-injection capabil
specifies the maximum stacktrace depth walked during search
for a caller within [address-start,address-end).
-- /debug/failslab/ignore-gfp-highmem:
- /debug/fail_page_alloc/ignore-gfp-highmem:
Format: { 0 | 1 }
@@ -167,7 +166,6 @@ echo 10 > /debug/$FAILNAME/probability
echo 100 > /debug/$FAILNAME/interval
echo -1 > /debug/$FAILNAME/times
echo 2 > /debug/$FAILNAME/verbose
-echo 1 > /debug/$FAILNAME/ignore-gfp-highmem
echo 1 > /debug/$FAILNAME/ignore-gfp-wait
blacklist()
^ permalink raw reply [flat|nested] 204+ messages in thread
* 2.6.19-rc5-mm2: warnings in MODPOST and later
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (6 preceding siblings ...)
2006-11-14 20:02 ` 2.6.19-rc5-mm2: no help text for FAULT_INJECTION Adrian Bunk
@ 2006-11-14 22:56 ` Adrian Bunk
2006-11-14 23:09 ` Andrew Morton
2006-11-14 23:13 ` and in www.kernel.org page? Re: 2.6.19-rc5-mm2 Sergio Monteiro Basto
` (26 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-14 22:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Since people were recently complaining about too many warnings:
Here is a list of the warnings I'm getting in MODPOST and later.
Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
I had to attach them compressed.
With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
warnings is present in Linus' tree.
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
[-- Attachment #2: warnings-mm.bz2 --]
[-- Type: application/octet-stream, Size: 46202 bytes --]
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2: warnings in MODPOST and later
2006-11-14 22:56 ` 2.6.19-rc5-mm2: warnings in MODPOST and later Adrian Bunk
@ 2006-11-14 23:09 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-14 23:09 UTC (permalink / raw)
To: Adrian Bunk; +Cc: virtualization@lists.osdl.org, linux-kernel
On Tue, 14 Nov 2006 23:56:22 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> Since people were recently complaining about too many warnings:
> Here is a list of the warnings I'm getting in MODPOST and later.
>
> Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
> I had to attach them compressed.
>
> With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
> warnings is present in Linus' tree.
yes, lots of new section mismatch warnings.
A large number of them are due to the paravirt patches:
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458470) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458478) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458480) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458488) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458490) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458498) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc04584a0) and '__stop_parainstructions'
WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x18)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x20)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x28)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x0)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x8)
but there are others too.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: warnings in MODPOST and later
@ 2006-11-14 23:09 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-14 23:09 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, Rusty Russell, virtualization@lists.osdl.org
On Tue, 14 Nov 2006 23:56:22 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> Since people were recently complaining about too many warnings:
> Here is a list of the warnings I'm getting in MODPOST and later.
>
> Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
> I had to attach them compressed.
>
> With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
> warnings is present in Linus' tree.
yes, lots of new section mismatch warnings.
A large number of them are due to the paravirt patches:
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458470) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458478) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458480) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458488) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458490) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458498) and '__stop_parainstructions'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc04584a0) and '__stop_parainstructions'
WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x18)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x20)
WARNING: drivers/ata/pata_legacy.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x28)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x0)
WARNING: drivers/ata/pata_qdi.o - Section mismatch: reference to .init.text: from .parainstructions after '' (at offset 0x8)
but there are others too.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: warnings in MODPOST and later
2006-11-14 23:09 ` Andrew Morton
(?)
@ 2006-11-15 7:42 ` Arjan van de Ven
-1 siblings, 0 replies; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-15 7:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, linux-kernel, Rusty Russell,
virtualization@lists.osdl.org
On Tue, 2006-11-14 at 15:09 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 23:56:22 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > Since people were recently complaining about too many warnings:
> > Here is a list of the warnings I'm getting in MODPOST and later.
> >
> > Since the warnings by far exceed the 100kB limit of linux-kernel (sic),
> > I had to attach them compressed.
> >
> > With the exception of the "drivers/ide/pci/atiixp:FFFF05", none of these
> > warnings is present in Linus' tree.
>
> yes, lots of new section mismatch warnings.
>
> A large number of them are due to the paravirt patches:
>
> WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458470) and '__stop_parainstructions'
> WARNING: vmlinux - Section mismatch: reference to .init.text: from .parainstructions between '__start_parainstructions' (at offset 0xc0458478) and '__stop_parainstructions'
ok this means that you shouldn't probably switch paravirtualizations
after boot, but that's ok ;) it's not like hypervisor support should be
a module anyway
^ permalink raw reply [flat|nested] 204+ messages in thread
* and in www.kernel.org page? Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (7 preceding siblings ...)
2006-11-14 22:56 ` 2.6.19-rc5-mm2: warnings in MODPOST and later Adrian Bunk
@ 2006-11-14 23:13 ` Sergio Monteiro Basto
2006-11-15 23:16 ` 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error Adrian Bunk
` (25 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Sergio Monteiro Basto @ 2006-11-14 23:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Hi,
What happens with www.kernel.org don't get update ?
I don't see 2.6.19-rc5-mm2 neither patch-2.6.19-rc5-git4.gz on
www.kernel.org
On Tue, 2006-11-14 at 01:41 -0800, Andrew Morton wrote:
> and will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/
>
>
--
Sérgio M.B.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]
^ permalink raw reply [flat|nested] 204+ messages in thread* 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (8 preceding siblings ...)
2006-11-14 23:13 ` and in www.kernel.org page? Re: 2.6.19-rc5-mm2 Sergio Monteiro Basto
@ 2006-11-15 23:16 ` Adrian Bunk
2006-11-15 23:36 ` Andrew Morton
2006-11-16 12:16 ` [-mm patch] remove arch/i386/kernel/time_hpet.c:hpet_reenable() Adrian Bunk
` (24 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-15 23:16 UTC (permalink / raw)
To: Andrew Morton, Rusty Russell; +Cc: linux-kernel
Paravirt breaks CONFIG_X86_PAE=y compilation:
<-- snip -->
...
CC init/main.o
In file included from include2/asm/pgtable.h:245,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
from
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
make[2]: *** [init/main.o] 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] 204+ messages in thread* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-15 23:16 ` 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error Adrian Bunk
@ 2006-11-15 23:36 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-15 23:36 UTC (permalink / raw)
To: Adrian Bunk; +Cc: virtualization@lists.osdl.org, linux-kernel
On Thu, 16 Nov 2006 00:16:26 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> Paravirt breaks CONFIG_X86_PAE=y compilation:
>
> <-- snip -->
>
> ...
> CC init/main.o
> In file included from include2/asm/pgtable.h:245,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> make[2]: *** [init/main.o] Error 1
>
So it does. Zach will save us.
How come allmodconfig doesn't select highmem?
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
@ 2006-11-15 23:36 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-15 23:36 UTC (permalink / raw)
To: Adrian Bunk
Cc: Rusty Russell, linux-kernel, Zachary Amsden,
virtualization@lists.osdl.org
On Thu, 16 Nov 2006 00:16:26 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> Paravirt breaks CONFIG_X86_PAE=y compilation:
>
> <-- snip -->
>
> ...
> CC init/main.o
> In file included from include2/asm/pgtable.h:245,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> make[2]: *** [init/main.o] Error 1
>
So it does. Zach will save us.
How come allmodconfig doesn't select highmem?
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-15 23:36 ` Andrew Morton
(?)
@ 2006-11-16 1:30 ` Zachary Amsden
2006-11-16 2:27 ` Chris Wright
-1 siblings, 1 reply; 204+ messages in thread
From: Zachary Amsden @ 2006-11-16 1:30 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Rusty Russell, linux-kernel,
virtualization@lists.osdl.org
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:16:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
>
>> Paravirt breaks CONFIG_X86_PAE=y compilation:
>>
>> <-- snip -->
>>
>> ...
>> CC init/main.o
>> In file included from include2/asm/pgtable.h:245,
>> from
>> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
>> from
>> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
>> from
>> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
>> from
>> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
>> from
>> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
>> include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
>> include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
>> include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
>> include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
>> make[2]: *** [init/main.o] Error 1
>>
>>
>
> So it does. Zach will save us.
>
>
Well that shouldn't have happened. Must have been some reject that went
unnoticed? Try this.
[-- Attachment #2: pae-fix.patch --]
[-- Type: text/plain, Size: 2118 bytes --]
Save big on PAE patches, now cheaper by the dozen!
I hope this doesn't trip someone's ham filter.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Index: linux-2.6.18/include/asm-i386/pgtable-3level.h
===================================================================
--- linux-2.6.18.orig/include/asm-i386/pgtable-3level.h 2006-11-10 14:49:51.000000000 -0800
+++ linux-2.6.18/include/asm-i386/pgtable-3level.h 2006-11-15 17:26:54.000000000 -0800
@@ -78,26 +78,6 @@ static inline void set_pte_present(struc
set_64bit((unsigned long long *)(pmdptr),pmd_val(pmdval))
#define set_pud(pudptr,pudval) \
(*(pudptr) = (pudval))
-#endif
-
-/*
- * Pentium-II erratum A13: in PAE mode we explicitly have to flush
- * the TLB via cr3 if the top-level pgd is changed...
- * We do not let the generic code free and clear pgd entries due to
- * this erratum.
- */
-static inline void pud_clear (pud_t * pud) { }
-
-#define pud_page(pud) \
-((struct page *) __va(pud_val(pud) & PAGE_MASK))
-
-#define pud_page_vaddr(pud) \
-((unsigned long) __va(pud_val(pud) & PAGE_MASK))
-
-
-/* Find an entry in the second-level page table.. */
-#define pmd_offset(pud, address) ((pmd_t *) pud_page(*(pud)) + \
- pmd_index(address))
/*
* For PTEs and PDEs, we must clear the P-bit first when clearing a page table
@@ -118,6 +98,26 @@ static inline void pmd_clear(pmd_t *pmd)
smp_wmb();
*(tmp + 1) = 0;
}
+#endif
+
+/*
+ * Pentium-II erratum A13: in PAE mode we explicitly have to flush
+ * the TLB via cr3 if the top-level pgd is changed...
+ * We do not let the generic code free and clear pgd entries due to
+ * this erratum.
+ */
+static inline void pud_clear (pud_t * pud) { }
+
+#define pud_page(pud) \
+((struct page *) __va(pud_val(pud) & PAGE_MASK))
+
+#define pud_page_vaddr(pud) \
+((unsigned long) __va(pud_val(pud) & PAGE_MASK))
+
+
+/* Find an entry in the second-level page table.. */
+#define pmd_offset(pud, address) ((pmd_t *) pud_page(*(pud)) + \
+ pmd_index(address))
#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-16 1:30 ` Zachary Amsden
@ 2006-11-16 2:27 ` Chris Wright
0 siblings, 0 replies; 204+ messages in thread
From: Chris Wright @ 2006-11-16 2:27 UTC (permalink / raw)
To: Zachary Amsden
Cc: Andrew Morton, virtualization@lists.osdl.org, linux-kernel,
Adrian Bunk
* Zachary Amsden (zach@vmware.com) wrote:
> Well that shouldn't have happened. Must have been some reject that went
> unnoticed? Try this.
Thanks Zach, added to the pv patchqueue as well.
-chris
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
@ 2006-11-16 2:27 ` Chris Wright
0 siblings, 0 replies; 204+ messages in thread
From: Chris Wright @ 2006-11-16 2:27 UTC (permalink / raw)
To: Zachary Amsden
Cc: Andrew Morton, Adrian Bunk, Rusty Russell, linux-kernel,
virtualization@lists.osdl.org
* Zachary Amsden (zach@vmware.com) wrote:
> Well that shouldn't have happened. Must have been some reject that went
> unnoticed? Try this.
Thanks Zach, added to the pv patchqueue as well.
-chris
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-16 2:27 ` Chris Wright
(?)
@ 2006-11-16 7:05 ` Andi Kleen
-1 siblings, 0 replies; 204+ messages in thread
From: Andi Kleen @ 2006-11-16 7:05 UTC (permalink / raw)
To: virtualization
Cc: Chris Wright, Zachary Amsden, Andrew Morton, linux-kernel,
Adrian Bunk
On Thursday 16 November 2006 03:27, Chris Wright wrote:
> * Zachary Amsden (zach@vmware.com) wrote:
> > Well that shouldn't have happened. Must have been some reject that went
> > unnoticed? Try this.
>
> Thanks Zach, added to the pv patchqueue as well.
That was one of the things that got fixed in paravirt-compile too iirc
-Andi
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
2006-11-15 23:36 ` Andrew Morton
@ 2006-11-28 23:36 ` Randy Dunlap
-1 siblings, 0 replies; 204+ messages in thread
From: Randy Dunlap @ 2006-11-28 23:36 UTC (permalink / raw)
To: Andrew Morton
Cc: zippel, virtualization@lists.osdl.org, linux-kernel, Adrian Bunk
On Wed, 15 Nov 2006 15:36:14 -0800 Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:16:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > Paravirt breaks CONFIG_X86_PAE=y compilation:
> >
> > <-- snip -->
> >
> > ...
> > CC init/main.o
> > In file included from include2/asm/pgtable.h:245,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> > include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> > include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> > include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> > include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> > make[2]: *** [init/main.o] Error 1
> >
>
> So it does. Zach will save us.
>
> How come allmodconfig doesn't select highmem?
Must be because of "choice" and its default:
choice
prompt "High Memory Support"
default NOHIGHMEM
Changing the default fixes it. I suppose conf.c could be
hacked to do something different on choices, but it's not
clear how/what to do there as a general rule.
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Make ix86 default to HIGHMEM4G instead of NOHIGHMEM.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/i386/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.19-rc6-git10.orig/arch/i386/Kconfig
+++ linux-2.6.19-rc6-git10/arch/i386/Kconfig
@@ -443,7 +443,8 @@ source "drivers/firmware/Kconfig"
choice
prompt "High Memory Support"
- default NOHIGHMEM
+ default HIGHMEM4G if !X86_NUMAQ
+ default HIGHMEM64G if X86_NUMAQ
config NOHIGHMEM
bool "off"
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error
@ 2006-11-28 23:36 ` Randy Dunlap
0 siblings, 0 replies; 204+ messages in thread
From: Randy Dunlap @ 2006-11-28 23:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, virtualization@lists.osdl.org, linux-kernel, zippel
On Wed, 15 Nov 2006 15:36:14 -0800 Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:16:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > Paravirt breaks CONFIG_X86_PAE=y compilation:
> >
> > <-- snip -->
> >
> > ...
> > CC init/main.o
> > In file included from include2/asm/pgtable.h:245,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/poll.h:11,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/rtc.h:113,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/efi.h:19,
> > from
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/init/main.c:43:
> > include2/asm/pgtable-3level.h:108: error: redefinition of 'pte_clear'
> > include2/asm/paravirt.h:365: error: previous definition of 'pte_clear' was here
> > include2/asm/pgtable-3level.h:115: error: redefinition of 'pmd_clear'
> > include2/asm/paravirt.h:370: error: previous definition of 'pmd_clear' was here
> > make[2]: *** [init/main.o] Error 1
> >
>
> So it does. Zach will save us.
>
> How come allmodconfig doesn't select highmem?
Must be because of "choice" and its default:
choice
prompt "High Memory Support"
default NOHIGHMEM
Changing the default fixes it. I suppose conf.c could be
hacked to do something different on choices, but it's not
clear how/what to do there as a general rule.
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Make ix86 default to HIGHMEM4G instead of NOHIGHMEM.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/i386/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.19-rc6-git10.orig/arch/i386/Kconfig
+++ linux-2.6.19-rc6-git10/arch/i386/Kconfig
@@ -443,7 +443,8 @@ source "drivers/firmware/Kconfig"
choice
prompt "High Memory Support"
- default NOHIGHMEM
+ default HIGHMEM4G if !X86_NUMAQ
+ default HIGHMEM64G if X86_NUMAQ
config NOHIGHMEM
bool "off"
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] remove arch/i386/kernel/time_hpet.c:hpet_reenable()
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (9 preceding siblings ...)
2006-11-15 23:16 ` 2.6.19-rc5-mm2: paravirt X86_PAE=y compile error Adrian Bunk
@ 2006-11-16 12:16 ` Adrian Bunk
2006-11-16 17:17 ` 2.6.19-rc5-mm2 Mattia Dongili
` (23 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-16 12:16 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner; +Cc: linux-kernel, Ingo Molnar, john stultz
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +updated-i386-convert-to-clock-event-devices.patch
>...
> Updated/fixed/reworked/redone hrtimer and dynticks patches.
>...
This patch removes the no longer used hpet_reenable()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/i386/kernel/time_hpet.c | 5 -----
include/asm-i386/hpet.h | 1 -
2 files changed, 6 deletions(-)
--- linux-2.6.19-rc5-mm2/include/asm-i386/hpet.h.old 2006-11-15 18:49:35.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/asm-i386/hpet.h 2006-11-15 18:49:44.000000000 +0100
@@ -96,7 +96,6 @@
extern int hpet_rtc_timer_init(void);
extern int hpet_enable(void);
-extern int hpet_reenable(void);
extern int is_hpet_enabled(void);
extern int is_hpet_capable(void);
extern int hpet_readl(unsigned long a);
--- linux-2.6.19-rc5-mm2/arch/i386/kernel/time_hpet.c.old 2006-11-15 18:49:53.000000000 +0100
+++ linux-2.6.19-rc5-mm2/arch/i386/kernel/time_hpet.c 2006-11-15 18:50:02.000000000 +0100
@@ -199,11 +199,6 @@
return 0;
}
-int hpet_reenable(void)
-{
- return hpet_timer_stop_set_go(hpet_tick);
-}
-
int is_hpet_enabled(void)
{
return use_hpet;
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (10 preceding siblings ...)
2006-11-16 12:16 ` [-mm patch] remove arch/i386/kernel/time_hpet.c:hpet_reenable() Adrian Bunk
@ 2006-11-16 17:17 ` Mattia Dongili
2006-11-16 18:29 ` 2.6.19-rc5-mm2 Stefan Richter
2006-11-17 1:19 ` [-mm patch] crypto/xcbc.c: make some code static Adrian Bunk
` (22 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Mattia Dongili @ 2006-11-16 17:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux1394-devel, bcollins, stefanr
Hello,
got the following when removing ohci1394 (also happens in -mm1), config
and full dmesg are here:
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm1-4
http://oioio.altervista.org/linux/oops_rmmod_ohci-2.6.19-rc5-mm2
http://oioio.altervista.org/linux/oops_rmmod_ohci-2.6.19-rc5-mm1
ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]
BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
printing eip:
c0238c60
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1c.1/0000:06:00.0/cmd
Modules linked in: ipv6 cpufreq_ondemand acpi_cpufreq freq_table thermal fan button processor ac battery ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables dm_snapshot dm_mirror dm_mod sonypi sony_acpi backlight loop hci_usb bluetooth eth1394 usb_storage pcmcia snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss ipw3945 snd_pcm ieee80211 ieee80211_crypt i2c_i801 intel_agp ohci1394 ide_cd firmware_class yenta_socket rsrc_nonstatic pcmcia_core sky2 tifm_7xx1 tifm_core agpgart rtc uhci_hcd psmouse tpm_infineon tpm tpm_bios ieee1394 snd_timer evdev usbcore pcspkr cdrom snd soundcore snd_page_alloc
CPU: 0
EIP: 0060:[<c0238c60>] Not tainted VLI
EFLAGS: 00010246 (2.6.19-rc5-mm2-1 #9)
EIP is at class_device_remove_attrs+0xd/0x34
eax: f7f7938c ebx: 00000000 ecx: c012013a edx: 00000000
esi: 00000000 edi: f7f7938c ebp: f71a7df4 esp: f71a7de8
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 2398, ti=f71a6000 task=c1974030 task.ti=f71a6000)
Stack: f7f7938c f7f79394 00000000 f71a7e10 c0238d47 00000000 f7f791f4 f7f7938c
f7f79230 00000000 f71a7e1c c0238d82 f7f791f4 f71a7e44 f8d49ea9 f8d4f495
013cb08b 00000026 00000187 f8eb5067 00000000 00000000 f8d49ebe f71a7e4c
Call Trace:
[<c0238d47>] class_device_del+0xc0/0xf0
[<c0238d82>] class_device_unregister+0xb/0x15
[<f8d49ea9>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
[<f8d49ec9>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
[<c02366dc>] device_for_each_child+0x1d/0x46
[<f8d49f9a>] nodemgr_remove_host+0x33/0x90 [ieee1394]
[<f8d47500>] __unregister_host+0x1b/0x9b [ieee1394]
[<f8d47716>] highlevel_remove_host+0x24/0x47 [ieee1394]
[<f8d4715e>] hpsb_remove_host+0x3b/0x5d [ieee1394]
[<f8dca212>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
[<c01dd619>] pci_device_remove+0x19/0x39
[<c02383f7>] __device_release_driver+0x71/0x86
[<c023885f>] driver_detach+0x83/0xc4
[<c023802b>] bus_remove_driver+0x5a/0x76
[<c02388c7>] driver_unregister+0xb/0x18
[<c01dd787>] pci_unregister_driver+0xf/0x5b
[<f8dcd2de>] ohci1394_cleanup+0xd/0xf [ohci1394]
[<c013b193>] sys_delete_module+0x18c/0x1b5
[<c0102d66>] sysenter_past_esp+0x5f/0x85
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x85
Leftover inexact backtrace:
=======================
Code: c0 08 e8 fb f2 f5 ff 89 c1 5d 89 c8 c3 55 85 c0 89 e5 74 08 83 c0 08 e8 6b d9 f5 ff 5d c3 55 89 e5 57 89 c7 56 53 31 db 8b 70 48 <83> be a4 00 00 00 00 75 09 eb 17 89 f8 e8 d0 ff ff ff 89 da 83
EIP: [<c0238c60>] class_device_remove_attrs+0xd/0x34 SS:ESP 0068:f71a7de8
--
mattia
:wq!
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2
2006-11-16 17:17 ` 2.6.19-rc5-mm2 Mattia Dongili
@ 2006-11-16 18:29 ` Stefan Richter
2006-11-16 20:39 ` 2.6.19-rc5-mm2 Mattia Dongili
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-16 18:29 UTC (permalink / raw)
To: Mattia Dongili; +Cc: Andrew Morton, linux-kernel, linux1394-devel, bcollins
Mattia Dongili wrote:
> got the following when removing ohci1394 (also happens in -mm1),
...
> ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]
Hm, there is garbage in this node data. Moreover, your full logs show
that there was never another node added besides the host node. IOW the
second "Node removed" line shouldn't be there. Very strange.
> BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
...
> EIP is at class_device_remove_attrs+0xd/0x34
...
Could you also test one or even better both of:
- 2.6.19-rc5 plus
http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
(these are the same FireWire drivers as in -rc5-mm2)
and/ or
- 2.6.19-rc5-mm2 minus
http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
Thanks so far,
--
Stefan Richter
-=====-=-==- =-== =----
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-16 18:29 ` 2.6.19-rc5-mm2 Stefan Richter
@ 2006-11-16 20:39 ` Mattia Dongili
2006-11-16 22:50 ` 2.6.19-rc5-mm2 Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Mattia Dongili @ 2006-11-16 20:39 UTC (permalink / raw)
To: Stefan Richter; +Cc: Andrew Morton, linux-kernel, linux1394-devel, bcollins
On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
> Mattia Dongili wrote:
> > got the following when removing ohci1394 (also happens in -mm1),
> ...
> > ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> > ieee1394: Node removed: ID:BUS[20754571-38:0391] GUID[00000000f8eb5067]
>
> Hm, there is garbage in this node data. Moreover, your full logs show
> that there was never another node added besides the host node. IOW the
> second "Node removed" line shouldn't be there. Very strange.
>
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 000000a4
> ...
> > EIP is at class_device_remove_attrs+0xd/0x34
> ...
>
> Could you also test one or even better both of:
> - 2.6.19-rc5 plus
> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
> (these are the same FireWire drivers as in -rc5-mm2)
the oops disappear
> and/ or
> - 2.6.19-rc5-mm2 minus
> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
the oops is there again.
I suppose git-ieee1394 is the one then...
dmesg:
http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
next step (smells like bisection) if for tomorrow :)
--
mattia
:wq!
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-16 20:39 ` 2.6.19-rc5-mm2 Mattia Dongili
@ 2006-11-16 22:50 ` Stefan Richter
2006-11-17 7:16 ` 2.6.19-rc5-mm2 Mattia Dongili
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-16 22:50 UTC (permalink / raw)
To: Mattia Dongili, Andrew Morton, linux-kernel, linux1394-devel,
bcollins
Mattia Dongili wrote:
> On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
>> Could you also test one or even better both of:
>> - 2.6.19-rc5 plus
>> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
>> (these are the same FireWire drivers as in -rc5-mm2)
>
> the oops disappear
>
>> and/ or
>> - 2.6.19-rc5-mm2 minus
>> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
>
> the oops is there again.
> I suppose git-ieee1394 is the one then...
On the contrary, it's very likely _not_ git-ieee1394.
> dmesg:
> http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
I will look at it tomorrow.
> next step (smells like bisection) if for tomorrow :)
Unless you are eager to get results faster, let me think about where
this superfluous node_entry could come from. Perhaps a run-time test of
-mm by myself is in order; I am currently on 2.6.19-rc4 plus that patch
at me.in-berlin.de. Could spare you a lot of time if I find out more. :-)
Thanks for the help,
--
Stefan Richter
-=====-=-==- =-== =----
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-16 22:50 ` 2.6.19-rc5-mm2 Stefan Richter
@ 2006-11-17 7:16 ` Mattia Dongili
2006-11-17 15:02 ` 2.6.19-rc5-mm2 Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Mattia Dongili @ 2006-11-17 7:16 UTC (permalink / raw)
To: Stefan Richter; +Cc: Andrew Morton, linux-kernel, linux1394-devel, bcollins
On Thu, Nov 16, 2006 at 11:50:48PM +0100, Stefan Richter wrote:
> Mattia Dongili wrote:
> > On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote:
> >> Could you also test one or even better both of:
> >> - 2.6.19-rc5 plus
> >> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2
> >> (these are the same FireWire drivers as in -rc5-mm2)
> >
> > the oops disappear
> >
> >> and/ or
> >> - 2.6.19-rc5-mm2 minus
> >> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch
> >
> > the oops is there again.
> > I suppose git-ieee1394 is the one then...
>
> On the contrary, it's very likely _not_ git-ieee1394.
yup, sorry. That's exactly what I ordered my fingers to type... (damn
fingers).
> > dmesg:
> > http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok
> > http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
>
> I will look at it tomorrow.
>
> > next step (smells like bisection) if for tomorrow :)
>
> Unless you are eager to get results faster, let me think about where
> this superfluous node_entry could come from. Perhaps a run-time test of
> -mm by myself is in order; I am currently on 2.6.19-rc4 plus that patch
> at me.in-berlin.de. Could spare you a lot of time if I find out more. :-)
No problems, I can wait :) After all I don't have any ieee1394 device
(that's why I was rmmod-ing modules :))
If needed feel free to ask me for a bisection.
--
mattia
:wq!
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2
2006-11-17 7:16 ` 2.6.19-rc5-mm2 Mattia Dongili
@ 2006-11-17 15:02 ` Stefan Richter
2006-11-17 15:24 ` 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host) Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-17 15:02 UTC (permalink / raw)
To: Mattia Dongili, Greg KH
Cc: Andrew Morton, linux-kernel, linux1394-devel, bcollins
Mattia Dongili wrote:
>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
and
http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
| # CONFIG_SYSFS_DEPRECATED is not set
| ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
| ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
| BUG: unable to handle kernel NULL pointer dereference at virtual
address 000000a4
| printing eip:
| c0238c60
| *pde = 00000000
| Oops: 0000 [#1]
| SMP
| last sysfs file: /devices/pci0000:00/0000:00:00.0/class
[...]
| EIP is at class_device_remove_attrs+0xd/0x34
| eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
| esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
| ds: 007b es: 007b ss: 0068
| Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
| Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
f7e02b8c
| f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
f8d63087
| 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
f7629e5c
| Call Trace:
| [<c0238d47>] class_device_del+0xc0/0xf0
| [<c0238d82>] class_device_unregister+0xb/0x15
| [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
| [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
| [<c02366dc>] device_for_each_child+0x1d/0x46
| [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
| [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
| [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
| [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
| [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
| [<c01dd619>] pci_device_remove+0x19/0x39
Either the FireWire host's device->klist_children was overwritten before
the call to device_for_each_child (perhaps nodemgr didn't hold a
reference which it should have), or/and all of this is an issue with the
ongoing migration away from class_device.
--
Stefan Richter
-=====-=-==- =-== =---=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-17 15:02 ` 2.6.19-rc5-mm2 Stefan Richter
@ 2006-11-17 15:24 ` Stefan Richter
2006-11-18 9:47 ` Greg KH
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-17 15:24 UTC (permalink / raw)
To: Mattia Dongili, Greg KH
Cc: Andrew Morton, linux-kernel, linux1394-devel, bcollins
I wrote:
> Mattia Dongili wrote:
>>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
> and
> http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
> | # CONFIG_SYSFS_DEPRECATED is not set
>
> | ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> | ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
> | BUG: unable to handle kernel NULL pointer dereference at virtual
> address 000000a4
> | printing eip:
> | c0238c60
> | *pde = 00000000
> | Oops: 0000 [#1]
> | SMP
> | last sysfs file: /devices/pci0000:00/0000:00:00.0/class
> [...]
> | EIP is at class_device_remove_attrs+0xd/0x34
> | eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
> | esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
> | ds: 007b es: 007b ss: 0068
> | Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
> | Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
> f7e02b8c
> | f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
> f8d63087
> | 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
> f7629e5c
> | Call Trace:
> | [<c0238d47>] class_device_del+0xc0/0xf0
> | [<c0238d82>] class_device_unregister+0xb/0x15
> | [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
> | [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
> | [<c02366dc>] device_for_each_child+0x1d/0x46
> | [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
> | [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
> | [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
> | [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
> | [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
> | [<c01dd619>] pci_device_remove+0x19/0x39
>
> Either the FireWire host's device->klist_children was overwritten before
> the call to device_for_each_child
or *during* the run of device_for_each_child, which first successfully
called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
false node [20754571-38:0455].
> (perhaps nodemgr didn't hold a reference which it should have), or/and
> all of this is an issue with the ongoing migration away from class_device.
--
Stefan Richter
-=====-=-==- =-== =---=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-17 15:24 ` 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host) Stefan Richter
@ 2006-11-18 9:47 ` Greg KH
2006-11-18 11:27 ` Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Greg KH @ 2006-11-18 9:47 UTC (permalink / raw)
To: Stefan Richter
Cc: Mattia Dongili, Andrew Morton, linux-kernel, linux1394-devel,
bcollins
On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote:
> I wrote:
> > Mattia Dongili wrote:
> >>>> http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko
> > and
> > http://oioio.altervista.org/linux/config-2.6.19-rc5-mm2-1
> > | # CONFIG_SYSFS_DEPRECATED is not set
> >
> > | ieee1394: Node removed: ID:BUS[0-00:1023] GUID[080046030227e7bb]
> > | ieee1394: Node removed: ID:BUS[20754571-38:0455] GUID[00000000f8ee6067]
> > | BUG: unable to handle kernel NULL pointer dereference at virtual
> > address 000000a4
> > | printing eip:
> > | c0238c60
> > | *pde = 00000000
> > | Oops: 0000 [#1]
> > | SMP
> > | last sysfs file: /devices/pci0000:00/0000:00:00.0/class
> > [...]
> > | EIP is at class_device_remove_attrs+0xd/0x34
> > | eax: f7e02b8c ebx: 00000000 ecx: ffffffff edx: 00000000
> > | esi: 00000000 edi: f7e02b8c ebp: f7629e04 esp: f7629df8
> > | ds: 007b es: 007b ss: 0068
> > | Process rmmod (pid: 2419, ti=f7628000 task=f702a550 task.ti=f7628000)
> > | Stack: f7e02b8c f7e02b94 00000000 f7629e20 c0238d47 00000000 f7e02a30
> > f7e02b8c
> > | f7e02a30 00000000 f7629e2c c0238d82 f7e029f4 f7629e54 f8d5da3d
> > f8d63087
> > | 013cb08b 00000026 000001c7 f8ee6067 00000000 00000000 f8d5da52
> > f7629e5c
> > | Call Trace:
> > | [<c0238d47>] class_device_del+0xc0/0xf0
> > | [<c0238d82>] class_device_unregister+0xb/0x15
> > | [<f8d5da3d>] nodemgr_remove_ne+0x64/0x79 [ieee1394]
> > | [<f8d5da5d>] __nodemgr_remove_host_dev+0xb/0xf [ieee1394]
> > | [<c02366dc>] device_for_each_child+0x1d/0x46
> > | [<f8d5dd82>] nodemgr_remove_host+0x36/0x5d [ieee1394]
> > | [<f8d5b4f3>] __unregister_host+0x1b/0x9c [ieee1394]
> > | [<f8d5b70b>] highlevel_remove_host+0x24/0x47 [ieee1394]
> > | [<f8d5b14f>] hpsb_remove_host+0x3b/0x5c [ieee1394]
> > | [<f8dcbf9d>] ohci1394_pci_remove+0x47/0x1c7 [ohci1394]
> > | [<c01dd619>] pci_device_remove+0x19/0x39
> >
> > Either the FireWire host's device->klist_children was overwritten before
> > the call to device_for_each_child
>
> or *during* the run of device_for_each_child, which first successfully
> called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
> false node [20754571-38:0455].
>
> > (perhaps nodemgr didn't hold a reference which it should have), or/and
> > all of this is an issue with the ongoing migration away from class_device.
I don't have any firewire class_device migration patches in -mm right
now.
I do have one sitting here if you wish to play around with it, but it
needs some more infrastructure patches that I have not really tested all
that well yet.
Either way, I don't think this is caused by any new class_device
patches, but I'm very willing to be proven wrong :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-18 9:47 ` Greg KH
@ 2006-11-18 11:27 ` Stefan Richter
2006-11-18 17:07 ` Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-18 11:27 UTC (permalink / raw)
To: Greg KH
Cc: Mattia Dongili, Andrew Morton, linux-kernel, linux1394-devel,
bcollins
Greg KH wrote:
> On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote:
>> I wrote:
>>> Either the FireWire host's device->klist_children was overwritten before
>>> the call to device_for_each_child
>> or *during* the run of device_for_each_child, which first successfully
>> called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the
>> false node [20754571-38:0455].
>>
>>> (perhaps nodemgr didn't hold a reference which it should have), or/and
>>> all of this is an issue with the ongoing migration away from class_device.
>
> I don't have any firewire class_device migration patches in -mm right
> now.
Yes, I looked through the driver core related patches in -mm but wasn't
sure if there was a change to generic code which could affect
ieee1394/nodemgr.
> I do have one sitting here if you wish to play around with it, but it
> needs some more infrastructure patches that I have not really tested all
> that well yet.
(Is this infrastructure something which other subsystems will require
anyway? If not, maybe the ieee1394 subsystem's sysfs interface could be
cut to size instead.)
> Either way, I don't think this is caused by any new class_device
> patches, but I'm very willing to be proven wrong :)
Good, I just wanted to hear your opinion before drilling further down.
Seems there is an older bug in nodemgr. But whatever it is, the reporter
reproduced it _only_ in -mm, with either of 2.6.19-rc-mm's and
2.6.19-rc's ieee1394 code. Time for me to let -mm loose on my PC.
Thanks,
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-18 11:27 ` Stefan Richter
@ 2006-11-18 17:07 ` Stefan Richter
2006-11-18 21:45 ` Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-18 17:07 UTC (permalink / raw)
To: Mattia Dongili
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
> Time for me to let -mm loose on my PC.
Small progress:
- I get the oops already in nodemgr_remove_ne, unlike the original
report where it happened a little later in driver core functions
called by nodemgr_remove_ne.
- I get it only if eth1394 is loaded when I unload ohci1394.
- Like Mattia already found, this only happens on -mm, not on
2.6.19-rc plus patched ieee1394 code which is 100% the same as
in -mm except for Nigel Cunningham's
add-include-linux-freezerh-and-move-definitions-from.patch
which is of course not involved.
EIP is at nodemgr_remove_ne+0x40/0x90 [ieee1394]
eax: 00000000 ebx: f6af0c68 ecx: c02fcc20 edx: 0000003a
esi: f6af0c2c edi: f8c14b60 ebp: f7395dd8 esp: f7395db8
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 4568, ti=f7394000 task=f69c3530 task.ti=f7394000)
Stack: f6af0c68 00000000 00000020 0000003a f8de0e00 00000000 00000000
f7395dfc
f7395dec f8c14b8e f6af0c2c f73c20c4 f6af0c9c f7395e18 c02228e2
f6af0c68
f73c20c4 f73c20c4 f73c20e4 f6af0c98 c02b4698 f73c20c4 f73c2000
f73c2000
Call Trace:
[<c010400f>] show_trace_log_lvl+0x2f/0x50
[<c01040f7>] show_stack_log_lvl+0x97/0xc0
[<c0104355>] show_registers+0x1c5/0x340
[<c010469a>] die+0x12a/0x220
[<c0114649>] do_page_fault+0x369/0x660
[<c02b697c>] error_code+0x7c/0x84
[<f8c14b8e>] __nodemgr_remove_host_dev+0x2e/0x40 [ieee1394]
[<c02228e2>] device_for_each_child+0x32/0x60
[<f8c14bbe>] nodemgr_remove_host_dev+0x1e/0x90 [ieee1394]
[<f8c169f7>] nodemgr_remove_host+0x37/0x40 [ieee1394]
[<f8c111bc>] __unregister_host+0x8c/0xd0 [ieee1394]
[<f8c11b16>] highlevel_remove_host+0x36/0x60 [ieee1394]
[<f8c10c23>] hpsb_remove_host+0x43/0x70 [ieee1394]
[<f8c07e08>] ohci1394_pci_remove+0x68/0x240 [ohci1394]
[<c01f7f86>] pci_device_remove+0x46/0x50
[<c0224cae>] __device_release_driver+0xae/0xc0
[<c0224e38>] driver_detach+0x118/0x120
[<c0224174>] bus_remove_driver+0x44/0x70
[<c0225102>] driver_unregister+0x12/0x20
[<c01f8305>] pci_unregister_driver+0x15/0x30
[<f8c084d2>] ohci1394_cleanup+0x12/0x14 [ohci1394]
[<c0142aa6>] sys_delete_module+0x156/0x180
[<c01031f6>] sysenter_past_esp+0x5f/0x85
=======================
Code: c7 85 c0 89 c3 74 60 8b 06 8b 56 04 89 44 24 10 89 54 24 14 0f b7
46 14 89 c2 83 e0 3f c1 ea 06 89 44 24 08 89 54 24 0c 8b 46 10 <8b> 80
b8 00 00 00 c7 04 24 84 bc c1 f8 89 44 24 04 e8 7a 9c 50
EIP: [<f8c14b10>] nodemgr_remove_ne+0x40/0x90 [ieee1394] SS:ESP
0068:f7395db8
In that way it is 100% reproducible here. I continue to debug this.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-18 17:07 ` Stefan Richter
@ 2006-11-18 21:45 ` Stefan Richter
2006-11-18 22:08 ` Stefan Richter
` (2 more replies)
0 siblings, 3 replies; 204+ messages in thread
From: Stefan Richter @ 2006-11-18 21:45 UTC (permalink / raw)
To: Mattia Dongili
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
I added the following patch:
--- linux-2.6.19-rc5-mm2.orig/drivers/ieee1394/nodemgr.c 2006-11-18 21:18:05.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/ieee1394/nodemgr.c 2006-11-18 21:33:44.000000000 +0100
@@ -798,8 +798,9 @@ static void nodemgr_remove_uds(struct no
static void nodemgr_remove_ne(struct node_entry *ne)
{
- struct device *dev = &ne->device;
+ struct device *dev;
+ HPSB_DEBUG("****** nodemgr_remove_ne");
dev = get_device(&ne->device);
if (!dev)
return;
@@ -817,7 +818,10 @@ static void nodemgr_remove_ne(struct nod
static int __nodemgr_remove_host_dev(struct device *dev, void *data)
{
- nodemgr_remove_ne(container_of(dev, struct node_entry, device));
+ struct node_entry *ne = container_of(dev, struct node_entry, device);
+
+ HPSB_DEBUG("****** ne = %p", ne);
+ nodemgr_remove_ne(ne);
return 0;
}
@@ -906,6 +910,7 @@ static struct node_entry *nodemgr_create
HPSB_DEBUG("%s added: ID:BUS[" NODE_BUS_FMT "] GUID[%016Lx]",
(host->node_id == nodeid) ? "Host" : "Node",
NODE_BUS_ARGS(host, nodeid), (unsigned long long)guid);
+ HPSB_DEBUG("****** ne = %p", ne);
return ne;
With this I get the following kernel log on a PC with two FireWire cards:
# modprobe ohci1394
Nov 18 21:38:05 shuttle kernel: ieee1394: Initialized config rom entry `ip1394'
Nov 18 21:38:05 shuttle kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[17] MMIO=[e7004000-e70047ff] Max Packet=[4096] IR/IT contexts=[4/8]
Nov 18 21:38:05 shuttle kernel: ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[e7006000-e70067ff] Max Packet=[2048] IR/IT contexts=[8/8]
Nov 18 21:38:07 shuttle kernel: ieee1394: Error parsing configrom for node 0-01:1023
Nov 18 21:38:07 shuttle kernel: ieee1394: Host added: ID:BUS[0-02:1023] GUID[0001080000002d02]
Nov 18 21:38:07 shuttle kernel: ieee1394: ****** ne = f61f609c
Nov 18 21:38:07 shuttle kernel: eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Nov 18 21:38:07 shuttle kernel: eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1)
Nov 18 21:38:07 shuttle kernel: ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 21:38:07 shuttle kernel: ieee1394: ****** ne = f50db964
# modprobe -r ohci1394
Nov 18 21:38:18 shuttle kernel: ieee1394: ****** ne = f627952c
Nov 18 21:38:18 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 21:38:18 shuttle kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b8
We never created a "ne" at f627952c. This address is obtained by the
container_of() in __nodemgr_remove_host_dev(). Ergo the list of device
pointers which device_for_each_child() in nodemgr_remove_host_dev() is
iterating over, i.e. the host->device.klist_children, was corrupted
somewhere.
Nov 18 21:38:18 shuttle kernel: printing eip:
Nov 18 21:38:18 shuttle kernel: f9057b4c
Nov 18 21:38:18 shuttle kernel: *pde = 00000000
Nov 18 21:38:18 shuttle kernel: Oops: 0000 [#1]
Nov 18 21:38:18 shuttle kernel: PREEMPT SMP
Nov 18 21:38:18 shuttle kernel: last sysfs file: /class/printer/lp0/dev
Nov 18 21:38:18 shuttle kernel: Modules linked in: eth1394 ohci1394 ieee1394 nvidia(P) nfsd exportfs lockd sunrpc snd_via82xx snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd lp af_packet 8139too mii loop via_agp agpgart uhci_hcd
Nov 18 21:38:18 shuttle kernel: CPU: 0
Nov 18 21:38:18 shuttle kernel: EIP: 0060:[pg0+950528844/1067602944] Tainted: P VLI
Nov 18 21:38:18 shuttle kernel: EIP: 0060:[<f9057b4c>] Tainted: P VLI
Nov 18 21:38:18 shuttle kernel: EFLAGS: 00210213 (2.6.19-rc5-mm2 #15)
Nov 18 21:38:18 shuttle kernel: EIP is at nodemgr_remove_ne+0x4c/0x90 [ieee1394]
Nov 18 21:38:18 shuttle kernel: eax: 00000000 ebx: f6279568 ecx: 00003a2d edx: 0000037a
Nov 18 21:38:18 shuttle kernel: esi: f627952c edi: f9057b90 ebp: f57a3dd8 esp: f57a3db8
Nov 18 21:38:18 shuttle kernel: ds: 007b es: 007b ss: 0068
Nov 18 21:38:18 shuttle kernel: Process modprobe (pid: 5967, ti=f57a2000 task=f576e0f0 task.ti=f57a2000)
Nov 18 21:38:18 shuttle kernel: Stack: f6279568 f627952c 00000020 0000037a f8c7de00 00000000 f627952c f57a3dfc
Nov 18 21:38:18 shuttle kernel: f57a3dec f9057bb5 f627952c f627952c 00000000 f57a3e18 c02313b2 f6279568
Nov 18 21:38:18 shuttle kernel: 00000000 f73ea0c4 f73ea0e4 f6279598 c02d8b18 f73ea0c4 f73ea000 f73ea000
Nov 18 21:38:18 shuttle kernel: Call Trace:
Nov 18 21:38:19 shuttle kernel: [show_trace_log_lvl+47/80] show_trace_log_lvl+0x2f/0x50
Nov 18 21:38:19 shuttle kernel: [<c010400f>] show_trace_log_lvl+0x2f/0x50
Nov 18 21:38:19 shuttle kernel: [show_stack_log_lvl+151/192] show_stack_log_lvl+0x97/0xc0
Nov 18 21:38:19 shuttle kernel: [<c01040f7>] show_stack_log_lvl+0x97/0xc0
Nov 18 21:38:19 shuttle kernel: [show_registers+453/832] show_registers+0x1c5/0x340
Nov 18 21:38:19 shuttle kernel: [<c0104355>] show_registers+0x1c5/0x340
Nov 18 21:38:19 shuttle kernel: [die+298/544] die+0x12a/0x220
Nov 18 21:38:19 shuttle kernel: [<c010469a>] die+0x12a/0x220
Nov 18 21:38:19 shuttle kernel: [do_page_fault+873/1632] do_page_fault+0x369/0x660
Nov 18 21:38:19 shuttle kernel: [<c0114649>] do_page_fault+0x369/0x660
Nov 18 21:38:19 shuttle kernel: [error_code+124/132] error_code+0x7c/0x84
Nov 18 21:38:19 shuttle kernel: [<c02dadfc>] error_code+0x7c/0x84
Nov 18 21:38:19 shuttle kernel: [pg0+950528949/1067602944] __nodemgr_remove_host_dev+0x25/0x30 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9057bb5>] __nodemgr_remove_host_dev+0x25/0x30 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [device_for_each_child+50/96] device_for_each_child+0x32/0x60
Nov 18 21:38:19 shuttle kernel: [<c02313b2>] device_for_each_child+0x32/0x60
Nov 18 21:38:19 shuttle kernel: [pg0+950528994/1067602944] nodemgr_remove_host_dev+0x22/0x90 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9057be2>] nodemgr_remove_host_dev+0x22/0x90 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950536711/1067602944] nodemgr_remove_host+0x37/0x40 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9059a07>] nodemgr_remove_host+0x37/0x40 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950514108/1067602944] __unregister_host+0x8c/0xd0 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f90541bc>] __unregister_host+0x8c/0xd0 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950516502/1067602944] highlevel_remove_host+0x36/0x60 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9054b16>] highlevel_remove_host+0x36/0x60 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+950512675/1067602944] hpsb_remove_host+0x43/0x70 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [<f9053c23>] hpsb_remove_host+0x43/0x70 [ieee1394]
Nov 18 21:38:19 shuttle kernel: [pg0+946040328/1067602944] ohci1394_pci_remove+0x68/0x240 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [<f8c0fe08>] ohci1394_pci_remove+0x68/0x240 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [pci_device_remove+70/80] pci_device_remove+0x46/0x50
Nov 18 21:38:19 shuttle kernel: [<c01fe976>] pci_device_remove+0x46/0x50
Nov 18 21:38:19 shuttle kernel: [__device_release_driver+174/192] __device_release_driver+0xae/0xc0
Nov 18 21:38:19 shuttle kernel: [<c023377e>] __device_release_driver+0xae/0xc0
Nov 18 21:38:19 shuttle kernel: [driver_detach+280/288] driver_detach+0x118/0x120
Nov 18 21:38:19 shuttle kernel: [<c0233908>] driver_detach+0x118/0x120
Nov 18 21:38:19 shuttle kernel: [bus_remove_driver+68/112] bus_remove_driver+0x44/0x70
Nov 18 21:38:19 shuttle kernel: [<c0232c44>] bus_remove_driver+0x44/0x70
Nov 18 21:38:19 shuttle kernel: [driver_unregister+18/32] driver_unregister+0x12/0x20
Nov 18 21:38:19 shuttle kernel: [<c0233bd2>] driver_unregister+0x12/0x20
Nov 18 21:38:19 shuttle kernel: [pci_unregister_driver+21/48] pci_unregister_driver+0x15/0x30
Nov 18 21:38:19 shuttle kernel: [<c01fecf5>] pci_unregister_driver+0x15/0x30
Nov 18 21:38:19 shuttle kernel: [pg0+946042066/1067602944] ohci1394_cleanup+0x12/0x14 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [<f8c104d2>] ohci1394_cleanup+0x12/0x14 [ohci1394]
Nov 18 21:38:19 shuttle kernel: [sys_delete_module+342/384] sys_delete_module+0x156/0x180
Nov 18 21:38:19 shuttle kernel: [<c0142aa6>] sys_delete_module+0x156/0x180
Nov 18 21:38:19 shuttle kernel: [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
Nov 18 21:38:19 shuttle kernel: [<c01031f6>] sysenter_past_esp+0x5f/0x85
Nov 18 21:38:19 shuttle kernel: =======================
Nov 18 21:38:19 shuttle kernel: Code: c7 85 c0 89 c3 74 60 8b 06 8b 56 04 89 44 24 10 89 54 24 14 0f b7 46 14 89 c2 83 e0 3f c1 ea 06 89 44 24 08 89 54 24 0c 8b 46 10 <8b> 80 b8 00 00 00 c7 04 24 2c b5 07 f9 89 44 24 04 e8 3e 6c 0c
Nov 18 21:38:19 shuttle kernel: EIP: [pg0+950528844/1067602944] nodemgr_remove_ne+0x4c/0x90 [ieee1394] SS:ESP 0068:f57a3db8
Nov 18 21:38:19 shuttle kernel: EIP: [<f9057b4c>] nodemgr_remove_ne+0x4c/0x90 [ieee1394] SS:ESP 0068:f57a3db8
The same on Linux 2.6.19-rc4 plus what constitutes git-ieee1394.patch
plus the diagnostics patch:
# modprobe ohci1394
Nov 18 22:09:25 shuttle kernel: ieee1394: Initialized config rom entry `ip1394'
Nov 18 22:09:25 shuttle kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[17] MMIO=[e7004000-e70047ff] Max Packet=[4096] IR/IT contexts=[4/8]
Nov 18 22:09:25 shuttle kernel: ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[e7006000-e70067ff] Max Packet=[2048] IR/IT contexts=[8/8]
Nov 18 22:09:27 shuttle kernel: ieee1394: Error parsing configrom for node 0-01:1023
Nov 18 22:09:27 shuttle kernel: ieee1394: Host added: ID:BUS[0-02:1023] GUID[0001080000002d02]
Nov 18 22:09:27 shuttle kernel: ieee1394: ****** ne = f505512c
Nov 18 22:09:27 shuttle kernel: eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Nov 18 22:09:27 shuttle kernel: eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1)
Nov 18 22:09:27 shuttle kernel: ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 22:09:27 shuttle kernel: ieee1394: ****** ne = f5140d80
# modprobe -r ohci1394
Nov 18 22:09:31 shuttle kernel: ieee1394: ****** ne = f5140d80
Nov 18 22:09:31 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 22:09:31 shuttle kernel: ieee1394: Node removed: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
Nov 18 22:09:32 shuttle kernel: ieee1394: ****** ne = f505512c
Nov 18 22:09:32 shuttle kernel: ieee1394: ****** nodemgr_remove_ne
Nov 18 22:09:32 shuttle kernel: ieee1394: Node removed: ID:BUS[0-02:1023] GUID[0001080000002d02]
It seems like one of the patches in -mm overwrites a device's list of
children with junk.
Mattia, *if* your machine is able to compile and reboot into new
kernels really quickly, it would be nice if you could biject between
the -mm patches. I suppose the following ones are those to concentrate
on first:
broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
broken-out/gregkh-driver-driver-link-sysfs-timing.patch
broken-out/gregkh-driver-sysfs-crash-debugging.patch
broken-out/gregkh-driver-udev-compatible-hack.patch
But hold on, I will do one other thing after I sent this message; I'll
test -mm with CONFIG_SYSFS_DEPRECATED=y.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-18 21:45 ` Stefan Richter
@ 2006-11-18 22:08 ` Stefan Richter
2006-11-19 8:56 ` Mattia Dongili
2006-11-19 16:22 ` ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)] Mattia Dongili
2 siblings, 0 replies; 204+ messages in thread
From: Stefan Richter @ 2006-11-18 22:08 UTC (permalink / raw)
To: Mattia Dongili
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
I wrote:
> It seems like one of the patches in -mm overwrites a device's list of
> children with junk.
And this happens only if eth1394 wasn't unloaded (therefore unbound
from FireWire "ud" devices beneath FireWire "ne" devices beneath the
FireWire host devices) before the host devices's children are to be
removed.
> Mattia, *if* your machine is able to compile and reboot into new
> kernels really quickly, it would be nice if you could biject between
> the -mm patches.
...
> But hold on, I will do one other thing after I sent this message; I'll
> test -mm with CONFIG_SYSFS_DEPRECATED=y.
CONFIG_SYSFS_DEPRECATED=y does not change anything.
--
Stefan Richter
-=====-=-==- =-== =--=-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)
2006-11-18 21:45 ` Stefan Richter
2006-11-18 22:08 ` Stefan Richter
@ 2006-11-19 8:56 ` Mattia Dongili
2006-11-19 16:22 ` ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)] Mattia Dongili
2 siblings, 0 replies; 204+ messages in thread
From: Mattia Dongili @ 2006-11-19 8:56 UTC (permalink / raw)
To: Stefan Richter
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
[...]
> It seems like one of the patches in -mm overwrites a device's list of
> children with junk.
>
> Mattia, *if* your machine is able to compile and reboot into new
> kernels really quickly, it would be nice if you could biject between
> the -mm patches. I suppose the following ones are those to concentrate
> on first:
>
> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
> broken-out/gregkh-driver-sysfs-crash-debugging.patch
> broken-out/gregkh-driver-udev-compatible-hack.patch
>
> But hold on, I will do one other thing after I sent this message; I'll
> test -mm with CONFIG_SYSFS_DEPRECATED=y.
Ok, will go through these patches first and let you know
--
mattia
:wq!
^ permalink raw reply [flat|nested] 204+ messages in thread
* ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-18 21:45 ` Stefan Richter
2006-11-18 22:08 ` Stefan Richter
2006-11-19 8:56 ` Mattia Dongili
@ 2006-11-19 16:22 ` Mattia Dongili
2006-11-19 17:13 ` Stefan Richter
2006-11-19 17:14 ` Gene Heskett
2 siblings, 2 replies; 204+ messages in thread
From: Mattia Dongili @ 2006-11-19 16:22 UTC (permalink / raw)
To: Stefan Richter
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
[...]
> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
> broken-out/gregkh-driver-sysfs-crash-debugging.patch
> broken-out/gregkh-driver-udev-compatible-hack.patch
Very close :) But no, the winner is...
gregkh-driver-network-device.patch
--
mattia
:wq!
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-19 16:22 ` ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)] Mattia Dongili
@ 2006-11-19 17:13 ` Stefan Richter
2006-11-19 20:33 ` Andrew Morton
2006-11-19 17:14 ` Gene Heskett
1 sibling, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-19 17:13 UTC (permalink / raw)
To: Mattia Dongili
Cc: Greg KH, Andrew Morton, linux-kernel, linux1394-devel, bcollins
Mattia Dongili wrote:
> the winner is... gregkh-driver-network-device.patch
Interesting. Looks very much like eth1394's sysfs interface is getting
in the way. And since it is entirely handled by the ieee1394 core, it
means ieee1394 needs the class_dev to dev treatment. I think it's OK if
we just wait for Greg to finish his preliminary patch. Until then,
CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
eth1394 broken or removes gregkh-driver-network-device.patch...)
Mattia, thanks for the many tests.
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-19 17:13 ` Stefan Richter
@ 2006-11-19 20:33 ` Andrew Morton
2006-11-19 21:01 ` Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-19 20:33 UTC (permalink / raw)
To: Stefan Richter
Cc: Mattia Dongili, Greg KH, linux-kernel, linux1394-devel, bcollins
On Sun, 19 Nov 2006 18:13:45 +0100
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Mattia Dongili wrote:
> > the winner is... gregkh-driver-network-device.patch
That was a fair bet - that patch has caused a mountain of grief.
> Interesting. Looks very much like eth1394's sysfs interface is getting
> in the way. And since it is entirely handled by the ieee1394 core, it
> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
> we just wait for Greg to finish his preliminary patch. Until then,
> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
> eth1394 broken or removes gregkh-driver-network-device.patch...)
Do we know what's actually wrong, and what needs to be done about it?
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-19 20:33 ` Andrew Morton
@ 2006-11-19 21:01 ` Stefan Richter
2006-11-24 8:41 ` Greg KH
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-19 21:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, linux1394-devel, bcollins, linux-kernel, Greg KH
Andrew Morton wrote:
> On Sun, 19 Nov 2006 18:13:45 +0100
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Looks very much like eth1394's sysfs interface is getting
>> in the way. And since it is entirely handled by the ieee1394 core, it
>> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
>> we just wait for Greg to finish his preliminary patch. Until then,
>> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
>> eth1394 broken or removes gregkh-driver-network-device.patch...)
>
> Do we know what's actually wrong, and what needs to be done about it?
I for one don't know what's needed precisely. But at the moment I
actually don't want to spend any more time on this because:
- It happens only if ohci1394 is unloaded while eth1394 is loaded.
(That's not an unusual condition though.)
- It happens only in -mm, and only because -mm contains the work-in-
progress patches for class_device -> device transition.
I expect it to go away automatically once Greg is done with the
transition. It seems Greg is the one to do it :-), at least I'm not
available right now to lend a hand. There are older ieee1394 bugs in
mainline with bigger practical impact for me to work on. If there are
still issues once ieee1394 was converted away from class_device, I'm OK
with revisiting it.
(Besides, if anybody wants to become eth1394 maintainer, please step up.
MAINTAINERS currently lists eth1394 as in "Odd fixes" mode.)
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-19 21:01 ` Stefan Richter
@ 2006-11-24 8:41 ` Greg KH
2006-11-24 17:13 ` Stefan Richter
0 siblings, 1 reply; 204+ messages in thread
From: Greg KH @ 2006-11-24 8:41 UTC (permalink / raw)
To: Stefan Richter
Cc: Andrew Morton, Mattia Dongili, linux1394-devel, bcollins,
linux-kernel
On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
> Andrew Morton wrote:
> > On Sun, 19 Nov 2006 18:13:45 +0100
> > Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> >> Looks very much like eth1394's sysfs interface is getting
> >> in the way. And since it is entirely handled by the ieee1394 core, it
> >> means ieee1394 needs the class_dev to dev treatment. I think it's OK if
> >> we just wait for Greg to finish his preliminary patch. Until then,
> >> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks
> >> eth1394 broken or removes gregkh-driver-network-device.patch...)
> >
> > Do we know what's actually wrong, and what needs to be done about it?
>
> I for one don't know what's needed precisely. But at the moment I
> actually don't want to spend any more time on this because:
> - It happens only if ohci1394 is unloaded while eth1394 is loaded.
> (That's not an unusual condition though.)
Yes, I can trigger this quite easily here now.
> - It happens only in -mm, and only because -mm contains the work-in-
> progress patches for class_device -> device transition.
> I expect it to go away automatically once Greg is done with the
> transition. It seems Greg is the one to do it :-), at least I'm not
> available right now to lend a hand. There are older ieee1394 bugs in
> mainline with bigger practical impact for me to work on. If there are
> still issues once ieee1394 was converted away from class_device, I'm OK
> with revisiting it.
I'll hold off on submitting the network change to mainline until I fix
this problem, so it might be a while...
thanks for narrowing it down for me.
greg k-h
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-24 8:41 ` Greg KH
@ 2006-11-24 17:13 ` Stefan Richter
0 siblings, 0 replies; 204+ messages in thread
From: Stefan Richter @ 2006-11-24 17:13 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Mattia Dongili, linux1394-devel, bcollins,
linux-kernel
Greg KH wrote:
> On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
...
>> at the moment I actually don't want to spend any more time on this
...
>> There are older ieee1394 bugs in
>> mainline with bigger practical impact for me to work on. If there are
>> still issues once ieee1394 was converted away from class_device, I'm OK
>> with revisiting it.
>
> I'll hold off on submitting the network change to mainline until I fix
> this problem, so it might be a while...
In case you find the ieee1394 stack doing weird things to the driver
core, point it out. I'm not good at analyzing and (re)designing such
things but I might be able to contribute once I'm given clear
directions. ;-)
--
Stefan Richter
-=====-=-==- =-== ==---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]
2006-11-19 16:22 ` ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)] Mattia Dongili
2006-11-19 17:13 ` Stefan Richter
@ 2006-11-19 17:14 ` Gene Heskett
2006-11-19 18:07 ` Kino segfault (was Re: ohci1394 oops bisected) Stefan Richter
1 sibling, 1 reply; 204+ messages in thread
From: Gene Heskett @ 2006-11-19 17:14 UTC (permalink / raw)
To: linux-kernel
Cc: Mattia Dongili, Stefan Richter, Greg KH, Andrew Morton,
linux1394-devel, bcollins
On Sunday 19 November 2006 11:22, Mattia Dongili wrote:
>On Sat, Nov 18, 2006 at 10:45:01PM +0100, Stefan Richter wrote:
>[...]
>
>> broken-out/gregkh-driver-config_sysfs_deprecated-bus.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-class.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-device.patch
>> broken-out/gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
>> broken-out/gregkh-driver-driver-link-sysfs-timing.patch
>> broken-out/gregkh-driver-sysfs-crash-debugging.patch
>> broken-out/gregkh-driver-udev-compatible-hack.patch
>
>Very close :) But no, the winner is...
>gregkh-driver-network-device.patch
If this has anything to do with kino segfaulting and going away when
trying to make use of the on-screen camera motion controls, please see to
it that it gets incorporated into the next FC6 kernel release, its badly
needed for us ieee1394 users.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Kino segfault (was Re: ohci1394 oops bisected)
2006-11-19 17:14 ` Gene Heskett
@ 2006-11-19 18:07 ` Stefan Richter
2006-11-19 20:11 ` Gene Heskett
0 siblings, 1 reply; 204+ messages in thread
From: Stefan Richter @ 2006-11-19 18:07 UTC (permalink / raw)
To: Gene Heskett
Cc: linux-kernel, Mattia Dongili, Greg KH, Andrew Morton,
linux1394-devel, bcollins
Gene Heskett wrote:
> If this has anything to do with kino segfaulting and going away when
> trying to make use of the on-screen camera motion controls, please see to
> it that it gets incorporated into the next FC6 kernel release, its badly
> needed for us ieee1394 users.
No, it's very probably unrelated. You could report Kino related bugs via
www.kinodv.org --- or on bugzilla.redhat.com if it's merely an issue
with the distributed versions of Kino/ libraries/ kernel.
--
Stefan Richter
-=====-=-==- =-== =--==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: Kino segfault (was Re: ohci1394 oops bisected)
2006-11-19 18:07 ` Kino segfault (was Re: ohci1394 oops bisected) Stefan Richter
@ 2006-11-19 20:11 ` Gene Heskett
0 siblings, 0 replies; 204+ messages in thread
From: Gene Heskett @ 2006-11-19 20:11 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Richter, Mattia Dongili, Greg KH, Andrew Morton,
linux1394-devel, bcollins
On Sunday 19 November 2006 13:07, Stefan Richter wrote:
>Gene Heskett wrote:
>> If this has anything to do with kino segfaulting and going away when
>> trying to make use of the on-screen camera motion controls, please see
>> to it that it gets incorporated into the next FC6 kernel release, its
>> badly needed for us ieee1394 users.
>
>No, it's very probably unrelated. You could report Kino related bugs via
>www.kinodv.org --- or on bugzilla.redhat.com if it's merely an issue
>with the distributed versions of Kino/ libraries/ kernel.
Dan is aware of my problem(s) but cannot duplicate them on his system.
That is the first place I took my problem to.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] crypto/xcbc.c: make some code static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (11 preceding siblings ...)
2006-11-16 17:17 ` 2.6.19-rc5-mm2 Mattia Dongili
@ 2006-11-17 1:19 ` Adrian Bunk
2006-11-17 2:44 ` Herbert Xu
2006-11-17 1:19 ` [-mm patch] make drivers/acpi/bay.c:drive_bays static Adrian Bunk
` (21 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 1:19 UTC (permalink / raw)
To: Andrew Morton, herbert; +Cc: linux-kernel, linux-crypto
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
crypto/xcbc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.19-rc5-mm2/crypto/xcbc.c.old 2006-11-16 22:56:01.000000000 +0100
+++ linux-2.6.19-rc5-mm2/crypto/xcbc.c 2006-11-16 22:57:12.000000000 +0100
@@ -28,9 +28,9 @@
#include <linux/scatterlist.h>
#include "internal.h"
-u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
- 0x02020202, 0x02020202, 0x02020202, 0x02020202,
- 0x03030303, 0x03030303, 0x03030303, 0x03030303};
+static u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
+ 0x02020202, 0x02020202, 0x02020202, 0x02020202,
+ 0x03030303, 0x03030303, 0x03030303, 0x03030303};
/*
* +------------------------
* | <parent tfm>
@@ -96,7 +96,7 @@
return _crypto_xcbc_digest_setkey(parent, ctx);
}
-int crypto_xcbc_digest_init(struct hash_desc *pdesc)
+static int crypto_xcbc_digest_init(struct hash_desc *pdesc)
{
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(pdesc->tfm);
int bs = crypto_hash_blocksize(pdesc->tfm);
@@ -108,7 +108,9 @@
return 0;
}
-int crypto_xcbc_digest_update(struct hash_desc *pdesc, struct scatterlist *sg, unsigned int nbytes)
+static int crypto_xcbc_digest_update(struct hash_desc *pdesc,
+ struct scatterlist *sg,
+ unsigned int nbytes)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
@@ -181,7 +183,7 @@
return 0;
}
-int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
+static int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] make drivers/acpi/bay.c:drive_bays static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (12 preceding siblings ...)
2006-11-17 1:19 ` [-mm patch] crypto/xcbc.c: make some code static Adrian Bunk
@ 2006-11-17 1:19 ` Adrian Bunk
2006-11-17 1:19 ` [-mm patch] make drivers/base/core.c:setup_parent() static Adrian Bunk
` (20 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 1:19 UTC (permalink / raw)
To: Andrew Morton, len.brown; +Cc: linux-kernel, linux-acpi
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-acpi.patch
>...
> git trees
>...
This patch makes the needlessly global "drive_bays" static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/drivers/acpi/bay.c.old 2006-11-16 23:03:28.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/acpi/bay.c 2006-11-16 23:03:38.000000000 +0100
@@ -70,7 +70,7 @@
struct proc_dir_entry *proc;
};
-LIST_HEAD(drive_bays);
+static LIST_HEAD(drive_bays);
static struct proc_dir_entry *acpi_bay_dir;
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] make drivers/base/core.c:setup_parent() static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (13 preceding siblings ...)
2006-11-17 1:19 ` [-mm patch] make drivers/acpi/bay.c:drive_bays static Adrian Bunk
@ 2006-11-17 1:19 ` Adrian Bunk
2006-11-17 1:19 ` [-mm patch] make geode_aes_crypt() static Adrian Bunk
` (19 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 1:19 UTC (permalink / raw)
To: Andrew Morton, Greg Kroah-Hartman; +Cc: linux-kernel
This patch makes the needlessly global setup_parent() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/drivers/base/core.c.old 2006-11-16 23:14:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/base/core.c 2006-11-16 23:14:56.000000000 +0100
@@ -389,7 +389,7 @@
}
#ifdef CONFIG_SYSFS_DEPRECATED
-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
/* Set the parent to the class, not the parent device */
/* this keeps sysfs from having a symlink to make old udevs happy */
@@ -418,7 +418,7 @@
return 0;
}
-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
int error;
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] make geode_aes_crypt() static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (14 preceding siblings ...)
2006-11-17 1:19 ` [-mm patch] make drivers/base/core.c:setup_parent() static Adrian Bunk
@ 2006-11-17 1:19 ` Adrian Bunk
2006-11-17 12:42 ` -mm: cx88-blackbird.c: unused code re-added Adrian Bunk
` (18 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 1:19 UTC (permalink / raw)
To: Andrew Morton, Jordan Crouse, herbert; +Cc: linux-kernel, davem
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...
This patch makes the needlessly global geode_aes_crypt() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/crypto/geode-aes.c | 2 +-
drivers/crypto/geode-aes.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h.old 2006-11-16 23:17:43.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h 2006-11-16 23:17:57.000000000 +0100
@@ -37,6 +37,4 @@
u8 iv[AES_IV_LENGTH];
};
-unsigned int geode_aes_crypt(struct geode_aes_op *);
-
#endif
--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c.old 2006-11-16 23:17:12.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c 2006-11-16 23:17:38.000000000 +0100
@@ -97,7 +97,7 @@
return counter ? 0 : 1;
}
-unsigned int
+static unsigned int
geode_aes_crypt(struct geode_aes_op *op)
{
^ permalink raw reply [flat|nested] 204+ messages in thread* -mm: cx88-blackbird.c: unused code re-added
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (15 preceding siblings ...)
2006-11-17 1:19 ` [-mm patch] make geode_aes_crypt() static Adrian Bunk
@ 2006-11-17 12:42 ` Adrian Bunk
2006-11-17 13:53 ` [v4l-dvb-maintainer] " Michael Krufky
2006-11-17 14:13 ` Mauro Carvalho Chehab
2006-11-17 14:21 ` [-mm patch] drivers/media/video/cafe_ccic.c: make a function static Adrian Bunk
` (17 subsequent siblings)
34 siblings, 2 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 12:42 UTC (permalink / raw)
To: Andrew Morton, v4l-dvb-maintainer; +Cc: linux-kernel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-dvb.patch
>...
> git trees
>...
Why does this patch re-add the still unused cx88_ioctl_hook and
cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
I removed a few months ago?
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] 204+ messages in thread* Re: [v4l-dvb-maintainer] -mm: cx88-blackbird.c: unused code re-added
2006-11-17 12:42 ` -mm: cx88-blackbird.c: unused code re-added Adrian Bunk
@ 2006-11-17 13:53 ` Michael Krufky
2006-11-17 14:13 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 204+ messages in thread
From: Michael Krufky @ 2006-11-17 13:53 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, v4l-dvb-maintainer, linux-kernel,
Mauro Carvalho Chehab
Adrian Bunk wrote:
>On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>
>
>>...
>>Changes since 2.6.19-rc5-mm2:
>>...
>> git-dvb.patch
>>...
>> git trees
>>...
>>
>>
>
>Why does this patch re-add the still unused cx88_ioctl_hook and
>cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
>I removed a few months ago?
>
Adrian,
I have added those hooks back into the driver, because they are needed
for the cx88-ivtv ioctl emulation layer. However, I have instructed
Mauro not to merge that patch upstream -- it is meant to stay at our
mercurial repository only, since the vanilla kernel does not need to use
the cx88-ivtv ioctl emulation layer.
It looks like somehow these got into -mm ... I think that is because
Andrew's scripts pull from Mauro's devel branch in his git tree.
The problem commit is: de513acdbafc48c52017255fee02af727dcfcc32
It appears that Mauro has folded my patch into Steve's patch, which he
should not have done. :-( What a mess!
I will send a new patch to Mauro later on today to be applied to his git
devel branch, which will remove those hooks again.
As soon as ivtv gets merged into our tree, that's when we will be able
to remove cx88-ivtv alltogether, as there will no longer be any need to
support the ivtv API.
regards,
Mike Krufky
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [v4l-dvb-maintainer] -mm: cx88-blackbird.c: unused code re-added
2006-11-17 12:42 ` -mm: cx88-blackbird.c: unused code re-added Adrian Bunk
2006-11-17 13:53 ` [v4l-dvb-maintainer] " Michael Krufky
@ 2006-11-17 14:13 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 204+ messages in thread
From: Mauro Carvalho Chehab @ 2006-11-17 14:13 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, v4l-dvb-maintainer, linux-kernel
Hi Adrian,
Em Sex, 2006-11-17 às 13:42 +0100, Adrian Bunk escreveu:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-dvb.patch
> >...
> > git trees
> >...
>
> Why does this patch re-add the still unused cx88_ioctl_hook and
> cx88_ioctl_translator in drivers/media/video/cx88/cx88-blackbird.c
> I removed a few months ago?
Hmm... I think I sent to my -git the patch that reenables it.
Let me explain a little bit about those hooks.
As you know, ivtv is being re-worked to be inserted at kernel. This
includes a complete API review of several ivtv calls. Some of they were
providing stuff already at V4L2 API, but implemented on a different way.
This turned into a huge project, being delayed with the first scheduling
time. First, we've migrated all i2c drivers. Then mpeg decoding. Now, we
are working at mpeg encoding part.
cx88-blackbird provides mpeg outputs for analog tv, in a similar way as
ivtv devices. However, some userspace apps were not implementing the
experimental mpeg support added at V4L2 api for mpeg streams, but
instead, were using an API developed for ivtv.
We received a patch for a cx88-ivtv module that allows using
ivtv-enabled programs to work with cx88-blackbird.
To avoid causing later regressions of removing IVTV API calls from
kernel, we decided to create the hooks at kernel, and having cx88-ivtv
only at v4l-dvb tree. The proper API calls will be added as soon as ivtv
driver will be finished and the proper api is available to be
incorporated at cx88-blackbird.
Anyway, I've redesigned cx88 to use video_ioctl2 interface, who is
incompatible with the hooks. The newer approach is at:
http://www.linuxtv.org/hg/~mchehab/cx88_ioctls
After merging this branch into the v4l-dvb tree, the patches will be
removed. I intend to apply those changes to 2.6.20, so, there's no need
to worry about this stuff.
>
> cu
> Adrian
>
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] drivers/media/video/cafe_ccic.c: make a function static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (16 preceding siblings ...)
2006-11-17 12:42 ` -mm: cx88-blackbird.c: unused code re-added Adrian Bunk
@ 2006-11-17 14:21 ` Adrian Bunk
2006-11-17 14:21 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Adrian Bunk
` (16 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 14:21 UTC (permalink / raw)
To: Andrew Morton, corbet, v4l-dvb-maintainer; +Cc: linux-kernel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-dvb.patch
>...
> git trees
>...
This patch makes the needlessly global cafe_v4l_dev_release() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/drivers/media/video/cafe_ccic.c.old 2006-11-17 13:13:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/media/video/cafe_ccic.c 2006-11-17 13:13:57.000000000 +0100
@@ -1688,7 +1688,7 @@
};
-void cafe_v4l_dev_release(struct video_device *vd)
+static void cafe_v4l_dev_release(struct video_device *vd)
{
struct cafe_camera *cam = container_of(vd, struct cafe_camera, v4ldev);
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (17 preceding siblings ...)
2006-11-17 14:21 ` [-mm patch] drivers/media/video/cafe_ccic.c: make a function static Adrian Bunk
@ 2006-11-17 14:21 ` Adrian Bunk
2006-11-17 14:32 ` Alan Cox
2006-11-17 19:54 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Andrew Morton
2006-11-17 17:02 ` [-mm patch] make net/core/skbuff.c:skb_over_panic() static Adrian Bunk
` (15 subsequent siblings)
34 siblings, 2 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 14:21 UTC (permalink / raw)
To: Andrew Morton, gregkh; +Cc: linux-kernel, linux-pci, Alan Cox
This patch removes the no longer used pci_find_device_reverse().
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/pci/search.c | 38 --------------------------------------
include/linux/pci.h | 1 -
2 files changed, 39 deletions(-)
--- linux-2.6.19-rc5-mm2/include/linux/pci.h.old 2006-11-17 13:52:21.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/pci.h 2006-11-17 13:52:30.000000000 +0100
@@ -442,7 +442,6 @@
/* Generic PCI functions exported to card drivers */
struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
-struct pci_dev *pci_find_device_reverse (unsigned int vendor, unsigned int device, const struct pci_dev *from);
struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn);
int pci_find_capability (struct pci_dev *dev, int cap);
int pci_find_next_capability (struct pci_dev *dev, u8 pos, int cap);
--- linux-2.6.19-rc5-mm2/drivers/pci/search.c.old 2006-11-17 13:52:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/pci/search.c 2006-11-17 13:52:52.000000000 +0100
@@ -340,43 +340,6 @@
}
/**
- * pci_find_device_reverse - begin or continue searching for a PCI device by vendor/device id
- * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
- * @device: PCI device id to match, or %PCI_ANY_ID to match all device ids
- * @from: Previous PCI device found in search, or %NULL for new search.
- *
- * Iterates through the list of known PCI devices in the reverse order of
- * pci_find_device().
- * If a PCI device is found with a matching @vendor and @device, a pointer to
- * its device structure is returned. Otherwise, %NULL is returned.
- * A new search is initiated by passing %NULL as the @from argument.
- * Otherwise if @from is not %NULL, searches continue from previous device
- * on the global list.
- */
-struct pci_dev *
-pci_find_device_reverse(unsigned int vendor, unsigned int device, const struct pci_dev *from)
-{
- struct list_head *n;
- struct pci_dev *dev;
-
- WARN_ON(in_interrupt());
- down_read(&pci_bus_sem);
- n = from ? from->global_list.prev : pci_devices.prev;
-
- while (n && (n != &pci_devices)) {
- dev = pci_dev_g(n);
- if ((vendor == PCI_ANY_ID || dev->vendor == vendor) &&
- (device == PCI_ANY_ID || dev->device == device))
- goto exit;
- n = n->prev;
- }
- dev = NULL;
-exit:
- up_read(&pci_bus_sem);
- return dev;
-}
-
-/**
* pci_get_class - begin or continue searching for a PCI device by class
* @class: search for a PCI device with this class designation
* @from: Previous PCI device found in search, or %NULL for new search.
@@ -447,7 +410,6 @@
EXPORT_SYMBOL(pci_dev_present);
EXPORT_SYMBOL(pci_find_device);
-EXPORT_SYMBOL(pci_find_device_reverse);
EXPORT_SYMBOL(pci_find_slot);
/* For boot time work */
EXPORT_SYMBOL(pci_find_bus);
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-17 14:21 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Adrian Bunk
@ 2006-11-17 14:32 ` Alan Cox
2006-11-18 0:06 ` [2.6 patch] mark pci_find_device() as __deprecated Adrian Bunk
2006-11-17 19:54 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Andrew Morton
1 sibling, 1 reply; 204+ messages in thread
From: Alan Cox @ 2006-11-17 14:32 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, gregkh, linux-kernel, linux-pci, Alan Cox
On Fri, Nov 17, 2006 at 03:21:45PM +0100, Adrian Bunk wrote:
> This patch removes the no longer used pci_find_device_reverse().
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Alan Cox <alan@redhat.com>
Soon we should deprecate pci_find_device as well
^ permalink raw reply [flat|nested] 204+ messages in thread
* [2.6 patch] mark pci_find_device() as __deprecated
2006-11-17 14:32 ` Alan Cox
@ 2006-11-18 0:06 ` Adrian Bunk
2006-11-18 1:42 ` Alan
2006-11-19 9:47 ` Arjan van de Ven
0 siblings, 2 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-18 0:06 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, gregkh, linux-kernel, linux-pci
On Fri, Nov 17, 2006 at 09:32:36AM -0500, Alan Cox wrote:
> On Fri, Nov 17, 2006 at 03:21:45PM +0100, Adrian Bunk wrote:
> > This patch removes the no longer used pci_find_device_reverse().
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Acked-by: Alan Cox <alan@redhat.com>
>
> Soon we should deprecate pci_find_device as well
So let's mark it as __deprecated now, which also has the side effect
that noone can later whine that removing it might break some shiny
external modules.
Oh, and if anything starts complaining "But this adds some warnings to
my kernel build!", he should either first fix the 200 kB (sic) of
warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/include/linux/pci.h.old 2006-11-18 01:03:27.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/pci.h 2006-11-18 01:05:46.000000000 +0100
@@ -441,7 +441,7 @@
/* Generic PCI functions exported to card drivers */
-struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
+struct pci_dev __deprecated *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from);
struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn);
int pci_find_capability (struct pci_dev *dev, int cap);
int pci_find_next_capability (struct pci_dev *dev, u8 pos, int cap);
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-18 0:06 ` [2.6 patch] mark pci_find_device() as __deprecated Adrian Bunk
@ 2006-11-18 1:42 ` Alan
2006-11-19 9:47 ` Arjan van de Ven
1 sibling, 0 replies; 204+ messages in thread
From: Alan @ 2006-11-18 1:42 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Alan Cox, Andrew Morton, gregkh, linux-kernel, linux-pci
On Sat, 18 Nov 2006 01:06:29 +0100
> Oh, and if anything starts complaining "But this adds some warnings to
> my kernel build!", he should either first fix the 200 kB (sic) of
> warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
The only significant user remaining is the old ISDN code so it doesn't
create too many of them.
Acked-by: Alan Cox <alan@redhat.com>
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-18 0:06 ` [2.6 patch] mark pci_find_device() as __deprecated Adrian Bunk
2006-11-18 1:42 ` Alan
@ 2006-11-19 9:47 ` Arjan van de Ven
2006-11-19 9:52 ` Muli Ben-Yehuda
2006-11-19 14:04 ` Adrian Bunk
1 sibling, 2 replies; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-19 9:47 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Alan Cox, Andrew Morton, gregkh, linux-kernel, linux-pci
>
> Oh, and if anything starts complaining "But this adds some warnings to
> my kernel build!", he should either first fix the 200 kB (sic) of
> warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
we can solve this btw; we could have a
#define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
that would turn __deprecated into a nop for those few legacy modules
inside the kernel that nobody really is looking after.
(and yes the define should be really offensive so that nobody will put
it in a maintained module, and maybe it should even cause the kernel to
printk something when such a module gets loaded into the kernel)
If this sounds like a good idea I'll code it up...
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 9:47 ` Arjan van de Ven
@ 2006-11-19 9:52 ` Muli Ben-Yehuda
2006-11-19 10:01 ` Arjan van de Ven
2006-11-19 14:06 ` Adrian Bunk
2006-11-19 14:04 ` Adrian Bunk
1 sibling, 2 replies; 204+ messages in thread
From: Muli Ben-Yehuda @ 2006-11-19 9:52 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Adrian Bunk, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
>
> >
> > Oh, and if anything starts complaining "But this adds some warnings to
> > my kernel build!", he should either first fix the 200 kB (sic) of
> > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> we can solve this btw; we could have a
>
> #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
>
> that would turn __deprecated into a nop for those few legacy modules
> inside the kernel that nobody really is looking after.
If no one is looking after them, shouldn't they just be removed?
Cheers,
Muli
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 9:52 ` Muli Ben-Yehuda
@ 2006-11-19 10:01 ` Arjan van de Ven
2006-11-19 14:06 ` Adrian Bunk
1 sibling, 0 replies; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-19 10:01 UTC (permalink / raw)
To: Muli Ben-Yehuda
Cc: Adrian Bunk, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, 2006-11-19 at 11:52 +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >
> > that would turn __deprecated into a nop for those few legacy modules
> > inside the kernel that nobody really is looking after.
>
> If no one is looking after them, shouldn't they just be removed?
that's a whole different flamewar, esp if they sort of kinda mostly work
if the moon is aligned properly with Mars.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 9:52 ` Muli Ben-Yehuda
2006-11-19 10:01 ` Arjan van de Ven
@ 2006-11-19 14:06 ` Adrian Bunk
2006-11-19 15:24 ` Muli Ben-Yehuda
1 sibling, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-19 14:06 UTC (permalink / raw)
To: Muli Ben-Yehuda
Cc: Arjan van de Ven, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, Nov 19, 2006 at 11:52:58AM +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >
> > that would turn __deprecated into a nop for those few legacy modules
> > inside the kernel that nobody really is looking after.
>
> If no one is looking after them, shouldn't they just be removed?
unmaintained != not used
As an example, some people might be unhappy if the floppy driver that is
unmaintained for ages and not in a good state was removed.
> Cheers,
> Muli
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] 204+ messages in thread* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 14:06 ` Adrian Bunk
@ 2006-11-19 15:24 ` Muli Ben-Yehuda
2006-11-19 15:49 ` Adrian Bunk
2006-11-19 16:50 ` Arjan van de Ven
0 siblings, 2 replies; 204+ messages in thread
From: Muli Ben-Yehuda @ 2006-11-19 15:24 UTC (permalink / raw)
To: Adrian Bunk
Cc: Arjan van de Ven, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
> unmaintained != not used
>
> As an example, some people might be unhappy if the floppy driver that is
> unmaintained for ages and not in a good state was removed.
I understand. However, if it was slated to be removed, said people
might be inclined to start maintaining it. We have a bar for inclusion
of new code into the tree - why shouldn't a quality bar also be
applied to old code in the tree?
Cheers,
Muli
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 15:24 ` Muli Ben-Yehuda
@ 2006-11-19 15:49 ` Adrian Bunk
2006-11-19 16:50 ` Arjan van de Ven
1 sibling, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-19 15:49 UTC (permalink / raw)
To: Muli Ben-Yehuda
Cc: Arjan van de Ven, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, Nov 19, 2006 at 05:24:21PM +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
>
> > unmaintained != not used
> >
> > As an example, some people might be unhappy if the floppy driver that is
> > unmaintained for ages and not in a good state was removed.
>
> I understand. However, if it was slated to be removed, said people
> might be inclined to start maintaining it.
Most Linux users weren't able to maintain any peace of kernel code even
if they wanted to.
> We have a bar for inclusion
> of new code into the tree - why shouldn't a quality bar also be
> applied to old code in the tree?
Removing an older unmaintained but working driver is from a user's point
of view a regression that locks this user into using an older kernel.
> Cheers,
> Muli
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] 204+ messages in thread* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 15:24 ` Muli Ben-Yehuda
2006-11-19 15:49 ` Adrian Bunk
@ 2006-11-19 16:50 ` Arjan van de Ven
1 sibling, 0 replies; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-19 16:50 UTC (permalink / raw)
To: Muli Ben-Yehuda
Cc: Adrian Bunk, Alan Cox, Andrew Morton, gregkh, linux-kernel,
linux-pci
On Sun, 2006-11-19 at 17:24 +0200, Muli Ben-Yehuda wrote:
> On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
>
> > unmaintained != not used
> >
> > As an example, some people might be unhappy if the floppy driver that is
> > unmaintained for ages and not in a good state was removed.
>
> I understand. However, if it was slated to be removed, said people
> might be inclined to start maintaining it. We have a bar for inclusion
> of new code into the tree - why shouldn't a quality bar also be
> applied to old code in the tree?
this bypasses the convenient fact that there are 2 types of
unmaintained:
1) Drivers that barely, if at all, limp along and nobody has hw for
2) Drivers that no one person is the declared maintainer, but which do
get fixed when they break by "someone"
floppy.c is of the later kind; the hardware is widespread enough to make
that feasible I suppose; while the former kind are mostly ISA slot cards
that virtually nobody has (or only people who can't or don't want to
care about the linux kernel driver; a bunch of serial expander drivers
and a whole lot of the ISDN drivers falls in this category)
marking the category 1) drivers that limp along as "don't warn on
deprecated" is sort of fair; they're not far enough down deathrow yet
that they can be removed entirely, yet they also shouldn't clutter up
the build logs and they shouldn't prevent us from deprecating APIs that
are truely broken (*_sleep_on(), cli() etc) in 2.6 kernels...
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 9:47 ` Arjan van de Ven
2006-11-19 9:52 ` Muli Ben-Yehuda
@ 2006-11-19 14:04 ` Adrian Bunk
2006-11-19 14:13 ` Arjan van de Ven
1 sibling, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-19 14:04 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Cox, Andrew Morton, gregkh, linux-kernel, linux-pci
On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
>
> >
> > Oh, and if anything starts complaining "But this adds some warnings to
> > my kernel build!", he should either first fix the 200 kB (sic) of
> > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
>
> we can solve this btw; we could have a
>
> #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
>...
The few warnings by __deprecated are not that much of a problem.
But the > 200 kB starting at MODPOST in -mm are really annoying.
And it seems noone cares about them.
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] 204+ messages in thread* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 14:04 ` Adrian Bunk
@ 2006-11-19 14:13 ` Arjan van de Ven
2006-11-19 14:27 ` Adrian Bunk
0 siblings, 1 reply; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-19 14:13 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Alan Cox, Andrew Morton, gregkh, linux-kernel, linux-pci
On Sun, 2006-11-19 at 15:04 +0100, Adrian Bunk wrote:
> On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> >
> > >
> > > Oh, and if anything starts complaining "But this adds some warnings to
> > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> >
> > we can solve this btw; we could have a
> >
> > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> >...
>
> The few warnings by __deprecated are not that much of a problem.
yes they are; the current situation prevents things that are used in
only a set of old unmaintained legacy drivers (read: ISDN) as being
marked __deprecated because they add too many warnings, while the API
really should be marked deprecated..
think for example the entire sleep_on() family of API's (which basically
are impossible to use race-free in 2.6)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [2.6 patch] mark pci_find_device() as __deprecated
2006-11-19 14:13 ` Arjan van de Ven
@ 2006-11-19 14:27 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-19 14:27 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Cox, Andrew Morton, gregkh, linux-kernel, linux-pci
On Sun, Nov 19, 2006 at 03:13:04PM +0100, Arjan van de Ven wrote:
> On Sun, 2006-11-19 at 15:04 +0100, Adrian Bunk wrote:
> > On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
> > >
> > > >
> > > > Oh, and if anything starts complaining "But this adds some warnings to
> > > > my kernel build!", he should either first fix the 200 kB (sic) of
> > > > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
> > >
> > > we can solve this btw; we could have a
> > >
> > > #define THIS_MODULE_IS_LEGACY_CRAP_AND_WONT_GET_FIXED
> > >...
> >
> > The few warnings by __deprecated are not that much of a problem.
>
> yes they are; the current situation prevents things that are used in
> only a set of old unmaintained legacy drivers (read: ISDN) as being
ISDN at least has reachable maintainers.
There are much worse drivers in the kernel.
> marked __deprecated because they add too many warnings, while the API
> really should be marked deprecated..
>
> think for example the entire sleep_on() family of API's (which basically
> are impossible to use race-free in 2.6)
At about 100 warnings with an allyesconfig kernel build and less than a
handful of warnings with a normal .config .
That's not that bad, and it might result in even these legacy drivers
getting fixed so that the API can be completely removed.
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] 204+ messages in thread
* Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-17 14:21 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Adrian Bunk
2006-11-17 14:32 ` Alan Cox
@ 2006-11-17 19:54 ` Andrew Morton
2006-11-17 20:33 ` Adrian Bunk
` (2 more replies)
1 sibling, 3 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-17 19:54 UTC (permalink / raw)
To: Adrian Bunk; +Cc: gregkh, linux-kernel, linux-pci, Alan Cox
On Fri, 17 Nov 2006 15:21:45 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> This patch removes the no longer used pci_find_device_reverse().
But it is exported to modules.
This is what we created EXPORT_UNUSED_SYMBOL() for.
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-17 19:54 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Andrew Morton
@ 2006-11-17 20:33 ` Adrian Bunk
2006-11-17 22:16 ` Alan Cox
2006-11-19 9:44 ` Arjan van de Ven
2 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 20:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: gregkh, linux-kernel, linux-pci, Alan Cox
On Fri, Nov 17, 2006 at 11:54:04AM -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 15:21:45 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the no longer used pci_find_device_reverse().
>
> But it is exported to modules.
>
> This is what we created EXPORT_UNUSED_SYMBOL() for.
The fact that noone uses it (except for the 8 symbols I marked in June)
might be a good indication that it doesn't fit into the current kernel
development model:
- there is no stable kernel API and
- we lack a strict process for reviewing _every single_ newly added
export - especially the many that get added without any in-kernel user
And if you'd take your EXPORT_UNUSED_SYMBOL() serious, any changes to
the signatures of exported functions had to be strictly forbidden.
Please do either make strong promises about the API for external modules
with all consequences or allow all API changes immediately.
But you currently allowing API changes at any time while putting high
obstacles for my cleanup patches to remove code with zero in-kernel
users is very close to a personal offense.
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] 204+ messages in thread* Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-17 19:54 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Andrew Morton
2006-11-17 20:33 ` Adrian Bunk
@ 2006-11-17 22:16 ` Alan Cox
2006-11-19 9:44 ` Arjan van de Ven
2 siblings, 0 replies; 204+ messages in thread
From: Alan Cox @ 2006-11-17 22:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adrian Bunk, gregkh, linux-kernel, linux-pci, Alan Cox
On Fri, Nov 17, 2006 at 11:54:04AM -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 15:21:45 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the no longer used pci_find_device_reverse().
>
> But it is exported to modules.
>
> This is what we created EXPORT_UNUSED_SYMBOL() for.
Normally - but for the fact pci_find_device{_reverse} is unsafe on
any box with any kind of pci hotplug events.
It really needs to die. It is not hotplug safe. The alternative would be
to export it only with !CONFIG_HOTPLUG (which is what my test kernel
does for both this and pci_find_device()). If we do that then to all
intents and purposes it vanishes from most standard builds
The conversion is also trivial
Alan
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse()
2006-11-17 19:54 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Andrew Morton
2006-11-17 20:33 ` Adrian Bunk
2006-11-17 22:16 ` Alan Cox
@ 2006-11-19 9:44 ` Arjan van de Ven
2 siblings, 0 replies; 204+ messages in thread
From: Arjan van de Ven @ 2006-11-19 9:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adrian Bunk, gregkh, linux-kernel, linux-pci, Alan Cox
On Fri, 2006-11-17 at 11:54 -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 15:21:45 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > This patch removes the no longer used pci_find_device_reverse().
>
> But it is exported to modules.
and no module uses it ;)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] make net/core/skbuff.c:skb_over_panic() static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (18 preceding siblings ...)
2006-11-17 14:21 ` [-mm patch] remove drivers/pci/search.c:pci_find_device_reverse() Adrian Bunk
@ 2006-11-17 17:02 ` Adrian Bunk
2006-11-21 0:55 ` David Miller
2006-11-17 17:02 ` [-mm patch] security/slim/slm_main.c: make 2 functions static Adrian Bunk
` (14 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 17:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev
skb_over_panic() can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
Note:
This patch depends on net-uninline-skb_put.patch.
include/linux/skbuff.h | 2 --
net/core/skbuff.c | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.19-rc5-mm2/include/linux/skbuff.h.old 2006-11-17 15:24:22.000000000 +0100
+++ linux-2.6.19-rc5-mm2/include/linux/skbuff.h 2006-11-17 15:24:31.000000000 +0100
@@ -364,8 +364,6 @@ extern struct sk_buff *skb_copy_expand(c
gfp_t priority);
extern int skb_pad(struct sk_buff *skb, int pad);
#define dev_kfree_skb(a) kfree_skb(a)
-extern void skb_over_panic(struct sk_buff *skb, int len,
- void *here);
extern void skb_under_panic(struct sk_buff *skb, int len,
void *here);
extern void skb_truesize_bug(struct sk_buff *skb);
--- linux-2.6.19-rc5-mm2/net/core/skbuff.c.old 2006-11-17 15:24:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/net/core/skbuff.c 2006-11-17 15:25:09.000000000 +0100
@@ -84,7 +84,7 @@ static kmem_cache_t *skbuff_fclone_cache
*
* Out of line support code for skb_put(). Not user callable.
*/
-void skb_over_panic(struct sk_buff *skb, int sz, void *here)
+static void skb_over_panic(struct sk_buff *skb, int sz, void *here)
{
printk(KERN_EMERG "skb_over_panic: text:%p len:%d put:%d head:%p "
"data:%p tail:%p end:%p dev:%s\n",
@@ -2094,7 +2094,6 @@ EXPORT_SYMBOL(skb_copy_and_csum_bits);
EXPORT_SYMBOL(skb_copy_and_csum_dev);
EXPORT_SYMBOL(skb_copy_bits);
EXPORT_SYMBOL(skb_copy_expand);
-EXPORT_SYMBOL(skb_over_panic);
EXPORT_SYMBOL(skb_pad);
EXPORT_SYMBOL(skb_realloc_headroom);
EXPORT_SYMBOL(skb_under_panic);
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static
2006-11-17 17:02 ` [-mm patch] make net/core/skbuff.c:skb_over_panic() static Adrian Bunk
@ 2006-11-21 0:55 ` David Miller
2006-11-21 1:37 ` Andrew Morton
2006-11-21 1:39 ` David Miller
0 siblings, 2 replies; 204+ messages in thread
From: David Miller @ 2006-11-21 0:55 UTC (permalink / raw)
To: bunk; +Cc: akpm, linux-kernel, netdev
From: Adrian Bunk <bunk@stusta.de>
Date: Fri, 17 Nov 2006 18:02:05 +0100
> skb_over_panic() can now become static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied to net-2.6.20, thanks Adrian.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static
2006-11-21 0:55 ` David Miller
@ 2006-11-21 1:37 ` Andrew Morton
2006-11-21 1:40 ` David Miller
2006-11-21 1:39 ` David Miller
1 sibling, 1 reply; 204+ messages in thread
From: Andrew Morton @ 2006-11-21 1:37 UTC (permalink / raw)
To: David Miller; +Cc: bunk, linux-kernel, netdev
On Mon, 20 Nov 2006 19:55:56 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Adrian Bunk <bunk@stusta.de>
> Date: Fri, 17 Nov 2006 18:02:05 +0100
>
> > skb_over_panic() can now become static.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Applied to net-2.6.20, thanks Adrian.
Adrian's patch is only applicable if my net-uninline-skb_put.patch is also
applied.
I'm not sure what to do with net-uninline-skb_put.patch. It's a good patch
if all that deudgging stuff is present in skb_put(), but it's a bad patch
if it isn't present. But it _is_ present.
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static
2006-11-21 1:37 ` Andrew Morton
@ 2006-11-21 1:40 ` David Miller
0 siblings, 0 replies; 204+ messages in thread
From: David Miller @ 2006-11-21 1:40 UTC (permalink / raw)
To: akpm; +Cc: bunk, linux-kernel, netdev
From: Andrew Morton <akpm@osdl.org>
Date: Mon, 20 Nov 2006 17:37:16 -0800
> Adrian's patch is only applicable if my net-uninline-skb_put.patch is also
> applied.
I just realized that, see the email I just sent out.
> I'm not sure what to do with net-uninline-skb_put.patch. It's a
> good patch if all that deudgging stuff is present in skb_put(), but
> it's a bad patch if it isn't present. But it _is_ present.
Keep it in your tree if you want, it's never going into mine :)
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] make net/core/skbuff.c:skb_over_panic() static
2006-11-21 0:55 ` David Miller
2006-11-21 1:37 ` Andrew Morton
@ 2006-11-21 1:39 ` David Miller
1 sibling, 0 replies; 204+ messages in thread
From: David Miller @ 2006-11-21 1:39 UTC (permalink / raw)
To: bunk; +Cc: akpm, linux-kernel, netdev
From: David Miller <davem@davemloft.net>
Date: Mon, 20 Nov 2006 19:55:56 -0500 (EST)
> From: Adrian Bunk <bunk@stusta.de>
> Date: Fri, 17 Nov 2006 18:02:05 +0100
>
> > skb_over_panic() can now become static.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Applied to net-2.6.20, thanks Adrian.
I just realized this requires a patch already in -mm which
isn't in my tree.
Sorry about that.
I really doubt I'll put that skb_put() patch into my tree,
ever, we can just remove the debugging checks or make them
conditional to keep the inline.
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] security/slim/slm_main.c: make 2 functions static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (19 preceding siblings ...)
2006-11-17 17:02 ` [-mm patch] make net/core/skbuff.c:skb_over_panic() static Adrian Bunk
@ 2006-11-17 17:02 ` Adrian Bunk
2006-11-17 23:58 ` Adrian Bunk
` (13 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 17:02 UTC (permalink / raw)
To: Andrew Morton, Kylene Jo Hall; +Cc: linux-kernel, chrisw, linux-security-module
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
security/slim/slm_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.19-rc5-mm2/security/slim/slm_main.c.old 2006-11-17 16:42:58.000000000 +0100
+++ linux-2.6.19-rc5-mm2/security/slim/slm_main.c 2006-11-17 16:43:22.000000000 +0100
@@ -967,8 +967,8 @@
* of the current process. This is especially important for objects
* being promoted.
*/
-int slm_inode_setxattr(struct dentry *dentry, char *name, void *value,
- size_t size, int flags)
+static int slm_inode_setxattr(struct dentry *dentry, char *name, void *value,
+ size_t size, int flags)
{
struct slm_tsec_data *cur_tsec = current->security;
char *data = value;
@@ -1075,7 +1075,7 @@
/*
* Opening a socket demotes the integrity of a process to untrusted.
*/
-int slm_socket_create(int family, int type, int protocol, int kern)
+static int slm_socket_create(int family, int type, int protocol, int kern)
{
struct task_struct *parent_tsk;
struct slm_tsec_data *cur_tsec = current->security, *parent_tsec;
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-17 23:58 ` Adrian Bunk
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
` (33 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 23:58 UTC (permalink / raw)
To: Andrew Morton, perex; +Cc: alsa-devel, linux-kernel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-alsa.patch
>...
> git trees
>...
This patch makes the needlessly global stac92xx_dmic_labels[] static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
+++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
@@ -1201,7 +1201,7 @@
}
/* labels for dmic mux inputs */
-const char *stac92xx_dmic_labels[5] = {
+static const char *stac92xx_dmic_labels[5] = {
"Analog Inputs", "Digital Mic 1", "Digital Mic 2",
"Digital Mic 3", "Digital Mic 4"
};
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static
@ 2006-11-17 23:58 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 23:58 UTC (permalink / raw)
To: Andrew Morton, perex; +Cc: linux-kernel, alsa-devel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-alsa.patch
>...
> git trees
>...
This patch makes the needlessly global stac92xx_dmic_labels[] static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
+++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
@@ -1201,7 +1201,7 @@
}
/* labels for dmic mux inputs */
-const char *stac92xx_dmic_labels[5] = {
+static const char *stac92xx_dmic_labels[5] = {
"Analog Inputs", "Digital Mic 1", "Digital Mic 2",
"Digital Mic 3", "Digital Mic 4"
};
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static
2006-11-17 23:58 ` Adrian Bunk
@ 2006-11-20 16:44 ` Takashi Iwai
-1 siblings, 0 replies; 204+ messages in thread
From: Takashi Iwai @ 2006-11-20 16:44 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, alsa-devel, linux-kernel, perex
At Sat, 18 Nov 2006 00:58:20 +0100,
Adrian Bunk wrote:
>
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-alsa.patch
> >...
> > git trees
> >...
>
> This patch makes the needlessly global stac92xx_dmic_labels[] static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Thanks, fixed on ALSA tree now.
Takashi
>
> --- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
> @@ -1201,7 +1201,7 @@
> }
>
> /* labels for dmic mux inputs */
> -const char *stac92xx_dmic_labels[5] = {
> +static const char *stac92xx_dmic_labels[5] = {
> "Analog Inputs", "Digital Mic 1", "Digital Mic 2",
> "Digital Mic 3", "Digital Mic 4"
> };
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [Alsa-devel] [-mm patch] make sound/pci/hda/patch_sigmatel.c:stac92xx_dmic_labels[] static
@ 2006-11-20 16:44 ` Takashi Iwai
0 siblings, 0 replies; 204+ messages in thread
From: Takashi Iwai @ 2006-11-20 16:44 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, perex, alsa-devel, linux-kernel
At Sat, 18 Nov 2006 00:58:20 +0100,
Adrian Bunk wrote:
>
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-alsa.patch
> >...
> > git trees
> >...
>
> This patch makes the needlessly global stac92xx_dmic_labels[] static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Thanks, fixed on ALSA tree now.
Takashi
>
> --- linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c.old 2006-11-17 18:36:16.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/sound/pci/hda/patch_sigmatel.c 2006-11-17 18:36:26.000000000 +0100
> @@ -1201,7 +1201,7 @@
> }
>
> /* labels for dmic mux inputs */
> -const char *stac92xx_dmic_labels[5] = {
> +static const char *stac92xx_dmic_labels[5] = {
> "Analog Inputs", "Digital Mic 1", "Digital Mic 2",
> "Digital Mic 3", "Digital Mic 4"
> };
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] make mm/thrash.c:global_faults static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (21 preceding siblings ...)
2006-11-17 23:58 ` Adrian Bunk
@ 2006-11-17 23:58 ` Adrian Bunk
2006-11-17 23:59 ` [RFC: -mm patch] remove kernel/timer.c:wall_jiffies Adrian Bunk
` (11 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 23:58 UTC (permalink / raw)
To: Andrew Morton, Ashwin Chaugule; +Cc: linux-kernel, riel
This patch makes the needlessly global "global_faults" static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/mm/thrash.c.old 2006-11-17 18:47:46.000000000 +0100
+++ linux-2.6.19-rc5-mm2/mm/thrash.c 2006-11-17 18:48:06.000000000 +0100
@@ -24,7 +24,7 @@
static DEFINE_SPINLOCK(swap_token_lock);
struct mm_struct *swap_token_mm;
-unsigned int global_faults;
+static unsigned int global_faults;
void grab_swap_token(void)
{
^ permalink raw reply [flat|nested] 204+ messages in thread* [RFC: -mm patch] remove kernel/timer.c:wall_jiffies
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (22 preceding siblings ...)
2006-11-17 23:58 ` [-mm patch] make mm/thrash.c:global_faults static Adrian Bunk
@ 2006-11-17 23:59 ` Adrian Bunk
2006-11-18 7:00 ` Ingo Molnar
2006-11-17 23:59 ` [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static Adrian Bunk
` (10 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 23:59 UTC (permalink / raw)
To: Andrew Morton, John Stultz; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar
"wall_jiffies" was added, but it's completely unused...
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:09:54.000000000 +0100
+++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:10:01.000000000 +0100
@@ -42,9 +42,6 @@
#include <asm/timex.h>
#include <asm/io.h>
-/* jiffies at the most recent update of wall time */
-unsigned long wall_jiffies = INITIAL_JIFFIES;
-
u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
EXPORT_SYMBOL(jiffies_64);
^ permalink raw reply [flat|nested] 204+ messages in thread* [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (23 preceding siblings ...)
2006-11-17 23:59 ` [RFC: -mm patch] remove kernel/timer.c:wall_jiffies Adrian Bunk
@ 2006-11-17 23:59 ` Adrian Bunk
2006-11-18 6:58 ` Ingo Molnar
2006-11-20 2:23 ` [-mm patch] drivers/scsi/scsi_scan.c: make 2 functions static Adrian Bunk
` (9 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-17 23:59 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner; +Cc: linux-kernel, Ingo Molnar
This patch makes the needlessly global __next_timer_interrupt() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:11:49.000000000 +0100
+++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:12:02.000000000 +0100
@@ -621,7 +621,8 @@
* is used on S/390 to stop all activity when a cpus is idle.
* This functions needs to be called disabled.
*/
-unsigned long __next_timer_interrupt(tvec_base_t *base, unsigned long now)
+static unsigned long __next_timer_interrupt(tvec_base_t *base,
+ unsigned long now)
{
struct list_head *list;
struct timer_list *nte, *found = NULL;
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] drivers/scsi/scsi_scan.c: make 2 functions static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (24 preceding siblings ...)
2006-11-17 23:59 ` [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static Adrian Bunk
@ 2006-11-20 2:23 ` Adrian Bunk
2006-11-20 2:34 ` Matthew Wilcox
2006-11-20 2:24 ` Adrian Bunk
` (8 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-20 2:23 UTC (permalink / raw)
To: Andrew Morton, James.Bottomley; +Cc: linux-kernel, linux-scsi
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-scsi-misc.patch
>...
> git trees
>...
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/scsi/scsi_scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/scsi/scsi_scan.c.old 2006-11-20 00:57:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/scsi/scsi_scan.c 2006-11-20 00:58:05.000000000 +0100
@@ -1633,7 +1633,7 @@
* that other asynchronous scans started after this one won't affect the
* ordering of the discovered devices.
*/
-struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
+static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
{
struct async_scan_data *data;
@@ -1677,7 +1677,7 @@
* This function announces all the devices it has found to the rest
* of the system.
*/
-void scsi_finish_async_scan(struct async_scan_data *data)
+static void scsi_finish_async_scan(struct async_scan_data *data)
{
struct Scsi_Host *shost;
^ permalink raw reply [flat|nested] 204+ messages in thread* [Cluster-devel] [-mm patch] fs/dlm/lowcomms-tcp.c: remove 2 functions
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-20 2:24 ` Adrian Bunk
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
` (33 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-20 2:24 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-gfs2-nmw.patch
>...
> git trees
>...
This patch removes the following unused functions:
- lowcomms_send_message()
- lowcomms_max_buffer_size()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/dlm/lowcomms-tcp.c | 24 ------------------------
1 file changed, 24 deletions(-)
--- linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c.old 2006-11-20 01:16:31.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c 2006-11-20 01:17:22.000000000 +0100
@@ -913,22 +913,6 @@
return -1;
}
-/* API send message call, may queue the request */
-/* N.B. This is the old interface - use the new one for new calls */
-int lowcomms_send_message(int nodeid, char *buf, int len, gfp_t allocation)
-{
- struct writequeue_entry *e;
- char *b;
-
- e = dlm_lowcomms_get_buffer(nodeid, len, allocation, &b);
- if (e) {
- memcpy(b, buf, len);
- dlm_lowcomms_commit_buffer(e);
- return 0;
- }
- return -ENOBUFS;
-}
-
/* Look for activity on active sockets */
static void process_sockets(void)
{
@@ -1129,14 +1113,6 @@
return 0;
}
-/*
- * Return the largest buffer size we can cope with.
- */
-int lowcomms_max_buffer_size(void)
-{
- return PAGE_CACHE_SIZE;
-}
-
void dlm_lowcomms_stop(void)
{
int i;
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] fs/dlm/lowcomms-tcp.c: remove 2 functions
@ 2006-11-20 2:24 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-20 2:24 UTC (permalink / raw)
To: Andrew Morton, swhiteho; +Cc: linux-kernel, cluster-devel
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-gfs2-nmw.patch
>...
> git trees
>...
This patch removes the following unused functions:
- lowcomms_send_message()
- lowcomms_max_buffer_size()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/dlm/lowcomms-tcp.c | 24 ------------------------
1 file changed, 24 deletions(-)
--- linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c.old 2006-11-20 01:16:31.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/lowcomms-tcp.c 2006-11-20 01:17:22.000000000 +0100
@@ -913,22 +913,6 @@
return -1;
}
-/* API send message call, may queue the request */
-/* N.B. This is the old interface - use the new one for new calls */
-int lowcomms_send_message(int nodeid, char *buf, int len, gfp_t allocation)
-{
- struct writequeue_entry *e;
- char *b;
-
- e = dlm_lowcomms_get_buffer(nodeid, len, allocation, &b);
- if (e) {
- memcpy(b, buf, len);
- dlm_lowcomms_commit_buffer(e);
- return 0;
- }
- return -ENOBUFS;
-}
-
/* Look for activity on active sockets */
static void process_sockets(void)
{
@@ -1129,14 +1113,6 @@
return 0;
}
-/*
- * Return the largest buffer size we can cope with.
- */
-int lowcomms_max_buffer_size(void)
-{
- return PAGE_CACHE_SIZE;
-}
-
void dlm_lowcomms_stop(void)
{
int i;
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] make ext2_get_blocks() static
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (26 preceding siblings ...)
2006-11-20 2:24 ` Adrian Bunk
@ 2006-11-20 2:24 ` Adrian Bunk
2006-11-20 2:24 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
` (6 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-20 2:24 UTC (permalink / raw)
To: Andrew Morton, Martin J. Bligh; +Cc: linux-kernel, linux-ext4
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> +ext2-reservations.patch
>...
> Port the ext3 reservations code into ext2.
>...
This patch makes the needlessly global ext2_get_blocks() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/ext2/inode.c.old 2006-11-20 01:35:58.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/ext2/inode.c 2006-11-20 01:36:08.000000000 +0100
@@ -574,10 +574,10 @@
* return = 0, if plain lookup failed.
* return < 0, error case.
*/
-int ext2_get_blocks(struct inode *inode,
- sector_t iblock, unsigned long maxblocks,
- struct buffer_head *bh_result,
- int create)
+static int ext2_get_blocks(struct inode *inode,
+ sector_t iblock, unsigned long maxblocks,
+ struct buffer_head *bh_result,
+ int create)
{
int err = -EIO;
int offsets[4];
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] fs/reiser4/: possible cleanups
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (27 preceding siblings ...)
2006-11-20 2:24 ` [-mm patch] make ext2_get_blocks() static Adrian Bunk
@ 2006-11-20 2:24 ` Adrian Bunk
2006-11-21 18:37 ` -mm: please drop reiser4-export-handle_ra_miss.patch Adrian Bunk
` (5 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-20 2:24 UTC (permalink / raw)
To: Andrew Morton, Edward Shishkin; +Cc: linux-kernel, reiserfs-dev
This patch contains the following possible cleanups:
- make the following needlessly global functions statis:
- plugin/file/file_conversion.c: prepped_dclust_ok()
- plugin/file/file_conversion.c: cryptcompress2unixfile()
- #if 0 the following unused global functions:
- plugin/file/cryptcompress.c: prepare_write_cryptcompress()
- plugin/file/file_conversion.c: prot_delete_object_cryptcompress()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/reiser4/plugin/file/cryptcompress.c | 2 ++
fs/reiser4/plugin/file/file.h | 3 ---
fs/reiser4/plugin/file/file_conversion.c | 8 +++++---
3 files changed, 7 insertions(+), 6 deletions(-)
--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file.h.old 2006-11-20 02:12:25.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file.h 2006-11-20 02:14:54.000000000 +0100
@@ -203,8 +203,6 @@
ssize_t prot_read_cryptcompress(struct file *, char __user *buf,
size_t read_amount, loff_t * off);
-int prepare_write_cryptcompress(struct file *file, struct page *page,
- unsigned from, unsigned to);
ssize_t write_cryptcompress(struct file *, const char __user *buf, size_t write_amount,
loff_t * off, int * conv);
ssize_t prot_write_cryptcompress(struct file *, const char __user *buf, size_t write_amount,
@@ -230,7 +228,6 @@
int create_cryptcompress(struct inode *, struct inode *,
reiser4_object_create_data *);
int delete_object_cryptcompress(struct inode *);
-int prot_delete_object_cryptcompress(struct inode *);
void init_inode_data_cryptcompress(struct inode *, reiser4_object_create_data *,
int create);
int cut_tree_worker_cryptcompress(tap_t *, const reiser4_key * from_key,
--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/cryptcompress.c.old 2006-11-20 02:12:37.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/cryptcompress.c 2006-11-20 02:12:56.000000000 +0100
@@ -3768,11 +3768,13 @@
return 0;
}
+#if 0
int prepare_write_cryptcompress(struct file *file, struct page *page,
unsigned from, unsigned to)
{
return prepare_write_common(file, page, from, to);
}
+#endif /* 0 */
/*
--- linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file_conversion.c.old 2006-11-20 02:13:24.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/reiser4/plugin/file/file_conversion.c 2006-11-20 02:15:07.000000000 +0100
@@ -239,7 +239,7 @@
}
#if REISER4_DEBUG
-int prepped_dclust_ok(hint_t * hint)
+static int prepped_dclust_ok(hint_t * hint)
{
reiser4_key key;
coord_t * coord = &hint->ext_coord.coord;
@@ -410,8 +410,8 @@
/* do conversion */
-int cryptcompress2unixfile(struct file *file, struct inode * inode,
- reiser4_cluster_t * clust)
+static int cryptcompress2unixfile(struct file *file, struct inode * inode,
+ reiser4_cluster_t * clust)
{
int i;
int result = 0;
@@ -577,10 +577,12 @@
(file, ppos, count, actor, target));
}
+#if 0
int prot_delete_object_cryptcompress(struct inode *inode)
{
return PROT_PASSIVE(int, delete_object, (inode));
}
+#endif /* 0 */
/*
Local variables:
^ permalink raw reply [flat|nested] 204+ messages in thread* -mm: please drop reiser4-export-handle_ra_miss.patch
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (28 preceding siblings ...)
2006-11-20 2:24 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
@ 2006-11-21 18:37 ` Adrian Bunk
2006-11-21 19:42 ` [-mm patch] unexport {,__}remove_from_page_cache Adrian Bunk
` (4 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-21 18:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Alexaner Zarochentsev, reiserfs-dev
Andrew,
please drop reiser4-export-handle_ra_miss.patch, this patch was
obsoleted by reiser4-simplify-reading-of-partially-converted-files.patch.
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] 204+ messages in thread* [-mm patch] unexport {,__}remove_from_page_cache
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (29 preceding siblings ...)
2006-11-21 18:37 ` -mm: please drop reiser4-export-handle_ra_miss.patch Adrian Bunk
@ 2006-11-21 19:42 ` Adrian Bunk
2006-11-22 3:23 ` 2.6.19-rc5-mm2: suspend related BLOCK=n compile error Adrian Bunk
` (3 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-21 19:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, reiserfs-dev
This patch removes the no longer required export of
{,__}remove_from_page_cache introduced by
reiser4-export-remove_from_page_cache.patch.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/mm/filemap.c.old 2006-11-21 19:48:44.000000000 +0100
+++ linux-2.6.19-rc5-mm2/mm/filemap.c 2006-11-21 19:48:51.000000000 +0100
@@ -127,7 +127,6 @@
mapping->nrpages--;
__dec_zone_page_state(page, NR_FILE_PAGES);
}
-EXPORT_SYMBOL(__remove_from_page_cache);
void remove_from_page_cache(struct page *page)
{
@@ -139,7 +138,6 @@
__remove_from_page_cache(page);
write_unlock_irq(&mapping->tree_lock);
}
-EXPORT_SYMBOL(remove_from_page_cache);
static int sync_page(void *word)
{
^ permalink raw reply [flat|nested] 204+ messages in thread* 2.6.19-rc5-mm2: suspend related BLOCK=n compile error
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (30 preceding siblings ...)
2006-11-21 19:42 ` [-mm patch] unexport {,__}remove_from_page_cache Adrian Bunk
@ 2006-11-22 3:23 ` Adrian Bunk
2006-11-22 3:34 ` Randy Dunlap
2006-11-22 4:17 ` [-mm patch] CACHEFILES must depend on PROC_FS Adrian Bunk
` (2 subsequent siblings)
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-22 3:23 UTC (permalink / raw)
To: Andrew Morton, Rafael J. Wysocki
Cc: linux-kernel, Nigel Cunningham, pavel, linux-pm
swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
following compile error with CONFIG_BLOCK=n:
<-- snip -->
...
CC kernel/power/process.o
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
make[3]: *** [kernel/power/process.o] 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] 204+ messages in thread* Re: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error
2006-11-22 3:23 ` 2.6.19-rc5-mm2: suspend related BLOCK=n compile error Adrian Bunk
@ 2006-11-22 3:34 ` Randy Dunlap
0 siblings, 0 replies; 204+ messages in thread
From: Randy Dunlap @ 2006-11-22 3:34 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-pm, linux-kernel
On Wed, 22 Nov 2006 04:23:41 +0100 Adrian Bunk wrote:
> swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
> following compile error with CONFIG_BLOCK=n:
>
> <-- snip -->
>
> ...
> CC kernel/power/process.o
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
> make[3]: *** [kernel/power/process.o] Error 1
Yes, I sent a patch for that, but Pavel said that they will be
removing/dropping that code anyway.
---
~Randy
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error
@ 2006-11-22 3:34 ` Randy Dunlap
0 siblings, 0 replies; 204+ messages in thread
From: Randy Dunlap @ 2006-11-22 3:34 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Rafael J. Wysocki, linux-kernel, Nigel Cunningham,
pavel, linux-pm
On Wed, 22 Nov 2006 04:23:41 +0100 Adrian Bunk wrote:
> swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
> following compile error with CONFIG_BLOCK=n:
>
> <-- snip -->
>
> ...
> CC kernel/power/process.o
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
> make[3]: *** [kernel/power/process.o] Error 1
Yes, I sent a patch for that, but Pavel said that they will be
removing/dropping that code anyway.
---
~Randy
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: 2.6.19-rc5-mm2: suspend related BLOCK=n compile error
2006-11-22 3:34 ` Randy Dunlap
(?)
@ 2006-11-22 11:20 ` Rafael J. Wysocki
-1 siblings, 0 replies; 204+ messages in thread
From: Rafael J. Wysocki @ 2006-11-22 11:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: Adrian Bunk, Andrew Morton, linux-kernel, Nigel Cunningham, pavel,
linux-pm
On Wednesday, 22 November 2006 04:34, Randy Dunlap wrote:
> On Wed, 22 Nov 2006 04:23:41 +0100 Adrian Bunk wrote:
>
> > swsusp-freeze-filesystems-during-suspend-rev-2.patch causes the
> > following compile error with CONFIG_BLOCK=n:
> >
> > <-- snip -->
> >
> > ...
> > CC kernel/power/process.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'freeze_processes':
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:124: error: implicit declaration of function 'freeze_filesystems'
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c: In function 'thaw_processes':
> > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/kernel/power/process.c:189: error: implicit declaration of function 'thaw_filesystems'
> > make[3]: *** [kernel/power/process.o] Error 1
>
> Yes, I sent a patch for that, but Pavel said that they will be
> removing/dropping that code anyway.
AFAICT, the swsusp-freeze-filesystems-during-suspend-rev-2.patch has been
dropped from -mm already.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] CACHEFILES must depend on PROC_FS
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (31 preceding siblings ...)
2006-11-22 3:23 ` 2.6.19-rc5-mm2: suspend related BLOCK=n compile error Adrian Bunk
@ 2006-11-22 4:17 ` Adrian Bunk
2006-11-22 4:35 ` Randy Dunlap
2006-11-22 4:17 ` [-mm patch] fs/fscache/main.c: cleanups Adrian Bunk
2006-11-22 4:38 ` Adrian Bunk
34 siblings, 1 reply; 204+ messages in thread
From: Adrian Bunk @ 2006-11-22 4:17 UTC (permalink / raw)
To: Andrew Morton, David Howells; +Cc: linux-kernel
I got the following compile error with CONFIG_PROC_FS=n:
<-- snip -->
...
CC fs/cachefiles/cf-main.o
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c: In function 'cachefiles_init':
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: 'proc_root_fs' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: for each function it appears in.)
make[3]: *** [fs/cachefiles/cf-main.o] Error 1
<-- snip -->
This patch adds the missing dependency of CACHEFILES on PROC_FS.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.19-rc5-mm2/fs/Kconfig.old 2006-11-22 02:48:36.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/Kconfig 2006-11-22 02:49:01.000000000 +0100
@@ -654,6 +654,7 @@ config FSCACHE
config CACHEFILES
tristate "Filesystem caching on files"
+ depends on PROC_FS
select FSCACHE
help
This permits use of a mounted filesystem as a cache for other
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] CACHEFILES must depend on PROC_FS
2006-11-22 4:17 ` [-mm patch] CACHEFILES must depend on PROC_FS Adrian Bunk
@ 2006-11-22 4:35 ` Randy Dunlap
0 siblings, 0 replies; 204+ messages in thread
From: Randy Dunlap @ 2006-11-22 4:35 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, David Howells, linux-kernel
On Wed, 22 Nov 2006 05:17:36 +0100 Adrian Bunk wrote:
> I got the following compile error with CONFIG_PROC_FS=n:
>
> <-- snip -->
>
> ...
> CC fs/cachefiles/cf-main.o
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c: In function 'cachefiles_init':
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: 'proc_root_fs' undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/fs/cachefiles/cf-main.c:77: error: for each function it appears in.)
> make[3]: *** [fs/cachefiles/cf-main.o] Error 1
>
> <-- snip -->
>
> This patch adds the missing dependency of CACHEFILES on PROC_FS.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.19-rc5-mm2/fs/Kconfig.old 2006-11-22 02:48:36.000000000 +0100
> +++ linux-2.6.19-rc5-mm2/fs/Kconfig 2006-11-22 02:49:01.000000000 +0100
> @@ -654,6 +654,7 @@ config FSCACHE
>
> config CACHEFILES
> tristate "Filesystem caching on files"
> + depends on PROC_FS
> select FSCACHE
> help
> This permits use of a mounted filesystem as a cache for other
I made that same patch (on linux-fsdevel). David Howells replied:
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> CACHEFILES uses PROC_FS, so make it a Kconfig depends.
Thanks, but the new and improved CacheFiles doesn't use procfs as Christoph
Hellwig objects to such a practice. In any case, Andrew Morton has dropped it
from -mm as it's now obsolete.
---
~Randy
^ permalink raw reply [flat|nested] 204+ messages in thread
* [-mm patch] fs/fscache/main.c: cleanups
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
` (32 preceding siblings ...)
2006-11-22 4:17 ` [-mm patch] CACHEFILES must depend on PROC_FS Adrian Bunk
@ 2006-11-22 4:17 ` Adrian Bunk
2006-11-22 4:38 ` Adrian Bunk
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-22 4:17 UTC (permalink / raw)
To: Andrew Morton, David Howells; +Cc: linux-kernel
This patch contains the following cleanups:
- remove the unused global variable fscache_debug
- make the needlessly global struct fscache_kset static
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/fscache/main.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- linux-2.6.19-rc5-mm2/fs/fscache/main.c.old 2006-11-22 03:08:53.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/fscache/main.c 2006-11-22 03:09:23.000000000 +0100
@@ -16,8 +16,6 @@
#include <linux/slab.h>
#include "fscache-int.h"
-int fscache_debug;
-
static int fscache_init(void);
static void fscache_exit(void);
@@ -41,14 +39,12 @@ static struct kobj_type fscache_ktype =
.default_attrs = NULL,
};
-struct kset fscache_kset = {
+static struct kset fscache_kset = {
.kobj.name = "fscache",
.kobj.kset = &fs_subsys.kset,
.ktype = &fscache_ktype,
};
-EXPORT_SYMBOL(fscache_kset);
-
/*****************************************************************************/
/*
* initialise the fs caching module
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
2006-11-14 9:41 2.6.19-rc5-mm2 Andrew Morton
@ 2006-11-22 4:38 ` Adrian Bunk
2006-11-14 11:31 ` 2.6.19-rc5-mm2 Reuben Farrelly
` (33 subsequent siblings)
34 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-22 4:38 UTC (permalink / raw)
To: Andrew Morton, dwmw2; +Cc: linux-mtd, linux-kernel, Akinobu Mita
This patch converts drivers/mtd/nand/rtc_from4.c to use the new
lib/bitrev.c
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/mtd/nand/Kconfig | 1
drivers/mtd/nand/rtc_from4.c | 44 +----------------------------------
2 files changed, 3 insertions(+), 42 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig.old 2006-11-22 05:23:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig 2006-11-22 05:23:52.000000000 +0100
@@ -90,6 +90,7 @@
depends on MTD_NAND && SH_SOLUTION_ENGINE
select REED_SOLOMON
select REED_SOLOMON_DEC8
+ select BITREVERSE
help
This enables the driver for the Renesas Technology AG-AND
flash interface board (FROM_BOARD4)
--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c.old 2006-11-22 05:22:37.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c 2006-11-22 05:24:31.000000000 +0100
@@ -24,6 +24,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/rslib.h>
+#include <linux/bitrev.h>
#include <linux/module.h>
#include <linux/mtd/compatmac.h>
#include <linux/mtd/mtd.h>
@@ -152,47 +153,6 @@
.oobfree = {{32, 32}}
};
-/* Aargh. I missed the reversed bit order, when I
- * was talking to Renesas about the FPGA.
- *
- * The table is used for bit reordering and inversion
- * of the ecc byte which we get from the FPGA
- */
-static uint8_t revbits[256] = {
- 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
- 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
- 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
- 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
- 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
- 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
- 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
- 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
- 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
- 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
- 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
- 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
- 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
- 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
- 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
- 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
- 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
- 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
- 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
- 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
- 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
- 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
- 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
- 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
- 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
- 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
- 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
- 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
- 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
- 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
- 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
- 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
#endif
/*
@@ -397,7 +357,7 @@
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = revbits[(*rs_ecc) & 0xFF];
+ ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
rs_ecc++;
}
^ permalink raw reply [flat|nested] 204+ messages in thread* [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
@ 2006-11-22 4:38 ` Adrian Bunk
0 siblings, 0 replies; 204+ messages in thread
From: Adrian Bunk @ 2006-11-22 4:38 UTC (permalink / raw)
To: Andrew Morton, dwmw2; +Cc: linux-kernel, linux-mtd, Akinobu Mita
This patch converts drivers/mtd/nand/rtc_from4.c to use the new
lib/bitrev.c
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/mtd/nand/Kconfig | 1
drivers/mtd/nand/rtc_from4.c | 44 +----------------------------------
2 files changed, 3 insertions(+), 42 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig.old 2006-11-22 05:23:38.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/Kconfig 2006-11-22 05:23:52.000000000 +0100
@@ -90,6 +90,7 @@
depends on MTD_NAND && SH_SOLUTION_ENGINE
select REED_SOLOMON
select REED_SOLOMON_DEC8
+ select BITREVERSE
help
This enables the driver for the Renesas Technology AG-AND
flash interface board (FROM_BOARD4)
--- linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c.old 2006-11-22 05:22:37.000000000 +0100
+++ linux-2.6.19-rc5-mm2/drivers/mtd/nand/rtc_from4.c 2006-11-22 05:24:31.000000000 +0100
@@ -24,6 +24,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/rslib.h>
+#include <linux/bitrev.h>
#include <linux/module.h>
#include <linux/mtd/compatmac.h>
#include <linux/mtd/mtd.h>
@@ -152,47 +153,6 @@
.oobfree = {{32, 32}}
};
-/* Aargh. I missed the reversed bit order, when I
- * was talking to Renesas about the FPGA.
- *
- * The table is used for bit reordering and inversion
- * of the ecc byte which we get from the FPGA
- */
-static uint8_t revbits[256] = {
- 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
- 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
- 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
- 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
- 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
- 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
- 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
- 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
- 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
- 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
- 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
- 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
- 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
- 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
- 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
- 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
- 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
- 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
- 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
- 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
- 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
- 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
- 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
- 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
- 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
- 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
- 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
- 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
- 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
- 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
- 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
- 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
#endif
/*
@@ -397,7 +357,7 @@
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = revbits[(*rs_ecc) & 0xFF];
+ ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
rs_ecc++;
}
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
2006-11-22 4:38 ` Adrian Bunk
(?)
@ 2006-11-28 22:19 ` David Woodhouse
2006-11-28 22:49 ` Andrew Morton
-1 siblings, 1 reply; 204+ messages in thread
From: David Woodhouse @ 2006-11-28 22:19 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-mtd, linux-kernel, Akinobu Mita
On Wed, 2006-11-22 at 05:38 +0100, Adrian Bunk wrote:
> This patch converts drivers/mtd/nand/rtc_from4.c to use the new
> lib/bitrev.c
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied; thanks.
--
dwmw2
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
2006-11-28 22:19 ` David Woodhouse
@ 2006-11-28 22:49 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-28 22:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, linux-kernel, Akinobu Mita, Adrian Bunk
On Tue, 28 Nov 2006 22:19:36 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2006-11-22 at 05:38 +0100, Adrian Bunk wrote:
> > This patch converts drivers/mtd/nand/rtc_from4.c to use the new
> > lib/bitrev.c
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Applied; thanks.
>
Won't compile - you don't have the bitrev library patches.
I'll take that as an ack and shall merge this once
crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
@ 2006-11-28 22:49 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-28 22:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: Adrian Bunk, linux-mtd, linux-kernel, Akinobu Mita
On Tue, 28 Nov 2006 22:19:36 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2006-11-22 at 05:38 +0100, Adrian Bunk wrote:
> > This patch converts drivers/mtd/nand/rtc_from4.c to use the new
> > lib/bitrev.c
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Applied; thanks.
>
Won't compile - you don't have the bitrev library patches.
I'll take that as an ack and shall merge this once
crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
2006-11-28 22:49 ` Andrew Morton
@ 2006-11-28 22:52 ` David Woodhouse
-1 siblings, 0 replies; 204+ messages in thread
From: David Woodhouse @ 2006-11-28 22:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mtd, linux-kernel, Akinobu Mita, Adrian Bunk
On Tue, 2006-11-28 at 14:49 -0800, Andrew Morton wrote:
> Won't compile - you don't have the bitrev library patches.
Hm, yeah -- I'd just come to that conclusion :)
> I'll take that as an ack and shall merge this once
> crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
I assume the bitrev thing will be going in as soon as 2.6.19 is actually
released, so there's no point in me reverting it from the mtd tree?
--
dwmw2
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
@ 2006-11-28 22:52 ` David Woodhouse
0 siblings, 0 replies; 204+ messages in thread
From: David Woodhouse @ 2006-11-28 22:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adrian Bunk, linux-mtd, linux-kernel, Akinobu Mita
On Tue, 2006-11-28 at 14:49 -0800, Andrew Morton wrote:
> Won't compile - you don't have the bitrev library patches.
Hm, yeah -- I'd just come to that conclusion :)
> I'll take that as an ack and shall merge this once
> crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
I assume the bitrev thing will be going in as soon as 2.6.19 is actually
released, so there's no point in me reverting it from the mtd tree?
--
dwmw2
^ permalink raw reply [flat|nested] 204+ messages in thread
* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
2006-11-28 22:52 ` David Woodhouse
@ 2006-11-29 0:09 ` Andrew Morton
-1 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-29 0:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, linux-kernel, Akinobu Mita, Adrian Bunk
On Tue, 28 Nov 2006 22:52:16 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> > I'll take that as an ack and shall merge this once
> > crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
>
> I assume the bitrev thing will be going in as soon as 2.6.19 is actually
> released,
It will take over a week after 2.6.19 - I prefer to wait until the git tree
laggards^Wowners have merged before merging -mm stuff, so things land in
appropriate order.
> so there's no point in me reverting it from the mtd tree?
Your call.
I do have a fixlet against this patch:
--- a/drivers/mtd/nand/rtc_from4.c~drivers-mtd-nand-rtc_from4c-use-lib-bitrevc-tidy
+++ a/drivers/mtd/nand/rtc_from4.c
@@ -357,7 +357,7 @@ static int rtc_from4_correct_data(struct
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
+ ecc[i] = bitrev8(*rs_ecc);
rs_ecc++;
}
_
^ permalink raw reply [flat|nested] 204+ messages in thread* Re: [-mm patch] drivers/mtd/nand/rtc_from4.c: use lib/bitrev.c
@ 2006-11-29 0:09 ` Andrew Morton
0 siblings, 0 replies; 204+ messages in thread
From: Andrew Morton @ 2006-11-29 0:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: Adrian Bunk, linux-mtd, linux-kernel, Akinobu Mita
On Tue, 28 Nov 2006 22:52:16 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> > I'll take that as an ack and shall merge this once
> > crc32-replace-bitreverse-by-bitrev32.patch is merged ;)
>
> I assume the bitrev thing will be going in as soon as 2.6.19 is actually
> released,
It will take over a week after 2.6.19 - I prefer to wait until the git tree
laggards^Wowners have merged before merging -mm stuff, so things land in
appropriate order.
> so there's no point in me reverting it from the mtd tree?
Your call.
I do have a fixlet against this patch:
--- a/drivers/mtd/nand/rtc_from4.c~drivers-mtd-nand-rtc_from4c-use-lib-bitrevc-tidy
+++ a/drivers/mtd/nand/rtc_from4.c
@@ -357,7 +357,7 @@ static int rtc_from4_correct_data(struct
/* Read the syndrom pattern from the FPGA and correct the bitorder */
rs_ecc = (volatile unsigned short *)(rtc_from4_fio_base + RTC_FROM4_RS_ECC);
for (i = 0; i < 8; i++) {
- ecc[i] = byte_rev_table[(*rs_ecc) & 0xFF];
+ ecc[i] = bitrev8(*rs_ecc);
rs_ecc++;
}
_
^ permalink raw reply [flat|nested] 204+ messages in thread