Re: [RFT] Port 0x80 I/O speed
On 12 Dec 2007 06:20:49 -0500 [EMAIL PROTECTED] wrote: > With -O2, the cycle counts come out (before division) as > out: 0xFFEA6F4F > in: 0xFCE68BB6 > I think the "A" constraint doesn't work quite the same in > 64-bit code. The compiler seems to be using %rdx rather than > %edx:%eax. In another message he says to compile it with "-m32" :) -- Paolo Ornati Linux 2.6.24-rc5-g4af75653 on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Wed, 12 Dec 2007 00:31:18 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > and on a PII 400 (Intel 440BX chipset) a constant: > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 > cycles: out 553, in 251 > > Results are (mostly) independent of compiler optimisation, but testing with > an -O2 compile should be most useful. Thanks! > ### Core2 Duo 1.8 GHz ### X86_64 -m32 -O2: $ for i in `seq 5`; do sudo ./port80; sleep 1; done cycles: out 1498, in 964 cycles: out 1498, in 964 cycles: out 1499, in 964 cycles: out 1498, in 964 cycles: out 1498, in 965 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.805 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.82 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [...] -- Paolo Ornati Linux 2.6.24-rc4-g94545bad on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Wed, 12 Dec 2007 00:31:18 +0100 Rene Herman [EMAIL PROTECTED] wrote: and on a PII 400 (Intel 440BX chipset) a constant: [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 cycles: out 553, in 251 Results are (mostly) independent of compiler optimisation, but testing with an -O2 compile should be most useful. Thanks! ### Core2 Duo 1.8 GHz ### X86_64 -m32 -O2: $ for i in `seq 5`; do sudo ./port80; sleep 1; done cycles: out 1498, in 964 cycles: out 1498, in 964 cycles: out 1499, in 964 cycles: out 1498, in 964 cycles: out 1498, in 965 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.805 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.82 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [...] -- Paolo Ornati Linux 2.6.24-rc4-g94545bad on x86_64 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On 12 Dec 2007 06:20:49 -0500 [EMAIL PROTECTED] wrote: With -O2, the cycle counts come out (before division) as out: 0xFFEA6F4F in: 0xFCE68BB6 I think the A constraint doesn't work quite the same in 64-bit code. The compiler seems to be using %rdx rather than %edx:%eax. In another message he says to compile it with -m32 :) -- Paolo Ornati Linux 2.6.24-rc5-g4af75653 on x86_64 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
On Sat, 8 Dec 2007 13:12:14 +0100
Markus <[EMAIL PROTECTED]> wrote:
> I try that, but it will take a lot of time!
>
> Markus
This problem remembers me something...
http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gst=konqueror+vanish#591a0b3a05bd3596
Are you the same Markus? (or it's just a coincidence?)
It seems the same BUG...
--
Paolo Ornati
Linux 2.6.24-rc4-g7e1fb765 on x86_64
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
On Sat, 8 Dec 2007 13:12:14 +0100 Markus [EMAIL PROTECTED] wrote: I try that, but it will take a lot of time! Markus This problem remembers me something... http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gstq=konqueror+vanish#591a0b3a05bd3596 Are you the same Markus? (or it's just a coincidence?) It seems the same BUG... -- Paolo Ornati Linux 2.6.24-rc4-g7e1fb765 on x86_64 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask'
CC drivers/kvm/kvm_main.o drivers/kvm/kvm_main.c: In function 'kvm_flush_remote_tlbs': drivers/kvm/kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask' make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 --- "smp_call_function_mask" is defined only on "CONFIG_SMP" but kvm uses it unconditionally, oops! -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask'
CC drivers/kvm/kvm_main.o drivers/kvm/kvm_main.c: In function 'kvm_flush_remote_tlbs': drivers/kvm/kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask' make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 --- smp_call_function_mask is defined only on CONFIG_SMP but kvm uses it unconditionally, oops! -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 100% iowait on one of cpus in current -git
On Mon, 22 Oct 2007 08:22:52 +0200 Maxim Levitsky <[EMAIL PROTECTED]> wrote: > I tried to bisect this, but eventually I run into other bugs that cause > system to oops early. You can pick a different revision to test with: git-reset --hard "SHA1" Choose one with "git-bisect visualize". -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 100% iowait on one of cpus in current -git
On Mon, 22 Oct 2007 08:22:52 +0200 Maxim Levitsky [EMAIL PROTECTED] wrote: I tried to bisect this, but eventually I run into other bugs that cause system to oops early. You can pick a different revision to test with: git-reset --hard SHA1 Choose one with git-bisect visualize. -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Tue, 02 Oct 2007 18:19:14 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Yeah, "World's first" is a pretty good clue indicating "broken". > Blacklisting it seems like a good idea after all. OT: I cannot test anything NCQ related for a while because the Intel Mobo departed yesterday, so I'm on a different board without NCQ support ;) -- Paolo Ornati Linux 2.6.23-rc8generic-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Tue, 02 Oct 2007 18:19:14 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Yeah, World's first is a pretty good clue indicating broken. Blacklisting it seems like a good idea after all. OT: I cannot test anything NCQ related for a while because the Intel Mobo departed yesterday, so I'm on a different board without NCQ support ;) -- Paolo Ornati Linux 2.6.23-rc8generic-ga64314e6 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 17:45:41 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Are you sure this isn't just a bum drive? Looking at the SMART listing > that was posted, looks like it's had some uncorrectable sector read > errors in the event log.. Don't know. The error count is still 12 today, the differences are: --> === START OF INFORMATION SECTION === @@ -10,7 +10,7 @@ Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 -Local Time is:Sun Jan 21 20:15:40 2007 CET +Local Time is:Mon Oct 1 09:01:05 2007 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled @@ -48,21 +48,22 @@ SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE - 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always - 215927244 + 1 Raw_Read_Error_Rate 0x000f 060 047 006Pre-fail Always - 129093793 3 Spin_Up_Time0x0003 098 098 000Pre-fail Always - 0 - 4 Start_Stop_Count0x0032 098 098 020Old_age Always - 2182 + 4 Start_Stop_Count0x0032 097 097 020Old_age Always - 3094 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 - 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always - 204305750 - 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 3494 + 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 298020973 + 9 Power_On_Hours 0x0032 094 094 000Old_age Always - 5274 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 - 12 Power_Cycle_Count 0x0032 098 098 020Old_age Always - 2541 -194 Temperature_Celsius 0x0022 024 040 000Old_age Always - 24 (Lifetime Min/Max 0/15) -195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always - 215927244 + 12 Power_Cycle_Count 0x0032 097 097 020Old_age Always - 3457 +194 Temperature_Celsius 0x0022 023 040 000Old_age Always - 23 (Lifetime Min/Max 0/15) +195 Hardware_ECC_Recovered 0x001a 060 047 000Old_age Always - 129093793 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 1 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 <--- Moreover the five logged errors are all about the same sector: Error 12 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 - That sector isn't in mine XFS partition (sda1): First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 02924*632925*Linux (83) Boot 2 Primary2925* 156296384 0 136295460 Extended (05)None 5 Logical2925* 20161574*63 160650 Linux (83) None 6 Logical20161575* 120166199 63 14625 Linux (83) None 7 Logical 120166200 122174324 63 2008125 Linux swap / So (82) None 8 Logical 122174325 156296384 6334122060 Linux (83) None So I don't know. To me it looks like these errors are not related... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 17:45:41 -0600 Robert Hancock [EMAIL PROTECTED] wrote: Are you sure this isn't just a bum drive? Looking at the SMART listing that was posted, looks like it's had some uncorrectable sector read errors in the event log.. Don't know. The error count is still 12 today, the differences are: -- === START OF INFORMATION SECTION === @@ -10,7 +10,7 @@ Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 -Local Time is:Sun Jan 21 20:15:40 2007 CET +Local Time is:Mon Oct 1 09:01:05 2007 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled @@ -48,21 +48,22 @@ SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE - 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always - 215927244 + 1 Raw_Read_Error_Rate 0x000f 060 047 006Pre-fail Always - 129093793 3 Spin_Up_Time0x0003 098 098 000Pre-fail Always - 0 - 4 Start_Stop_Count0x0032 098 098 020Old_age Always - 2182 + 4 Start_Stop_Count0x0032 097 097 020Old_age Always - 3094 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 - 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always - 204305750 - 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 3494 + 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 298020973 + 9 Power_On_Hours 0x0032 094 094 000Old_age Always - 5274 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 - 12 Power_Cycle_Count 0x0032 098 098 020Old_age Always - 2541 -194 Temperature_Celsius 0x0022 024 040 000Old_age Always - 24 (Lifetime Min/Max 0/15) -195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always - 215927244 + 12 Power_Cycle_Count 0x0032 097 097 020Old_age Always - 3457 +194 Temperature_Celsius 0x0022 023 040 000Old_age Always - 23 (Lifetime Min/Max 0/15) +195 Hardware_ECC_Recovered 0x001a 060 047 000Old_age Always - 129093793 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 1 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 --- Moreover the five logged errors are all about the same sector: Error 12 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 - That sector isn't in mine XFS partition (sda1): First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 02924*632925*Linux (83) Boot 2 Primary2925* 156296384 0 136295460 Extended (05)None 5 Logical2925* 20161574*63 160650 Linux (83) None 6 Logical20161575* 120166199 63 14625 Linux (83) None 7 Logical 120166200 122174324 63 2008125 Linux swap / So (82) None 8 Logical 122174325 156296384 6334122060 Linux (83) None So I don't know. To me it looks like these errors are not related... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:59:45 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Is libata built into the kernel, or a module?
built-in, my kernel is pretty monolithic
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:43:38 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > it isn't supported here:
> > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
>
> Did you actually try my suggestion?
Yes ("libata.fua=1" is ok I think, or it should just be "libata.fua"?):
...
[0.00] Kernel command line: root=/dev/sda6 ro vga=0x305 libata.fua=1
...
[ 285.004166] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
...
>
> That message is normal, because libata defaults to FUA==off.
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
53.680358] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 150.036560] SGI XFS with large block/inode numbers, no debug enabled [ 150.076345] XFS mounting filesystem sda1 [ 150.138250] Ending clean XFS mount for filesystem: sda1 [ 372.948796] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 372.948805] ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out [ 372.948806] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 373.252286] ata1: soft resetting port [ 373.458239] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 373.461012] ata1.00: configured for UDMA/133 [ 373.461022] ata1: EH complete [ 373.461061] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) [ 373.461075] sd 0:0:0:0: [sda] Write Protect is off [ 373.461077] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 373.461095] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 15:29:08 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > > Seagate Barracuda ST380817AS has troubles with NCQ. For example, > > unpacking a tarball on an XFS filesystem gives this: > > > > ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen > > ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > What makes you sure that is an NCQ problem ? It goes away with: echo 1 > /sys/block/sda/device/queue_depth I have this problem only with XFS, and even with XFS it goes away mounting with "nobarrier"... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 07:17:05 -0700 Tejun Heo <[EMAIL PROTECTED]> wrote: > Paolo Ornati wrote: > > Seagate Barracuda ST380817AS has troubles with NCQ. For example, > > unpacking a tarball on an XFS filesystem gives this: > > > > ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen > > ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > Hmmm... Was there a thread about this one? Also, please cc > [EMAIL PROTECTED] Yes, this was the thread: http://lkml.org/lkml/2007/1/21/43 -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
Hi, I think you forgot to blacklist this one :)
--
Seagate Barracuda ST380817AS has troubles with NCQ. For example,
unpacking a tarball on an XFS filesystem gives this:
ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
More info here:
http://lkml.org/lkml/2007/1/21/76
Blacklist it!
Signed-off-by: Paolo Ornati <[EMAIL PROTECTED]>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 772be09..be289d0 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3781,6 +3781,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "Maxtor 7B250S0", "BANC1B70", ATA_HORKAGE_NONCQ, },
{ "Maxtor 7B300S0", "BANC1B70", ATA_HORKAGE_NONCQ },
{ "Maxtor 7V300F0", "VA111630", ATA_HORKAGE_NONCQ },
+ { "ST380817AS", "3.42", ATA_HORKAGE_NONCQ },
{ "HITACHI HDS7250SASUN500G 0621KTAWSD", "K2AOAJ0AHITACHI",
ATA_HORKAGE_NONCQ },
/* NCQ hard hangs device under heavier load, needs hard power cycle */
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
Hi, I think you forgot to blacklist this one :)
--
Seagate Barracuda ST380817AS has troubles with NCQ. For example,
unpacking a tarball on an XFS filesystem gives this:
ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
More info here:
http://lkml.org/lkml/2007/1/21/76
Blacklist it!
Signed-off-by: Paolo Ornati [EMAIL PROTECTED]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 772be09..be289d0 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3781,6 +3781,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ Maxtor 7B250S0, BANC1B70, ATA_HORKAGE_NONCQ, },
{ Maxtor 7B300S0, BANC1B70, ATA_HORKAGE_NONCQ },
{ Maxtor 7V300F0, VA111630, ATA_HORKAGE_NONCQ },
+ { ST380817AS, 3.42, ATA_HORKAGE_NONCQ },
{ HITACHI HDS7250SASUN500G 0621KTAWSD, K2AOAJ0AHITACHI,
ATA_HORKAGE_NONCQ },
/* NCQ hard hangs device under heavier load, needs hard power cycle */
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6-dirty on x86_64
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 07:17:05 -0700 Tejun Heo [EMAIL PROTECTED] wrote: Paolo Ornati wrote: Seagate Barracuda ST380817AS has troubles with NCQ. For example, unpacking a tarball on an XFS filesystem gives this: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Hmmm... Was there a thread about this one? Also, please cc [EMAIL PROTECTED] Yes, this was the thread: http://lkml.org/lkml/2007/1/21/43 -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 15:29:08 +0100 Alan Cox [EMAIL PROTECTED] wrote: Seagate Barracuda ST380817AS has troubles with NCQ. For example, unpacking a tarball on an XFS filesystem gives this: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) What makes you sure that is an NCQ problem ? It goes away with: echo 1 /sys/block/sda/device/queue_depth I have this problem only with XFS, and even with XFS it goes away mounting with nobarrier... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
SErr 0x0 action 0x2 frozen [ 372.948805] ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out [ 372.948806] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 373.252286] ata1: soft resetting port [ 373.458239] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 373.461012] ata1.00: configured for UDMA/133 [ 373.461022] ata1: EH complete [ 373.461061] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) [ 373.461075] sd 0:0:0:0: [sda] Write Protect is off [ 373.461077] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 373.461095] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:43:38 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: it isn't supported here: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Did you actually try my suggestion? Yes (libata.fua=1 is ok I think, or it should just be libata.fua?): ... [0.00] Kernel command line: root=/dev/sda6 ro vga=0x305 libata.fua=1 ... [ 285.004166] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen ... That message is normal, because libata defaults to FUA==off. -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:59:45 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Is libata built into the kernel, or a module? built-in, my kernel is pretty monolithic -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Tue, 28 Aug 2007 10:27:09 +0200 Clemens Ladisch <[EMAIL PROTECTED]> wrote: > Luck, Tony wrote: > > [...] Given that the hang went away when you applied the earlier patch, I > > conclude that the drivers/char/hpet.c code is the one that got selected when > > you had two "hpet" entries ... and that there is something wrong with that > > code that doesn't work right on x86_64. > > Apparently, the 'generic' code was just copied from ia64 and assumes that the > timer is 64 bits. This is not true with hardware from VIA (even on x86_64). The hardware of this PC is Intel, not VIA. > > This patch should make it work (although I'd prefer to set the mask > dynamically > according to the hardware caps). > > --- a/drivers/char/hpet.c Tue Aug 28 09:42:22 2007 > +++ b/drivers/char/hpet.c Tue Aug 28 10:16:54 2007 > @@ -73,7 +73,7 @@ > .name = "hpet", > .rating = 250, > .read = read_hpet, > -.mask = CLOCKSOURCE_MASK(64), > +.mask = CLOCKSOURCE_MASK(32), Anyway, I've applied it (manually... whitespace/mime damage) to -rc4 and it seems to work, no crash so far (I'm sure I'm testing it because plain -rc4 doesn't have the "2hpet" fix and still manifest the problem). -- Paolo Ornati Linux 2.6.23-rc4-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Mon, 27 Aug 2007 17:34:58 -0300 "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> wrote: > | Yea. While I'm still not completely comfortable leaving this up to boot > | order alone (the ia64 hpet clocksource is clearly causing issues on > | x86_64), I think this patch is something we need as well. > > Does -stable need this too? No :) -- Paolo Ornati Linux 2.6.22.5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Mon, 27 Aug 2007 17:34:58 -0300 Luiz Fernando N. Capitulino [EMAIL PROTECTED] wrote: | Yea. While I'm still not completely comfortable leaving this up to boot | order alone (the ia64 hpet clocksource is clearly causing issues on | x86_64), I think this patch is something we need as well. Does -stable need this too? No :) -- Paolo Ornati Linux 2.6.22.5 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Tue, 28 Aug 2007 10:27:09 +0200 Clemens Ladisch [EMAIL PROTECTED] wrote: Luck, Tony wrote: [...] Given that the hang went away when you applied the earlier patch, I conclude that the drivers/char/hpet.c code is the one that got selected when you had two hpet entries ... and that there is something wrong with that code that doesn't work right on x86_64. Apparently, the 'generic' code was just copied from ia64 and assumes that the timer is 64 bits. This is not true with hardware from VIA (even on x86_64). The hardware of this PC is Intel, not VIA. This patch should make it work (although I'd prefer to set the mask dynamically according to the hardware caps). --- a/drivers/char/hpet.c Tue Aug 28 09:42:22 2007 +++ b/drivers/char/hpet.c Tue Aug 28 10:16:54 2007 @@ -73,7 +73,7 @@ .name = hpet, .rating = 250, .read = read_hpet, -.mask = CLOCKSOURCE_MASK(64), +.mask = CLOCKSOURCE_MASK(32), Anyway, I've applied it (manually... whitespace/mime damage) to -rc4 and it seems to work, no crash so far (I'm sure I'm testing it because plain -rc4 doesn't have the 2hpet fix and still manifest the problem). -- Paolo Ornati Linux 2.6.23-rc4-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Fri, 24 Aug 2007 09:04:22 -0700 "Luck, Tony" <[EMAIL PROTECTED]> wrote: > It is good to avoid registering two clocksources with the same name, but > the fix might be a bit more fragile than the eariler one that temporarily > marked the drivers/char/hpet.c one as CONFIG_IA64 only. Given that the > hang went away when you applied the earlier patch, I conclude that the > drivers/char/hpet.c code is the one that got selected when you had two > "hpet" entries ... and that there is something wrong with that code that > doesn't work right on x86_64. The fix to prevent registering a duplicate > name is presumably working for you simply because arch/x86_64/kernel/hpet.c > happens to get there first with its "hpet", so the drivers/char/hpet.c one > is dropped. If something changed that reversed the order of these > registrations, > then you'd get the "hpet" clocksource that results in a hang. 100% agree -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Fri, 24 Aug 2007 08:46:31 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote: > Prevent duplicate names being registered with clocksource. This also > eliminates the duplication of hpet clock registration when the arch > uses the hpet timer and the hpet driver does too. The patch was > compile and link tested. This one works too. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 14:41:45 -0700 john stultz <[EMAIL PROTECTED]> wrote: > > My initial reaction would be to either ifdef ia64 implementation in > > drivers/char/hpet.c or move the code under the ia64 arch dir until it is > > really usable by all arches. > > Here is a possible quick fix. I'm open to other approaches, but I also > want to avoid too much churn before 2.6.23 goes out. > > Paolo, could you verify this fixes the issue for you? It works: there's only one "hpet" in "available_clocksource" and also the hard freeze using it seems gone. :) -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 17:38:49 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote: > It appears ACPI discovery failed during driver initialization because > of: > hpet_resources: 0xfed0 is busy Note: this was always there as far as I can remember. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Thu, 23 Aug 2007 14:41:45 -0700 john stultz [EMAIL PROTECTED] wrote: My initial reaction would be to either ifdef ia64 implementation in drivers/char/hpet.c or move the code under the ia64 arch dir until it is really usable by all arches. Here is a possible quick fix. I'm open to other approaches, but I also want to avoid too much churn before 2.6.23 goes out. Paolo, could you verify this fixes the issue for you? It works: there's only one hpet in available_clocksource and also the hard freeze using it seems gone. :) -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Thu, 23 Aug 2007 17:38:49 -0400 Bob Picco [EMAIL PROTECTED] wrote: It appears ACPI discovery failed during driver initialization because of: hpet_resources: 0xfed0 is busy Note: this was always there as far as I can remember. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Fri, 24 Aug 2007 08:46:31 -0400 Bob Picco [EMAIL PROTECTED] wrote: Prevent duplicate names being registered with clocksource. This also eliminates the duplication of hpet clock registration when the arch uses the hpet timer and the hpet driver does too. The patch was compile and link tested. This one works too. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Fri, 24 Aug 2007 09:04:22 -0700 Luck, Tony [EMAIL PROTECTED] wrote: It is good to avoid registering two clocksources with the same name, but the fix might be a bit more fragile than the eariler one that temporarily marked the drivers/char/hpet.c one as CONFIG_IA64 only. Given that the hang went away when you applied the earlier patch, I conclude that the drivers/char/hpet.c code is the one that got selected when you had two hpet entries ... and that there is something wrong with that code that doesn't work right on x86_64. The fix to prevent registering a duplicate name is presumably working for you simply because arch/x86_64/kernel/hpet.c happens to get there first with its hpet, so the drivers/char/hpet.c one is dropped. If something changed that reversed the order of these registrations, then you'd get the hpet clocksource that results in a hang. 100% agree -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 22:21:15 +0200
Paolo Ornati <[EMAIL PROTECTED]> wrote:
> config & dmesg attached
ehmm..
--
Paolo Ornati
Linux 2.6.22-g5bae7ac9 on x86_64
config.gz
Description: GNU Zip compressed data
dmesg.gz
Description: GNU Zip compressed data
"double" hpet clocksource && hard freeze [bisected]
Hi, since commit: commit 0aa366f351d044703e25c8425e508170e80d83b1 Author: Tony Luck <[EMAIL PROTECTED]> Date: Fri Jul 20 11:22:30 2007 -0700 [IA64] Convert to generic timekeeping/clocksource This is a merge of Peter Keilty's initial patch (which was revived by Bob Picco) for this with Hidetoshi Seto's fixes and scaling improvements. I have a double "hpet" entry in "available_clocksource": $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet hpet acpi_pm jiffies And, more interesting, if I select hpet as clocksource (tsc is used by default here) I get an hard freeze some time later (few minutes)... SysRQ don't work ;) config & dmesg attached Motherboard is a Intel DG965SS CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.75 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3729.63 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- Paolo Ornati Linux 2.6.22-g5bae7ac9 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel "problem"?
On Thu, 23 Aug 2007 13:56:48 +0200
walter harms <[EMAIL PROTECTED]> wrote:
> xclip converts tabs to space if i remember correctly
no, it doesn't
[EMAIL PROTECTED] ~ $ echo -e "\tHello" | xclip
(middle mouse button)
Hello
:)
--
Paolo Ornati
Linux 2.6.23-rc3-g2a677896-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel "problem"?
On Wed, 22 Aug 2007 23:54:41 -0400 "Scott Thompson" <[EMAIL PROTECTED]> wrote: > if anyone knows of a free/inexpensive mail > client that will be able to handle the wordwrap requirements for > the current state of the linux tree please advise. http://www.claws-mail.org/ Configuration -> Preferences -> Wrapping: " [x] Auto wrapping [ ] Wrap quotation [ ] Wrap pasted text Wrap messages at [..] characters" Then use the "Insert File" button or (xclip < mypatch.diff && middle mouse button). Either will wrap with "Wrap pasted text", so keep it off. PS: auto wrapping has effect on the text you write directly in the mailer, you can even turn it off and use "CTRL + L" to wrap the current paragraph. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel problem?
On Wed, 22 Aug 2007 23:54:41 -0400 Scott Thompson [EMAIL PROTECTED] wrote: if anyone knows of a free/inexpensive mail client that will be able to handle the wordwrap requirements for the current state of the linux tree please advise. http://www.claws-mail.org/ Configuration - Preferences - Wrapping: [x] Auto wrapping [ ] Wrap quotation [ ] Wrap pasted text Wrap messages at [..] characters Then use the Insert File button or (xclip mypatch.diff middle mouse button). Either will wrap with Wrap pasted text, so keep it off. PS: auto wrapping has effect on the text you write directly in the mailer, you can even turn it off and use CTRL + L to wrap the current paragraph. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel problem?
On Thu, 23 Aug 2007 13:56:48 +0200 walter harms [EMAIL PROTECTED] wrote: xclip converts tabs to space if i remember correctly no, it doesn't [EMAIL PROTECTED] ~ $ echo -e \tHello | xclip (middle mouse button) Hello :) -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
double hpet clocksource hard freeze [bisected]
Hi, since commit: commit 0aa366f351d044703e25c8425e508170e80d83b1 Author: Tony Luck [EMAIL PROTECTED] Date: Fri Jul 20 11:22:30 2007 -0700 [IA64] Convert to generic timekeeping/clocksource This is a merge of Peter Keilty's initial patch (which was revived by Bob Picco) for this with Hidetoshi Seto's fixes and scaling improvements. I have a double hpet entry in available_clocksource: $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet hpet acpi_pm jiffies And, more interesting, if I select hpet as clocksource (tsc is used by default here) I get an hard freeze some time later (few minutes)... SysRQ don't work ;) config dmesg attached Motherboard is a Intel DG965SS CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.75 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3729.63 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- Paolo Ornati Linux 2.6.22-g5bae7ac9 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: double hpet clocksource hard freeze [bisected]
On Thu, 23 Aug 2007 22:21:15 +0200 Paolo Ornati [EMAIL PROTECTED] wrote: config dmesg attached ehmm.. -- Paolo Ornati Linux 2.6.22-g5bae7ac9 on x86_64 config.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data
Re: huge improvement with per-device dirty throttling
On 22 Aug 2007 13:05:13 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes: > > > > My system is a Core 2 Duo, 2GB, single SATA disk. > > Hmm, I thought the patch was only supposed to make a real difference > if you have multiple devices? But you only got a single disk. No, there's also: [PATCH 22/23] mm: dirty balancing for tasks :) -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: huge improvement with per-device dirty throttling
On 22 Aug 2007 13:05:13 +0200 Andi Kleen [EMAIL PROTECTED] wrote: Jeffrey W. Baker [EMAIL PROTECTED] writes: My system is a Core 2 Duo, 2GB, single SATA disk. Hmm, I thought the patch was only supposed to make a real difference if you have multiple devices? But you only got a single disk. No, there's also: [PATCH 22/23] mm: dirty balancing for tasks :) -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 06:22:37 -0700 (PDT) Marc Perkel <[EMAIL PROTECTED]> wrote: > 20 years, a million programmers, tens of millions of > users and RM is BROKEN. Am I the only one who has a > problem with this? If so - I'm normal - and Linux is a > cult. Fixed in 2.6.23-rc (and not just for "rm"): commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild <[EMAIL PROTECTED]> Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. [...] -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: variable length argument support (was: [OT] Re: The vi editor causes brain damage)
On Sun, 19 Aug 2007 15:07:01 +0200 (CEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >Remove the arg+env limit of MAX_ARG_PAGES by copying the strings > >directly from the old mm into the new mm. > > Me wonders. Will that make the "checking for maximum length of command line > arguments" from autotools run forever since execve() will not fail anymore? Since I'm running Gentoo and do many compiles I can tell that it works :) If I remeber correctly it was discussed on LKML and turend out that that check is done starting with a "max" len and going down rather than starting low and going up. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Sun, 19 Aug 2007 13:55:13 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Sorry about the delay -- here is the fairly simple patch. A Tested-by:
> would be appreciated.
it works :)
Tested-by: Paolo Ornati <[EMAIL PROTECTED]>
--
Paolo Ornati
Linux 2.6.23-rc3-g2a677896-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 14:31:21 +0200 Benny Amorsen <[EMAIL PROTECTED]> wrote: > >>>>> "WT" == Willy Tarreau <[EMAIL PROTECTED]> writes: > > WT> Under unix, the shell resolves "*" and passes the 1 file names > WT> to the "rm" command. Now, execve() may fail because 1 names in > WT> arguments can require too much memory. That's why find and xargs > WT> were invented! > > It would be very handy if the argument memory space was expanded. > Many years ago I hit the limit regularly on Solaris, and going to > Linux with its comparatively large limit was a joy. Now it happens to > me quite often on Linux as well. > done :) commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild <[EMAIL PROTECTED]> Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 14:31:21 +0200 Benny Amorsen [EMAIL PROTECTED] wrote: WT == Willy Tarreau [EMAIL PROTECTED] writes: WT Under unix, the shell resolves * and passes the 1 file names WT to the rm command. Now, execve() may fail because 1 names in WT arguments can require too much memory. That's why find and xargs WT were invented! It would be very handy if the argument memory space was expanded. Many years ago I hit the limit regularly on Solaris, and going to Linux with its comparatively large limit was a joy. Now it happens to me quite often on Linux as well. done :) commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild [EMAIL PROTECTED] Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Sun, 19 Aug 2007 13:55:13 +0300 Avi Kivity [EMAIL PROTECTED] wrote: Sorry about the delay -- here is the fairly simple patch. A Tested-by: would be appreciated. it works :) Tested-by: Paolo Ornati [EMAIL PROTECTED] -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: variable length argument support (was: [OT] Re: The vi editor causes brain damage)
On Sun, 19 Aug 2007 15:07:01 +0200 (CEST) Jan Engelhardt [EMAIL PROTECTED] wrote: Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. Me wonders. Will that make the checking for maximum length of command line arguments from autotools run forever since execve() will not fail anymore? Since I'm running Gentoo and do many compiles I can tell that it works :) If I remeber correctly it was discussed on LKML and turend out that that check is done starting with a max len and going down rather than starting low and going up. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 06:22:37 -0700 (PDT) Marc Perkel [EMAIL PROTECTED] wrote: 20 years, a million programmers, tens of millions of users and RM is BROKEN. Am I the only one who has a problem with this? If so - I'm normal - and Linux is a cult. Fixed in 2.6.23-rc (and not just for rm): commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild [EMAIL PROTECTED] Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. [...] -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 20:33:22 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Exactly. This is not reliable. It needs to be done in kernel. This patch
> should do it.
ok, this one works :)
I suspect that there are many more broken devices out there ;)
thanks,
--
Paolo Ornati
Linux 2.6.23-rc3-gbfefa254 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 17:46:16 +0200 Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Dienstag 14 August 2007 schrieb Paolo Ornati: > > Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) > > Please try this patch. Tried on -rc3 but it doesn't work, dmesg attached. However I've found that if "hald" is running the problems doesn't happen (I think it's just hidden by the fact that hald do some polling on it preventing autosuspend to trigger). -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 dmesg.gz Description: GNU Zip compressed data
Re: [linux-usb-devel] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 15:30:27 +0200 Oliver Neukum <[EMAIL PROTECTED]> wrote: > > my USB photo-camera gets automagically disconnected before I can do > > anything with it ;) > > > > hi, > > I need vendor:product. Please provide "lsusb". > Generally a bug report for a specific usb device without vendor:product > is a bad idea. oopss :) HP PHOTOSMART E317 tux ~ # lsusb Bus 007 Device 001: ID : Bus 006 Device 002: ID 03f0:4002 Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) ... -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
spontaneous disconnect with "usb-storage: implement autosuspend"
Hi, with "CONFIG_USB_SUSPEND=y", since commit: 8dfe4b14869fd185ca25ee88b02ada58a3005eaf usb-storage: implement autosuspend This patch (as930) implements autosuspend for usb-storage. It is adapted from a patch by Oliver Neukum. Autosuspend is allowed except during LUN scanning, resets, and command execution. my USB photo-camera gets automagically disconnected before I can do anything with it ;) Relevant dmesg (what I get by just attaching it): [ 70.722898] scsi 8:0:0:0: Direct-Access HP PHOTOSMART E317 A001 PQ: 0 ANSI: 0 CCS [ 70.727880] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.730876] sd 8:0:0:0: [sdb] Write Protect is off [ 70.730879] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.730882] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.742874] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.745873] sd 8:0:0:0: [sdb] Write Protect is off [ 70.745876] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.745878] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.745882] sdb: sdb1 [ 70.755192] sd 8:0:0:0: [sdb] Attached SCSI removable disk [ 70.755446] sd 8:0:0:0: Attached scsi generic sg3 type 0 [ 70.755657] usb-storage: device scan complete [ 73.071490] usb 6-2: usb auto-suspend [ 73.321445] hub 6-0:1.0: state 7 ports 2 chg evt 0004 [ 73.321453] uhci_hcd :00:1d.1: port 2 portsc 108a,00 [ 73.321462] hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s [ 73.321465] usb 6-2: USB disconnect, address 2 [ 73.321467] usb 6-2: unregistering device The relevant differences of dmesg between pre and post "autosuspend" patch: @@ -1,4 +1,4 @@ - Linux version 2.6.22-gb0e2a705 ... + Linux version 2.6.22-g8dfe4b14 ... @@ -606,6 +606,12 @@ hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend ehci_hcd :00:1a.7: suspend root hub + hub 4-0:1.0: hub_suspend + usb usb4: bus auto-suspend + usb usb4: suspend_rh + hub 5-0:1.0: hub_suspend + usb usb5: bus auto-suspend + usb usb5: suspend_rh hub 6-0:1.0: hub_suspend usb usb6: bus auto-suspend usb usb6: suspend_rh @@ -618,12 +624,6 @@ hub 3-0:1.0: hub_suspend usb usb3: bus auto-suspend usb usb3: suspend_rh - hub 4-0:1.0: hub_suspend - usb usb4: bus auto-suspend - usb usb4: suspend_rh - hub 5-0:1.0: hub_suspend - usb usb5: bus auto-suspend - usb usb5: suspend_rh usb usb3: uevent usb 3-0:1.0: uevent usb 3-0:1.0: uevent @@ -686,6 +686,7 @@ usb-storage 6-2:1.0: usb_probe_interface - got id scsi8 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '002' + hub 6-0:1.0: state 7 ports 2 chg evt 0004 usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning hub 2-0:1.0: hub_suspend @@ -704,3 +705,22 @@ sd 8:0:0:0: [sdb] Attached SCSI removable disk sd 8:0:0:0: Attached scsi generic sg3 type 0 usb-storage: device scan complete + usb 6-2: usb auto-suspend + hub 6-0:1.0: state 7 ports 2 chg evt 0004 + uhci_hcd :00:1d.1: port 2 portsc 108a,00 + hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s + usb 6-2: USB disconnect, address 2 + usb 6-2: unregistering device + usb 6-2: usb_disable_device nuking all URBs + usb 6-2: unregistering interface 6-2:1.0 + usb_endpoint usbdev6.2_ep82: ep_device_release called for usbdev6.2_ep82 + usb_endpoint usbdev6.2_ep03: ep_device_release called for usbdev6.2_ep03 + usb 6-2:1.0: uevent + usb 6-2:1.0: uevent + usb_endpoint usbdev6.2_ep00: ep_device_release called for usbdev6.2_ep00 + usb 6-2: uevent + hub 6-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 + usb usb6: suspend_rh (auto-stop) + hub 6-0:1.0: hub_suspend + usb usb6: bus auto-suspend + usb usb6: suspend_rh config for 2.6.22-gb0e2a705 attached -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 config-usb.gz Description: GNU Zip compressed data
spontaneous disconnect with usb-storage: implement autosuspend
Hi, with CONFIG_USB_SUSPEND=y, since commit: 8dfe4b14869fd185ca25ee88b02ada58a3005eaf usb-storage: implement autosuspend This patch (as930) implements autosuspend for usb-storage. It is adapted from a patch by Oliver Neukum. Autosuspend is allowed except during LUN scanning, resets, and command execution. my USB photo-camera gets automagically disconnected before I can do anything with it ;) Relevant dmesg (what I get by just attaching it): [ 70.722898] scsi 8:0:0:0: Direct-Access HP PHOTOSMART E317 A001 PQ: 0 ANSI: 0 CCS [ 70.727880] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.730876] sd 8:0:0:0: [sdb] Write Protect is off [ 70.730879] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.730882] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.742874] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.745873] sd 8:0:0:0: [sdb] Write Protect is off [ 70.745876] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.745878] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.745882] sdb: sdb1 [ 70.755192] sd 8:0:0:0: [sdb] Attached SCSI removable disk [ 70.755446] sd 8:0:0:0: Attached scsi generic sg3 type 0 [ 70.755657] usb-storage: device scan complete [ 73.071490] usb 6-2: usb auto-suspend [ 73.321445] hub 6-0:1.0: state 7 ports 2 chg evt 0004 [ 73.321453] uhci_hcd :00:1d.1: port 2 portsc 108a,00 [ 73.321462] hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s [ 73.321465] usb 6-2: USB disconnect, address 2 [ 73.321467] usb 6-2: unregistering device The relevant differences of dmesg between pre and post autosuspend patch: @@ -1,4 +1,4 @@ - Linux version 2.6.22-gb0e2a705 ... + Linux version 2.6.22-g8dfe4b14 ... @@ -606,6 +606,12 @@ hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend ehci_hcd :00:1a.7: suspend root hub + hub 4-0:1.0: hub_suspend + usb usb4: bus auto-suspend + usb usb4: suspend_rh + hub 5-0:1.0: hub_suspend + usb usb5: bus auto-suspend + usb usb5: suspend_rh hub 6-0:1.0: hub_suspend usb usb6: bus auto-suspend usb usb6: suspend_rh @@ -618,12 +624,6 @@ hub 3-0:1.0: hub_suspend usb usb3: bus auto-suspend usb usb3: suspend_rh - hub 4-0:1.0: hub_suspend - usb usb4: bus auto-suspend - usb usb4: suspend_rh - hub 5-0:1.0: hub_suspend - usb usb5: bus auto-suspend - usb usb5: suspend_rh usb usb3: uevent usb 3-0:1.0: uevent usb 3-0:1.0: uevent @@ -686,6 +686,7 @@ usb-storage 6-2:1.0: usb_probe_interface - got id scsi8 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '002' + hub 6-0:1.0: state 7 ports 2 chg evt 0004 usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning hub 2-0:1.0: hub_suspend @@ -704,3 +705,22 @@ sd 8:0:0:0: [sdb] Attached SCSI removable disk sd 8:0:0:0: Attached scsi generic sg3 type 0 usb-storage: device scan complete + usb 6-2: usb auto-suspend + hub 6-0:1.0: state 7 ports 2 chg evt 0004 + uhci_hcd :00:1d.1: port 2 portsc 108a,00 + hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s + usb 6-2: USB disconnect, address 2 + usb 6-2: unregistering device + usb 6-2: usb_disable_device nuking all URBs + usb 6-2: unregistering interface 6-2:1.0 + usb_endpoint usbdev6.2_ep82: ep_device_release called for usbdev6.2_ep82 + usb_endpoint usbdev6.2_ep03: ep_device_release called for usbdev6.2_ep03 + usb 6-2:1.0: uevent + usb 6-2:1.0: uevent + usb_endpoint usbdev6.2_ep00: ep_device_release called for usbdev6.2_ep00 + usb 6-2: uevent + hub 6-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 + usb usb6: suspend_rh (auto-stop) + hub 6-0:1.0: hub_suspend + usb usb6: bus auto-suspend + usb usb6: suspend_rh config for 2.6.22-gb0e2a705 attached -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 config-usb.gz Description: GNU Zip compressed data
Re: [linux-usb-devel] spontaneous disconnect with usb-storage: implement autosuspend
On Tue, 14 Aug 2007 15:30:27 +0200 Oliver Neukum [EMAIL PROTECTED] wrote: my USB photo-camera gets automagically disconnected before I can do anything with it ;) hi, I need vendor:product. Please provide lsusb. Generally a bug report for a specific usb device without vendor:product is a bad idea. oopss :) HP PHOTOSMART E317 tux ~ # lsusb Bus 007 Device 001: ID : Bus 006 Device 002: ID 03f0:4002 Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) ... -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] spontaneous disconnect with usb-storage: implement autosuspend
On Tue, 14 Aug 2007 17:46:16 +0200 Oliver Neukum [EMAIL PROTECTED] wrote: Am Dienstag 14 August 2007 schrieb Paolo Ornati: Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) Please try this patch. Tried on -rc3 but it doesn't work, dmesg attached. However I've found that if hald is running the problems doesn't happen (I think it's just hidden by the fact that hald do some polling on it preventing autosuspend to trigger). -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 dmesg.gz Description: GNU Zip compressed data
Re: [linux-usb-devel] spontaneous disconnect with usb-storage: implement autosuspend
On Tue, 14 Aug 2007 20:33:22 +0200 Oliver Neukum [EMAIL PROTECTED] wrote: Exactly. This is not reliable. It needs to be done in kernel. This patch should do it. ok, this one works :) I suspect that there are many more broken devices out there ;) thanks, -- Paolo Ornati Linux 2.6.23-rc3-gbfefa254 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Fri, 10 Aug 2007 14:04:33 +0200 "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > > [ 756.707601] Disabling non-boot CPUs ... > > [ 756.712034] kvm: disabling virtualization on CPU1 > > [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 > > smp_call_function_single() > > [ 756.712039] > > [ 756.712039] Call Trace: > > [ 756.712046] [] smp_call_function_single+0x119/0x120 > > [ 756.712050] [] thread_return+0x1bf/0x626 > > [ 756.712054] [] sys_sched_yield+0x2b/0x80 > > [ 756.712057] [] kvm_cpu_hotplug+0x4b/0xa0 > > [ 756.712060] [] notifier_call_chain+0x53/0x80 > > [ 756.712062] [] __raw_notifier_call_chain+0x9/0x10 > > [ 756.712065] [] raw_notifier_call_chain+0x11/0x20 > > [ 756.712068] [] take_cpu_down+0x1b/0x30 > > [ 756.712071] [] do_stop+0xd2/0x150 > > [ 756.712073] [] do_stop+0x0/0x150 > > [ 756.712076] [] kthread+0x4d/0x80 > > [ 756.712079] [] child_rip+0xa/0x12 > > [ 756.712081] [] restore_args+0x0/0x30 > > [ 756.712084] [] kthread+0x0/0x80 > > [ 756.712086] [] child_rip+0x0/0x12 > > [ 756.712087] > > [ 756.815693] CPU 1 is now offline > > [ 756.815697] lockdep: not fixing up alternatives. > > [ 756.819276] CPU1 is down > > > > Added to KR list, thanks for the report. I've bisected it down to this commit: cec9ad279b66793bee0b5009b7ca311060061efd KVM: Use CPU_DYING for disabling virtualization Only at the CPU_DYING stage can we be sure that no user process will be scheduled onto the cpu and oops when trying to use virtualization extensions. $ git-bisect log git-bisect start # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1 git-bisect bad f695baf2df9e0413d3521661070103711545207a # good: [7dcca30a32aadb0520417521b0c44f42d09fe05c] Linux 2.6.22 git-bisect good 7dcca30a32aadb0520417521b0c44f42d09fe05c # good: [1f1c2881f673671539b25686df463518d69c4649] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 git-bisect good 1f1c2881f673671539b25686df463518d69c4649 # bad: [3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c] coda: remove statistics counters from /proc/fs/coda git-bisect bad 3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c # bad: [b8c638acacfe32c0bde361916467af00691f1965] Merge branch 'uninit-var' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 git-bisect bad b8c638acacfe32c0bde361916467af00691f1965 # good: [c06e677aed0c86480b01faa894967daa8aa3568a] SPI: add 3wire mode flag git-bisect good c06e677aed0c86480b01faa894967daa8aa3568a # good: [90da63e54604fd515c17014a0a7f332a018a0a11] fbdev: extract fb_show_logo_line() git-bisect good 90da63e54604fd515c17014a0a7f332a018a0a11 # good: [e495606dd09d79f9fa496334ac3958f6ff179d82] KVM: Clean up #includes git-bisect good e495606dd09d79f9fa496334ac3958f6ff179d82 # good: [27d41718157626e4509026c7dac247a659c0e71f] mark a bunch of ISA|EISA|PCI drivers as such git-bisect good 27d41718157626e4509026c7dac247a659c0e71f # bad: [3bd858ab1c451725c07a805dcb315215dc85b86e] Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check git-bisect bad 3bd858ab1c451725c07a805dcb315215dc85b86e # bad: [cec9ad279b66793bee0b5009b7ca311060061efd] KVM: Use CPU_DYING for disabling virtualization git-bisect bad cec9ad279b66793bee0b5009b7ca311060061efd # good: [401bbcb0d0be8c916134b4e9074826e89638] x86_64: Allow smp_call_function_single() to current cpu git-bisect good 401bbcb0d0be8c916134b4e9074826e89638 # good: [a52b1752c077cb919b71167c54968a0b91673281] SMP: Allow smp_call_function_single() to current cpu git-bisect good a52b1752c077cb919b71167c54968a0b91673281 # good: [4267c41a458cd7d287dc8031468fc385c2f5b2c3] KVM: Tune hotplug/suspend IPIs git-bisect good 4267c41a458cd7d287dc8031468fc385c2f5b2c3 -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Fri, 10 Aug 2007 14:04:33 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote: [ 756.707601] Disabling non-boot CPUs ... [ 756.712034] kvm: disabling virtualization on CPU1 [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single() [ 756.712039] [ 756.712039] Call Trace: [ 756.712046] [8021d159] smp_call_function_single+0x119/0x120 [ 756.712050] [80542169] thread_return+0x1bf/0x626 [ 756.712054] [80234b5b] sys_sched_yield+0x2b/0x80 [ 756.712057] [8043684b] kvm_cpu_hotplug+0x4b/0xa0 [ 756.712060] [80247c83] notifier_call_chain+0x53/0x80 [ 756.712062] [80247d09] __raw_notifier_call_chain+0x9/0x10 [ 756.712065] [80247d21] raw_notifier_call_chain+0x11/0x20 [ 756.712068] [8026184b] take_cpu_down+0x1b/0x30 [ 756.712071] [802699d2] do_stop+0xd2/0x150 [ 756.712073] [80269900] do_stop+0x0/0x150 [ 756.712076] [8024f84d] kthread+0x4d/0x80 [ 756.712079] [8020cb28] child_rip+0xa/0x12 [ 756.712081] [8020c23c] restore_args+0x0/0x30 [ 756.712084] [8024f800] kthread+0x0/0x80 [ 756.712086] [8020cb1e] child_rip+0x0/0x12 [ 756.712087] [ 756.815693] CPU 1 is now offline [ 756.815697] lockdep: not fixing up alternatives. [ 756.819276] CPU1 is down Added to KR list, thanks for the report. I've bisected it down to this commit: cec9ad279b66793bee0b5009b7ca311060061efd KVM: Use CPU_DYING for disabling virtualization Only at the CPU_DYING stage can we be sure that no user process will be scheduled onto the cpu and oops when trying to use virtualization extensions. $ git-bisect log git-bisect start # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1 git-bisect bad f695baf2df9e0413d3521661070103711545207a # good: [7dcca30a32aadb0520417521b0c44f42d09fe05c] Linux 2.6.22 git-bisect good 7dcca30a32aadb0520417521b0c44f42d09fe05c # good: [1f1c2881f673671539b25686df463518d69c4649] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 git-bisect good 1f1c2881f673671539b25686df463518d69c4649 # bad: [3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c] coda: remove statistics counters from /proc/fs/coda git-bisect bad 3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c # bad: [b8c638acacfe32c0bde361916467af00691f1965] Merge branch 'uninit-var' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 git-bisect bad b8c638acacfe32c0bde361916467af00691f1965 # good: [c06e677aed0c86480b01faa894967daa8aa3568a] SPI: add 3wire mode flag git-bisect good c06e677aed0c86480b01faa894967daa8aa3568a # good: [90da63e54604fd515c17014a0a7f332a018a0a11] fbdev: extract fb_show_logo_line() git-bisect good 90da63e54604fd515c17014a0a7f332a018a0a11 # good: [e495606dd09d79f9fa496334ac3958f6ff179d82] KVM: Clean up #includes git-bisect good e495606dd09d79f9fa496334ac3958f6ff179d82 # good: [27d41718157626e4509026c7dac247a659c0e71f] mark a bunch of ISA|EISA|PCI drivers as such git-bisect good 27d41718157626e4509026c7dac247a659c0e71f # bad: [3bd858ab1c451725c07a805dcb315215dc85b86e] Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check git-bisect bad 3bd858ab1c451725c07a805dcb315215dc85b86e # bad: [cec9ad279b66793bee0b5009b7ca311060061efd] KVM: Use CPU_DYING for disabling virtualization git-bisect bad cec9ad279b66793bee0b5009b7ca311060061efd # good: [401bbcb0d0be8c916134b4e9074826e89638] x86_64: Allow smp_call_function_single() to current cpu git-bisect good 401bbcb0d0be8c916134b4e9074826e89638 # good: [a52b1752c077cb919b71167c54968a0b91673281] SMP: Allow smp_call_function_single() to current cpu git-bisect good a52b1752c077cb919b71167c54968a0b91673281 # good: [4267c41a458cd7d287dc8031468fc385c2f5b2c3] KVM: Tune hotplug/suspend IPIs git-bisect good 4267c41a458cd7d287dc8031468fc385c2f5b2c3 -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
On 12 Aug 2007 15:55:50 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Ok Linus already applied your patch. Even though it's a really bad
> > > fragile hack, not better than the old bug.
> > > Petr are you double sure you really tested with
> > > ab144f5ec64c42218a555ec1dbde6b60cf2982d6
> > > already applied? I bet not -- it is the symptom exactly fixed by this
> > > patch
> >
> > I'm quite sure that this patch is in my tree, as I have that "u8
> > *instr = a->instr;" in apply_alternatives, and it seems that this one
> > was added by checkin you mention... My tree was synced up to:
>
> Can you double check? I have a hard time believing it.
I've seen the reboot too, with "rc2-g3864e8cc" that is newer than
ab144f5ec64c4:
$ git-log ab144f5ec64c4..| grep 3864e8cc
commit 3864e8ccbba1dcdea87398ab80fdc8ae0fab7c45
--
Paolo Ornati
Linux 2.6.23-rc2-gac078602 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: reset during bootup - solved
On Sun, 12 Aug 2007 05:44:36 -0400
"Dan Merillat" <[EMAIL PROTECTED]> wrote:
> However, a git-pull at 2am (b8d3f244) fixed it. Not sure where in
> there it started working again, I can bisect backwards to find out if
> need be.
I think it is was fixed by this one:
Do not replace whole memcpy in apply alternatives
apply_alternatives uses memcpy() to apply alternatives. Which has the
unfortunate effect that while applying memcpy alternative to memcpy
itself it tries to overwrite itself with nops - which causes #UD fault
as it overwrites half of an instruction in copy loop, and from this
point on only possible outcome is triplefault and reboot.
b8d3f2448b8f4ba24f301e23585547ba1acc1f04
arch/x86_64/lib/memcpy.S |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S
index 0ea0ddc..c22981f 100644
--- a/arch/x86_64/lib/memcpy.S
+++ b/arch/x86_64/lib/memcpy.S
@@ -124,6 +124,8 @@ ENDPROC(__memcpy)
.quad memcpy
.quad 1b
.byte X86_FEATURE_REP_GOOD
- .byte .Lfinal - memcpy
+ /* Replace only beginning, memcpy is used to apply alternatives, so it
+* is silly to overwrite itself with nops - reboot is only outcome... */
+ .byte 2b - 1b
.byte 2b - 1b
.previous
--
Paolo Ornati
Linux 2.6.23-rc2-gac078602 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: reset during bootup - solved
On Sun, 12 Aug 2007 05:44:36 -0400 Dan Merillat [EMAIL PROTECTED] wrote: However, a git-pull at 2am (b8d3f244) fixed it. Not sure where in there it started working again, I can bisect backwards to find out if need be. I think it is was fixed by this one: Do not replace whole memcpy in apply alternatives apply_alternatives uses memcpy() to apply alternatives. Which has the unfortunate effect that while applying memcpy alternative to memcpy itself it tries to overwrite itself with nops - which causes #UD fault as it overwrites half of an instruction in copy loop, and from this point on only possible outcome is triplefault and reboot. b8d3f2448b8f4ba24f301e23585547ba1acc1f04 arch/x86_64/lib/memcpy.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S index 0ea0ddc..c22981f 100644 --- a/arch/x86_64/lib/memcpy.S +++ b/arch/x86_64/lib/memcpy.S @@ -124,6 +124,8 @@ ENDPROC(__memcpy) .quad memcpy .quad 1b .byte X86_FEATURE_REP_GOOD - .byte .Lfinal - memcpy + /* Replace only beginning, memcpy is used to apply alternatives, so it +* is silly to overwrite itself with nops - reboot is only outcome... */ + .byte 2b - 1b .byte 2b - 1b .previous -- Paolo Ornati Linux 2.6.23-rc2-gac078602 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
On 12 Aug 2007 15:55:50 +0200 Andi Kleen [EMAIL PROTECTED] wrote: Ok Linus already applied your patch. Even though it's a really bad fragile hack, not better than the old bug. Petr are you double sure you really tested with ab144f5ec64c42218a555ec1dbde6b60cf2982d6 already applied? I bet not -- it is the symptom exactly fixed by this patch I'm quite sure that this patch is in my tree, as I have that u8 *instr = a-instr; in apply_alternatives, and it seems that this one was added by checkin you mention... My tree was synced up to: Can you double check? I have a hard time believing it. I've seen the reboot too, with rc2-g3864e8cc that is newer than ab144f5ec64c4: $ git-log ab144f5ec64c4..| grep 3864e8cc commit 3864e8ccbba1dcdea87398ab80fdc8ae0fab7c45 -- Paolo Ornati Linux 2.6.23-rc2-gac078602 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
Just got this warning during suspend2ram (2.6.23-rc2-gac078602). Config and full dmesg attached. [ 756.707601] Disabling non-boot CPUs ... [ 756.712034] kvm: disabling virtualization on CPU1 [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single() [ 756.712039] [ 756.712039] Call Trace: [ 756.712046] [] smp_call_function_single+0x119/0x120 [ 756.712050] [] thread_return+0x1bf/0x626 [ 756.712054] [] sys_sched_yield+0x2b/0x80 [ 756.712057] [] kvm_cpu_hotplug+0x4b/0xa0 [ 756.712060] [] notifier_call_chain+0x53/0x80 [ 756.712062] [] __raw_notifier_call_chain+0x9/0x10 [ 756.712065] [] raw_notifier_call_chain+0x11/0x20 [ 756.712068] [] take_cpu_down+0x1b/0x30 [ 756.712071] [] do_stop+0xd2/0x150 [ 756.712073] [] do_stop+0x0/0x150 [ 756.712076] [] kthread+0x4d/0x80 [ 756.712079] [] child_rip+0xa/0x12 [ 756.712081] [] restore_args+0x0/0x30 [ 756.712084] [] kthread+0x0/0x80 [ 756.712086] [] child_rip+0x0/0x12 [ 756.712087] [ 756.815693] CPU 1 is now offline [ 756.815697] lockdep: not fixing up alternatives. [ 756.819276] CPU1 is down -- Paolo Ornati Linux 2.6.23-rc2-gac078602 on x86_64 config.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data
WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
Just got this warning during suspend2ram (2.6.23-rc2-gac078602). Config and full dmesg attached. [ 756.707601] Disabling non-boot CPUs ... [ 756.712034] kvm: disabling virtualization on CPU1 [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single() [ 756.712039] [ 756.712039] Call Trace: [ 756.712046] [8021d159] smp_call_function_single+0x119/0x120 [ 756.712050] [80542169] thread_return+0x1bf/0x626 [ 756.712054] [80234b5b] sys_sched_yield+0x2b/0x80 [ 756.712057] [8043684b] kvm_cpu_hotplug+0x4b/0xa0 [ 756.712060] [80247c83] notifier_call_chain+0x53/0x80 [ 756.712062] [80247d09] __raw_notifier_call_chain+0x9/0x10 [ 756.712065] [80247d21] raw_notifier_call_chain+0x11/0x20 [ 756.712068] [8026184b] take_cpu_down+0x1b/0x30 [ 756.712071] [802699d2] do_stop+0xd2/0x150 [ 756.712073] [80269900] do_stop+0x0/0x150 [ 756.712076] [8024f84d] kthread+0x4d/0x80 [ 756.712079] [8020cb28] child_rip+0xa/0x12 [ 756.712081] [8020c23c] restore_args+0x0/0x30 [ 756.712084] [8024f800] kthread+0x0/0x80 [ 756.712086] [8020cb1e] child_rip+0x0/0x12 [ 756.712087] [ 756.815693] CPU 1 is now offline [ 756.815697] lockdep: not fixing up alternatives. [ 756.819276] CPU1 is down -- Paolo Ornati Linux 2.6.23-rc2-gac078602 on x86_64 config.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data
Re: Problems with kernel 2.6.22-git15, 2.6.23-rc1
On Mon, 23 Jul 2007 09:40:04 -0300 (GFT) "werner" <[EMAIL PROTECTED]> wrote: > > The kernel need to stay compatible to old versions of the file system and > other fundamental programs. This sounds new to me... Documentation/stable_api_nonsense.txt -- Paolo Ornati Linux 2.6.22-cfs-v19-g03634801 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with kernel 2.6.22-git15, 2.6.23-rc1
On Mon, 23 Jul 2007 09:40:04 -0300 (GFT) werner [EMAIL PROTECTED] wrote: The kernel need to stay compatible to old versions of the file system and other fundamental programs. This sounds new to me... Documentation/stable_api_nonsense.txt -- Paolo Ornati Linux 2.6.22-cfs-v19-g03634801 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 15:56:36 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > > And yes, programs/distributions should set good defaults for you... and > > if they don't, just complain to them :) > > I'm sure they'll do once a fair scheduler goes into mainline :) Some already does... for example the current version of: http://www.exit1.org/dvdrip/ it sets transcode nice to "+19" by default :) > > I guess what I was missing from the beginning is that "fair" means that the > scheduler will be fair among tasks that have the same priority, but if a task > has a higher priority, it _will_ get more CPU. So we'll just have to mark > applications like video players, audio players or games with a high priority, > others like encoders or compilers with low priority, and leave the rest > (browsers, word processors, email readers, etc...) as normal priority. This > way a fair scheduler would be able to give each task right amount of CPU. Yes. I think that the more important thing is to nice background tasks (like encoders etc..), then games / video players can run without problems even without renicing (usually normal programs don't eat much CPU). -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 10:01:02 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > I see. So you mean that in 90% of the cases the mainline scheduler behaves > better than fair schedulers, but when its "logic" fails it behaves much worse > (the other 10% cases)? Yes and no... the "logic" is supposed to identify what processes are somehow interactive and give them more priority / CPU time. This makes the system behaves better when there are CPU hog processes (like encoders etc...) because the interactive ones doesn't suffer too much. The big problem is that it can identify an almost CPU hog process as interactive and giving him an insane amount of CPU starve the others. In my case it was "trancode", and I assure you... it wasn't funny. Sometimes it happened that running it (at standard nice 0) made the machine totally unusable! (something like 30s to switch from X to a virtual terminal... and I don't tell you how hard was doing login and killing/renicing it). So far I've seen these pathological behaviour only with trancode and wine (only with particular programs I don't remember now). But the fact is, the "interactivity estimator" is too fragile, and when it fails it can do much damage. Fair scheduler instead: - are robust - provide consistent behaviour - provide good interactivity within the bounds of fairness > In my very simple test scenario the mainline scheduler > did behave much better. Of course... because of the two competing processes the "interactive" (for you) one needs 60%, that is more than it's 50% fair share. The real solution is to use nice levels so the scheduler doesn't have to guess what process is more important. And yes, programs/distributions should set good defaults for you... and if they don't, just complain to them :) -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 00:07:15 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > My conclusion is that SD behaves as expected: it's more fair. But for a > desktop, shouldn't an "intelligently unfair" scheduler be better? "intelligently unfair" is what the current scheduler is (because of interactivity estimator). When it works (say 90% of the time) the desktop feels really good... but when it doesn't it can be a disaster. Look this for example: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/6aa5c93c379ae9e1/98ab31c0e6fed2ee?=en#98ab31c0e6fed2ee -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 00:07:15 +0200 Alberto Gonzalez [EMAIL PROTECTED] wrote: My conclusion is that SD behaves as expected: it's more fair. But for a desktop, shouldn't an intelligently unfair scheduler be better? intelligently unfair is what the current scheduler is (because of interactivity estimator). When it works (say 90% of the time) the desktop feels really good... but when it doesn't it can be a disaster. Look this for example: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/6aa5c93c379ae9e1/98ab31c0e6fed2ee?hl=en#98ab31c0e6fed2ee -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 10:01:02 +0200 Alberto Gonzalez [EMAIL PROTECTED] wrote: I see. So you mean that in 90% of the cases the mainline scheduler behaves better than fair schedulers, but when its logic fails it behaves much worse (the other 10% cases)? Yes and no... the logic is supposed to identify what processes are somehow interactive and give them more priority / CPU time. This makes the system behaves better when there are CPU hog processes (like encoders etc...) because the interactive ones doesn't suffer too much. The big problem is that it can identify an almost CPU hog process as interactive and giving him an insane amount of CPU starve the others. In my case it was trancode, and I assure you... it wasn't funny. Sometimes it happened that running it (at standard nice 0) made the machine totally unusable! (something like 30s to switch from X to a virtual terminal... and I don't tell you how hard was doing login and killing/renicing it). So far I've seen these pathological behaviour only with trancode and wine (only with particular programs I don't remember now). But the fact is, the interactivity estimator is too fragile, and when it fails it can do much damage. Fair scheduler instead: - are robust - provide consistent behaviour - provide good interactivity within the bounds of fairness In my very simple test scenario the mainline scheduler did behave much better. Of course... because of the two competing processes the interactive (for you) one needs 60%, that is more than it's 50% fair share. The real solution is to use nice levels so the scheduler doesn't have to guess what process is more important. And yes, programs/distributions should set good defaults for you... and if they don't, just complain to them :) -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 15:56:36 +0200 Alberto Gonzalez [EMAIL PROTECTED] wrote: And yes, programs/distributions should set good defaults for you... and if they don't, just complain to them :) I'm sure they'll do once a fair scheduler goes into mainline :) Some already does... for example the current version of: http://www.exit1.org/dvdrip/ it sets transcode nice to +19 by default :) I guess what I was missing from the beginning is that fair means that the scheduler will be fair among tasks that have the same priority, but if a task has a higher priority, it _will_ get more CPU. So we'll just have to mark applications like video players, audio players or games with a high priority, others like encoders or compilers with low priority, and leave the rest (browsers, word processors, email readers, etc...) as normal priority. This way a fair scheduler would be able to give each task right amount of CPU. Yes. I think that the more important thing is to nice background tasks (like encoders etc..), then games / video players can run without problems even without renicing (usually normal programs don't eat much CPU). -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Fri, 15 Jun 2007 12:19:35 +0100 "Simon Arlott" <[EMAIL PROTECTED]> wrote: > > It *is* a good idea. MD works that way too. > > There's a patch around somewhere to create at least 8 devices, I don't know > why it's not in Linus' tree yet... It is! It's just that it was applied after -rc4... commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen <[EMAIL PROTECTED]> Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices [...] -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Fri, 15 Jun 2007 12:19:35 +0100 Simon Arlott [EMAIL PROTECTED] wrote: It *is* a good idea. MD works that way too. There's a patch around somewhere to create at least 8 devices, I don't know why it's not in Linus' tree yet... It is! It's just that it was applied after -rc4... commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen [EMAIL PROTECTED] Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices [...] -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 16:10:44 +0200 Matthew <[EMAIL PROTECTED]> wrote: > I just tried out > > modprobe loop max_loop=32 > > output of dmesg is: > > [ 457.607575] loop: the max_loop option is obsolete and will be > removed in March 2008 > [ 457.607578] loop: module loaded > > but there are NO loop devices in /dev: > > ls -l /dev/ | grep loop > still shows nothing, strange ... it's not strange, with your kernel version "max_loop" will just limit the max number of loop devices at most. This is what happens with the mentioned patch (-rc5 and later): + /* +* loop module now has a feature to instantiate underlying device +* structure on-demand, provided that there is an access dev node. +* However, this will not work well with user space tool that doesn't +* know about such "feature". In order to not break any existing +* tool, we do the following: +* +* (1) if max_loop is specified, create that many upfront, and this +* also becomes a hard limit. +* (2) if max_loop is not specified, create 8 loop device on module +* load, user can further extend loop device by create dev node +* themselves and have kernel automatically instantiate actual +* device on-demand. +*/ So with this patch "max_loop=32" will create 32 loop devices... but then it doesn't allow more of them. Without options it creates 8 and you (or some userspace tool) can add more dynamically. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 13:37:32 +0200 Matthew <[EMAIL PROTECTED]> wrote: > now back to topic: > > /dev/loop* seems to be broken since (at least) 2.6.22-rc3, since that > was the first kernel I tried of the 2.6.22-rc* series > > ls -l /dev/ | grep loop > > shows no output Yes, now the "loop" devices are dynamically allocated a patch to provide the 8 "static allocated" loop devices is already in current git (post -rc4, will be in -rc5). commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen <[EMAIL PROTECTED]> Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices The kernel on-demand loop device instantiation breaks several user space tools as the tools are not ready to cope with the "on-demand feature". Fix it by instantiate default 8 loop devices and also reinstate max_loop module parameter. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 13:37:32 +0200 Matthew [EMAIL PROTECTED] wrote: now back to topic: /dev/loop* seems to be broken since (at least) 2.6.22-rc3, since that was the first kernel I tried of the 2.6.22-rc* series ls -l /dev/ | grep loop shows no output Yes, now the loop devices are dynamically allocated a patch to provide the 8 static allocated loop devices is already in current git (post -rc4, will be in -rc5). commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen [EMAIL PROTECTED] Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices The kernel on-demand loop device instantiation breaks several user space tools as the tools are not ready to cope with the on-demand feature. Fix it by instantiate default 8 loop devices and also reinstate max_loop module parameter. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 16:10:44 +0200 Matthew [EMAIL PROTECTED] wrote: I just tried out modprobe loop max_loop=32 output of dmesg is: [ 457.607575] loop: the max_loop option is obsolete and will be removed in March 2008 [ 457.607578] loop: module loaded but there are NO loop devices in /dev: ls -l /dev/ | grep loop still shows nothing, strange ... it's not strange, with your kernel version max_loop will just limit the max number of loop devices at most. This is what happens with the mentioned patch (-rc5 and later): + /* +* loop module now has a feature to instantiate underlying device +* structure on-demand, provided that there is an access dev node. +* However, this will not work well with user space tool that doesn't +* know about such feature. In order to not break any existing +* tool, we do the following: +* +* (1) if max_loop is specified, create that many upfront, and this +* also becomes a hard limit. +* (2) if max_loop is not specified, create 8 loop device on module +* load, user can further extend loop device by create dev node +* themselves and have kernel automatically instantiate actual +* device on-demand. +*/ So with this patch max_loop=32 will create 32 loop devices... but then it doesn't allow more of them. Without options it creates 8 and you (or some userspace tool) can add more dynamically. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 16:07:49 +0200 Tommy Vercetti <[EMAIL PROTECTED]> wrote: > > Anyway 97% is quite high... what CPU / Hard Disk do you have? > Intel(R) Pentium(R) M processor 1400MHz > TOSHIBA MK8025GAS > > > What kernel version? > 2.6.21.1 > > I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) > [EMAIL PROTECTED]:~$ cat /sys/block/hda/queue/scheduler > noop anticipatory deadline [cfq] > > > Filesystem? > reiser3 > > And what time of "operations" are you doing? > apt-get install, vmware It's probably just a slow disk... try hdparm as suggested by Ray and see if they look sane (PS: just seen the numbers and looks sane to me). If they are and you need more performance buy a better HD :) Improvements from kernel side are possible but don't expect too much. Things to check/try: 1) FS: is it in good shape? Or is it full and fragmented? 2) FS mount options, try adding everything that can reduce accesses (noatime, nodiratime) 3) try experimental patches such as Adaptive Readahead, it seems to help some workload (it was there in older -mm, now there's a much simplier readahead replacement in 2.6.22-rc2-mm1 called "on-demand readahead", maybe that helps too?) -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 15:05:38 +0200 Tommy Vercetti <[EMAIL PROTECTED]> wrote: > I was trying to get answer to my question around, but no one knows. > I do have DMA turned on, etc, yet - on extensive harddrive operations wait > time is 90+% , which means that machine is waiting, rather than doing > something meanwhile. (I guess). > Can someone describe to me , in more detail why is that happening, and what > steps should I consider to avoid it ? I couldn't find any answers that would > have help me on net. It means that the disk is slow and the CPU is fast... so while the disk is busy seeking and reading data the CPU has nothing to do but wait for it. Idle == CPU has nothing to do Waiting == CPU has nothing to do, but it will have as soon as the slow disk (or whatever) delivers data Anyway 97% is quite high... what CPU / Hard Disk do you have? What kernel version? I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) Filesystem? And what time of "operations" are you doing? -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 15:05:38 +0200 Tommy Vercetti [EMAIL PROTECTED] wrote: I was trying to get answer to my question around, but no one knows. I do have DMA turned on, etc, yet - on extensive harddrive operations wait time is 90+% , which means that machine is waiting, rather than doing something meanwhile. (I guess). Can someone describe to me , in more detail why is that happening, and what steps should I consider to avoid it ? I couldn't find any answers that would have help me on net. It means that the disk is slow and the CPU is fast... so while the disk is busy seeking and reading data the CPU has nothing to do but wait for it. Idle == CPU has nothing to do Waiting == CPU has nothing to do, but it will have as soon as the slow disk (or whatever) delivers data Anyway 97% is quite high... what CPU / Hard Disk do you have? What kernel version? I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) Filesystem? And what time of operations are you doing? -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 16:07:49 +0200 Tommy Vercetti [EMAIL PROTECTED] wrote: Anyway 97% is quite high... what CPU / Hard Disk do you have? Intel(R) Pentium(R) M processor 1400MHz TOSHIBA MK8025GAS What kernel version? 2.6.21.1 I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) [EMAIL PROTECTED]:~$ cat /sys/block/hda/queue/scheduler noop anticipatory deadline [cfq] Filesystem? reiser3 And what time of operations are you doing? apt-get install, vmware It's probably just a slow disk... try hdparm as suggested by Ray and see if they look sane (PS: just seen the numbers and looks sane to me). If they are and you need more performance buy a better HD :) Improvements from kernel side are possible but don't expect too much. Things to check/try: 1) FS: is it in good shape? Or is it full and fragmented? 2) FS mount options, try adding everything that can reduce accesses (noatime, nodiratime) 3) try experimental patches such as Adaptive Readahead, it seems to help some workload (it was there in older -mm, now there's a much simplier readahead replacement in 2.6.22-rc2-mm1 called on-demand readahead, maybe that helps too?) -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 fails to suspend/resume to disk (sort of)
On Thu, 24 May 2007 10:01:21 +0200 "Antonino Ingargiola" <[EMAIL PROTECTED]> wrote: > Is not the ubuntu or debian way to take hours to compile. Is that you > have to trim the config and enable the only modules you need for your > hardware, then a rebuild cycle could last 10-15 min. Even 3-5 min if you strip it down a lot and with good hardware :) Also ccache helps. -- Paolo Ornati Linux 2.6.22-rc2-gd2579053 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 fails to suspend/resume to disk (sort of)
On Thu, 24 May 2007 10:01:21 +0200 Antonino Ingargiola [EMAIL PROTECTED] wrote: Is not the ubuntu or debian way to take hours to compile. Is that you have to trim the config and enable the only modules you need for your hardware, then a rebuild cycle could last 10-15 min. Even 3-5 min if you strip it down a lot and with good hardware :) Also ccache helps. -- Paolo Ornati Linux 2.6.22-rc2-gd2579053 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/69] -stable review
On Wed, 23 May 2007 09:09:00 +0200
Romano Giannetti <[EMAIL PROTECTED]> wrote:
> Will try to reboot with clocksource=acpi_pm, althoughI think that this
> is the one I'm using.
you can see that with:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
--
Paolo Ornati
Linux 2.6.22-rc2-gd2579053 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/69] -stable review
On Wed, 23 May 2007 09:09:00 +0200 Romano Giannetti [EMAIL PROTECTED] wrote: Will try to reboot with clocksource=acpi_pm, althoughI think that this is the one I'm using. you can see that with: cat /sys/devices/system/clocksource/clocksource0/current_clocksource -- Paolo Ornati Linux 2.6.22-rc2-gd2579053 on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Contributor Agreement/Copyright Assignment
On Wed, 16 May 2007 10:59:49 -0400 "Bhutani Meeta-W19091" <[EMAIL PROTECTED]> wrote: > > Motorola would like to understand if kernel.org has a contributor > agreement (or a copyright assignment agreement) that is posted somewhere > ? We are investigating what would be needed from a legal standpoint to > possibly contribute in the future. maybe this helps: http://groups.google.com/group/linux.kernel/browse_thread/thread/21d472915541ac48/5a2d152a1d1b62b6?lnk=st==3=en#5a2d152a1d1b62b6 :) -- Paolo Ornati Linux 2.6.21.1-cfs-v12-gd805260d on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Contributor Agreement/Copyright Assignment
On Wed, 16 May 2007 10:59:49 -0400 Bhutani Meeta-W19091 [EMAIL PROTECTED] wrote: Motorola would like to understand if kernel.org has a contributor agreement (or a copyright assignment agreement) that is posted somewhere ? We are investigating what would be needed from a legal standpoint to possibly contribute in the future. maybe this helps: http://groups.google.com/group/linux.kernel/browse_thread/thread/21d472915541ac48/5a2d152a1d1b62b6?lnk=stq=rnum=3hl=en#5a2d152a1d1b62b6 :) -- Paolo Ornati Linux 2.6.21.1-cfs-v12-gd805260d on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On Sat, 28 Apr 2007 09:30:06 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > There are worse examples. Try connecting some flash disk over USB-1, and > untar to it. Ugh. > > I'd love to have some per-device dirty limit, but it's harder than it > should be. this one should help: Patch: per device dirty throttling http://lwn.net/Articles/226709/ -- Paolo Ornati Linux 2.6.21-cfs-v7-g13fe02de on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On Sat, 28 Apr 2007 09:30:06 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: There are worse examples. Try connecting some flash disk over USB-1, and untar to it. Ugh. I'd love to have some per-device dirty limit, but it's harder than it should be. this one should help: Patch: per device dirty throttling http://lwn.net/Articles/226709/ -- Paolo Ornati Linux 2.6.21-cfs-v7-g13fe02de on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to tell linux (on x86) to ignore 1M or memory
On Thu, 19 Apr 2007 10:18:04 -0400 Bart Trojanowski <[EMAIL PROTECTED]> wrote: > I need to preserve some state from the bios before entering protected > mode. For now I want to copy it into some ram accessible by real-mode, > say the last megabyte visible in real-mode. > > What's the easiest way to have linux ignore the megabyte starting at 15M? > Documentation/kernel-parameters.txt: memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn. So adding this to kernel boot parameters should do the trick: memmap=15M$1M -- Paolo Ornati Linux 2.6.21-rc7-CFS-v3-g6262cd9f on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to tell linux (on x86) to ignore 1M or memory
On Thu, 19 Apr 2007 10:18:04 -0400 Bart Trojanowski [EMAIL PROTECTED] wrote: I need to preserve some state from the bios before entering protected mode. For now I want to copy it into some ram accessible by real-mode, say the last megabyte visible in real-mode. What's the easiest way to have linux ignore the megabyte starting at 15M? Documentation/kernel-parameters.txt: memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn. So adding this to kernel boot parameters should do the trick: memmap=15M$1M -- Paolo Ornati Linux 2.6.21-rc7-CFS-v3-g6262cd9f on x86_64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
