* 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: 2.6.17-rc5-mm3
From: Andrew Morton @ 2006-06-04 9:49 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: linux-kernel
In-Reply-To: <986ed62e0606040238t712d7b01xde5f4a23da12fb1a@mail.gmail.com>
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 ;)
> (This is also true of -mm2, but I didn't get a chance to report it
> before -mm3 was released. Before then, I built it into the kernel and
> not as a module.)
>
> and I still get this:
> WARNING: "scsi_tgt_queue_command" [drivers/scsi/libsrp.ko] undefined!
git-scsi-target Kconfig snafu. I passed it over to James the other day.
He might have fixed it - I get my git-scsi-misc via git-infiniband (don't
ask) and it's a bit laggy.
^ permalink raw reply
* Re: images -> DVD-slideshow ?
From: Christian Pedaschus @ 2006-06-04 9:49 UTC (permalink / raw)
To: chuck gelm; +Cc: linux-newbie
In-Reply-To: <44804628.5070106@gelm.net>
chuck gelm wrote:
> Howdy:
>
> What is your suggestion for an application that will convert
> many (still) images into a DVD slideshow, perhaps with
> background music? I've been trying to obtain image2mpeg
> with varying sucess. I was able to get a version downloaded
> and compiled. I created an image (stream.ppm), but there
> seems to be no mention of how to get the output file onto a DVD.
>
> If the output DVD <image> is small, can it be placed on
> a (650-700MB) CDROM and played on a standard DVD player?
> If yes, how? 'growisofs' balks at writing to my CDROM media.
>
> I am using Slackware v10.2 and understand *.tar.gz.
> I am poorer at installing *.rpm, but will try if that is the only
> offering of another application. *.deb, I don't know.
>
> Regards, Chuck
I once had to create the same and decided to use mplayer/mencoder, as i
like to automate things if possible.
As a start:
#Create an uncompressed avi-file from all the PNG files in the current
directory (fps defines the time)
mencoder mf://*.png -mf w=800:h=600:fps=25:type=png -ovc raw -oac copy
-o output.avi
#Now add sound using:
mencoder output.avi -audiofile audio.wav -oac copy -ovc copy -o
output_waudio.avi
#and now encode it into a dvd/svcd compliant format using:
13.6.5.1. PAL DVD
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf
scale=720:576,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:acodec=ac3:\
abitrate=192:aspect=16/9 -ofps 25 \
-o movie.mpg movie.avi
13.6.5.5. PAL SVCD
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \
scale=480:576,harddup -srate 44100 -af lavcresample=44100 -lavcopts \
vcodec=mpeg2video:mbd=2:keyint=15:vrc_buf_size=917:vrc_minrate=600:\
vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224 -ofps 25 \
-o movie.mpg movie.avi
You need to adjust the filenames as i just copied the stuff from the
mencoder manual, which you really should read, it's very interesting
and tells a lot of stuff about various video-formats.
Greets, Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: skge killing off snd_via686 interrupts on Fedora Core 5
From: Sitsofe Wheeler @ 2006-06-04 9:45 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1149181417.12932.44.camel@localhost>
(This accidentally fell off list so I'm going to see if I bodge it back)
On Sat, 03 Jun 2006 10:55:48 +0100, Alan Cox wrote:
> Ar Sad, 2006-06-03 am 21:31 +0100, ysgrifennodd Sitsofe Wheeler:
> > As mentioned in another reply the cards aren't onbord and are a PCI card
> > upgrade.
>
> Same slot as the card you upgraded from ?
You've got me there. I have no idea - most of the machines had their
network card removed before a clean upgrade from Fedora Core 4 to Fedora
Core 5. I can go and swap an old card back on to the same slot though. On
the one machine that had its card swapped after the upgrade it looks like
ACPI allocated the old and new cards the same IRQ (16). Is there anything
in particular that I'm looking for on the old card (e.g. would showing
/proc/interrupts before and after help)? It might be worth noting that
IRQ 11 doesn't seem to be disabled when there is anything else going
during the network transfer - e.g. if a video is being watched while the
netperf is being carried out the IRQ isn't disabled. Seemingly the problem
only shows when the card is hitting some sort of top speed...
[netperf showed that there was a performance hit to enabling irqpoll but
there was less of a hit using noapic. Either option cured the problem
and I added the netperf score to the mail]
> > irqpoll
> > 87380 16384 16384 10.00 29.63
> > noapic
> > 87380 16384 16384 10.00 53.21
>
> That does strongly suggest IRQ routing problems are involved, but it may
> also be timing, hence the question about slots
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* Re: readdir & bonnie++
From: Tomas Hruby @ 2006-06-04 9:48 UTC (permalink / raw)
To: linux-fsdevel
In-Reply-To: <e48344780606031942hbc46461q21a03894b83174df@mail.gmail.com>
>> Bonnie++ creates a directory with 16384 files. Then it calls readdir in a loop
>> to read all the entries and calls stat for each. The test fails since only 16383
>> entries were returned (one is missing). According to my logs our readdir calls
>> filldir on the last item as well. Also strace says that all entries were
>> returned. But the last one is missing.
>
>Possibly unrelated, but I saw something similar in my filesystem. A
>simple loop calling readdir would fail, but explicit calls to getdents
>worked properly (and whatever ls did also worked). In my case, I was
>playing games with d_off (filp->fpos) that caused d_off to overflow 32
>bits. Then glibc would detect this and be "smart" -- seek back to
>some point and start over to read up to the overflow. Eliminating the
Thanks for a good hint, I checked that but there is no overflow.
> Are you getting this problem *after* bonnie has deleted some entries
> from the directory? I had some problems with bonnie because it tries
> to delete entries from a directory in a while(readdir) loop, which
> happens to test a somewhat obscure and underspecified behaviour of
> directories. I discussed this on the ML a while back. Maybe this
> thread might help you:
I check the dicsussion on the suggested thread. It describes all issues I was
already facing :-) since we use similar tree structure as ext3.
I return hash (32bit) instead of a real position, but it works fine with ls
rm -r so far.
My problem with bonnie happens in a test which counts how many files where
created. It just call readdir in loop and counts how many entries were
returned. As far as I understand the bonnie code, there were no files deleted
yet.
I checked the glibc code (i hope that the correct one) and it seems that the
loop inside readdir is returned only if there are no more data in the buffer
and so the getdents is called again. My problem is that there SHOULD be the
last entry still in the buffer.
Tomas
^ permalink raw reply
* 2.6.17-rc3: XFS internal error xlog_clear_stale_blocks(1)
From: David Greaves @ 2006-06-04 9:44 UTC (permalink / raw)
To: xfs, linux-kernel
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
--
^ permalink raw reply
* [PATCH] bcm43xx-d80211: add DMA rx poll workaround to DMA4
From: Michael Buesch @ 2006-06-04 9:41 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev
This is the same patch as before, but for the dscape port.
Please apply to wireless-dev.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..ebe0984 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -604,25 +604,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -640,16 +643,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -867,8 +870,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
--
Greetings Michael.
^ permalink raw reply related
* Re: images -> DVD-slideshow ?
From: chuck gelm @ 2006-06-04 9:41 UTC (permalink / raw)
To: Bhikkhu Mettavihari; +Cc: Hal MacArgle, linux-newbie
In-Reply-To: <20060604075621.A26508@col7.metta.lk>
Howdy, Fellows:
Thanks for the hints, but 'cinelerra' is much, much more
complex than what I want or need. Those suggestions
are video editors, movie editors, ...
All I want to do is make a slide show of my still images
and put them on a DVD, perhaps with background music,
to play on a television DVD player.
Again, thanks,
Chuck
Bhikkhu Mettavihari wrote:
>* Hal MacArgle <haltec@kvinet.com> [2006-06-04 07:40]:
>
>
>>On 06-02, chuck gelm wrote:
>>
>>
>>>Howdy:
>>>
>>>What is your suggestion for an application that will convert
>>>many (still) images into a DVD slideshow, perhaps with
>>>background music? I've been trying to obtain image2mpeg
>>>with varying sucess. I was able to get a version downloaded
>>>and compiled. I created an image (stream.ppm), but there
>>>seems to be no mention of how to get the output file onto a DVD.
>>>
>>>If the output DVD <image> is small, can it be placed on
>>>a (650-700MB) CDROM and played on a standard DVD player?
>>>If yes, how? 'growisofs' balks at writing to my CDROM media.
>>>
>>>I am using Slackware v10.2 and understand *.tar.gz.
>>>I am poorer at installing *.rpm, but will try if that is the only
>>>offering of another application. *.deb, I don't know.
>>>
>>>Regards, Chuck
>>>
>>>
>> I haven't tried slide shows yet still stuck on editing
>>streaming video with two, partially successful, routes: Linux Video
>>Editor; http://lvempeg.sourceforge.net that compiles and installs
>>under Slack10.2, but I've not, yet, been able to figure out how to
>>actually edit videos, only preview.. It wont work with .avi files,
>>just .vob's that I've converted with videotrans' -M flag.. (You
>>discovered most that led up to this.) It, of course, requires a
>>bazillion libs that, in turn, require more libs.. <grin> LVE has a
>>DVDAuthoring-HOWTO that's interesting referring to many buzz words
>>we're now immersed in.. Of course videotrans can convert to non muxed
>>files; .mp2 and m2v..
>>
>>Another much more powerful scheme I've installed is cinelerra:
>>www.cinelerra.org
>>the heroinewarrior.com version that only installs into FedoraCore 4,
>>but includes all the deps in the 30mB rpm package.. I tried cinelerra
>>tarball but never got it working under Slack10.2.. It's world class
>>and you can do everything with it including washing dishes I think..The blurb says that
>>cinelerra is "professional."
>>
>>Cinelerra recommends Kino for blokes like me but I got nowhere with
>>it, especially since it's sort of designed for digital camera to
>>editor and back... The various codecs can drive one to drink too..
>>
>There is a list on cinelerra where you could get much info.
>
>There is a link to a slackware site on www.cinelerra.org
>It really is pro.
>
>I will have a look at lvempeg.sf.net
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vk67xclx7.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > What you suggest we need it's a kind of history of tags.
>
> I do not understand what you mean by "history of tags". Are you
> talking about "tag v1.0.0 was pointing at X commit yesterday but
> now today it points at Y commit"?
>
> > And, according to Paul suggestions, not only tags, but merge revisions
> > between tags.
> >
> > A more general and IMHO very powerful tool could be something like
> >
> > git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
> > <sha 2> ..... <sha n>
> >
> > Where git rev list gives the history, with modified parents, of the
> > given revisions _only_ plus the merging revisions among them.
>
> You completely lost me here. The '--' markers are to mean "from
> here on the parameters are not revisions but are path limiters",
> so you are doing something else. What are these <sha1#1>, <sha1#2>,...
> in this? Are they revisions (i.e. commit object names)?
Yes they are.
Insted of path limiters I meant revisions limiters.
Given a revision history like
a
b--|
| f
| g
c
d
e
git-rev-list --top-order --parents --selected-only HEAD -- <a> <g> <d>
Should output something like
a
b--|
| g
d
Of course with modified parent information as does git-rev-list
--parents -- foo.c
^ permalink raw reply
* [PATCH] Add Apple MacBook product IDs to usbhid
From: Rene Rebe @ 2006-06-04 9:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton
Hi all,
This adds the Apple MacBook product IDs for the Fn translation
to the usbhid.
Signed-off-by: René Rebe <rene@exactcode.de>
--- ./drivers/usb/input/hid-core.c.orig 2006-06-01 15:52:13.000000000 +0200
+++ ./drivers/usb/input/hid-core.c 2006-06-01 15:54:09.000000000 +0200
@@ -1602,6 +1602,9 @@
{ USB_VENDOR_ID_APPLE, 0x0214, HID_QUIRK_POWERBOOK_HAS_FN },
{ USB_VENDOR_ID_APPLE, 0x0215, HID_QUIRK_POWERBOOK_HAS_FN },
{ USB_VENDOR_ID_APPLE, 0x0216, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0217, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0218, HID_QUIRK_POWERBOOK_HAS_FN },
+ { USB_VENDOR_ID_APPLE, 0x0219, HID_QUIRK_POWERBOOK_HAS_FN },
{ USB_VENDOR_ID_APPLE, 0x030A, HID_QUIRK_POWERBOOK_HAS_FN },
{ USB_VENDOR_ID_APPLE, 0x030B, HID_QUIRK_POWERBOOK_HAS_FN },
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
^ permalink raw reply
* Re: 2.6.17-rc5-mm3
From: Barry K. Nathan @ 2006-06-04 9:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <20060603232004.68c4e1e3.akpm@osdl.org>
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'
(This is also true of -mm2, but I didn't get a chance to report it
before -mm3 was released. Before then, I built it into the kernel and
not as a module.)
and I still get this:
WARNING: "scsi_tgt_queue_command" [drivers/scsi/libsrp.ko] undefined!
--
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply
* Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()
From: Arjan van de Ven @ 2006-06-04 9:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Alan Cox, Ingo Molnar, Andrew Morton, linux-kernel
In-Reply-To: <1149374090.14408.4.camel@localhost.localdomain>
On Sat, 2006-06-03 at 18:34 -0400, Steven Rostedt wrote:
> On Sat, 2006-06-03 at 17:53 -0400, Alan Cox wrote:
> > On Sat, Jun 03, 2006 at 10:37:01AM -0400, Steven Rostedt wrote:
> > > Couldn't it be possible to have the misrouted irq function mark the
> > > DISABLED_IRQ handlers as IRQ_PENDING? Then have the enable_irq that
> > > actually enables the irq to call the handlers with interrupts disabled
> > > if the IRQ_PENDING is set?
> >
> > We still have the ambiguity with disable_irq. Really we need to have
> > disable_irq_handler(irq, handler)
>
> Yeah, that does make sense, but I think the IRQ_PENDING idea works too.
> This way disable_irq_handler doesn't need to mask the interrupt even
> without the irqpoll and irqfixup. Let the interrupt happen and just
> skip those handlers that that are disabled. Then when the handler is
> re-enabled, then we can call the handler. Of course we would need a
> enable_irq_handler too.
>
> This would make the vortex card's disable_irq not hurt all the other
> devices that share the irq with it.
can't do that; if you get an irq anyway from the hardware you now have a
screamer...... which is why vortex really needs to disable the irq at
the hardware level.
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Marco Costalba @ 2006-06-04 9:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, linux-kernel
In-Reply-To: <e5u8fk$ju6$1@sea.gmane.org>
On 6/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > This is qgit-1.3
> [...]
> > NEW IN THIS RELEASE
> >
> > Main focus of this release is usability.
> >
> > The big feature is the use of tabs instead of independent windows.
> >
> > This change alone could be enough for a release. It's a big rewrite of UI
> > code to let browsing revisions and patches quicker and easier.
>
> Of course that is advantage _only_ if the tabs are independend, and one
> (usually) doesn't need to view them simultaneously, e.g. side by side.
>
Actually they are.
One for revisions list, one for patches and one for file content.
File content tab is indipendent from previous two (of course it can be
synced on request).
> Just my 3 eurocents ;-)
Well, at today exchange rate should be 'my 2.3 eurocents' :-)
Marco
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Junio C Hamano @ 2006-06-04 9:31 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060604091601.GN14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> hoi :)
>
> On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:
>> I would agree in the reproduction recipe Martin gave there is no
>> problem but feature, but at the same time I suspect the recent
>> "reset --hard simplification" has introduced a true regression.
>
> This may have been the bug that bit me.
> Thanks for finding it although I was not able to reproduce it myself!
I found this somewhat the hard way myself. I have:
[pull]
twohead = resolve
in my .git/config -- IOW, I usually do not use recursive
strategy myself. When a merge with resolve strategy fails (and
with recent trend to busyboxify git commands, many merges
between my topics and "next" and/or "master" do), I relied on
"reset --hard" followed by the same merge of the topic using
"pull -s recursive" to recover things, but it didn't. When
pulling a branch with builtin-*.c names into another branch with
older names, regressed "reset --hard" left builtin-*.c files
behind, and then the next merge attempt complained by saying my
untracked working tree files would be overwritten X-<.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 9:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: Paul Mackerras, Junio C Hamano, git, Jonas Fonseca
In-Reply-To: <e5bfff550606040008m4dbf02bdga4f4e6bc2d2fe9d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> What you suggest we need it's a kind of history of tags.
I do not understand what you mean by "history of tags". Are you
talking about "tag v1.0.0 was pointing at X commit yesterday but
now today it points at Y commit"?
> And, according to Paul suggestions, not only tags, but merge revisions
> between tags.
>
> A more general and IMHO very powerful tool could be something like
>
> git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
> <sha 2> ..... <sha n>
>
> Where git rev list gives the history, with modified parents, of the
> given revisions _only_ plus the merging revisions among them.
You completely lost me here. The '--' markers are to mean "from
here on the parameters are not revisions but are path limiters",
so you are doing something else. What are these <sha1#1>, <sha1#2>,...
in this? Are they revisions (i.e. commit object names)?
^ permalink raw reply
* Re: [PATCH] readahead: initial method - expected read size - fix fastcall
From: Arjan van de Ven @ 2006-06-04 9:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Fengguang Wu, Valdis.Kletnieks, diegocg, lista1, linux-kernel
In-Reply-To: <20060604020738.31f43cb0.akpm@osdl.org>
On Sun, 2006-06-04 at 02:07 -0700, Andrew Morton wrote:
> On Sun, 4 Jun 2006 15:34:15 +0800
> Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:
>
> > Remove 'fastcall' directive for function readahead_close().
> >
> > It has drawn concerns from Andrew Morton.
>
> Well. I think fastcall is ugly and vaguely silly. Now if we has a
> really_really_fastcall then I'd like to use that!
>
>
> > Now I have some benchmarks
> > on it, and proved it as a _false_ optimization.
>
> Sorry, I don't believe this will be measurable (and with CONFIG_REGPARM
> it'll be a no-op).
we should just make CONFIG_REGPARM be "it" always (and thus make it go
away as config option) and then just remove all "fastcall" from the
kernel...
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 9:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com>
"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. For tagList = (t1, t2), the
rev-list would return "e", and then "d". Parent of "d" are "b"
and "c", and c is tagged but b is not. So if you are willing to
try 2^N permutations of what tagList to use, then the above
sequence, with a bit of tweak to step (4) to see which parents
are tagged, would yield the closest tag in the past of "e", but
is that what you are suggesting?
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Jakub Narebski @ 2006-06-04 9:17 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <e5bfff550606040155v14565312na26f8c866f0fc32d@mail.gmail.com>
Marco Costalba wrote:
> This is qgit-1.3
[...]
> NEW IN THIS RELEASE
>
> Main focus of this release is usability.
>
> The big feature is the use of tabs instead of independent windows.
>
> This change alone could be enough for a release. It's a big rewrite of UI
> code to let browsing revisions and patches quicker and easier.
Of course that is advantage _only_ if the tabs are independend, and one
(usually) doesn't need to view them simultaneously, e.g. side by side.
Just my 3 eurocents ;-)
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [patch 05/61] lock validator: introduce WARN_ON_ONCE(cond)
From: Arjan van de Ven @ 2006-06-04 9:18 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Andrew Morton, Ingo Molnar, linux-kernel
In-Reply-To: <1149358157.13993.94.camel@localhost.localdomain>
On Sat, 2006-06-03 at 14:09 -0400, Steven Rostedt wrote:
>
> As you can see, because the whole thing is unlikely, the first condition
> is expected to fail. With the current WARN_ON logic, that means that
> the __warn_once is expected to fail, but that's not the case. So on a
> normal system where the WARN_ON_ONCE condition would never happen, you
> are always branching.
which is no cost since it's consistent for the branch predictor
> So simply reversing the order to test the
> condition before testing the __warn_once variable should improve cache
> performance.
> - if (unlikely(__warn_once && (condition))) { \
> + if (unlikely((condition) && __warn_once)) { \
> __warn_once = 0; \
I disagree with this; "condition" can be a relatively complex thing,
such as a function call. doing the cheaper (and consistent!) test first
will be better. __warn_once will be branch predicted correctly ALWAYS,
except the exact ONE time you turn hit the backtrace. So it's really
really cheap to test, and if the WARN_ON_ONCE is triggering a lot after
the first time, you now would have a flapping first condition (which
means lots of branch mispredicts) while the original code has a perfect
one-check-predicted-exit scenario.
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Jakub Narebski @ 2006-06-04 9:17 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550606040155v14565312na26f8c866f0fc32d@mail.gmail.com>
Marco Costalba wrote:
> This is qgit-1.3
[...]
> NEW IN THIS RELEASE
>
> Main focus of this release is usability.
>
> The big feature is the use of tabs instead of independent windows.
>
> This change alone could be enough for a release. It's a big rewrite of UI
> code to let browsing revisions and patches quicker and easier.
Of course that is advantage _only_ if the tabs are independend, and one
(usually) doesn't need to view them simultaneously, e.g. side by side.
Just my 3 eurocents ;-)
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Martin Waitz @ 2006-06-04 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vhd33d2q2.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
hoi :)
On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:
> I would agree in the reproduction recipe Martin gave there is no
> problem but feature, but at the same time I suspect the recent
> "reset --hard simplification" has introduced a true regression.
This may have been the bug that bit me.
Thanks for finding it although I was not able to reproduce it myself!
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ocfs2: dereference before NULL check in ocfs2_direct_IO_get_blocks()
From: Arjan van de Ven @ 2006-06-04 9:15 UTC (permalink / raw)
To: Joel Becker
Cc: Alexey Dobriyan, Florin Malita, mark.fasheh, kurt.hackel,
linux-kernel, akpm
In-Reply-To: <20060603211657.GK2422@ca-server1.us.oracle.com>
On Sat, 2006-06-03 at 14:16 -0700, Joel Becker wrote:
> On Sat, Jun 03, 2006 at 11:15:58PM +0400, Alexey Dobriyan wrote:
> > On Sat, Jun 03, 2006 at 11:34:39AM -0400, Florin Malita wrote:
> > > 'bh_result' & 'inode' are explicitly checked against NULL so they
> > > shouldn't be dereferenced prior to that.
> > >
> > > Coverity ID: 1273, 1274.
> >
> > AFAICS, the patch is BS, as usual with this type of patches.
> >
> > Can "inode" and "bh_result" be NULL here? I bet they can't.
>
> This is a common result of this sort of scan. The scan merely
> provides good information, not a perfect patch. There are two
> possibilities:
>
> 1) The scan is right, and the dereference is dangerous. The
> patch is correct.
> 2) The dereference is not dangerous ("can't happen"), and the
> later check for NULL is spurious. A correct patch would
> merely remove the check.
>
> This is clearly a case of (2), but I bet that (1) is seen just
> as often.
and in case of (2); newer gcc is often smart enough to do that
automatically :)
^ permalink raw reply
* Re: [PATCH 4/5] SCSI: add cpu cache flushes after kmapping and modifying a page
From: Tejun Heo @ 2006-06-04 9:13 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe, James Bottomley, Dave Miller,
bzolnier, james.steward, jgarzik, mattjreimer,
Guennadi Liakhovetski, rmk, lkml, linux-ide, linux-scsi
In-Reply-To: <20060604082035.GB29696@infradead.org>
Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 12:41:20PM +0900, Tejun Heo wrote:
>> local_irq_save(flags);
>> buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
>> memcpy(buf, tw_dev->generic_buffer_virt[request_id], sg->length);
>> + flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg->offset));
>> kunmap_atomic(buf - sg->offset, KM_IRQ0);
>> local_irq_restore(flags);
>
> all these should switch to scsi_kmap_atomic_sg which should do the
> flush_kernel_dcache_page call for you.
>
This is not specific to scsi or block. This is a common problem for all
kmap users. As I wrote in the other mail, I think this should be
mandated at the kmap/kunmap() interface.
--
tejun
^ permalink raw reply
* Re: [minor fix] radixtree: regulate tag get return value
From: Andrew Morton @ 2006-06-04 9:11 UTC (permalink / raw)
To: Wu Fengguang; +Cc: linux-kernel, nickpiggin
In-Reply-To: <349410738.29011@ustc.edu.cn>
On Sun, 4 Jun 2006 16:45:48 +0800
Wu Fengguang <wfg@mail.ustc.edu.cn> wrote:
> Andrew, this small patch makes the radixtree tester program from
> http://www.zip.com.au/~akpm/linux/patches/stuff/rtth.tar.gz
> run OK, with the latest radix tree code in linux-2.6.17-rc5-mm2.
>
> It regulates the return value to 0/1 for functions
> radix_tree_tag_get() and radix_tree_tagged().
>
Well yes. But it slows down the kernel. It would be better to fix rtth.
> ---
>
> --- linux.orig/lib/radix-tree.c
> +++ linux/lib/radix-tree.c
> @@ -156,7 +156,7 @@ static inline void tag_clear(struct radi
> static inline int tag_get(struct radix_tree_node *node, unsigned int tag,
> int offset)
> {
> - return test_bit(offset, node->tags[tag]);
> + return !! test_bit(offset, node->tags[tag]);
> }
test_bit() is (sadly) defined to return 0 or 1. Did this really make a difference?
> static inline void root_tag_set(struct radix_tree_root *root, unsigned int tag)
> @@ -177,7 +177,7 @@ static inline void root_tag_clear_all(st
>
> static inline int root_tag_get(struct radix_tree_root *root, unsigned int tag)
> {
> - return root->gfp_mask & (1 << (tag + __GFP_BITS_SHIFT));
> + return !! (root->gfp_mask & (1 << (tag + __GFP_BITS_SHIFT)));
> }
>
^ permalink raw reply
* Re: [PATCH 2/5] ide: add cpu cache flushes after kmapping and modifying a page
From: Tejun Heo @ 2006-06-04 9:09 UTC (permalink / raw)
To: Christoph Hellwig, Tejun Heo, Jens Axboe, James Bottomley,
Dave Miller, bzolnier, james.steward, jgarzik, mattjreimer,
Guennadi Liakhovetski, rmk, lkml, linux-ide, linux-scsi
In-Reply-To: <20060604081734.GA29696@infradead.org>
Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 12:41:20PM +0900, Tejun Heo wrote:
>> data = bvec_kmap_irq(bvec, &flags);
>> drive->hwif->atapi_input_bytes(drive, data, count);
>> + flush_kernel_dcache_page(kmap_atomic_to_page(data));
>> bvec_kunmap_irq(data, &flags);
>
> shouldn't bvec_kunmap_irq do the flush_kernel_dcache_page call?
>
Eventually, yes. At the moment, not all archs implement
flush_kernel_dcache_page(), so converting
kmap();
modify buffer;
flush_dcache_page();
kunmap();
to
kmap_wrapper();
modify buffer;
kunmap_wrapper_which_calls_flush_kernel_dcache_page()
breaks cache coherency on those archs. The current patches simply add
calls to flush_kernel_dcache_page() where missing such that it doesn't
break anything while fixing cache coherency for arm and parisc. In the
long term...
1. implement flush_kernel_dcache_page() for all needed archs
2. update kmap interface such that the caller is mandated to specify
whether the buffer has been modified or not when unmapping (maybe
addition of simple boolean argument?)
3. update bvec_kmap_*() similarly
4. update all calls to kunmap & friends.
Thanks.
--
tejun
^ 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.