* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags bug part 2
From: Barry K. Nathan @ 2006-06-04 9:53 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Ingo Molnar, linux-kernel, Andrew Morton
In-Reply-To: <1149411525.3109.73.camel@laptopd505.fenrus.org>
On 6/4/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> just the preempt the next email from Barry; while fixing this one I
> looked at the usage of the locks more and found another patch needed...
[snip]
Nice try, but it didn't work. ~_^
I was about to reply to the previous ns83820 patch with my dmesg, when
I saw this one. I applied this patch too, and like the previous patch,
it reports an instance of illegal lock usage. My dmesg follows.
--
-Barry K. Nathan <barryn@pobox.com>
[ 0.000000] Linux version 2.6.17-rc5-mm3 (barryn@nserv) (gcc
version 4.1.1) #1 Sun Jun 4 02:03:43 PDT 2006
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] sanitize start
[ 0.000000] sanitize end
[ 0.000000] copy_e820_map() start: 0000000000000000 size:
000000000009fc00 end: 000000000009fc00 type: 1
[ 0.000000] copy_e820_map() type is E820_RAM
[ 0.000000] add_memory_region(0000000000000000, 000000000009fc00, 1)
[ 0.000000] copy_e820_map() start: 000000000009fc00 size:
0000000000000400 end: 00000000000a0000 type: 2
[ 0.000000] add_memory_region(000000000009fc00, 0000000000000400, 2)
[ 0.000000] copy_e820_map() start: 00000000000f0000 size:
0000000000010000 end: 0000000000100000 type: 2
[ 0.000000] add_memory_region(00000000000f0000, 0000000000010000, 2)
[ 0.000000] copy_e820_map() start: 0000000000100000 size:
000000001fef0000 end: 000000001fff0000 type: 1
[ 0.000000] copy_e820_map() type is E820_RAM
[ 0.000000] add_memory_region(0000000000100000, 000000001fef0000, 1)
[ 0.000000] copy_e820_map() start: 000000001fff0000 size:
0000000000008000 end: 000000001fff8000 type: 3
[ 0.000000] add_memory_region(000000001fff0000, 0000000000008000, 3)
[ 0.000000] copy_e820_map() start: 000000001fff8000 size:
0000000000008000 end: 0000000020000000 type: 4
[ 0.000000] add_memory_region(000000001fff8000, 0000000000008000, 4)
[ 0.000000] copy_e820_map() start: 00000000ffff0000 size:
0000000000010000 end: 0000000100000000 type: 2
[ 0.000000] add_memory_region(00000000ffff0000, 0000000000010000, 2)
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
[ 0.000000] BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
[ 0.000000] BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
[ 0.000000] 511MB LOWMEM available.
[ 0.000000] On node 0 totalpages: 131056
[ 0.000000] DMA zone: 4096 pages, LIFO batch:0
[ 0.000000] Normal zone: 126960 pages, LIFO batch:31
[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP (v000 AMI
) @ 0x000fa8f0
[ 0.000000] ACPI: RSDT (v001 AMIINT 0x00000010 MSFT
0x00000097) @ 0x1fff0000
[ 0.000000] ACPI: FADT (v001 AMIINT 0x00000010 MSFT
0x00000097) @ 0x1fff0030
[ 0.000000] ACPI: DSDT (v001 AMD75X IRONGATE 0x00001000 MSFT
0x0100000b) @ 0x00000000
[ 0.000000] Allocating PCI resources starting at 30000000 (gap:
20000000:dfff0000)
[ 0.000000] Detected 805.687 MHz processor.
[ 73.586916] Built 1 zonelists
[ 73.586923] Kernel command line: BOOT_IMAGE=bzimage lapic
root=/dev/sdc1 vga=6
[ 73.587430] Local APIC disabled by BIOS -- reenabling.
[ 73.587438] Found and enabled local APIC!
[ 73.587447] mapped APIC to ffffd000 (fee00000)
[ 73.587456] Enabling fast FPU save and restore... done.
[ 73.587465] Initializing CPU#0
[ 73.587609] CPU 0 irqstacks, hard=c03f3000 soft=c03f2000
[ 73.587619] PID hash table entries: 2048 (order: 11, 8192 bytes)
[ 73.591125] Console: colour VGA+ 80x60
[ 73.593702] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[ 73.593851] ... MAX_LOCKDEP_SUBTYPES: 8
[ 73.593943] ... MAX_LOCK_DEPTH: 30
[ 73.594035] ... MAX_LOCKDEP_KEYS: 2048
[ 73.594124] ... TYPEHASH_SIZE: 1024
[ 73.594215] ... MAX_LOCKDEP_ENTRIES: 8192
[ 73.594311] ... MAX_LOCKDEP_CHAINS: 8192
[ 73.594406] ... CHAINHASH_SIZE: 4096
[ 73.594496] memory used by lock dependency info: 696 kB
[ 73.594592] per task-struct memory footprint: 1080 bytes
[ 73.594687] ------------------------
[ 73.594782] | Locking API testsuite:
[ 73.594876] ----------------------------------------------------------------------------
[ 73.595029] | spin |wlock |rlock
|mutex | wsem | rsem |
[ 73.595181]
--------------------------------------------------------------------------
[ 73.595357] A-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.597758] A-B-B-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.600104] A-B-B-C-C-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.602480] A-B-C-A-B-C deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.604863] A-B-B-C-C-D-D-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.607310] A-B-C-D-B-D-D-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.609796] A-B-C-D-B-C-D-A deadlock: ok | ok | ok |
ok | ok | ok |
[ 73.612246] double unlock: ok | ok | ok |
ok | ok | ok |
[ 73.614529] bad unlock order: ok | ok | ok |
ok | ok | ok |
[ 73.616838]
--------------------------------------------------------------------------
[ 73.616984] recursive read-lock: | ok |
| ok |
[ 73.617956]
--------------------------------------------------------------------------
[ 73.618106] non-nested unlock: ok | ok | ok | ok |
[ 73.619665] ------------------------------------------------------------
[ 73.619757] hard-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 73.620943] soft-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 73.622135] hard-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 73.623315] soft-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 73.624505] sirq-safe-A => hirqs-on/12: ok | ok | ok |
[ 73.625696] sirq-safe-A => hirqs-on/21: ok | ok | ok |
[ 73.626879] hard-safe-A + irqs-on/12: ok | ok | ok |
[ 73.628085] soft-safe-A + irqs-on/12: ok | ok | ok |
[ 73.629273] hard-safe-A + irqs-on/21: ok | ok | ok |
[ 73.630454] soft-safe-A + irqs-on/21: ok | ok | ok |
[ 73.631635] hard-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 73.632844] soft-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 73.634051] hard-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 73.635251] soft-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 73.636451] hard-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 73.637679] soft-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 73.638890] hard-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 73.640092] soft-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 73.641297] hard-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 73.642484] soft-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 73.643679] hard-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 73.644888] soft-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 73.646088] hard-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 73.647296] soft-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 73.648535] hard-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 73.649752] soft-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 73.650965] hard-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 73.652178] soft-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 73.653382] hard-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 73.654585] soft-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 73.655794] hard-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 73.656999] soft-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 73.658237] hard-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 73.659450] soft-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 73.660660] hard-irq lock-inversion/123: ok | ok | ok |
[ 73.661870] soft-irq lock-inversion/123: ok | ok | ok |
[ 73.663088] hard-irq lock-inversion/132: ok | ok | ok |
[ 73.664300] soft-irq lock-inversion/132: ok | ok | ok |
[ 73.665519] hard-irq lock-inversion/213: ok | ok | ok |
[ 73.666732] soft-irq lock-inversion/213: ok | ok | ok |
[ 73.667974] hard-irq lock-inversion/231: ok | ok | ok |
[ 73.669179] soft-irq lock-inversion/231: ok | ok | ok |
[ 73.670386] hard-irq lock-inversion/312: ok | ok | ok |
[ 73.671606] soft-irq lock-inversion/312: ok | ok | ok |
[ 73.672830] hard-irq lock-inversion/321: ok | ok | ok |
[ 73.674036] soft-irq lock-inversion/321: ok | ok | ok |
[ 73.675254] hard-irq read-recursion/123: ok |
[ 73.675748] soft-irq read-recursion/123: ok |
[ 73.676246] hard-irq read-recursion/132: ok |
[ 73.676740] soft-irq read-recursion/132: ok |
[ 73.677234] hard-irq read-recursion/213: ok |
[ 73.677747] soft-irq read-recursion/213: ok |
[ 73.678240] hard-irq read-recursion/231: ok |
[ 73.678736] soft-irq read-recursion/231: ok |
[ 73.679229] hard-irq read-recursion/312: ok |
[ 73.679725] soft-irq read-recursion/312: ok |
[ 73.680217] hard-irq read-recursion/321: ok |
[ 73.680710] soft-irq read-recursion/321: ok |
[ 73.681207] -------------------------------------------------------
[ 73.681306] Good, all 210 testcases passed! |
[ 73.681399] ---------------------------------
[ 73.682349] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 73.683329] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 73.731760] Memory: 514628k/524224k available (1572k kernel code,
9028k reserved, 909k data, 160k init, 0k highmem)
[ 73.731928] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 73.877388] Calibrating delay using timer specific routine..
1613.94 BogoMIPS (lpj=8069734)
[ 73.877840] Mount-cache hash table entries: 512
[ 73.878796] CPU: After generic identify, caps: 0183fbff c1c3fbff
00000000 00000000 00000000 00000000 00000000
[ 73.878828] CPU: After vendor identify, caps: 0183fbff c1c3fbff
00000000 00000000 00000000 00000000 00000000
[ 73.878860] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 73.878966] CPU: L2 Cache: 512K (64 bytes/line)
[ 73.879060] CPU: After all inits, caps: 0183fbff c1c3fbff 00000000
00000420 00000000 00000000 00000000
[ 73.879089] Intel machine check architecture supported.
[ 73.879186] Intel machine check reporting enabled on CPU#0.
[ 73.879289] Compat vDSO mapped to ffffe000.
[ 73.879399] CPU: AMD Athlon(tm) Processor stepping 01
[ 73.879567] Checking 'hlt' instruction... OK.
[ 73.917472] SMP alternatives: switching to UP code
[ 73.917563] Freeing SMP alternatives: 0k freed
[ 73.926938] ACPI: setting ELCR to 0010 (from 0e00)
[ 73.927753] lockdep: disabled NMI watchdog.
[ 74.053321] NET: Registered protocol family 16
[ 74.053729] ACPI: bus type pci registered
[ 74.065724] PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1
[ 74.065832] Setting up standard PCI resources
[ 74.068330] spurious 8259A interrupt: IRQ7.
[ 74.081547] ACPI: Subsystem revision 20060310
[ 74.097165] ACPI: Interpreter enabled
[ 74.097320] ACPI: Using PIC for interrupt routing
[ 74.100331] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 74.100466] PCI: Probing PCI hardware (bus 00)
[ 74.110098] Boot video device is 0000:01:05.0
[ 74.110458] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 74.121205] ACPI: Power Resource [URP1] (off)
[ 74.121717] ACPI: Power Resource [URP2] (off)
[ 74.122187] ACPI: Power Resource [FDDP] (off)
[ 74.122657] ACPI: Power Resource [LPTP] (off)
[ 74.124439] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10
11 12 14 15)
[ 74.125981] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[ 74.127521] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10
11 12 14 15)
[ 74.129033] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[ 74.130089] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 74.130299] pnp: PnP ACPI init
[ 74.136579] pnp: PnP ACPI: found 8 devices
[ 74.136688] PnPBIOS: Disabled by ACPI PNP
[ 74.137816] SCSI subsystem initialized
[ 74.138209] PCI: Using ACPI for IRQ routing
[ 74.138301] PCI: If a device doesn't work, try "pci=routeirq". If
it helps, post a report
[ 74.149421] PCI: Bridge: 0000:00:01.0
[ 74.149534] IO window: 9000-9fff
[ 74.149658] MEM window: e7d00000-efdfffff
[ 74.149775] PREFETCH window: e3b00000-e3bfffff
[ 74.150036] NET: Registered protocol family 2
[ 74.247378] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 74.248173] TCP established hash table entries: 16384 (order: 8,
1376256 bytes)
[ 74.256402] TCP bind hash table entries: 8192 (order: 7, 720896 bytes)
[ 74.260910] TCP: Hash tables configured (established 16384 bind 8192)
[ 74.261061] TCP reno registered
[ 74.263479] Machine check exception polling timer started.
[ 74.269336] Initializing Cryptographic API
[ 74.269474] io scheduler noop registered
[ 74.269644] io scheduler cfq registered (default)
[ 74.270194] ACPI: Power Button (FF) [PWRF]
[ 74.270306] ACPI: Sleep Button (FF) [SLPF]
[ 74.270430] ACPI: Power Button (CM) [PWRB]
[ 74.271006] isapnp: Scanning for PnP cards...
[ 74.628027] isapnp: No Plug & Play device found
[ 74.645301] Floppy drive(s): fd0 is 1.44M
[ 74.658905] FDC 0 is a post-1991 82077
[ 74.661870] libata version 1.30 loaded.
[ 74.662184] pata_pdc2027x 0000:00:0a.0: version 0.74
[ 74.663009] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
[ 74.663121] PCI: setting IRQ 11 as level-triggered
[ 74.663131] ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKB] ->
GSI 11 (level, low) -> IRQ 11
[ 74.763521] pata_pdc2027x 0000:00:0a.0: PLL input clock 16813 kHz
[ 74.793952] ata1: PATA max UDMA/133 cmd 0xE08097C0 ctl 0xE0809FDA
bmdma 0xE0809000 irq 11
[ 74.794290] ata2: PATA max UDMA/133 cmd 0xE08095C0 ctl 0xE0809DDA
bmdma 0xE0809008 irq 11
[ 74.947356] ata1.00: cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69
86:3e01 87:4003 88:407f
[ 74.947372] ata1.00: ATA-7, max UDMA/133, 490234752 sectors: LBA48
[ 74.948337] ata1.00: configured for UDMA/133
[ 74.948440] scsi0 : pata_pdc2027x
[ 75.107315] ata2.00: cfg 49:2f00 82:346b 83:7f01 84:4003 85:3469
86:3c01 87:4003 88:203f
[ 75.107328] ata2.00: ATA-6, max UDMA/100, 625142448 sectors: LBA48
[ 75.108429] ata2.00: configured for UDMA/100
[ 75.108531] scsi1 : pata_pdc2027x
[ 75.109758] Vendor: ATA Model: Maxtor 6Y250P0 Rev: YAR4
[ 75.110792] Type: Direct-Access ANSI SCSI
revision: 05
[ 75.112186] Vendor: ATA Model: WDC WD3200JB-00K Rev: 08.0
[ 75.113248] Type: Direct-Access ANSI SCSI
revision: 05
[ 75.114516] sata_sil 0000:00:0d.0: version 1.0
[ 75.115265] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
[ 75.115374] PCI: setting IRQ 10 as level-triggered
[ 75.115384] ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKA] ->
GSI 10 (level, low) -> IRQ 10
[ 75.115653] sata_sil 0000:00:0d.0: Applying R_ERR on DMA activate
FIS errata fix
[ 75.116016] ata3: SATA max UDMA/100 cmd 0xE080E480 ctl 0xE080E48A
bmdma 0xE080E400 irq 10
[ 75.116357] ata4: SATA max UDMA/100 cmd 0xE080E4C0 ctl 0xE080E4CA
bmdma 0xE080E408 irq 10
[ 75.116738] ata5: SATA max UDMA/100 cmd 0xE080E680 ctl 0xE080E68A
bmdma 0xE080E600 irq 10
[ 75.117051] ata6: SATA max UDMA/100 cmd 0xE080E6C0 ctl 0xE080E6CA
bmdma 0xE080E608 irq 10
[ 75.486123] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 75.487064] ata3.00: cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69
86:3e01 87:4003 88:207f
[ 75.487078] ata3.00: ATA-7, max UDMA/133, 585940320 sectors: LBA48
[ 75.487187] ata3.00: applying bridge limits
[ 75.488298] ata3.00: configured for UDMA/100
[ 75.488395] scsi2 : sata_sil
[ 75.855823] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 75.857125] ata4.00: cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469
86:3c01 87:4023 88:203f
[ 75.857137] ata4.00: ATA-7, max UDMA/100, 781422768 sectors: LBA48
[ 75.857235] ata4.00: applying bridge limits
[ 75.858607] ata4.00: configured for UDMA/100
[ 75.858710] scsi3 : sata_sil
[ 76.225523] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 76.226496] ata5.00: cfg 49:2f00 82:346b 83:7f01 84:4003 85:3469
86:3e01 87:4003 88:203f
[ 76.226509] ata5.00: ATA-6, max UDMA/100, 625142448 sectors: LBA48
[ 76.226605] ata5.00: applying bridge limits
[ 76.227685] ata5.00: configured for UDMA/100
[ 76.227783] scsi4 : sata_sil
[ 76.435337] ata6: SATA link down (SStatus 0 SControl 310)
[ 76.435450] scsi5 : sata_sil
[ 76.436397] Vendor: ATA Model: Maxtor 4A300J0 Rev: RAMB
[ 76.437451] Type: Direct-Access ANSI SCSI
revision: 05
[ 76.438841] Vendor: ATA Model: ST3400832A Rev: 3.01
[ 76.439911] Type: Direct-Access ANSI SCSI
revision: 05
[ 76.441340] Vendor: ATA Model: WDC WD3200JB-00K Rev: 08.0
[ 76.442397] Type: Direct-Access ANSI SCSI
revision: 05
[ 76.444277] SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
[ 76.444481] sda: Write Protect is off
[ 76.444572] sda: Mode Sense: 00 3a 00 00
[ 76.444744] SCSI device sda: drive cache: write back
[ 76.445381] SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
[ 76.445594] sda: Write Protect is off
[ 76.445688] sda: Mode Sense: 00 3a 00 00
[ 76.445885] SCSI device sda: drive cache: write back
[ 76.445984] sda: unknown partition table
[ 76.448576] sd 0:0:0:0: Attached scsi disk sda
[ 76.449210] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[ 76.449391] sdb: Write Protect is off
[ 76.449478] sdb: Mode Sense: 00 3a 00 00
[ 76.449645] SCSI device sdb: drive cache: write back
[ 76.450141] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[ 76.450332] sdb: Write Protect is off
[ 76.450420] sdb: Mode Sense: 00 3a 00 00
[ 76.450608] SCSI device sdb: drive cache: write back
[ 76.450706] sdb: unknown partition table
[ 76.453773] sd 1:0:0:0: Attached scsi disk sdb
[ 76.454378] SCSI device sdc: 585940320 512-byte hdwr sectors (300001 MB)
[ 76.454567] sdc: Write Protect is off
[ 76.454670] sdc: Mode Sense: 00 3a 00 00
[ 76.454837] SCSI device sdc: drive cache: write back
[ 76.455366] SCSI device sdc: 585940320 512-byte hdwr sectors (300001 MB)
[ 76.455564] sdc: Write Protect is off
[ 76.455670] sdc: Mode Sense: 00 3a 00 00
[ 76.455864] SCSI device sdc: drive cache: write back
[ 76.455961] sdc: sdc1
[ 76.466882] sd 2:0:0:0: Attached scsi disk sdc
[ 76.467443] SCSI device sdd: 781422768 512-byte hdwr sectors (400088 MB)
[ 76.467636] sdd: Write Protect is off
[ 76.467725] sdd: Mode Sense: 00 3a 00 00
[ 76.467892] SCSI device sdd: drive cache: write back
[ 76.468408] SCSI device sdd: 781422768 512-byte hdwr sectors (400088 MB)
[ 76.468616] sdd: Write Protect is off
[ 76.468716] sdd: Mode Sense: 00 3a 00 00
[ 76.468906] SCSI device sdd: drive cache: write back
[ 76.469014] sdd: unknown partition table
[ 76.485819] sd 3:0:0:0: Attached scsi disk sdd
[ 76.486391] SCSI device sde: 625142448 512-byte hdwr sectors (320073 MB)
[ 76.486581] sde: Write Protect is off
[ 76.486681] sde: Mode Sense: 00 3a 00 00
[ 76.486848] SCSI device sde: drive cache: write back
[ 76.487359] SCSI device sde: 625142448 512-byte hdwr sectors (320073 MB)
[ 76.487560] sde: Write Protect is off
[ 76.487664] sde: Mode Sense: 00 3a 00 00
[ 76.487853] SCSI device sde: drive cache: write back
[ 76.487960] sde: sde1 sde2
[ 76.508717] sd 4:0:0:0: Attached scsi disk sde
[ 76.511901] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at
0x60,0x64 irq 1,12
[ 76.512803] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 76.512945] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 76.514756] mice: PS/2 mouse device common for all mice
[ 76.515161] NET: Registered protocol family 1
[ 76.515349] Using IPI Shortcut mode
[ 76.516174] ACPI: (supports S0 S1 S4 S5)
[ 76.517145] Freeing unused kernel memory: 160k freed
[ 76.517418] Write protecting the kernel read-only data: 312k
[ 76.525255] Time: tsc clocksource has been installed.
[ 76.530890] ReiserFS: sdc1: found reiserfs format "3.6" with standard journal
[ 76.550312] input: AT Translated Set 2 keyboard as /class/input/input0
[ 76.725051] logips2pp: Detected unknown logitech mouse model 0
[ 77.245394] input: PS/2 Logitech Mouse as /class/input/input1
[ 94.958327] ReiserFS: sdc1: using ordered data mode
[ 94.991667] ReiserFS: sdc1: journal params: device sdc1, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
[ 94.994994] ReiserFS: sdc1: checking transaction log (sdc1)
[ 95.080519] ReiserFS: sdc1: Using r5 hash to sort names
[ 102.790993] Real Time Clock Driver v1.12ac
[ 105.362817] Linux Tulip driver version 1.1.13-NAPI (December 15, 2004)
[ 105.364136] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
[ 105.364252] PCI: setting IRQ 9 as level-triggered
[ 105.364263] ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKC] ->
GSI 9 (level, low) -> IRQ 9
[ 105.380719] tulip0: EEPROM default media type Autosense.
[ 105.380828] tulip0: Index #0 - Media MII (#11) described by a
21142 MII PHY (3) block.
[ 105.385259] tulip0: MII transceiver #1 config 1000 status 782d
advertising 01e1.
[ 105.390474] eth0: Digital DS21143 Tulip rev 65 at 0001d000,
00:C0:F0:4A:0C:46, IRQ 9.
[ 105.412046] pcnet32.c:v1.32 18.Mar.2006 tsbogend@alpha.franken.de
[ 105.515961] NET: Registered protocol family 5
[ 105.613710] ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
[ 105.614319] ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKA] ->
GSI 10 (level, low) -> IRQ 10
[ 105.614625] eth1: ns83820.c: 0x22c: 00000000, subsystem: 0000:0000
[ 105.641785] eth1: ns83820 v0.23: DP83820 v1.2: 00:4f:4a:00:13:5a
io=0xefffb000 irq=10 f=sg
[ 106.289402] Loading Reiser4. See www.namesys.com for a description
of Reiser4.
[ 139.047608] JFS: nTxBlock = 4023, nTxLock = 32185
[ 157.171109] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 158.611757] eth1: link now 1000 mbps, full duplex and up.
[ 161.526960] eth0: Setting full-duplex based on MII#1 link partner
capability of cde1.
[ 168.051671]
[ 168.051676] ============================
[ 168.055000] [ BUG: illegal lock usage! ]
[ 168.055087] ----------------------------
[ 168.055176] illegal {softirq-on-W} -> {in-softirq-W} usage.
[ 168.055273] idle/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 168.055368] (&dev->rx_info.lock){-+..}, at: [<e090a98f>]
rx_irq+0x24/0x18f [ns83820]
[ 168.055664] {softirq-on-W} state was registered at:
[ 168.055755] [<c012d27d>] trace_hardirqs_on+0x142/0x16d
[ 168.055972] [<c028815a>] _spin_unlock_irq+0x21/0x25
[ 168.056166] [<e090b78e>] ns83820_open+0x25b/0x381 [ns83820]
[ 168.056357] [<c0242c60>] dev_open+0x2d/0x64
[ 168.056543] [<c024171e>] dev_change_flags+0x51/0xf1
[ 168.056728] [<c0274e42>] devinet_ioctl+0x238/0x556
[ 168.056915] [<c02753d3>] inet_ioctl+0x73/0x91
[ 168.057095] [<c023929f>] sock_ioctl+0x190/0x1b6
[ 168.057279] [<c0164701>] do_ioctl+0x19/0x4f
[ 168.057466] [<c0164940>] vfs_ioctl+0x209/0x220
[ 168.057648] [<c0164983>] sys_ioctl+0x2c/0x59
[ 168.057827] [<c0288283>] syscall_call+0x7/0xb
[ 168.058009] irq event stamp: 575395
[ 168.058098] hardirqs last enabled at (575394): [<c011a64d>]
tasklet_action+0x20/0x71
[ 168.058299] hardirqs last disabled at (575395): [<c0287ffd>]
_spin_lock_irqsave+0xf/0x2f
[ 168.058491] softirqs last enabled at (575386): [<c011aa6a>]
__do_softirq+0x97/0x9c
[ 168.058680] softirqs last disabled at (575391): [<c01045e3>]
do_softirq+0x45/0xb6
[ 168.058873]
[ 168.058875] other info that might help us debug this:
[ 168.059056] no locks held by idle/0.
[ 168.059149]
[ 168.059151] stack backtrace:
[ 168.059732] [<c010311a>] show_trace_log_lvl+0x54/0xfd
[ 168.059889] [<c0103709>] show_trace+0xd/0x10
[ 168.060031] [<c0103750>] dump_stack+0x19/0x1b
[ 168.060173] [<c012b89a>] print_usage_bug+0x1a4/0x1ae
[ 168.060512] [<c012be3d>] mark_lock+0x16b/0x502
[ 168.060844] [<c012cae0>] __lockdep_acquire+0x3cb/0xa26
[ 168.061181] [<c012d56f>] lockdep_acquire+0x69/0x82
[ 168.061515] [<c028800e>] _spin_lock_irqsave+0x20/0x2f
[ 168.061880] [<e090a98f>] rx_irq+0x24/0x18f [ns83820]
[ 168.062026] [<e090acd9>] rx_action+0x19/0x5a [ns83820]
[ 168.062164] [<c011a672>] tasklet_action+0x45/0x71
[ 168.062422] [<c011aa19>] __do_softirq+0x46/0x9c
[ 168.062681] [<c01045e3>] do_softirq+0x45/0xb6
[ 168.062838] [<c011aa9f>] irq_exit+0x30/0x32
[ 168.063095] [<c01046d9>] do_IRQ+0x85/0x90
[ 168.063246] [<c0102c45>] common_interrupt+0x25/0x2c
[ 170.236049] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[ 170.236840] NFSD: starting 90-second grace period
[ 172.087631] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.088785] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.091643] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.092365] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.095425] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.096145] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.099023] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.099742] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.102564] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 172.103278] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vodx9cm3g.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > As example given a selected revision with id <sha> is it possible to
> > do something like this to fond the ancestor?
> >
> > 1) get the tag list with git-peek-remote or something similar if tags
> > are not already loaded
> >
> > 2) given the tagList vector with n elements run
> >
> > git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
> > ^tagList[n-1]
> >
> > 3) take the last sha spit out by git-rev-list, be it <lastSha>.
> >
> > 4) Previous nearest tag is the parent of lastSha
>
> Sorry, I do not understand what you are doing here at all.
> Suppose you have this simple history.
>
> (root)
>
> a---b---d---e---f---g
> t1 \ / t3
> ---c
> t2
>
> and <sha1> in (2) is "e". When tagList = (t1, t2, t3), the
> above rev-list would return empty.
This is enough!
Empty list is an useful and enough information.
It means:
1) Parent of current revision ("e" in our case) is a tag, indeed our seeked tag.
2) If previous point is not true then there are no previous tags.
In a less corner case, just to better explaing my idea, consider this:
a---b---d---e---f---g---h
t1 \ / t3
---c
t2
Where our sha1 is still "e", in this case
git-rev-list --topo-order <e> ^a ^c ^g
gives, as last revision in output list, "f"
Then parentOf(<f>) is <g> and our looked for tag is t3
Marco
^ permalink raw reply
* Re: Linux kernel development
From: Paolo Ciarrocchi @ 2006-06-04 10:00 UTC (permalink / raw)
To: Horst von Brand; +Cc: linux-kernel, Kalin KOZHUHAROV, Jesper Juhl, Greg KH
In-Reply-To: <200606031828.k53ISSgr012167@laptop11.inf.utfsm.cl>
On 6/3/06, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > On 11/15/05, Greg KH <greg@kroah.com> wrote:
> > [...]
> > > > http://linux.tar.bz/articles/2.6-development_process
> > >
> > > Ah, a very nice summary.
> > >
> > > Paolo, can I use this document as a base for this section in the HOWTO
> > > file (with proper attribution of course.)
> >
> > That article is now living in a git tree, it now contains only spell
> > checks but I plan to work more on it in the next few days.
>
> I'd break it up into logical pieces (i.e., chapters...)
Yup, already in my todo list.
> The lines are way too long for easy reading.
Ok, I'll try to work on it.
> There are several other tools to check kernel quality: sparse, the
> lockcheck, ... And don't forget about the various debugging config options
Mmmh... Right, but the goal of the document was mainly to document the
process not the tools. However, that's a good comment.
> There are required tools for serious kernel development, i.e. git and its
> entournage. Link to them.
Ok.
> You mention that patches cook in -mm for a while, but you don't tell what
> that is beforehand. In general, a high-level overview of the current
> git-based development would be useful, and the various important git kernel
> trees and the patch flow among them.
Ok.
> Don't be shy in mentioning the stuff under Documentation in your nearest
> kernel source!
Right.
> Perhaps do an asccidoc format, to be able to create HTML?
Sure, but I don't know how to do it.
Patches are more then welcome :-)
Thank you for your valuable comments!!
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* [PATCH] bcm43xx-d80211: Fix 64bit compiler warnings
From: Michael Buesch @ 2006-06-04 10:03 UTC (permalink / raw)
To: linville; +Cc: netdev, bcm43xx-dev
Fix all 64bit compiler warnings.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
index e882bc1..0f7303e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
@@ -227,7 +227,7 @@ static ssize_t tsf_write_file(struct fil
res = -EFAULT;
goto out_unlock;
}
- if (sscanf(buf, "%lli", &tsf) != 1) {
+ if (sscanf(buf, "%llu", (unsigned long long *)(&tsf)) != 1) {
printk(KERN_INFO PFX "debugfs: invalid values for \"tsf\"\n");
res = -EINVAL;
goto out_unlock;
@@ -449,11 +449,11 @@ void bcm43xx_printk_dump(const char *dat
size_t size,
const char *description)
{
- size_t i;
+ unsigned int i;
char c;
- printk(KERN_INFO PFX "Data dump (%s, %u bytes):",
- description, size);
+ printk(KERN_INFO PFX "Data dump (%s, %lu bytes):",
+ description, (unsigned long)size);
for (i = 0; i < size; i++) {
c = data[i];
if (i % 8 == 0)
@@ -468,12 +468,13 @@ void bcm43xx_printk_bitdump(const unsign
size_t bytes, int msb_to_lsb,
const char *description)
{
- size_t i;
+ unsigned int i;
int j;
const unsigned char *d;
- printk(KERN_INFO PFX "*** Bitdump (%s, %u bytes, %s) ***",
- description, bytes, msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
+ printk(KERN_INFO PFX "*** Bitdump (%s, %lu bytes, %s) ***",
+ description, (unsigned long)bytes,
+ msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
for (i = 0; i < bytes; i++) {
d = data + i;
if (i % 8 == 0)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..1dfd74e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -180,7 +180,7 @@ static int alloc_ringmemory(struct bcm43
if (ring->dmabase + BCM43xx_DMA_RINGMEMSIZE > BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RINGMEMORY >1G "
"(0x%08x, len: %lu)\n",
- ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
+ (unsigned int)ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
ring->vbase, ring->dmabase);
return -ENOMEM;
@@ -292,7 +292,7 @@ static int setup_rx_descbuffer(struct bc
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RX SKB >1G "
"(0x%08x, len: %u)\n",
- dmaaddr, ring->rx_buffersize);
+ (unsigned int)dmaaddr, ring->rx_buffersize);
return -ENOMEM;
}
meta->skb = skb;
@@ -711,7 +711,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, hdr_skb->len);
+ (unsigned int)meta->dmaaddr, hdr_skb->len);
return -ENOMEM;
}
@@ -742,7 +742,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, skb->len);
+ (unsigned int)meta->dmaaddr, skb->len);
return -ENOMEM;
}
--
Greetings Michael.
^ permalink raw reply related
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:06 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606040254n1449b62ta70c209ad8e1a0c@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> In a less corner case, just to better explaing my idea, consider this:
>
> a---b---d---e---f---g---h
> t1 \ / t3
> ---c
> t2
>
> Where our sha1 is still "e", in this case
>
> git-rev-list --topo-order <e> ^a ^c ^g
>
> gives, as last revision in output list, "f"
> Then parentOf(<f>) is <g> and our looked for tag is t3
Sorry, in the example time flows from left to right. If you
exclude g then you are excluding everything that is reachable
from g so you would not see "f".
Even if your example is different from what I gave (which had
"a" as the root commit) and h is the root commit, your ^a and ^c
would exclude everything that is reachable from either a or c,
so you would get an empty set. So your "last revision in
output" would not be "f" either.
^ permalink raw reply
* [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags part 3
From: Arjan van de Ven @ 2006-06-04 10:08 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: Ingo Molnar, linux-kernel, Andrew Morton
In-Reply-To: <986ed62e0606040253pfe9c300qf88029f88ae65039@mail.gmail.com>
On Sun, 2006-06-04 at 02:53 -0700, Barry K. Nathan wrote:
> On 6/4/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> > just the preempt the next email from Barry; while fixing this one I
> > looked at the usage of the locks more and found another patch needed...
> [snip]
>
> Nice try, but it didn't work. ~_^
>
> I was about to reply to the previous ns83820 patch with my dmesg, when
> I saw this one. I applied this patch too, and like the previous patch,
> it reports an instance of illegal lock usage. My dmesg follows.
> --
ok this is a real driver deadlock:
The ns83820 driver enabled interrupts (by unlocking the misc_lock with
_irq) while still holding the rx_info.lock, which is required to be irq
safe since it's used in the ISR like this:
writel(1, dev->base + IER);
spin_unlock_irq(&dev->misc_lock);
kick_rx(ndev);
spin_unlock_irq(&dev->rx_info.lock);
This is can cause a deadlock if an irq was pending at the first
spin_unlock_irq already, or if one would hit during kick_rx().
Simply remove the first _irq solves this
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
drivers/net/ns83820.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc5-mm3/drivers/net/ns83820.c
===================================================================
--- linux-2.6.17-rc5-mm3.orig/drivers/net/ns83820.c
+++ linux-2.6.17-rc5-mm3/drivers/net/ns83820.c
@@ -808,7 +808,7 @@ static int ns83820_setup_rx(struct net_d
writel(dev->IMR_cache, dev->base + IMR);
writel(1, dev->base + IER);
- spin_unlock_irq(&dev->misc_lock);
+ spin_unlock(&dev->misc_lock);
kick_rx(ndev);
^ permalink raw reply
* Re: 2.6.17-rc5-mm3
From: Michal Piotrowski @ 2006-06-04 10:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Arjan van de Ven, linux-kernel
In-Reply-To: <20060604024937.0fb57258.akpm@osdl.org>
Hi Andrew,
On 04/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 4 Jun 2006 02:38:03 -0700
> "Barry K. Nathan" <barryn@pobox.com> wrote:
>
> > When I build ACPI processor support as a module, I get this:
> >
> > MODPOST
> > WARNING: drivers/acpi/processor.o - Section mismatch: reference to
> > .init.data: from .text between 'acpi_processor_power_init' (at offset
> > 0xfb0) and 'acpi_safe_halt'
>
> yup. The code in there is actually correct (assuming
> acpi_processor_power_init()'s first invokation is at initcall-time).
>
> Maybe we'll do something to kill the warning, once we're down to the last
> few thousand of them ;)
I have got something similar
WARNING: drivers/usb/storage/usb-storage.o - Section mismatch:
reference to .exit.text: from .smp_locks after '' (at offset 0x3c)
WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch:
reference to .init.text: from .smp_locks after '' (at offset 0x8)
WARNING: net/ipv6/ipv6.o - Section mismatch: reference to .init.text:
from .smp_locks after '' (at offset 0x14c)
WARNING: net/ipv6/ipv6.o - Section mismatch: reference to .init.text:
from .smp_locks after '' (at offset 0x17c)
BTW. I still get this bug
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/bug_1.jpg
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply
* Re: 2.6.17-rc3: XFS internal error xlog_clear_stale_blocks(1)
From: David Greaves @ 2006-06-04 10:10 UTC (permalink / raw)
To: xfs, linux-kernel
In-Reply-To: <4482AB6A.9010105@dgreaves.com>
David Greaves wrote:
> Hi
>
> vanilla 2.6.17-rc3
>
> mounting onto an lvm2 ontop of raid5 on top of sata
>
> Filesystem "dm-0": Disabling barriers, not supported by the underlying
> device
> XFS mounting filesystem dm-0
> Filesystem "dm-0": XFS internal error xlog_clear_stale_blocks(1) at line
> 1225 of file fs/xfs/xfs_log_recover.c. Caller 0xb01fca2f
> <b01fb8d9> xlog_find_tail+0xa39/0xeb0 <b01fca2f> xlog_recover+0x2f/0x2f0
> <b01fca2f> xlog_recover+0x2f/0x2f0 <b01f5566> xfs_log_mount+0x256/0x650
> <b01fec19> xfs_mountfs+0xd09/0x1260 <b021b199>
> xfs_mountfs_check_barriers+0x39/0x120
> <b0207cef> xfs_mount+0xa2f/0xbf0 <b021c130> xfs_fs_fill_super+0xa0/0x250
> <b0237e8b> snprintf+0x2b/0x30 <b0198095> disk_name+0xd5/0xf0
> <b016644f> sb_set_blocksize+0x1f/0x50 <b0165407> get_sb_bdev+0x117/0x155
> <b021b6ff> xfs_fs_get_sb+0x2f/0x40 <b021c090> xfs_fs_fill_super+0x0/0x250
> <b0164882> do_kern_mount+0x52/0xe0 <b017cd1d> do_mount+0x29d/0x770
> <b016eb8e> do_path_lookup+0x10e/0x270 <b016c35a> getname+0xda/0x100
> <b014219e> __alloc_pages+0x5e/0x2f0 <b01426e4> __get_free_pages+0x34/0x60
> <b017b824> copy_mount_options+0x44/0x140 <b017d28d> sys_mount+0x9d/0xe0
> <b010304b> syscall_call+0x7/0xb
> XFS: failed to locate log tail
> XFS: log mount/recovery failed: error 990
> XFS: log mount failed
>
>
> Anything else I can do?
> (is it worth trying -rc5?)
>
> I'm building 2.6.16.19 and I'll try that shortly...
>
> David
>
So I tried 2.6.17-rc5 and the problem resolved itself.
David
--
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <7vbqt9ck05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>> In a less corner case, just to better explaing my idea, consider this:
>>
>> a---b---d---e---f---g---h
>> t1 \ / t3
>> ---c
>> t2
>>
>> Where our sha1 is still "e", in this case
>>
>> git-rev-list --topo-order <e> ^a ^c ^g
>>
>> gives, as last revision in output list, "f"
>> Then parentOf(<f>) is <g> and our looked for tag is t3
>
> Sorry, in the example time flows from left to right. If you
> exclude g then you are excluding everything that is reachable
> from g so you would not see "f".
>
> Even if your example is different from what I gave (which had
> "a" as the root commit) and h is the root commit, your ^a and ^c
> would exclude everything that is reachable from either a or c,
> so you would get an empty set. So your "last revision in
> output" would not be "f" either.
BTW, that was exactly what I meant by "2^N permutations of
tags". If you exclude all tags that are older than "e" then
your algorithm would work beautifully, but the algorithm is
about finding out which tags are older than "e" to begin with,
so...
^ permalink raw reply
* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags part 3
From: Ingo Molnar @ 2006-06-04 10:11 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Barry K. Nathan, linux-kernel, Andrew Morton
In-Reply-To: <1149415707.3109.96.camel@laptopd505.fenrus.org>
* Arjan van de Ven <arjan@linux.intel.com> wrote:
> On Sun, 2006-06-04 at 02:53 -0700, Barry K. Nathan wrote:
> > On 6/4/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> > > just the preempt the next email from Barry; while fixing this one I
> > > looked at the usage of the locks more and found another patch needed...
> > [snip]
> >
> > Nice try, but it didn't work. ~_^
> >
> > I was about to reply to the previous ns83820 patch with my dmesg, when
> > I saw this one. I applied this patch too, and like the previous patch,
> > it reports an instance of illegal lock usage. My dmesg follows.
> > --
>
> ok this is a real driver deadlock:
preexisting bug, right? So this fix should go into 2.6.16/17 too,
correct?
Ingo
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Stefan Rompf @ 2006-06-04 10:14 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606041002.33696.IvDoorn@gmail.com>
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
> Except for the bluetooth radio key (which should be supported by the
> radiobtn interface as well) the other buttons have support through already
> excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. That's why I pointed you to
the wistron_btns driver. Alternatively, look at the acerhk driver
(http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
number of additional buttons that need to be handled by a special driver, all
sent to userspace, and just one of them to trigger the wireless card. Other
models just handle the button in ACPI and generate an additional ACPI event.
Looking at the RT2400-driver, I see what you want to accomplish: Take the view
of the WLAN card on the hardware controlled button enable/disable and
generate events on it. However, in many cases it is another driver (see
above) that sets or clears this state, and this should be the instance to
send the input event.
Note that I do not have objections against the driver being included in the
kernel - it just does not qualify as generic radiobutton support, but I know
it's hard to find a good name ;-)
Looking at the code only: There should be an additional non-polling interface
for drivers that can generate events on the own.
Stefan
^ permalink raw reply
* pci_restore_state
From: Ryan Lortie @ 2006-06-04 10:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Matthew Garrett, Ben Collins
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
Hello.
Currently pci_restore_state() (drivers/pci/pci.c) restores the PCI state
by copying in the saved PCI configuration space, a dword at a time,
starting from 0 up to 15.
This causes a crash when my Macbook resumes from sleep (specifically,
when restoring the configuration space of the PCI bridge).
Reading the PCI specification, the register at dword 1 (ie: bytes 4-7)
is split half and half between status and command words. The command
word effectively controls the way which the PCI device interacts with
the system. If it is 0, the device is logically disconnected from the
bus (PCI Local Bus Specification Revision 2.2, 6.2.2 "Device
Control").
When a device first powers up, the command register value is normally
zero (and is zero in my specific case).
The problem with the way that the PCI state is currently restored is
that the write to the command register logically reconnects the device
to the bus before the rest of the configuration space has been filled
in.
My Macbook crashes on resume.
If I reverse the for loop to start from 15 and count down to 0, then the
majority of the configuration space is filled in _before_ the command
word is modified. No crash.
About dword 0 -- this dword contains only the vendor and product ID
codes which will always be set by the device (as far as I know) so it's
not a problem to not have written these before restoring the value of
the command register. I'm not sure they even ever need to be written.
I am essentially requesting that this piece of code be changed in the
stock kernel as I changed it (described above). It makes sleep work on
my Macbook and may fix some others too (and/or make more reliable some
which already work).
Cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 703 bytes --]
^ permalink raw reply
* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags part 3
From: Arjan van de Ven @ 2006-06-04 10:16 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Barry K. Nathan, linux-kernel, Andrew Morton
In-Reply-To: <20060604101136.GA14693@elte.hu>
On Sun, 2006-06-04 at 12:11 +0200, Ingo Molnar wrote:
> * Arjan van de Ven <arjan@linux.intel.com> wrote:
>
> > On Sun, 2006-06-04 at 02:53 -0700, Barry K. Nathan wrote:
> > > On 6/4/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> > > > just the preempt the next email from Barry; while fixing this one I
> > > > looked at the usage of the locks more and found another patch needed...
> > > [snip]
> > >
> > > Nice try, but it didn't work. ~_^
> > >
> > > I was about to reply to the previous ns83820 patch with my dmesg, when
> > > I saw this one. I applied this patch too, and like the previous patch,
> > > it reports an instance of illegal lock usage. My dmesg follows.
> > > --
> >
> > ok this is a real driver deadlock:
>
> preexisting bug, right? So this fix should go into 2.6.16/17 too,
> correct?
yes; this is real driver deadlock that has been there for quite some
time
^ permalink raw reply
* SMP HT + USB2.0 crash
From: davor emard @ 2006-06-04 10:19 UTC (permalink / raw)
To: linux-kernel
HI
I have an asus MB with intel 925XE chipset and hyperthreading capable CPU.
Certain lockups with random oops occur all through kernel 2.6.16.19. Some of
lockups are SMP only oopses (sorry but I didn't catch them exactly to a file),
other are usually like this attached file
As a general rule, if both
1) SMP
2) EHCI (usb 2.0)
Are enabled and USB2.0 devices are used frequently, then
kernel lockup appear between few minutes and 1 day. It is very annoying
Disabling either SMP or the EHCI fixes the lockups. Probably some
missing spin_lock or whatever in EHCI...
Emard
^ permalink raw reply
* SMP HT + USB2.0 crash
From: davor emard @ 2006-06-04 10:22 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 37 bytes --]
Usually SMP + EHCI crashes like this
[-- Attachment #2: crash2.syslog --]
[-- Type: text/plain, Size: 3343 bytes --]
Apr 13 00:49:00 localhost kernel: Unable to handle kernel paging request at virtual address 1359024b
Apr 13 00:49:00 localhost kernel: printing eip:
Apr 13 00:49:00 localhost kernel: c013c633
Apr 13 00:49:00 localhost kernel: *pde = 00000000
Apr 13 00:49:00 localhost kernel: Oops: 0002 [#1]
Apr 13 00:49:00 localhost kernel: PREEMPT SMP
Apr 13 00:49:00 localhost kernel: Modules linked in: police sch_ingress cls_u32 sch_sfq sch_cbq pppoe pppox rfcomm l2cap lp thermal fan button processor ac battery ppp_generic slhc dv1394 raw1394 w83627ehf hwmon i2c_isa uinput nvram ircomm_tty ircomm stir4200 irda vfat fat db9 saa7134_alsa eeprom nvidia pl2303 usbserial usbhid usblp eth1394 dvb_usb_a800 dvb_usb_dibusb_common dib3000mc dib3000_common dvb_usb dvb_pll hci_usb bluetooth tuner snd_mpu401 8250_pnp snd_mpu401_uart 8250 serial_core snd_rawmidi snd_hda_intel saa7134 ir_kbd_i2c ir_common serio_raw snd_seq_device pcspkr dvb_ttpci l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev ves1820 stv0299 dvb_core tda8083 stv0297 sp8870 ves1x93 snd_hda_codec parport_pc parport rtc ohci1394 ieee1394 ttpci_eeprom i2c_i801 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd ehci_hcd snd_page_alloc uhci_hcd ide_cd cdrom
Apr 13 00:49:00 localhost kernel: CPU: 1
Apr 13 00:49:00 localhost kernel: EIP: 0060:[free_block+57/183] Tainted: P VLI
Apr 13 00:49:00 localhost kernel: EFLAGS: 00210002 (2.6.15.7)
Apr 13 00:49:00 localhost kernel: EIP is at free_block+0x39/0xb7
Apr 13 00:49:00 localhost kernel: eax: 87be9624 ebx: dc6b7000 ecx: dc6b76f8 edx: 13590247
Apr 13 00:49:00 localhost kernel: esi: f792bfc0 edi: f7f20840 ebp: 00000008 esp: f7c8ff14
Apr 13 00:49:00 localhost kernel: ds: 007b es: 007b ss: 0068
Apr 13 00:49:00 localhost kernel: Process events/1 (pid: 9, threadinfo=f7c8c000 task=f7c64a30)
Apr 13 00:49:00 localhost kernel: Stack: f7fbe618 00000018 f7fbe600 00000000 c013ce68 f7f20840 f7fbe618 00000018
Apr 13 00:49:00 localhost kernel: 00000000 f7f20840 f792bf50 f792bfc0 f7f20840 00000001 c013cefb f7f20840
Apr 13 00:49:00 localhost kernel: f7fbe600 00000000 00000000 f792bfe8 f7f20898 c1712120 f7c081c0 c1712124
Apr 13 00:49:00 localhost kernel: Call Trace:
Apr 13 00:49:00 localhost kernel: [drain_array_locked+98/140] drain_array_locked+0x62/0x8c
Apr 13 00:49:00 localhost kernel: [cache_reap+105/372] cache_reap+0x69/0x174
Apr 13 00:49:00 localhost kernel: [worker_thread+342/452] worker_thread+0x156/0x1c4
Apr 13 00:49:00 localhost kernel: [cache_reap+0/372] cache_reap+0x0/0x174
Apr 13 00:49:00 localhost kernel: [default_wake_function+0/18] default_wake_function+0x0/0x12
Apr 13 00:49:00 localhost kernel: [worker_thread+0/452] worker_thread+0x0/0x1c4
Apr 13 00:49:00 localhost kernel: [kthread+114/159] kthread+0x72/0x9f
Apr 13 00:49:00 localhost kernel: [kthread+0/159] kthread+0x0/0x9f
Apr 13 00:49:00 localhost kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb
Apr 13 00:49:00 localhost kernel: Code: 00 8b 44 24 18 8b 0c a8 8d 81 00 00 00 40 c1 e8 0c c1 e0 05 8b 15 10 e2 4f c0 8b 5c 10 1c 8b 44 24 20 8b 74 87 18 8b 13 8b 43 04 <89> 42 04 89 10 c7 03 00 01 10 00 c7 43 04 00 02 20 00 2b 4b 0c
Apr 13 00:49:00 localhost kernel: <6>note: events/1[9] exited with preempt_count 1
Apr 13 00:52:11 localhost syslogd 1.4.1#17: restart.
^ permalink raw reply
* Re: pci_restore_state
From: Andrew Morton @ 2006-06-04 10:27 UTC (permalink / raw)
To: Ryan Lortie; +Cc: linux-kernel, mjg59, bcollins, Greg KH
In-Reply-To: <1149416010.30767.14.camel@moonpix.desrt.ca>
On Sun, 04 Jun 2006 06:13:30 -0400
Ryan Lortie <desrt@desrt.ca> wrote:
> Currently pci_restore_state() (drivers/pci/pci.c) restores the PCI state
> by copying in the saved PCI configuration space, a dword at a time,
> starting from 0 up to 15.
>
> This causes a crash when my Macbook resumes from sleep (specifically,
> when restoring the configuration space of the PCI bridge).
>
> Reading the PCI specification, the register at dword 1 (ie: bytes 4-7)
> is split half and half between status and command words. The command
> word effectively controls the way which the PCI device interacts with
> the system. If it is 0, the device is logically disconnected from the
> bus (PCI Local Bus Specification Revision 2.2, 6.2.2 "Device
> Control").
>
> When a device first powers up, the command register value is normally
> zero (and is zero in my specific case).
>
> The problem with the way that the PCI state is currently restored is
> that the write to the command register logically reconnects the device
> to the bus before the rest of the configuration space has been filled
> in.
>
> My Macbook crashes on resume.
>
> If I reverse the for loop to start from 15 and count down to 0, then the
> majority of the configuration space is filled in _before_ the command
> word is modified. No crash.
We have a patch pending which will do that.
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-pci/pci-reverse-pci-config-space-restore-order.patch
The present plan will be to get this into 2.6.18.
^ permalink raw reply
* Re: Linux kernel development
From: Paolo Ciarrocchi @ 2006-06-04 10:30 UTC (permalink / raw)
To: Horst von Brand; +Cc: linux-kernel, Kalin KOZHUHAROV, Jesper Juhl, Greg KH
In-Reply-To: <4d8e3fd30606040300w6d939f4csfe96829d3e5481a9@mail.gmail.com>
On 6/4/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 6/3/06, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
[...]
>
> Thank you for your valuable comments!!
BTW, I implemented a few changes according to your feedbacks.
Committed and pushed out.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqt9ck05.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > In a less corner case, just to better explaing my idea, consider this:
> >
> > a---b---d---e---f---g---h
> > t1 \ / t3
> > ---c
> > t2
> >
> > Where our sha1 is still "e", in this case
> >
> > git-rev-list --topo-order <e> ^a ^c ^g
> >
> > gives, as last revision in output list, "f"
> > Then parentOf(<f>) is <g> and our looked for tag is t3
>
> Sorry, in the example time flows from left to right. If you
> exclude g then you are excluding everything that is reachable
> from g so you would not see "f".
>
From today git:
tag list is:
v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
(Allow "git repack" users to specify repacking window/depth)
$ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
^1b9bc5a7b7434d771726011613a00cb202bd9f44
^7abd7117ec57b8c3c2a469db62c7811fdac5c655
^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
^4baff50551545e2b6825973ec37bcaf03edb95fe
ccb365047a1081455b767867f0887e7b4334f9d8
85e6326cc3e7c272566c60a39741f84391830d49
4262c1b0c38613a8c5ae729bd4d3f18f0df3ec44
24735cfc500feb2a8dba9f140080ab3476363d28
caef71a5354ca162cc5a6914a7a643efbc9ae28a
34e98ea56414adc5a582e6368e8ec9c109dbee48
3a624b346db02a07b0317743b362d1a15c6c3c18
965f803c323bb72a9dedbbc8f7ba00bbadb6cf58
b073f26b256cded6252bafd34982eb6f69d2a4b6
a4d34e2db5565e6b75f79f9d3938aa9151e72e44
eab144ac49c18d981261c2d0ba964d6380d9f1da
9153983310a169a340bd1023dccafd80b70b05bc
db89665fbf86d4e0166b2f252a939ed8bf6782fe
78fff6ebbafe2d23464a2b059104954bfe8732c7
cb8f64b4e3f263c113b7a2f156af74b810e969ff
d4ed9793fd981ea5a35ebaa8e337446bb29f6d55
b2934926dd7455de61577c1dfdf4c12d224e7ae0
ba1d45051e050cbcf68ccccacea86a4b6ecde731
5b84f4d87a1bd58c7540e9ea82ee3673ecddbad5
7594c4b2d7cc81f806453402aefe1bf71ae6dd53
6b9c58f4669b3832ed2830f0cb1a307ea6bc6063
8c1f0b44c59530dea8007a9f5b69d0fac6aea3b1
8e8f998739db6526fe890fabc88c866759bc2ac3
cd2bdc5309461034e5cc58e1d3e87535ed9e093b
Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
4baff50551545e2b6825973ec37bcaf03edb95fe
aka tag v1.3.0
Am I missing something?
^ permalink raw reply
* Re: 2.6.17-rc5-mm3
From: Ingo Molnar @ 2006-06-04 10:41 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, Arjan van de Ven, linux-kernel
In-Reply-To: <6bffcb0e0606040308j28d9e89axa0136908c5530ae3@mail.gmail.com>
* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> BTW. I still get this bug
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/bug_1.jpg
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/mm-config
could you please apply the following patches ontop of -mm3:
http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc5-mm3.patch
http://redhat.com/~mingo/lockdep-patches/lockdep-tracer-2.6.17-rc5-mm3.patch
accept all the default 'make oldconfig' options and reboot into the
patched kernel. If everything goes well then the system should still
boot up fine and you should still get the lockdep warning - but this
time there should be a long trace in /proc/latency_trace. Please upload
that trace - it gives us the kernel's function trace, leading up to the
warning.
Ingo
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com>
On 6/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
> > > In a less corner case, just to better explaing my idea, consider this:
> > >
> > > a---b---d---e---f---g---h
> > > t1 \ / t3
> > > ---c
> > > t2
> > >
> > > Where our sha1 is still "e", in this case
> > >
> > > git-rev-list --topo-order <e> ^a ^c ^g
> > >
> > > gives, as last revision in output list, "f"
> > > Then parentOf(<f>) is <g> and our looked for tag is t3
> >
> > Sorry, in the example time flows from left to right. If you
> > exclude g then you are excluding everything that is reachable
> > from g so you would not see "f".
To better explain what I mean, that's the algorithm :
cmd = "git-rev-list --topo-order --parents " + sha;
for (uint i = 0; i < tagList.count(); i++)
cmd.append(" ^" + tagList[i]);
output = run(cmd);
if (output.isEmpty()) {
parent = parentOf(sha);
return (parent && parent->isTag()) ? parent->tag() : NO_TAG;
}
lastSha = getLastLine(output);
parent = parentOf(lastSha);
return (parent && parent->isTag()) ? parent->tag() : NO_TAG;
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
>> Sorry, in the example time flows from left to right. If you
>> exclude g then you are excluding everything that is reachable
>> from g so you would not see "f".
>>
> From today git:
>
> tag list is:
>
> v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
> v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
> v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
>
> selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
> (Allow "git repack" users to specify repacking window/depth)
>
> $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
> ^1b9bc5a7b7434d771726011613a00cb202bd9f44
> ^7abd7117ec57b8c3c2a469db62c7811fdac5c655
> ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> ^4baff50551545e2b6825973ec37bcaf03edb95fe
>
> ccb365047a1081455b767867f0887e7b4334f9d8
> ...
> cd2bdc5309461034e5cc58e1d3e87535ed9e093b
>
> Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
>
> 4baff50551545e2b6825973ec37bcaf03edb95fe
>
> aka tag v1.3.0
>
> Am I missing something?
No, just that I am not getting what you are trying to prove
here. The tags are all older than your chosen commit.
$ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff
would show nothing -- and you propose to find out that commit is
between v1.3.1 and v1.3.2 by using the information that the
command gives an empty result but I do not know how?
$ git show-branch v1.3.1 e923eff v1.3.2
does show it is between these two, but that is because it avoids
the 2^N permutations by using 1-bit per revision that it wants to
check the reachability across.
^ permalink raw reply
* Re: [PATCH 25/27] Documentation: Spelling fixes
From: Ben Clifford @ 2006-06-04 10:42 UTC (permalink / raw)
To: Horst.H.von.Brand; +Cc: git, Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366517875-git-send-email->
Horst,
> The default post-update hook, when enabled, runs
> `git-update-server-info` to keep the information used by dumb
> -transports (eg, http) up-to-date. If you are publishing
> +transports (e.g.,, http) up-to-date. If you are publishing
> a git repository that is accessible via http, you should
> probably enable this hook.
just one extra , there
(btw private mail to you keeps bouncing here with various declarations
that you do not exist)
--
^ permalink raw reply
* Re: [patch, -rc5-mm3] lock validator: fix ns83820.c irq-flags part 3
From: Barry K. Nathan @ 2006-06-04 10:46 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Ingo Molnar, linux-kernel, Andrew Morton
In-Reply-To: <1149415707.3109.96.camel@laptopd505.fenrus.org>
On 6/4/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> ok this is a real driver deadlock:
[snip]
With this third patch added, it boots cleanly, with no lockdep
messages. (And, each time, I've been checking things by sshing into
the box via the ns83820 NIC, so I can also confirm that the card works
with these patches.)
--
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply
* [patch, -rc5-mm3] lock validator: sparc64, sparc, m68k, alpha, cris, irqtrace build fix
From: Ingo Molnar @ 2006-06-04 10:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Arjan van de Ven
Subject: lock validator: sparc64, sparc, m68k, alpha, cris, irqtrace build fix
From: Ingo Molnar <mingo@elte.hu>
early_init_irq_lock_type() should only be provided by an architecture
if it offers CONFIG_TRACE_IRQFLAGS.
this makes sparc64 (and probably the other non-genirq arches) build.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/lockdep.h | 2 ++
init/main.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
Index: linux/include/linux/lockdep.h
===================================================================
--- linux.orig/include/linux/lockdep.h
+++ linux/include/linux/lockdep.h
@@ -226,9 +226,11 @@ struct lockdep_type_key { };
#endif /* !LOCKDEP */
#ifdef CONFIG_TRACE_IRQFLAGS
+extern void early_init_irq_lock_type(void);
extern void early_boot_irqs_off(void);
extern void early_boot_irqs_on(void);
#else
+# define early_init_irq_lock_type() do { } while (0)
# define early_boot_irqs_off() do { } while (0)
# define early_boot_irqs_on() do { } while (0)
#endif
Index: linux/init/main.c
===================================================================
--- linux.orig/init/main.c
+++ linux/init/main.c
@@ -82,7 +82,6 @@
static int init(void *);
-extern void early_init_irq_lock_type(void);
extern void init_IRQ(void);
extern void fork_init(unsigned long);
extern void mca_init(void);
^ permalink raw reply
* Re: [PATCH] Update writing udev rules documentation
From: Remco @ 2006-06-04 10:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4481B0C5.80301@gentoo.org>
> The patch isn't very readable, if anyone wants to review the changes I
> suggest you just look at the online version as almost all of it has been
> rewritten:
> http://www.reactivated.net/writing_udev_rules.html
>
> Comments appreciated.
>
Under 'About this document'
I don't think hotplug is a requirement nowadays.
Under 'Built-in persistent naming schemes'
I'm not sure this is true but
'/dev/disk/by-id/usb-Prolific_Technology_Inc._USB_Mass_Storage_Device-part1'
sounds semi-persistent to me. Imagine you've got two of these memory
sticks, what names do they get, and how can they be differentiated ? Since I
don't see a unique id, and unless udev has some trick up it's sleeve, I
suppose the second device detected will either overwrite the link created
by the first, or it won't create a link at all.
Under 'Putting your rules into action':
Maybe it's time to replace udevstart with udevtrigger ? Or at least mention
the udevtrigger/udevsettle combo.
I don't know if it's worthwhile mentioning that if a rule gets changed and
udevtrigger is run, the new device node / symlinks will be created
alongside the older existing one(s). Anything created by the old rules will
stay in place. The old stuff either needs to be removed manually or it will
disappear when the /dev tree is built from scratch. (probably only after a
reboot)
Under 'Logging'
AFAICT udev_log is used to set the logging severity. Normally setting it to
'err' is probably recommended, 'info' is useful for debugging and will dump
a lot of information to syslog. If I remember correctly, for this to work,
some option needs to be set to 'yes' during the build. (like 'make
USE_LOG=yes' or something similar)
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.