hpet on nforce4/MCP51 in asus a6t
Hello, I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24 32 bit the options acpi_use_timer_override and hpet=force, in this way and the timer IRQ ends up routed as IO-APIC-edge instead of XT-PIC. With acpi_use_timer_override I just get: TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 and it works through the IO-APIC. Instead the hpet is disabled and I just get : Time: acpi_pm clocksource has been installed. Clocksource tsc unstable (delta = -85010975 ns) Is possible to have hpet working also with if the BIOS doesn't support it ? I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. Cecco Tiscali.Fax: ricevi gratis sulla tua email e invii a 12 cent per pagina senza scatto alla risposta http://vas.tiscali.it/fax// -- 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/
hpet on nforce4/MCP51 in asus a6t
Hello, I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24 32 bit the options acpi_use_timer_override and hpet=force, in this way and the timer IRQ ends up routed as IO-APIC-edge instead of XT-PIC. With acpi_use_timer_override I just get: TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 and it works through the IO-APIC. Instead the hpet is disabled and I just get : Time: acpi_pm clocksource has been installed. Clocksource tsc unstable (delta = -85010975 ns) Is possible to have hpet working also with if the BIOS doesn't support it ? I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. Cecco Tiscali.Fax: ricevi gratis sulla tua email e invii a 12 cent per pagina senza scatto alla risposta http://vas.tiscali.it/fax// -- 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/
Guadagna con il tuo sito web
Ti piace l' idea di creare una rendita dal tuo sito web? E'possibile senza spese e senza rischi. Ci sono varie agenzie che ti forniscono infatti pubblicit� da inserire nel tuo sito e che ti pagano ogni volta che un utente compie una determinata azione (clicca sulla pubblicit�, o magari acquista o si registra presso il sito dell' inserzionista ). NON esiste solo ADSENSE ! leggi l'articolo intero qui <http://larecensione.com/guadagna-con-il-tuo-sito-webiscriviti-ora-e-ti-regaliamo-20-euro/> -- If you do not want to receive any more newsletters, http://dowebmarketing.com/mail/?p=unsubscribe=52b1b36bba467d31b4c9dd2d1fa4c4ba To update your preferences and to unsubscribe visit http://dowebmarketing.com/mail/?p=preferences=52b1b36bba467d31b4c9dd2d1fa4c4ba Forward a Message to Someone http://dowebmarketing.com/mail/?p=forward=52b1b36bba467d31b4c9dd2d1fa4c4ba=17 -- Powered by PHPlist, www.phplist.com -- -- 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/
Guadagna con il tuo sito web
Ti piace l' idea di creare una rendita dal tuo sito web? E'possibile senza spese e senza rischi. Ci sono varie agenzie che ti forniscono infatti pubblicit� da inserire nel tuo sito e che ti pagano ogni volta che un utente compie una determinata azione (clicca sulla pubblicit�, o magari acquista o si registra presso il sito dell' inserzionista ). NON esiste solo ADSENSE ! leggi l'articolo intero qui http://larecensione.com/guadagna-con-il-tuo-sito-webiscriviti-ora-e-ti-regaliamo-20-euro/ -- If you do not want to receive any more newsletters, http://dowebmarketing.com/mail/?p=unsubscribeuid=52b1b36bba467d31b4c9dd2d1fa4c4ba To update your preferences and to unsubscribe visit http://dowebmarketing.com/mail/?p=preferencesuid=52b1b36bba467d31b4c9dd2d1fa4c4ba Forward a Message to Someone http://dowebmarketing.com/mail/?p=forwarduid=52b1b36bba467d31b4c9dd2d1fa4c4bamid=17 -- Powered by PHPlist, www.phplist.com -- -- 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Len Brown ha scritto: On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote: have emerged lm_sensors but can't get it running - it keeps saying "No sensors found!" and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. In this case, getting sensors installed is the opposite of what you want to do. The idea is to simplify the system until it works, then figure out what simplification made it work. ie. disable sensors entirely by building a kernel with CONFIG_HWMON=n If that makes things work, then it is a clue. If that was disabled already, then just keep it disabled. It is disabled since when I abandoned the lm_sensors approach; I remember that I did some more testing with lm_sensors and got almost all chips identified, although didn't know how to use lm_sensors to generate some useful logs. I agree with you that we have to simplify the system down. Note: when I built kernel 2.6.24-rc3 to see if it is still affected by bug #9147, CONFIG_HWMON was enabled instead (and the problem was verified anyway). I don't recall how that setting got enabled, however I did not enable it manually and I was not enabling lm_sensors support. Best regards, -- Daniele C. cheers, -Len - 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/ - 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: Laptop keyboard unusable when ACPI is active
Len Brown ha scritto: On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote: It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). No, 8740 is not an ACPI issue. http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2 Sorry for the misleading statement; I no more think that it is an ACPI issue. Although I am still curious about the reason of these bugs happening together even on different hardware configurations; maybe a side effect of the same kernel bug? No idea. Best regards, -- Daniele C. -Len - 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/ - 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: Laptop keyboard unusable when ACPI is active
Len Brown ha scritto: On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote: It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). No, 8740 is not an ACPI issue. http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2 Sorry for the misleading statement; I no more think that it is an ACPI issue. Although I am still curious about the reason of these bugs happening together even on different hardware configurations; maybe a side effect of the same kernel bug? No idea. Best regards, -- Daniele C. -Len - 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/ - 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Len Brown ha scritto: On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote: have emerged lm_sensors but can't get it running - it keeps saying No sensors found! and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. In this case, getting sensors installed is the opposite of what you want to do. The idea is to simplify the system until it works, then figure out what simplification made it work. ie. disable sensors entirely by building a kernel with CONFIG_HWMON=n If that makes things work, then it is a clue. If that was disabled already, then just keep it disabled. It is disabled since when I abandoned the lm_sensors approach; I remember that I did some more testing with lm_sensors and got almost all chips identified, although didn't know how to use lm_sensors to generate some useful logs. I agree with you that we have to simplify the system down. Note: when I built kernel 2.6.24-rc3 to see if it is still affected by bug #9147, CONFIG_HWMON was enabled instead (and the problem was verified anyway). I don't recall how that setting got enabled, however I did not enable it manually and I was not enabling lm_sensors support. Best regards, -- Daniele C. cheers, -Len - 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/ - 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: Laptop keyboard unusable when ACPI is active
Hi all, some upates about this issue (see also bug 9147 http://bugzilla.kernel.org/show_bug.cgi?id=9147 ). The 'ac', 'battery' and 'thermal' modules (compiled as stand-alone) do cause the bug; it suffices that one of them (or any set of them) is loaded to trigger the bug either immediately or after some time. If none of them is loaded into memory, the bug does not happen. Also, the 'battery' module does not generate system messages although the problem is equally verified. The 'thermal' module instead, when loaded with 'modprobe thermal', causes the enter key pressed to execute the command to be indefinitively repeated into any terminal. This is currently a perfectly reproducible testcase for bug 9147. The bug has been confirmed by at least another user (with different hardware configuration); please reply for either bug addressing or confirmation. The current known best workaround to this bug is to compile all the above mentioned ACPI modules as stand-alone and to not (auto)load them (loosing their vital functionalities, since we are talking about laptops here, see http://gentoo-wiki.com/HARDWARE_Maxdata_Pro_7000_DX for an example of affected hardware). It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). Best regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - 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: Laptop keyboard unusable when ACPI is active
Hi all, some upates about this issue (see also bug 9147 http://bugzilla.kernel.org/show_bug.cgi?id=9147 ). The 'ac', 'battery' and 'thermal' modules (compiled as stand-alone) do cause the bug; it suffices that one of them (or any set of them) is loaded to trigger the bug either immediately or after some time. If none of them is loaded into memory, the bug does not happen. Also, the 'battery' module does not generate system messages although the problem is equally verified. The 'thermal' module instead, when loaded with 'modprobe thermal', causes the enter key pressed to execute the command to be indefinitively repeated into any terminal. This is currently a perfectly reproducible testcase for bug 9147. The bug has been confirmed by at least another user (with different hardware configuration); please reply for either bug addressing or confirmation. The current known best workaround to this bug is to compile all the above mentioned ACPI modules as stand-alone and to not (auto)load them (loosing their vital functionalities, since we are talking about laptops here, see http://gentoo-wiki.com/HARDWARE_Maxdata_Pro_7000_DX for an example of affected hardware). It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). Best regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - 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/
PROBLEM: IM Kernel Failure 12/11/07
This is the 5th attempt to email you! I keep being Greylisted! I've extracted the minimal info from a zip which may be failing. I've had to send it from my personal Tiscali account. Regards Martin [1.] One line summary of the problem: System crashed the night of Monday Nov 12 at 22:01 [2.] Full description of the problem/report: There is a cronjob at that time 00 22 * * * . /usr/local/bin/backup_RCP_CVSROOT.sh > /usr/local/bin/cvs_backup.log 2>&1 [3.] Keywords (i.e., modules, networking, kernel): kernel [4.] Kernel version (from /proc/version): Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb 11 00:09:01 EST 2004 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) NO OOPS'ES ! vi ./usr/src/linux-2.4.9-e.3/Documentation/oops-tracing.txt will investigate ... not ... intuitive at first read! [6.] A small shell script or example program which triggers the problem (if possible) N/A [7.] Environment Er ... a Dell box I think! [7.1.] Software (add the output of the ver_linux script here) [EMAIL PROTECTED] /]# sh ./usr/src/linux-2.4.9-e.3/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux pleco.investmaster.com 2.4.9-e.38smp #1 SMP Wed Feb 11 00:09:01 EST 2004 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.11.90.0.8 util-linux 2.11f mount 2.11g modutils 2.4.13 e2fsprogs 1.26 reiserfsprogs 3.x.0j PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded soundcore ide-tape lp parport sr_mod ide-cd cdrom sg esm autofs nfs lockd sunrpc ppp_async ppp_generic slhc tg3 ipchains st usb-ohci usbcore ext3 jbd aic7xxx sd_mod scsi_mod [7.2.] Processor information (from vi /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4757.91 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 [7.3.] Module information (from vi /proc/modules): soundcore 7940 0 (autoclean) ide-tape 61120 0 (autoclean) lp 8192 0 (autoclean) parport38144 0 (autoclean) [lp] sr_mod 17560 0 (autoclean) (unused) ide-cd 35296 0 (autoclean) cdrom 35520 0 (autoclean) [sr_mod ide-cd] sg 35076 0 (autoclean) esm84239
PROBLEM: IM Kernel Failure 12/11/07
This is the 5th attempt to email you! I keep being Greylisted! I've extracted the minimal info from a zip which may be failing. I've had to send it from my personal Tiscali account. Regards Martin [1.] One line summary of the problem: System crashed the night of Monday Nov 12 at 22:01 [2.] Full description of the problem/report: There is a cronjob at that time 00 22 * * * . /usr/local/bin/backup_RCP_CVSROOT.sh /usr/local/bin/cvs_backup.log 21 [3.] Keywords (i.e., modules, networking, kernel): kernel [4.] Kernel version (from /proc/version): Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb 11 00:09:01 EST 2004 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) NO OOPS'ES ! vi ./usr/src/linux-2.4.9-e.3/Documentation/oops-tracing.txt will investigate ... not ... intuitive at first read! [6.] A small shell script or example program which triggers the problem (if possible) N/A [7.] Environment Er ... a Dell box I think! [7.1.] Software (add the output of the ver_linux script here) [EMAIL PROTECTED] /]# sh ./usr/src/linux-2.4.9-e.3/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux pleco.investmaster.com 2.4.9-e.38smp #1 SMP Wed Feb 11 00:09:01 EST 2004 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.11.90.0.8 util-linux 2.11f mount 2.11g modutils 2.4.13 e2fsprogs 1.26 reiserfsprogs 3.x.0j PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded soundcore ide-tape lp parport sr_mod ide-cd cdrom sg esm autofs nfs lockd sunrpc ppp_async ppp_generic slhc tg3 ipchains st usb-ohci usbcore ext3 jbd aic7xxx sd_mod scsi_mod [7.2.] Processor information (from vi /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4757.91 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 [7.3.] Module information (from vi /proc/modules): soundcore 7940 0 (autoclean) ide-tape 61120 0 (autoclean) lp 8192 0 (autoclean) parport38144 0 (autoclean) [lp] sr_mod 17560 0 (autoclean) (unused) ide-cd 35296 0 (autoclean) cdrom 35520 0 (autoclean) [sr_mod ide-cd] sg 35076 0 (autoclean) esm84239 1 autofs 13796
Re: [PATCH] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. OK, that's fair. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). I agree. The problem is that Dell's DMI tables are not defined in the SMBIOS standard. Thus getting the parameters required for the backlight control (io port, io code, location) needs to be dealt with specifically. Plus DMI is not as comprehensively supported as ACPI is under Linux. I think reading Dell's tables to find out backlight parameters in kernelspace is possible. Unfortunately it would require a significant amount of brand new code to be written. And i'm not sure it is worth the effort. Libsmbios is big and complex because it is written in proficient C++ with lots of OO abstraction. It is also portable. But the task accomplished is simple in principle. jacopo - 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] backlight dimmer
Ok,
now checkpatch.pl only complains about a missing signed-off-by.
Is this ok for review?
jacopo
--- linux-2.6.23.1/include/linux/backlight.h2007-10-12 18:43:44.0
+0200
+++ b/include/linux/backlight.h 2007-10-28 21:14:21.0 +0100
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/* Notes on locking:
*
@@ -70,6 +71,12 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* dimmer stuff */
+ struct timeout *timeout;
+ struct input_handler *input_handler;
+ unsigned short dimmer_low_level;
+ unsigned short dimmer_high_level;
+
struct device dev;
};
--- linux-2.6.23.1/drivers/video/backlight/Makefile 2007-10-12
18:43:44.0 +0200
+++ b/drivers/video/backlight/Makefile 2007-10-28 16:42:09.0 +0100
@@ -1,7 +1,7 @@
# Backlight & LCD drivers
obj-$(CONFIG_LCD_CLASS_DEVICE) += lcd.o
-obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
+obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o timeout.o
obj-$(CONFIG_BACKLIGHT_CORGI) += corgi_bl.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
--- linux-2.6.23.1/include/linux/timeout.h 1970-01-01 01:00:00.0
+0100
+++ b/include/linux/timeout.h 2007-10-28 21:14:27.0 +0100
@@ -0,0 +1,68 @@
+/*
+ * timeout.h - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#ifndef _TIMEOUT_H_
+#define _TIMEOUT_H_
+
+#include
+#include
+#include
+
+enum timeout_state {
+ TIMEOUT_RUNNING,
+ TIMEOUT_TRIGGERED,
+ TIMEOUT_FINILIZED
+};
+
+struct timeout {
+ /* allow either start() or trigger() at a time */
+ struct mutex lock;
+ /* serialize updates to latest */
+ spinlock_t latest_lock;
+ struct delayed_work trigger_worker;
+ struct work_struct start_worker;
+ unsigned long latest;
+ enum timeout_state state;
+
+ unsigned long duration; /* client defined duration */
+ unsigned long data; /* client data */
+ void (*trigger)(unsigned long); /* client function */
+ void (*start)(unsigned long); /* client function */
+};
+
+extern void timeout_touch(struct timeout *timeout);
+
+extern void timeout_init(struct timeout *timeout);
+
+extern void timeout_kill(struct timeout *timeout);
+
+static inline int timeout_sec2jiffies(int secs)
+{
+ return secs * HZ;
+}
+
+static inline int timeout_jif2sec(unsigned long jif)
+{
+ return jif / HZ;
+}
+
+#endif
--- linux-2.6.23.1/drivers/video/backlight/timeout.c1970-01-01
01:00:00.0 +0100
+++ b/drivers/video/backlight/timeout.c 2007-10-28 21:18:09.0 +0100
@@ -0,0 +1,135 @@
+/*
+ * timeout.c - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+
+/* atomic context helpers for timeout->latest */
+static inline unsigned long read_latest(struct timeout *timeout)
+{
+ unsigned long ret;
+ spin_lock(>latest_lock);
+ ret = timeout->latest;
+ spin_unlock(>latest_lock);
+ return ret;
+}
+
+static inline unsigned long elapsed(struct timeout *timeout)
+{
+ unsigned long elapsed;
+ spin_lock(>latest_lock);
+ elapsed = jiffies - timeout->latest;
+ spin_unlock(>latest_lock);
+ return elapsed;
+}
+
+static inline void
Re: [PATCH] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). jacopo - 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] /drivers/ide/pci/piix.c kernel 2.6.23
In piix.c (and in ata_piix.c) are already included some patches to skip the
cable check on some laptops and to enable UDMA>33 modes, but I've noticed than
theese doesn't work on my Acer Aspire 5602WLMi (maybe exist more versions of
this laptop).
With this simple patch i can set transfert mode to UDMA100
--- linux-source-2.6.23/drivers/ide/pci/piix.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/ide/pci/piix.c 2007-10-25 22:25:53.0 +0200
@@ -405,6 +405,7 @@
static const struct ich_laptop ich_laptop[] = {
/* devid, subvendor, subdev */
+ { 0x27DF, 0x1025, 0x0102 }, /* ICH7 on Acer 5602aWLMi */
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
-
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] /drivers/ide/pci/piix.c kernel 2.6.23
In piix.c (and in ata_piix.c) are already included some patches to skip the
cable check on some laptops and to enable UDMA33 modes, but I've noticed than
theese doesn't work on my Acer Aspire 5602WLMi (maybe exist more versions of
this laptop).
With this simple patch i can set transfert mode to UDMA100
--- linux-source-2.6.23/drivers/ide/pci/piix.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/ide/pci/piix.c 2007-10-25 22:25:53.0 +0200
@@ -405,6 +405,7 @@
static const struct ich_laptop ich_laptop[] = {
/* devid, subvendor, subdev */
+ { 0x27DF, 0x1025, 0x0102 }, /* ICH7 on Acer 5602aWLMi */
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
-
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] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). jacopo - 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] backlight dimmer
Ok,
now checkpatch.pl only complains about a missing signed-off-by.
Is this ok for review?
jacopo
--- linux-2.6.23.1/include/linux/backlight.h2007-10-12 18:43:44.0
+0200
+++ b/include/linux/backlight.h 2007-10-28 21:14:21.0 +0100
@@ -11,6 +11,7 @@
#include linux/device.h
#include linux/mutex.h
#include linux/notifier.h
+#include linux/timeout.h
/* Notes on locking:
*
@@ -70,6 +71,12 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* dimmer stuff */
+ struct timeout *timeout;
+ struct input_handler *input_handler;
+ unsigned short dimmer_low_level;
+ unsigned short dimmer_high_level;
+
struct device dev;
};
--- linux-2.6.23.1/drivers/video/backlight/Makefile 2007-10-12
18:43:44.0 +0200
+++ b/drivers/video/backlight/Makefile 2007-10-28 16:42:09.0 +0100
@@ -1,7 +1,7 @@
# Backlight LCD drivers
obj-$(CONFIG_LCD_CLASS_DEVICE) += lcd.o
-obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
+obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o timeout.o
obj-$(CONFIG_BACKLIGHT_CORGI) += corgi_bl.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
--- linux-2.6.23.1/include/linux/timeout.h 1970-01-01 01:00:00.0
+0100
+++ b/include/linux/timeout.h 2007-10-28 21:14:27.0 +0100
@@ -0,0 +1,68 @@
+/*
+ * timeout.h - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#ifndef _TIMEOUT_H_
+#define _TIMEOUT_H_
+
+#include linux/workqueue.h
+#include linux/mutex.h
+#include linux/spinlock.h
+
+enum timeout_state {
+ TIMEOUT_RUNNING,
+ TIMEOUT_TRIGGERED,
+ TIMEOUT_FINILIZED
+};
+
+struct timeout {
+ /* allow either start() or trigger() at a time */
+ struct mutex lock;
+ /* serialize updates to latest */
+ spinlock_t latest_lock;
+ struct delayed_work trigger_worker;
+ struct work_struct start_worker;
+ unsigned long latest;
+ enum timeout_state state;
+
+ unsigned long duration; /* client defined duration */
+ unsigned long data; /* client data */
+ void (*trigger)(unsigned long); /* client function */
+ void (*start)(unsigned long); /* client function */
+};
+
+extern void timeout_touch(struct timeout *timeout);
+
+extern void timeout_init(struct timeout *timeout);
+
+extern void timeout_kill(struct timeout *timeout);
+
+static inline int timeout_sec2jiffies(int secs)
+{
+ return secs * HZ;
+}
+
+static inline int timeout_jif2sec(unsigned long jif)
+{
+ return jif / HZ;
+}
+
+#endif
--- linux-2.6.23.1/drivers/video/backlight/timeout.c1970-01-01
01:00:00.0 +0100
+++ b/drivers/video/backlight/timeout.c 2007-10-28 21:18:09.0 +0100
@@ -0,0 +1,135 @@
+/*
+ * timeout.c - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/timeout.h
+
+
+/* atomic context helpers for timeout-latest */
+static inline unsigned long read_latest(struct timeout *timeout)
+{
+ unsigned long ret;
+ spin_lock(timeout-latest_lock);
+ ret = timeout-latest;
+ spin_unlock(timeout-latest_lock);
+ return ret;
+}
+
+static inline unsigned long elapsed(struct timeout *timeout)
+{
+ unsigned long elapsed;
+ spin_lock(timeout-latest_lock
Re: [PATCH] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. OK, that's fair. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). I agree. The problem is that Dell's DMI tables are not defined in the SMBIOS standard. Thus getting the parameters required for the backlight control (io port, io code, location) needs to be dealt with specifically. Plus DMI is not as comprehensively supported as ACPI is under Linux. I think reading Dell's tables to find out backlight parameters in kernelspace is possible. Unfortunately it would require a significant amount of brand new code to be written. And i'm not sure it is worth the effort. Libsmbios is big and complex because it is written in proficient C++ with lots of OO abstraction. It is also portable. But the task accomplished is simple in principle. jacopo - 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! >> [EMAIL PROTECTED] ha scritto: >> >>> Kernel: 2.6.22-r5 >>> Kernel option: i8042.nomux=1 >>> >> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: >> >> i8042.nomux=1 acpi=off >> >> I have tried kernel 2.6.23-rc9 but the problem is still there. >> > Try usb keyboard. > The USB keyboard is not affected by the problem, and more importantly it has not the latencies in ACPI mode which the embedded PS2 keyboard has. > Try disabling lm_sensors. > lm_sensors was not installed at all. I have now enabled HWMON and other CONFIG_I2C_* kernel config parameters to use lm_sensors (without success). > Is it smp box? > It is not but from the sensors-detect's log seems like the motherboard supports it. Best regards, -- Daniele - 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! Hi! >>> Try disabling acpi embedded controller. >>> >>> >> How can I accomplish this? Are you referring to the i8042? >> > > rmmod acpi_ec or how is it called. But I'm not sure how easy this is. > My lsmod doesn't list any acpi module - but I have kacpid, kacpi_listen and hald-addon-acpi processes running. I have compiled the kernel with embedded ACPI support, not modular - maybe that's what you are talking about? > >>> Try watching keyboard interrupts. Are they lost? >>> >>> >> I am pretty sure they are. I think that ACPI pauses interrupts for a >> while (100ms?) and so some keyboard interrupts are lost. >> > input layer can poll keyboard on its own, perhaps that helps? > I am not yet very good at kernel hacking - however yes, it gives me more clues about identifying the issue (see also below link). > Can you try to measure the interrupt latencies? > I will try to do it myself, however somebody else the same problem of mine has already made the tests, please see http://dev.laptop.org/ticket/2401 > Does this happen in init=/bin/bash? > I will perform a test, however the problem rarely verifies in a VT console. I have tried both the kbd and keyboard drivers of X, without any difference. The keyboard problem happens a lot more when plugging in the battery (more ACPI traffic?). I have emerged lm_sensors but can't get it running - it keeps saying "No sensors found!" and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. Thank you, -- Daniele > Pavel > > # sensors-detect revision 4171 (2006-09-24 03:37:01 -0700) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no): Y Probing for PCI bus adapters... Use driver `i2c-i801' for device :00:1f.3: Intel 82801DB ICH4 We will now try to load each adapter module in turn. Module `i2c-i801' already loaded. If you have undetectable or unsupported adapters, you can have them scanned by manually loading the modules before running this script. We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case. If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed. Next adapter: SMBus I801 adapter at 1880 Do you want to scan it? (YES/no/selectively): Y Client found at address 0x08 Client found at address 0x1a Probing for `Analog Devices ADM1021'... No Probing for `Analog Devices ADM1021A/ADM1023'...No Probing for `Maxim MAX1617'... No Probing for `Maxim MAX1617A'... No Probing for `TI THMC10'... No Probing for `National Semiconductor LM84'...No Probing for `Genesys Logic GL523SM'... No Probing for `Onsemi MC1066'... No Probing for `Maxim MAX1619'... No Probing for `National Semiconductor LM82/LM83'... No Probing for `Philips Semiconductors PCA9556'... No Client found at address 0x44 Probing for `Maxim MAX6633/MAX6634/MAX6635'... No Client found at address 0x51 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x57 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x69 Some chips are also accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Y Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Probing for `Winbond W83627HF' at 0x290... No Probing for `Silicon Integrated Systems SIS5595'... No Probing for `VIA VT82C686 Integrated Sensors'...No Probing for `VIA VT8231 Integrated Sensors'... No Probing for `AMD K8 thermal sensors'... No Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some Super I/O chips may also contain sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to
Re: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: Hi! Hi! Try disabling acpi embedded controller. How can I accomplish this? Are you referring to the i8042? rmmod acpi_ec or how is it called. But I'm not sure how easy this is. My lsmod doesn't list any acpi module - but I have kacpid, kacpi_listen and hald-addon-acpi processes running. I have compiled the kernel with embedded ACPI support, not modular - maybe that's what you are talking about? Try watching keyboard interrupts. Are they lost? I am pretty sure they are. I think that ACPI pauses interrupts for a while (100ms?) and so some keyboard interrupts are lost. input layer can poll keyboard on its own, perhaps that helps? I am not yet very good at kernel hacking - however yes, it gives me more clues about identifying the issue (see also below link). Can you try to measure the interrupt latencies? I will try to do it myself, however somebody else the same problem of mine has already made the tests, please see http://dev.laptop.org/ticket/2401 Does this happen in init=/bin/bash? I will perform a test, however the problem rarely verifies in a VT console. I have tried both the kbd and keyboard drivers of X, without any difference. The keyboard problem happens a lot more when plugging in the battery (more ACPI traffic?). I have emerged lm_sensors but can't get it running - it keeps saying No sensors found! and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. Thank you, -- Daniele Pavel # sensors-detect revision 4171 (2006-09-24 03:37:01 -0700) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no): Y Probing for PCI bus adapters... Use driver `i2c-i801' for device :00:1f.3: Intel 82801DB ICH4 We will now try to load each adapter module in turn. Module `i2c-i801' already loaded. If you have undetectable or unsupported adapters, you can have them scanned by manually loading the modules before running this script. We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case. If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed. Next adapter: SMBus I801 adapter at 1880 Do you want to scan it? (YES/no/selectively): Y Client found at address 0x08 Client found at address 0x1a Probing for `Analog Devices ADM1021'... No Probing for `Analog Devices ADM1021A/ADM1023'...No Probing for `Maxim MAX1617'... No Probing for `Maxim MAX1617A'... No Probing for `TI THMC10'... No Probing for `National Semiconductor LM84'...No Probing for `Genesys Logic GL523SM'... No Probing for `Onsemi MC1066'... No Probing for `Maxim MAX1619'... No Probing for `National Semiconductor LM82/LM83'... No Probing for `Philips Semiconductors PCA9556'... No Client found at address 0x44 Probing for `Maxim MAX6633/MAX6634/MAX6635'... No Client found at address 0x51 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x57 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x69 Some chips are also accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Y Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Probing for `Winbond W83627HF' at 0x290... No Probing for `Silicon Integrated Systems SIS5595'... No Probing for `VIA VT82C686 Integrated Sensors'...No Probing for `VIA VT8231 Integrated Sensors'... No Probing for `AMD K8 thermal sensors'... No Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some Super I/O chips may also contain sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): Y
Re: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: Hi! [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. Try usb keyboard. The USB keyboard is not affected by the problem, and more importantly it has not the latencies in ACPI mode which the embedded PS2 keyboard has. Try disabling lm_sensors. lm_sensors was not installed at all. I have now enabled HWMON and other CONFIG_I2C_* kernel config parameters to use lm_sensors (without success). Is it smp box? It is not but from the sensors-detect's log seems like the motherboard supports it. Best regards, -- Daniele - 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! > Hi! Finally an answer, thank you. >> [EMAIL PROTECTED] ha scritto: >> >>> Kernel: 2.6.22-r5 >>> Kernel option: i8042.nomux=1 >>> >> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: >> >> i8042.nomux=1 acpi=off >> >> I have tried kernel 2.6.23-rc9 but the problem is still there. >> > > Try usb keyboard. > I will get one within 24 hours. > Are you experiencing unusually high latencies in acpi mode? > Yes. > Any unusual activity on top? > Xorg with XFCE4 - it even happens opening up a mousepad and typing something in it. I do not have particular services running, I have apache, mysql and samba. I have installed it on July, so it's a pretty new system - the problem didn't happen before the most recent kernels. > Try disabling lm_sensors. > I will and report here. > Try disabling acpi embedded controller. > How can I accomplish this? Are you referring to the i8042? > Is it smp box? > It is a laptop (Maxdata Pro 7000 DX) with an Intel Centrino 1.6 GhZ (pentium-m), so it is not. > Try watching keyboard interrupts. Are they lost? > I am pretty sure they are. I think that ACPI pauses interrupts for a while (100ms?) and so some keyboard interrupts are lost. See also http://bugzilla.kernel.org/show_bug.cgi?id=9147 I will come up with a test for lm_sensors and the USB keyboard as soon as possible. Thank you very much -- Daniele > Pavel > - 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: Hi! Hi! Finally an answer, thank you. [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. Try usb keyboard. I will get one within 24 hours. Are you experiencing unusually high latencies in acpi mode? Yes. Any unusual activity on top? Xorg with XFCE4 - it even happens opening up a mousepad and typing something in it. I do not have particular services running, I have apache, mysql and samba. I have installed it on July, so it's a pretty new system - the problem didn't happen before the most recent kernels. Try disabling lm_sensors. I will and report here. Try disabling acpi embedded controller. How can I accomplish this? Are you referring to the i8042? Is it smp box? It is a laptop (Maxdata Pro 7000 DX) with an Intel Centrino 1.6 GhZ (pentium-m), so it is not. Try watching keyboard interrupts. Are they lost? I am pretty sure they are. I think that ACPI pauses interrupts for a while (100ms?) and so some keyboard interrupts are lost. See also http://bugzilla.kernel.org/show_bug.cgi?id=9147 I will come up with a test for lm_sensors and the USB keyboard as soon as possible. Thank you very much -- Daniele Pavel - 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: [irda-users] [PATCH] irlmp_unregister_link needs to free lsaps hashbin
Samuel Ortiz wrote: > Hi Hinko, > > On Fri, Oct 12, 2007 at 02:56:27PM +0200, [EMAIL PROTECTED] wrote: >> Hi, >> >> While testing the mcs7780 based IrDA USB dongle I've stumbled upon >> memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in >> irlmp_register_link and should probably be freed in irlmp_unregister_link(). >> >> Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> >> >> Best regards, >> Hinko >> >> >> >> > >> --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 >> +0200 >> +++ linux-2.6.23/net/irda/irlmp.c2007-10-12 14:05:41.0 +0200 >> @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) >> /* Final cleanup */ >> del_timer(>idle_timer); >> link->magic = 0; >> +hashbin_delete(link->lsaps, (FREE_FUNC) kfree); > Good catch, but I think the right fix sould be: > + hashbin_delete(link->lsaps, (FREE_FUNC) __irlmp_close_lsap); > You're probably right since struct lsap_cb get inserted into the hashbin. Regards, Hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - 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: [irda-users] [PATCH] irlmp_unregister_link needs to free lsaps hashbin
Samuel Ortiz wrote: Hi Hinko, On Fri, Oct 12, 2007 at 02:56:27PM +0200, [EMAIL PROTECTED] wrote: Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in irlmp_register_link and should probably be freed in irlmp_unregister_link(). Signed-off-by: Hinko Kocevar [EMAIL PROTECTED] Best regards, Hinko --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 +0200 +++ linux-2.6.23/net/irda/irlmp.c2007-10-12 14:05:41.0 +0200 @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) /* Final cleanup */ del_timer(link-idle_timer); link-magic = 0; +hashbin_delete(link-lsaps, (FREE_FUNC) kfree); Good catch, but I think the right fix sould be: + hashbin_delete(link-lsaps, (FREE_FUNC) __irlmp_close_lsap); You're probably right since struct lsap_cb get inserted into the hashbin. Regards, Hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - 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] mcs7780 needs to free allocated rx buffer
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in mcs_net_close(). Patch below fixes it. Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> Best regards, Hinko --- linux-2.6.23/drivers/net/irda/mcs7780.c.orig2007-10-12 14:02:55.0 +0200 +++ linux-2.6.23/drivers/net/irda/mcs7780.c 2007-10-12 14:05:03.0 +0200 @@ -678,6 +678,8 @@ static int mcs_net_close(struct net_devi /* Stop transmit processing */ netif_stop_queue(netdev); + kfree_skb(mcs->rx_buff.skb); + /* kill and free the receive and transmit URBs */ usb_kill_urb(mcs->rx_urb); usb_free_urb(mcs->rx_urb);
[PATCH] irlmp_unregister_link needs to free lsaps hashbin
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in irlmp_register_link and should probably be freed in irlmp_unregister_link(). Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> Best regards, Hinko --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 +0200 +++ linux-2.6.23/net/irda/irlmp.c 2007-10-12 14:05:41.0 +0200 @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) /* Final cleanup */ del_timer(>idle_timer); link->magic = 0; + hashbin_delete(link->lsaps, (FREE_FUNC) kfree); kfree(link); } }
Re: Laptop keyboard unusable when ACPI is active
I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: > [EMAIL PROTECTED] ha scritto: > >> Kernel: 2.6.22-r5 >> Kernel option: i8042.nomux=1 >> > I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: > > i8042.nomux=1 acpi=off > > I have tried kernel 2.6.23-rc9 but the problem is still there. > > >> The problem which still remains, and I can't fix or work it around, is >> witnessed by the below dmesg lines: >> - >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> - >> The release event for some keys is never caught, so all sorts of >> troubles happen if for example I use the Del key and it stucks, or if >> I use the Ctrl key and it never gets released...pushing again the >> stuck key brings back the key in the proper status. >> > With acpi=off the problem is totally worked around. > > >> Can somebody please give me some clues about this issue, and possible >> solutions? I have been searching the web for a couple of weeks and >> seems like it is a common trouble of notebook users, but nobody has >> yet published a solution. >> > I am trying to find a path myself in this issue - which dates back to at > least 2005 and has never been resolved. > > I would now try some other kernel parameter in order to preserve ACPI > functionality and possibly prevent ACPI from messing up the keyboard IRQs. > Can somebody please give me istructions regarding the correct tests > (regarding kernel parameters and/or anything else) to perform in order > to better isolate the issue? > > Related Gentoo bug tracker item: > http://bugs.gentoo.org/show_bug.cgi?id=194781 > > Other messages about the same kernel bug (many more can be found > googling around, and no solution yet): > https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html > http://dev.laptop.org/ticket/2401 > > Regards, > -- > Daniele C. > > - > 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/ > > - 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] mcs7780 needs to free allocated rx buffer
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in mcs_net_close(). Patch below fixes it. Signed-off-by: Hinko Kocevar [EMAIL PROTECTED] Best regards, Hinko --- linux-2.6.23/drivers/net/irda/mcs7780.c.orig2007-10-12 14:02:55.0 +0200 +++ linux-2.6.23/drivers/net/irda/mcs7780.c 2007-10-12 14:05:03.0 +0200 @@ -678,6 +678,8 @@ static int mcs_net_close(struct net_devi /* Stop transmit processing */ netif_stop_queue(netdev); + kfree_skb(mcs-rx_buff.skb); + /* kill and free the receive and transmit URBs */ usb_kill_urb(mcs-rx_urb); usb_free_urb(mcs-rx_urb);
[PATCH] irlmp_unregister_link needs to free lsaps hashbin
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in irlmp_register_link and should probably be freed in irlmp_unregister_link(). Signed-off-by: Hinko Kocevar [EMAIL PROTECTED] Best regards, Hinko --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 +0200 +++ linux-2.6.23/net/irda/irlmp.c 2007-10-12 14:05:41.0 +0200 @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) /* Final cleanup */ del_timer(link-idle_timer); link-magic = 0; + hashbin_delete(link-lsaps, (FREE_FUNC) kfree); kfree(link); } }
Re: Laptop keyboard unusable when ACPI is active
I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - 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/ - 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/
Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
[EMAIL PROTECTED] ha scritto: > Kernel: 2.6.22-r5 > Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. > The problem which still remains, and I can't fix or work it around, is > witnessed by the below dmesg lines: > - > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > - > The release event for some keys is never caught, so all sorts of > troubles happen if for example I use the Del key and it stucks, or if > I use the Ctrl key and it never gets released...pushing again the > stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. > Can somebody please give me some clues about this issue, and possible > solutions? I have been searching the web for a couple of weeks and > seems like it is a common trouble of notebook users, but nobody has > yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - 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/
Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
[EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - 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] softdog - panic instead of reboot, kernel 2.6.22.9
>From Ken Sugawara <[EMAIL PROTECTED]>
Description: Add an option to softdog to panic upon timer expiration
instead of reboot.
Signed-off-by: Ken Sugawara <[EMAIL PROTECTED]>
---
This patch is intended to help increase the chance of postmortem
analysis in the event of silent system hang where it is impossible to
initiate crash dump manually (e.g. no console or network response).
We've had occasions where some of our customers had silent system hang
problems in which they were unable to obtain vmcore for root cause
analysis. Provided that timer interrupts are not blocked, this patch
might enable them to get a crash dump in such a situation by activating
softdog.
--- linux-2.6.22.9/drivers/char/watchdog/softdog.c.orig 2007-09-27
03:03:01.0 +0900
+++ linux-2.6.22.9/drivers/char/watchdog/softdog.c 2007-10-04
12:06:28.0 +0900
@@ -49,6 +49,7 @@
#include
#include
+#include
#define PFX "SoftDog: "
@@ -70,6 +71,11 @@ static int soft_noboot = 0;
module_param(soft_noboot, int, 0);
MODULE_PARM_DESC(soft_noboot, "Softdog action, set to 1 to ignore reboots, 0
to reboot (default depends on ONLY_TESTING)");
+static int panic_instead = 0;
+
+module_param(panic_instead, int, 0);
+MODULE_PARM_DESC(panic_instead, "Softdog action, set to 1 to panic instead of
reboot, 0 to reboot (default 0)");
+
/*
* Our timer
*/
@@ -93,8 +99,11 @@ static void watchdog_fire(unsigned long
if (soft_noboot)
printk(KERN_CRIT PFX "Triggered - Reboot ignored.\n");
- else
- {
+ else if (panic_instead) {
+ printk(KERN_CRIT PFX "Initiating panic.\n");
+ panic("Watchdog timer expired.");
+ printk(KERN_CRIT PFX "Panic didn't ?\n");
+ } else {
printk(KERN_CRIT PFX "Initiating system reboot.\n");
emergency_restart();
printk(KERN_CRIT PFX "Reboot didn't ?\n");
@@ -262,7 +271,7 @@ static struct notifier_block softdog_not
.notifier_call = softdog_notify_sys,
};
-static char banner[] __initdata = KERN_INFO "Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec (nowayout= %d)\n";
+static char banner[] __initdata = KERN_INFO "Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec panic_instead=%d (nowayout=
%d)\n";
static int __init watchdog_init(void)
{
@@ -290,7 +299,7 @@ static int __init watchdog_init(void)
return ret;
}
- printk(banner, soft_noboot, soft_margin, nowayout);
+ printk(banner, soft_noboot, soft_margin, panic_instead, nowayout);
return 0;
}
-
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] softdog - panic instead of reboot, kernel 2.6.22.9
From Ken Sugawara [EMAIL PROTECTED]
Description: Add an option to softdog to panic upon timer expiration
instead of reboot.
Signed-off-by: Ken Sugawara [EMAIL PROTECTED]
---
This patch is intended to help increase the chance of postmortem
analysis in the event of silent system hang where it is impossible to
initiate crash dump manually (e.g. no console or network response).
We've had occasions where some of our customers had silent system hang
problems in which they were unable to obtain vmcore for root cause
analysis. Provided that timer interrupts are not blocked, this patch
might enable them to get a crash dump in such a situation by activating
softdog.
--- linux-2.6.22.9/drivers/char/watchdog/softdog.c.orig 2007-09-27
03:03:01.0 +0900
+++ linux-2.6.22.9/drivers/char/watchdog/softdog.c 2007-10-04
12:06:28.0 +0900
@@ -49,6 +49,7 @@
#include linux/jiffies.h
#include asm/uaccess.h
+#include linux/kernel.h
#define PFX SoftDog:
@@ -70,6 +71,11 @@ static int soft_noboot = 0;
module_param(soft_noboot, int, 0);
MODULE_PARM_DESC(soft_noboot, Softdog action, set to 1 to ignore reboots, 0
to reboot (default depends on ONLY_TESTING));
+static int panic_instead = 0;
+
+module_param(panic_instead, int, 0);
+MODULE_PARM_DESC(panic_instead, Softdog action, set to 1 to panic instead of
reboot, 0 to reboot (default 0));
+
/*
* Our timer
*/
@@ -93,8 +99,11 @@ static void watchdog_fire(unsigned long
if (soft_noboot)
printk(KERN_CRIT PFX Triggered - Reboot ignored.\n);
- else
- {
+ else if (panic_instead) {
+ printk(KERN_CRIT PFX Initiating panic.\n);
+ panic(Watchdog timer expired.);
+ printk(KERN_CRIT PFX Panic didn't ?\n);
+ } else {
printk(KERN_CRIT PFX Initiating system reboot.\n);
emergency_restart();
printk(KERN_CRIT PFX Reboot didn't ?\n);
@@ -262,7 +271,7 @@ static struct notifier_block softdog_not
.notifier_call = softdog_notify_sys,
};
-static char banner[] __initdata = KERN_INFO Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec (nowayout= %d)\n;
+static char banner[] __initdata = KERN_INFO Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec panic_instead=%d (nowayout=
%d)\n;
static int __init watchdog_init(void)
{
@@ -290,7 +299,7 @@ static int __init watchdog_init(void)
return ret;
}
- printk(banner, soft_noboot, soft_margin, nowayout);
+ printk(banner, soft_noboot, soft_margin, panic_instead, nowayout);
return 0;
}
-
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/
[2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 See attached full dmesg for more. I have recently updated my kernel to 2.6.22 and - in the same occasion - changed various options in the kernel .config; I cannot state that the problem have arisen since kernel 2.6.22 but more probably since I enabled ACPI. My recent configuration changes have been also to xorg.conf (regarding GLX and AIGLX), but I have no real clue about what is causing the troubles. It must be a particular combination of kernel options which triggers this faulty scenario. The first problem I had to solve was about the mouse, not working properly: - psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. - I fixed it adding i8042.nomux=1 in the kernel options. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. I could not find a pattern for the verification of the problem, it seems to happen at random. I /feel/ that this is still an i8042/ACPI chipset issue (note that I have ipw2100 active when the problem happens; the mouse problem did not happen when ipw2100 was disabled and I think the psmouse.c lines and atkbd.c are someway related). Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. Thanks, -- Daniele C. Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #4 SMP Wed Sep 12 19:07:11 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1f6e (usable) BIOS-e820: 1f6e - 1f6eb000 (ACPI data) BIOS-e820: 1f6eb000 - 1f70 (ACPI NVS) BIOS-e820: 1f70 - 2000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) 0MB HIGHMEM available. 502MB LOWMEM available. Entering add_active_range(0, 0, 128736) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 128736 HighMem128736 -> 128736 early_node_map[1] active PFN ranges 0:0 -> 128736 On node 0 totalpages: 128736 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 973 pages used for memmap Normal zone: 123667 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6700, 0014 (r0 PTLTD ) ACPI: RSDT 1F6E6557, 0030 (r1 PTLTD Montara 604 LTP0) ACPI: FACP 1F6EAED2, 0074 (r1 INTEL MONTARAG 604 PTL50) ACPI: DSDT 1F6E6A68, 446A (r1 INTEL MONTARAG 604 MSFT 10E) ACPI: FACS 1F6FBFC0, 0040 ACPI: BOOT 1F6EAFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 1F6E6587, 04D9 (r1 INTELGV3Ref 1001 MSFT 10E) ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 3000 (gap: 2000:dec1) Built 1 zonelists. Total pages: 127731 Kernel command line: root=/dev/hda3 vga=0x318 i8042.nomux=1 console=tty1 Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (013fd000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0558000 soft=c0538000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected
[2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 See attached full dmesg for more. I have recently updated my kernel to 2.6.22 and - in the same occasion - changed various options in the kernel .config; I cannot state that the problem have arisen since kernel 2.6.22 but more probably since I enabled ACPI. My recent configuration changes have been also to xorg.conf (regarding GLX and AIGLX), but I have no real clue about what is causing the troubles. It must be a particular combination of kernel options which triggers this faulty scenario. The first problem I had to solve was about the mouse, not working properly: - psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. - I fixed it adding i8042.nomux=1 in the kernel options. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. I could not find a pattern for the verification of the problem, it seems to happen at random. I /feel/ that this is still an i8042/ACPI chipset issue (note that I have ipw2100 active when the problem happens; the mouse problem did not happen when ipw2100 was disabled and I think the psmouse.c lines and atkbd.c are someway related). Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. Thanks, -- Daniele C. Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #4 SMP Wed Sep 12 19:07:11 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1f6e (usable) BIOS-e820: 1f6e - 1f6eb000 (ACPI data) BIOS-e820: 1f6eb000 - 1f70 (ACPI NVS) BIOS-e820: 1f70 - 2000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) 0MB HIGHMEM available. 502MB LOWMEM available. Entering add_active_range(0, 0, 128736) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 128736 HighMem128736 - 128736 early_node_map[1] active PFN ranges 0:0 - 128736 On node 0 totalpages: 128736 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 973 pages used for memmap Normal zone: 123667 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6700, 0014 (r0 PTLTD ) ACPI: RSDT 1F6E6557, 0030 (r1 PTLTD Montara 604 LTP0) ACPI: FACP 1F6EAED2, 0074 (r1 INTEL MONTARAG 604 PTL50) ACPI: DSDT 1F6E6A68, 446A (r1 INTEL MONTARAG 604 MSFT 10E) ACPI: FACS 1F6FBFC0, 0040 ACPI: BOOT 1F6EAFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 1F6E6587, 04D9 (r1 INTELGV3Ref 1001 MSFT 10E) ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 3000 (gap: 2000:dec1) Built 1 zonelists. Total pages: 127731 Kernel command line: root=/dev/hda3 vga=0x318 i8042.nomux=1 console=tty1 Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (013fd000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0558000 soft=c0538000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1599.891
[no subject]
- 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/
[no subject]
- 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]hpet and rtc max_user_freq predefine in Kconfig
I think users should be able to set max_user_freq values for rtc and hpet during kernel configuration. The default value is set to 1024 with this patch. The default value of 64 is really too small for modern multimedia apps. Besides, this patch fixes link on intel hpet spec. Signed-off-by: Milinevsky Dmitry <[EMAIL PROTECTED]> diff -Nupar linux-2.6.22-cfs-19/drivers/char/hpet.c linux-2.6.22-cfs-19.niam/drivers/char/hpet.c --- linux-2.6.22-cfs-19/drivers/char/hpet.c 2007-07-10 20:57:20.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/hpet.c2007-08-02 01:34:54.0 +0300 @@ -44,9 +44,9 @@ /* * The High Precision Event Timer driver. * This driver is closely modelled after the rtc.c driver. - * http://www.intel.com/hardwaredesign/hpetspec.htm + * http://www.intel.com/technology/architecture/hpetspec.htm */ -#defineHPET_USER_FREQ (64) +#defineHPET_USER_FREQ (CONFIG_HPET_MAX_USER_FREQ) #defineHPET_DRIFT (500) #define HPET_RANGE_SIZE1024/* from HPET spec */ diff -Nupar linux-2.6.22-cfs-19/drivers/char/Kconfig linux-2.6.22-cfs-19.niam/drivers/char/Kconfig --- linux-2.6.22-cfs-19/drivers/char/Kconfig2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/Kconfig 2007-08-02 01:33:33.0 +0300 @@ -791,6 +791,13 @@ config RTC To compile this driver as a module, choose M here: the module will be called rtc. +config RTC_MAX_USER_FREQ + int "User interrupt frequency" + depends on RTC + default "1024" + help + Default value of user interrupt frequency(/proc/sys/dev/rtc/max-user-freq). + config SGI_DS1286 tristate "SGI DS1286 RTC support" depends on SGI_IP22 @@ -1022,6 +1029,13 @@ config HPET open selects one of the timers supported by the HPET. The timers are non-periodic and/or periodic. +config HPET_MAX_USER_FREQ + int "User interrupt frequency" + depends on HPET + default "1024" + help + Default value of user interrupt frequency(/proc/sys/dev/hpet/max-user-freq). + config HPET_RTC_IRQ bool "HPET Control RTC IRQ" if !HPET_EMULATE_RTC default n diff -Nupar linux-2.6.22-cfs-19/drivers/char/rtc.c linux-2.6.22-cfs-19.niam/drivers/char/rtc.c --- linux-2.6.22-cfs-19/drivers/char/rtc.c 2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/rtc.c 2007-08-02 01:33:48.0 +0300 @@ -191,7 +191,7 @@ static int rtc_proc_open(struct inode *i static unsigned long rtc_status = 0; /* bitmapped status byte. */ static unsigned long rtc_freq = 0; /* Current periodic IRQ rate*/ static unsigned long rtc_irq_data = 0; /* our output to the world */ -static unsigned long rtc_max_user_freq = 64; /* > this, need CAP_SYS_RESOURCE */ +static unsigned long rtc_max_user_freq = CONFIG_RTC_MAX_USER_FREQ; /* > this, need CAP_SYS_RESOURCE */ #ifdef RTC_IRQ /* - 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]hpet and rtc max_user_freq predefine in Kconfig
I think users should be able to set max_user_freq values for rtc and hpet during kernel configuration. The default value is set to 1024 with this patch. The default value of 64 is really too small for modern multimedia apps. Besides, this patch fixes link on intel hpet spec. Signed-off-by: Milinevsky Dmitry [EMAIL PROTECTED] diff -Nupar linux-2.6.22-cfs-19/drivers/char/hpet.c linux-2.6.22-cfs-19.niam/drivers/char/hpet.c --- linux-2.6.22-cfs-19/drivers/char/hpet.c 2007-07-10 20:57:20.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/hpet.c2007-08-02 01:34:54.0 +0300 @@ -44,9 +44,9 @@ /* * The High Precision Event Timer driver. * This driver is closely modelled after the rtc.c driver. - * http://www.intel.com/hardwaredesign/hpetspec.htm + * http://www.intel.com/technology/architecture/hpetspec.htm */ -#defineHPET_USER_FREQ (64) +#defineHPET_USER_FREQ (CONFIG_HPET_MAX_USER_FREQ) #defineHPET_DRIFT (500) #define HPET_RANGE_SIZE1024/* from HPET spec */ diff -Nupar linux-2.6.22-cfs-19/drivers/char/Kconfig linux-2.6.22-cfs-19.niam/drivers/char/Kconfig --- linux-2.6.22-cfs-19/drivers/char/Kconfig2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/Kconfig 2007-08-02 01:33:33.0 +0300 @@ -791,6 +791,13 @@ config RTC To compile this driver as a module, choose M here: the module will be called rtc. +config RTC_MAX_USER_FREQ + int User interrupt frequency + depends on RTC + default 1024 + help + Default value of user interrupt frequency(/proc/sys/dev/rtc/max-user-freq). + config SGI_DS1286 tristate SGI DS1286 RTC support depends on SGI_IP22 @@ -1022,6 +1029,13 @@ config HPET open selects one of the timers supported by the HPET. The timers are non-periodic and/or periodic. +config HPET_MAX_USER_FREQ + int User interrupt frequency + depends on HPET + default 1024 + help + Default value of user interrupt frequency(/proc/sys/dev/hpet/max-user-freq). + config HPET_RTC_IRQ bool HPET Control RTC IRQ if !HPET_EMULATE_RTC default n diff -Nupar linux-2.6.22-cfs-19/drivers/char/rtc.c linux-2.6.22-cfs-19.niam/drivers/char/rtc.c --- linux-2.6.22-cfs-19/drivers/char/rtc.c 2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/rtc.c 2007-08-02 01:33:48.0 +0300 @@ -191,7 +191,7 @@ static int rtc_proc_open(struct inode *i static unsigned long rtc_status = 0; /* bitmapped status byte. */ static unsigned long rtc_freq = 0; /* Current periodic IRQ rate*/ static unsigned long rtc_irq_data = 0; /* our output to the world */ -static unsigned long rtc_max_user_freq = 64; /* this, need CAP_SYS_RESOURCE */ +static unsigned long rtc_max_user_freq = CONFIG_RTC_MAX_USER_FREQ; /* this, need CAP_SYS_RESOURCE */ #ifdef RTC_IRQ /* - 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: sound is interrupting with new kernels
On 7/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > could you try CONFIG_HZ_1000 instead of the 250 you are using currently? > Also, please enable CONFIG_SCHED_DEBUG to improve the output of > cfs-debug-info.sh. > > Ingo > Hi, Igno. Sorry for so long response, I hadn't opportunity to reboot machine for new kernel. I've built 2.6.22 with CONFIG_HZ_1000 and CONFIG_PREEMPT - nothing changed =(. Interesting that in Totem(Gnome vp) sound isn't interrupting during video watching. I'll try other kernels later to find out what is working good for my case. In gxine(xine-based) sound is interrupting too! >firstly, could you check whether the ogg123/mpg321 console apps work >without any audio skipping? If they work fine, does Amarok work fine? >(Amarok is an X apps that has a high-quality latency design - most other >X based players are affected by X communication latencies.) I'm not using amarok but audacious. It's seems that's everything is alright with it. I'll send more tests results later. Best wishes! Dima - 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: sound is interrupting with new kernels
On 7/23/07, Ingo Molnar [EMAIL PROTECTED] wrote: could you try CONFIG_HZ_1000 instead of the 250 you are using currently? Also, please enable CONFIG_SCHED_DEBUG to improve the output of cfs-debug-info.sh. Ingo Hi, Igno. Sorry for so long response, I hadn't opportunity to reboot machine for new kernel. I've built 2.6.22 with CONFIG_HZ_1000 and CONFIG_PREEMPT - nothing changed =(. Interesting that in Totem(Gnome vp) sound isn't interrupting during video watching. I'll try other kernels later to find out what is working good for my case. In gxine(xine-based) sound is interrupting too! firstly, could you check whether the ogg123/mpg321 console apps work without any audio skipping? If they work fine, does Amarok work fine? (Amarok is an X apps that has a high-quality latency design - most other X based players are affected by X communication latencies.) I'm not using amarok but audacious. It's seems that's everything is alright with it. I'll send more tests results later. Best wishes! Dima - 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: sound is interrupting with new kernels
Hi! Please run this script while using mplayer or audacious http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh No need. I'm testing now pure 2.6.22: my uname is 'Linux niam 2.6.22 #2 Sun Jul 22 13:52:03 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux' and I have described problems with mplayer, but they are not so hard: sound is interrupting for much less time! Usually this case occurs after pause in watching the movie ... for the first time sound is interrupting and then normal flow is restoring. I'll try 2.6.20 later and I'll send a report! Best wishes! - 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: sound is interrupting with new kernels
Hi! Please run this script while using mplayer or audacious http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh No need. I'm testing now pure 2.6.22: my uname is 'Linux niam 2.6.22 #2 Sun Jul 22 13:52:03 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux' and I have described problems with mplayer, but they are not so hard: sound is interrupting for much less time! Usually this case occurs after pause in watching the movie ... for the first time sound is interrupting and then normal flow is restoring. I'll try 2.6.20 later and I'll send a report! Best wishes! - 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/
ck1 patches for 2.6.22 and 2.6.20
Hi! I'm not happy with 2.6.22 stability so I want to stay on 2.6.20. Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's better to backport -ck1 for 2.6.22 to 2.6.20? Thanks for your time! Best regards, Dmitry Milinevsky. - 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/
ck1 patches for 2.6.22 and 2.6.20
Hi! I'm not happy with 2.6.22 stability so I want to stay on 2.6.20. Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's better to backport -ck1 for 2.6.22 to 2.6.20? Thanks for your time! Best regards, Dmitry Milinevsky. - 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/
Fwd: performance -cfs19 vs. -ck1 for 2.6.22
to help us figure out the nature of the delay, could you do another thing as well: strace -ttt -TTT -f -o firefox.trace.txt -p `pidof firefox-bin` I'll do that!! - 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: performance -cfs19 vs. -ck1 for 2.6.22
Hi, Ingo! Could you run the following script: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh I'll do that! But a little bit later - I have tested that on my home computer. hm, is there no other workload on the system? Workload: firefox, transmission(torrent client), gnome terminal, music player. Now I think it could be not a scheduler issue but network subsystem ... but I've got such situation on previous kernels and w/o torrent client running. The problem is not in switching tabs in firefox but in _opening_new_url_. I'm not good in Con's patches but are they touching network subsystem? - 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/
performance -cfs19 vs. -ck1 for 2.6.22
Hi, I haven't made special tests to compare 2.6.22-cfs19 and 2.6.22-ck1, but I see performance superiority of 2.6.22-ck1 using my own eyes. Especially in mozilla-firefox ... Using 2.6.22 or 2.6.22-cfs19 my firefox hangs for some time(~4-5 seconds) when I'm trying to open any url, but with 2.6.22-ck1 firefox doesn't hang at all or at least for a second when I have lots of open tabs. What is the reason? Had Con made better scheduler than cfs and O(1) in general kernel? Kernel configuration in 2.6.22, 2.6.22-ck1, 2.6.22-cfs19 is similar. - 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/
performance -cfs19 vs. -ck1 for 2.6.22
Hi, I haven't made special tests to compare 2.6.22-cfs19 and 2.6.22-ck1, but I see performance superiority of 2.6.22-ck1 using my own eyes. Especially in mozilla-firefox ... Using 2.6.22 or 2.6.22-cfs19 my firefox hangs for some time(~4-5 seconds) when I'm trying to open any url, but with 2.6.22-ck1 firefox doesn't hang at all or at least for a second when I have lots of open tabs. What is the reason? Had Con made better scheduler than cfs and O(1) in general kernel? Kernel configuration in 2.6.22, 2.6.22-ck1, 2.6.22-cfs19 is similar. - 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: performance -cfs19 vs. -ck1 for 2.6.22
Hi, Ingo! Could you run the following script: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh I'll do that! But a little bit later - I have tested that on my home computer. hm, is there no other workload on the system? Workload: firefox, transmission(torrent client), gnome terminal, music player. Now I think it could be not a scheduler issue but network subsystem ... but I've got such situation on previous kernels and w/o torrent client running. The problem is not in switching tabs in firefox but in _opening_new_url_. I'm not good in Con's patches but are they touching network subsystem? - 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/
Fwd: performance -cfs19 vs. -ck1 for 2.6.22
to help us figure out the nature of the delay, could you do another thing as well: strace -ttt -TTT -f -o firefox.trace.txt -p `pidof firefox-bin` I'll do that!! - 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/
i2c: pca954x I2C mux driver
if a device is attached to the virtual or the phisical bus and manage to not activate the first one to avoid duplicates, is that true? Is there a way to force the devices attached to the virtual bus to work? Or simply i made a mistake? Thank for the patience and a big thank for your work. -- Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada - 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/
i2c: pca954x I2C mux driver
if a device is attached to the virtual or the phisical bus and manage to not activate the first one to avoid duplicates, is that true? Is there a way to force the devices attached to the virtual bus to work? Or simply i made a mistake? Thank for the patience and a big thank for your work. -- Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada - 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/
Fwd: NPTL
BTW, please do _NOT_ top post! sorry No, a process also contains an address space. Of course .. I ment they are _almoust_ similar. No, that is creating a schedule unit (task) without an address space. Ok, I've already found that in kernel code ... and correctly understood. Surely you need some context switch when switching between runnable contexts. Hm. If the thread is running after it's sister or parent process - you do not have to switich the process context. Is this done in kernel?? Sorry if my thought are idiotic .. I'm a newby and trying to investigate the kernel. - 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: NPTL
So I can say that in linux 'thread' == 'process'? Is kernel routine 'kthread' creating a process? I'm just thinking on this subject: if to create 'real threads' - will it increase performance? Should I ever think in this way? When I say 'real thread' - I mean the thread that doen't switch context when it's starting to run. On 7/12/07, David Schwartz <[EMAIL PROTECTED]> wrote: > Hi! > I have a question about NPTL. > Are NPTL are still based on `clone` system call? Yes. > Are NPTL threads are > "processes" internally? No. By definition, all the threads belong to a single process. NPTL threads are based on KSEs (kernel scheduling entities). A non-threaded process is also a KSE. A threaded process is more than one KSEs. All KSE are, obviously, scheduled by the kernel. > Thanks! You're welcome. DS - 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/ - 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: NPTL
So I can say that in linux 'thread' == 'process'? Is kernel routine 'kthread' creating a process? I'm just thinking on this subject: if to create 'real threads' - will it increase performance? Should I ever think in this way? When I say 'real thread' - I mean the thread that doen't switch context when it's starting to run. On 7/12/07, David Schwartz [EMAIL PROTECTED] wrote: Hi! I have a question about NPTL. Are NPTL are still based on `clone` system call? Yes. Are NPTL threads are processes internally? No. By definition, all the threads belong to a single process. NPTL threads are based on KSEs (kernel scheduling entities). A non-threaded process is also a KSE. A threaded process is more than one KSEs. All KSE are, obviously, scheduled by the kernel. Thanks! You're welcome. DS - 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/ - 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/
Fwd: NPTL
BTW, please do _NOT_ top post! sorry No, a process also contains an address space. Of course .. I ment they are _almoust_ similar. No, that is creating a schedule unit (task) without an address space. Ok, I've already found that in kernel code ... and correctly understood. Surely you need some context switch when switching between runnable contexts. Hm. If the thread is running after it's sister or parent process - you do not have to switich the process context. Is this done in kernel?? Sorry if my thought are idiotic .. I'm a newby and trying to investigate the kernel. - 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/
vmware modules with 2.6.22
Hi! I have problem building vmware modules with 2.6.22. During code investigation I've notiesd that vmware modules are using old sk_buff structure / skb->h.raw != skb->nh.raw / how can I modify code to be able to compile it and where can I read migration guide for sk_buff? Thanks! Milinevsky Dmitriy - 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/
vmware modules with 2.6.22
Hi! I have problem building vmware modules with 2.6.22. During code investigation I've notiesd that vmware modules are using old sk_buff structure / skb-h.raw != skb-nh.raw / how can I modify code to be able to compile it and where can I read migration guide for sk_buff? Thanks! Milinevsky Dmitriy - 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] for NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS[unusual device] on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux, some previous kernels... lsusb -v Bus 001 Device 006: ID 04b0:0409 Nikon Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x04b0 Nikon Corp. idProduct 0x0409 bcdDevice1.00 iManufacturer 1 NIKON iProduct2 NIKON DSC D50 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered Sorry for flood ... but I disappointed where to send this patch. Signed-off-by: Milinevsky Dmitry <[EMAIL PROTECTED]> --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Milinevsky Dmitry <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + "NIKON", + "NIKON DSC D50", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold <[EMAIL PROTECTED]> */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, "NIKON", - 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] for NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS on 2.6.22-rc7, some previous kernels... --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Niam <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + "NIKON", + "NIKON DSC D50", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold <[EMAIL PROTECTED]> */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, "NIKON", - 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] for NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS on 2.6.22-rc7, some previous kernels... --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Niam [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + NIKON, + NIKON DSC D50, + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold [EMAIL PROTECTED] */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, NIKON, - 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] for NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS[unusual device] on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux, some previous kernels... lsusb -v Bus 001 Device 006: ID 04b0:0409 Nikon Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x04b0 Nikon Corp. idProduct 0x0409 bcdDevice1.00 iManufacturer 1 NIKON iProduct2 NIKON DSC D50 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered Sorry for flood ... but I disappointed where to send this patch. Signed-off-by: Milinevsky Dmitry [EMAIL PROTECTED] --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Milinevsky Dmitry [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + NIKON, + NIKON DSC D50, + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold [EMAIL PROTECTED] */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, NIKON, - 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/
NIKON D50 problem
Hi! Recently I've found out that my camera NIKON D50 can't mount any more. uname -a: "Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux" dmesg: scsi 2:0:0:0: Direct-Access NIKOND50 1.00 PQ: 0 ANSI: 2 sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1983992 Buffer I/O error on device sdb, logical block 1983992 end_request: I/O error, dev sdb, sector 1983993 Buffer I/O error on device sdb, logical block 1983993 Buffer I/O error on device sdb, logical block 1983994 Buffer I/O error on device sdb, logical block 1983995 Buffer I/O error on device sdb, logical block 1983996 Buffer I/O error on device sdb, logical block 1983997 Buffer I/O error on device sdb, logical block 1983998 Buffer I/O error on device sdb, logical block 1983999 end_request: I/O error, dev sdb, sector 1983992 ... Some time ago(I really can't remember version of the kernel) everything was Ok. I'll try to find out the workable version of the kernel ... but I've already tried 2.6.20 - the same =(. I'm not sure, but It's possible that I've had ATA subsystem but not libata ... I haven't tested this case yet. PS. I can see photos on my camera ... flash card is Ok. I have this problem even if I changed the flash card in this camera. - 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/
pci hidden behind transparent bridge
Hi! I noticed such message: "PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#06) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently" on my Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux What does it mean?? - 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/
pci hidden behind transparent bridge
Hi! I noticed such message: PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#06) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently on my Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux What does it mean?? - 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/
NIKON D50 problem
Hi! Recently I've found out that my camera NIKON D50 can't mount any more. uname -a: Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux dmesg: scsi 2:0:0:0: Direct-Access NIKOND50 1.00 PQ: 0 ANSI: 2 sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1983992 Buffer I/O error on device sdb, logical block 1983992 end_request: I/O error, dev sdb, sector 1983993 Buffer I/O error on device sdb, logical block 1983993 Buffer I/O error on device sdb, logical block 1983994 Buffer I/O error on device sdb, logical block 1983995 Buffer I/O error on device sdb, logical block 1983996 Buffer I/O error on device sdb, logical block 1983997 Buffer I/O error on device sdb, logical block 1983998 Buffer I/O error on device sdb, logical block 1983999 end_request: I/O error, dev sdb, sector 1983992 ... Some time ago(I really can't remember version of the kernel) everything was Ok. I'll try to find out the workable version of the kernel ... but I've already tried 2.6.20 - the same =(. I'm not sure, but It's possible that I've had ATA subsystem but not libata ... I haven't tested this case yet. PS. I can see photos on my camera ... flash card is Ok. I have this problem even if I changed the flash card in this camera. - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
That would be a bit like waiting for a Debian release and never happen. Ok, but Debian seems to be stable and sometimes their teem make releases =). - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
We have patches for "very high non-preempt latency in context_struct_compute_av()" and "list_add corruption. prev->next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33", but both are too intrusive. Anyway, those bugs are not regressions. Are you going to release 2.6.22 with this bugs?? But question wasn't on this subject ... The question was "why linux kernel release should have some bugs that would be fixed fixed in future?" Let's wait and publish kernel w/o known bugs. Let's wait for some time, let's publish 2.6.22-rc_last, test it for some time(2 weeks for example), fix bugs if any and after _test_period_of_whole_kernel_ but not _separate_patches/parts_ of kernel release stable one! - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hello! I'm a newbuy in kernel development. Now I'm just trying to find out what is going in it =). I noticed this: (BTW. There is a new category called "Will be fixed in 2.6.23") Is it really important to release 2.6.22 as soon as possible? I think kernel should be 99% stable. Why not to wait for patches on known regressions and release more or less stable 2.6.22? Thanks! Best wishes, Niam. - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hello! I'm a newbuy in kernel development. Now I'm just trying to find out what is going in it =). I noticed this: (BTW. There is a new category called Will be fixed in 2.6.23) Is it really important to release 2.6.22 as soon as possible? I think kernel should be 99% stable. Why not to wait for patches on known regressions and release more or less stable 2.6.22? Thanks! Best wishes, Niam. - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
We have patches for very high non-preempt latency in context_struct_compute_av() and list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33, but both are too intrusive. Anyway, those bugs are not regressions. Are you going to release 2.6.22 with this bugs?? But question wasn't on this subject ... The question was why linux kernel release should have some bugs that would be fixed fixed in future? Let's wait and publish kernel w/o known bugs. Let's wait for some time, let's publish 2.6.22-rc_last, test it for some time(2 weeks for example), fix bugs if any and after _test_period_of_whole_kernel_ but not _separate_patches/parts_ of kernel release stable one! - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
That would be a bit like waiting for a Debian release and never happen. Ok, offtopbut Debian seems to be stable and sometimes their teem make releases =)./offtop - 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/
PROBLEM: V4L2 - Leadtek Winfast PVR 2000 XP makes partial kernel freeze
CK804 fc00-fc1f : :00:01.1 cat /proc/iomem: -0009efff : System RAM - : Crash kernel 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000cefff : Video ROM 000f-000f : System ROM 0010-3fed : System RAM 0020-0042a620 : Kernel code 0042a621-0054d1ff : Kernel data 3fee-3fee2fff : ACPI Non-volatile Storage 3fee3000-3fee : ACPI Tables 3fef-3fef : reserved d000-dfff : PCI Bus #05 d000-dfff : :05:00.0 e000-efff : reserved fa00-fcff : PCI Bus #05 fa00-faff : :05:00.0 fa00-faff : nvidia fb00-fbff : :05:00.0 fcfe-fcff : :05:00.0 fd00-fdff : PCI Bus #01 fd00-fdff : :01:07.0 fd00-fdff : cx88[0] fe02a000-fe02afff : :00:0a.0 fe02a000-fe02afff : forcedeth fe02b000-fe02bfff : :00:08.0 fe02b000-fe02bfff : sata_nv fe02c000-fe02cfff : :00:07.0 fe02c000-fe02cfff : sata_nv fe02d000-fe02dfff : :00:04.0 fe02d000-fe02dfff : NVidia CK804 fe02f000-fe02 : :00:02.0 fe02f000-fe02 : ohci_hcd feb0-feb000ff : :00:02.1 feb0-feb000ff : ehci_hcd fec0-fec00fff : IOAPIC 0 fee0-fee00fff : Local APIC [EMAIL PROTECTED]:~$ lspci -vvv 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Capabilities: 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 255 Region 0: I/O ports at fc00 [size=32] Region 4: I/O ports at 4c00 [size=64] Region 5: I/O ports at 4c40 [size=64] Capabilities: 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 23 Region 0: Memory at feb0 (32-bit, non-prefetchable) [size=256] Capabilities: 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 822c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (500ns min, 1250ns max) Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at f000 [size=256] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Capabilities: 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at e800 [size=16] Capabilities: 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3
PROBLEM: V4L2 - Leadtek Winfast PVR 2000 XP makes partial kernel freeze
-fc1f : :00:01.1 cat /proc/iomem: -0009efff : System RAM - : Crash kernel 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000cefff : Video ROM 000f-000f : System ROM 0010-3fed : System RAM 0020-0042a620 : Kernel code 0042a621-0054d1ff : Kernel data 3fee-3fee2fff : ACPI Non-volatile Storage 3fee3000-3fee : ACPI Tables 3fef-3fef : reserved d000-dfff : PCI Bus #05 d000-dfff : :05:00.0 e000-efff : reserved fa00-fcff : PCI Bus #05 fa00-faff : :05:00.0 fa00-faff : nvidia fb00-fbff : :05:00.0 fcfe-fcff : :05:00.0 fd00-fdff : PCI Bus #01 fd00-fdff : :01:07.0 fd00-fdff : cx88[0] fe02a000-fe02afff : :00:0a.0 fe02a000-fe02afff : forcedeth fe02b000-fe02bfff : :00:08.0 fe02b000-fe02bfff : sata_nv fe02c000-fe02cfff : :00:07.0 fe02c000-fe02cfff : sata_nv fe02d000-fe02dfff : :00:04.0 fe02d000-fe02dfff : NVidia CK804 fe02f000-fe02 : :00:02.0 fe02f000-fe02 : ohci_hcd feb0-feb000ff : :00:02.1 feb0-feb000ff : ehci_hcd fec0-fec00fff : IOAPIC 0 fee0-fee00fff : Local APIC [EMAIL PROTECTED]:~$ lspci -vvv 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: access denied 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 255 Region 0: I/O ports at fc00 [size=32] Region 4: I/O ports at 4c00 [size=64] Region 5: I/O ports at 4c40 [size=64] Capabilities: access denied 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 23 Region 0: Memory at feb0 (32-bit, non-prefetchable) [size=256] Capabilities: access denied 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 822c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (500ns min, 1250ns max) Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at f000 [size=256] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (750ns min, 250ns max) Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable
Re: Improved UDP performance using 2.6.21-rc5-rt10
Ingo, Here are some more results: Nvidia w/cyclesoak 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 Nvidia w/top 2.6.21-rc5-rt12 938 31% netperf @51 hardirq @50 softirq @50 Hopefully I'll run some more tests in the morning Thanks, Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > rt10 shows a big improvement over rt8 > > > > ## > > etupThruput CPU% > > Nvidia > > 2.6.21-rc5-rt8 938 65% > >netperf @51 > >hardirq @50 > >softirq @50 > > > > Nvidia > > 2.6.21-rc5-rt10 938 32% > >netperf @51 > >hardirq @50 > >softirq @50 > > cool! Btw., could you run the same but without running cyclesoak, and > only watching the 'idle' metric in 'top' or vmstat? I found in my > experiments that cyclesoak sometimes interfers with the workload - and > the idle stats are precise and accurate on -rt. (they are not on > vanilla) > > Ingo - 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: Improved UDP performance using 2.6.21-rc5-rt10
Ingo, Here are some more results: Nvidia w/cyclesoak 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 Nvidia w/top 2.6.21-rc5-rt12 938 31% netperf @51 hardirq @50 softirq @50 Hopefully I'll run some more tests in the morning Thanks, Dave -- Original message -- From: Ingo Molnar [EMAIL PROTECTED] * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: rt10 shows a big improvement over rt8 ## etupThruput CPU% Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Nvidia 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 cool! Btw., could you run the same but without running cyclesoak, and only watching the 'idle' metric in 'top' or vmstat? I found in my experiments that cyclesoak sometimes interfers with the workload - and the idle stats are precise and accurate on -rt. (they are not on vanilla) Ingo - 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: Improved UDP performance using 2.6.21-rc5-rt10
rt10 shows a big improvement over rt8 ## etupThruput CPU% Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Nvidia 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 very nice for a "work in progress" I ran the netperf test a few times and one of the times the netperf test would no longer talk to the server. I had to reboot the rt client to get netperf to talk again. I did have cycle soak running which may have contributed to the problem. Also when netperf is not running the hard IRQs associated with the NIC use a constant 2% load. Thanks, Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * David Sperry <[EMAIL PROTECTED]> wrote: > > > > there are a few other things i'm working on to improve this. I've > > > uploaded -rt9 which is the current state of affairs. Note that using > > > -rt9 you'll likely only see IRQ-8406 overhead in the system, because > > > i've added an optimization to do process the softirq-net-tx workload > > > in the hardirq thread if the priority of the two is the same (which > > > is the default behavior). But -rt9 is still work in progress that is > > > not fully finished yet: in some cases i'm seeing 'fluctuating > > > performance' problems on forcedeth that werent there before. > > > > I tried -rt9 and saw some odd 'fluctuating performance'. I'll try it > > again tomorrow when I am much closer to the box's power button. > > could you try -rt10? I've improved hardirq/softirq threading performance > some more, and have tuned the forcedeth driver too. > > Ingo - 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: Improved UDP performance using 2.6.21-rc5-rt10
rt10 shows a big improvement over rt8 ## etupThruput CPU% Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Nvidia 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 very nice for a work in progress I ran the netperf test a few times and one of the times the netperf test would no longer talk to the server. I had to reboot the rt client to get netperf to talk again. I did have cycle soak running which may have contributed to the problem. Also when netperf is not running the hard IRQs associated with the NIC use a constant 2% load. Thanks, Dave -- Original message -- From: Ingo Molnar [EMAIL PROTECTED] * David Sperry [EMAIL PROTECTED] wrote: there are a few other things i'm working on to improve this. I've uploaded -rt9 which is the current state of affairs. Note that using -rt9 you'll likely only see IRQ-8406 overhead in the system, because i've added an optimization to do process the softirq-net-tx workload in the hardirq thread if the priority of the two is the same (which is the default behavior). But -rt9 is still work in progress that is not fully finished yet: in some cases i'm seeing 'fluctuating performance' problems on forcedeth that werent there before. I tried -rt9 and saw some odd 'fluctuating performance'. I'll try it again tomorrow when I am much closer to the box's power button. could you try -rt10? I've improved hardirq/softirq threading performance some more, and have tuned the forcedeth driver too. Ingo - 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: Poor UDP performance using 2.6.21-rc5-rt5
I have a new data point to add to the confusion. The box I'm testing has 2 nics in it. The one I have been testing so far is: 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) The other NIC is an Intel 1gig fiber 09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) The Intel controller did not work 2.6.20 but under 2.6.21-rc5-rt8 it does. Running the same netperf tests with the Intel NIC produces very different results for the RT case: setupThruput CPU% Nvidia 2.6.21-rc5 vanilla 935 29% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5 vanilla 933 30% netperf @51 hardirq @50 softirq @50 ## Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5-rt8 938 34% netperf @51 hardirq @50 softirq @50 The Intel NIC seems to behave better under RT top for each NIC under test yields some interesting results: Nvidia 2.6.21-rc5-rt8: top - 11:03:46 up 1:23, 2 users, load average: 1.75, 1.31, 0.70 Tasks: 167 total, 2 running, 165 sleeping, 0 stopped, 0 zombie Cpu(s): 0.8%us, 29.7%sy, 0.0%ni, 34.8%id, 0.0%wa, 22.1%hi, 10.6%si, 0.0%st Mem: 2035436k total, 618276k used, 1417160k free,31744k buffers Swap: 3068372k total,0k used, 3068372k free, 386060k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4139 root -52 0 6440 636 480 S 60 0.0 0:19.14 netperf 2706 root -51 -5 000 R 44 0.0 2:00.70 IRQ-8406 19 root -51 0 000 S 21 0.0 0:38.50 softirq-net-tx/ 4012 eadi 16 0 229m 6852 5584 S1 0.3 0:05.39 multiload-apple 6 root -51 0 000 S1 0.0 0:00.95 softirq-net-tx/ 3014 dbus 15 0 21352 896 548 S1 0.0 0:00.04 dbus-daemon 1 root 15 0 10308 668 552 S0 0.0 0:00.74 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 7 root -51 0 000 S0 0.0 0:00.00 softirq-net-rx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 Intel 2.6.21-rc5-rt8 top - 11:10:27 up 3 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 21.6%sy, 0.0%ni, 65.9%id, 0.0%wa, 3.0%hi, 9.0%si, 0.0%st Mem: 2035436k total, 618012k used, 1417424k free,29972k buffers Swap: 3068372k total,0k used, 3068372k free, 386084k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3955 root -52 0 6436 636 480 S 43 0.0 0:19.74 netperf 20 root -51 0 000 S 11 0.0 0:04.86 softirq-net-rx/ 7 root -51 0 000 S7 0.0 0:03.28 softirq-net-rx/ 2370 root -51 -5 000 S6 0.0 0:02.62 IRQ-8408 3858 eadi 16 0 229m 6848 5584 S1 0.3 0:01.45 multiload-apple 3954 eadi 15 0 12712 1096 788 R0 0.1 0:00.19 top 1 root 15 0 10304 664 552 S0 0.0 0:00.75 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 6 root -51 0 000 S0 0.0 0:00.00 softirq-net-tx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 9 root -51 0 000 S0 0.0 0:00.00 softirq-tasklet 10 root -51 0 000 S0 0.0 0:00.00 softirq-sched/0 I think there is some kind of bad behavior happening in the Nvidia driver with respect to softirq-net-tx and IRQ-8406. Any thoughts? If you want I can post the oprofile from both test cases. -Dave - 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: Poor UDP performance using 2.6.21-rc5-rt5
-- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Thanks for all the input Ingo, Here's a list of all the permutations > > I've tried: > > one thing i noticed is that cyclesoak interferes with the netperf > workload. This is quite surprising. 'top' and 'vmstat' output is > reliable on -rt, and the overhead goes down if i stop cyclesoak. > > Ingo I see the same effect setupThruput CPU% cyclesoak on 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 cyclesoak off 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Dave - 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: Poor UDP performance using 2.6.21-rc5-rt5
Thanks for all the input Ingo, Here's a list of all the permutations I've tried: setupThruput CPU% from cyclesoak 2.6.21-rc5 vanilla 935 29% 2.6.21-rc5-rt5 711 50% //basically all of 1 cpu 2.6.21-rc5-rt8 733 52% 2.6.21-rc5-rt8 824 64% netperf @50 hardirq @50 softirq @50 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 2.6.21-rc5-rt8 106 8% netperf @51 hardirq @49 softirq @50 2.6.21-rc5-rt8 233 14% netperf @51 hardirq @49 softirq @48 2.6.21-rc5-rt8 67 5% netperf @batch hardirq @batch softirq @batch 2.6.21-rc5-rt8 331 OFF netperf @batch hardirq @batch softirq @batch cyclesoak off Any thoughts? -Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * Dave Sperry <[EMAIL PROTECTED]> wrote: > > > I checked the clock source and in both the vanilla and rt cases and > > they were both acpi_pm > > ok, thanks for double-checking that. > > > Here's the oprofile for my vanilla case: > > i tried your workload and i think i managed to optimize it some more: i > have uploaded the -rt8 kernel with these improvements included - could > you try it? Is there any measurable improvement relative to -rt5? > > one more thing to improve netperf performance is to do this before > running it: > > chrt -f -p 50 $$ > > this will put netperf on the same priority level as the net hardirq and > the net softirq (which both default to SCHED_FIFO:50), and should result > in a (much) reduced context-switch rate. > > Or, if networking is not latency-critical, then you could move the net > hardirq and softirq threads to SCHED_BATCH, and run netperf under > SCHED_BATCH as well, using: > > chrt -b -p 0 $$ > > and figuring out the active softirq hardirq thread PIDs and "chrt -b" > -ing them too. > > Ingo - 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: Poor UDP performance using 2.6.21-rc5-rt5
Thanks for all the input Ingo, Here's a list of all the permutations I've tried: setupThruput CPU% from cyclesoak 2.6.21-rc5 vanilla 935 29% 2.6.21-rc5-rt5 711 50% //basically all of 1 cpu 2.6.21-rc5-rt8 733 52% 2.6.21-rc5-rt8 824 64% netperf @50 hardirq @50 softirq @50 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 2.6.21-rc5-rt8 106 8% netperf @51 hardirq @49 softirq @50 2.6.21-rc5-rt8 233 14% netperf @51 hardirq @49 softirq @48 2.6.21-rc5-rt8 67 5% netperf @batch hardirq @batch softirq @batch 2.6.21-rc5-rt8 331 OFF netperf @batch hardirq @batch softirq @batch cyclesoak off Any thoughts? -Dave -- Original message -- From: Ingo Molnar [EMAIL PROTECTED] * Dave Sperry [EMAIL PROTECTED] wrote: I checked the clock source and in both the vanilla and rt cases and they were both acpi_pm ok, thanks for double-checking that. Here's the oprofile for my vanilla case: i tried your workload and i think i managed to optimize it some more: i have uploaded the -rt8 kernel with these improvements included - could you try it? Is there any measurable improvement relative to -rt5? one more thing to improve netperf performance is to do this before running it: chrt -f -p 50 $$ this will put netperf on the same priority level as the net hardirq and the net softirq (which both default to SCHED_FIFO:50), and should result in a (much) reduced context-switch rate. Or, if networking is not latency-critical, then you could move the net hardirq and softirq threads to SCHED_BATCH, and run netperf under SCHED_BATCH as well, using: chrt -b -p 0 $$ and figuring out the active softirq hardirq thread PIDs and chrt -b -ing them too. Ingo - 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: Poor UDP performance using 2.6.21-rc5-rt5
-- Original message -- From: Ingo Molnar [EMAIL PROTECTED] * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks for all the input Ingo, Here's a list of all the permutations I've tried: one thing i noticed is that cyclesoak interferes with the netperf workload. This is quite surprising. 'top' and 'vmstat' output is reliable on -rt, and the overhead goes down if i stop cyclesoak. Ingo I see the same effect setupThruput CPU% cyclesoak on 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 cyclesoak off 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Dave - 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: Poor UDP performance using 2.6.21-rc5-rt5
I have a new data point to add to the confusion. The box I'm testing has 2 nics in it. The one I have been testing so far is: 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) The other NIC is an Intel 1gig fiber 09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) The Intel controller did not work 2.6.20 but under 2.6.21-rc5-rt8 it does. Running the same netperf tests with the Intel NIC produces very different results for the RT case: setupThruput CPU% Nvidia 2.6.21-rc5 vanilla 935 29% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5 vanilla 933 30% netperf @51 hardirq @50 softirq @50 ## Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5-rt8 938 34% netperf @51 hardirq @50 softirq @50 The Intel NIC seems to behave better under RT top for each NIC under test yields some interesting results: Nvidia 2.6.21-rc5-rt8: top - 11:03:46 up 1:23, 2 users, load average: 1.75, 1.31, 0.70 Tasks: 167 total, 2 running, 165 sleeping, 0 stopped, 0 zombie Cpu(s): 0.8%us, 29.7%sy, 0.0%ni, 34.8%id, 0.0%wa, 22.1%hi, 10.6%si, 0.0%st Mem: 2035436k total, 618276k used, 1417160k free,31744k buffers Swap: 3068372k total,0k used, 3068372k free, 386060k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4139 root -52 0 6440 636 480 S 60 0.0 0:19.14 netperf 2706 root -51 -5 000 R 44 0.0 2:00.70 IRQ-8406 19 root -51 0 000 S 21 0.0 0:38.50 softirq-net-tx/ 4012 eadi 16 0 229m 6852 5584 S1 0.3 0:05.39 multiload-apple 6 root -51 0 000 S1 0.0 0:00.95 softirq-net-tx/ 3014 dbus 15 0 21352 896 548 S1 0.0 0:00.04 dbus-daemon 1 root 15 0 10308 668 552 S0 0.0 0:00.74 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 7 root -51 0 000 S0 0.0 0:00.00 softirq-net-rx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 Intel 2.6.21-rc5-rt8 top - 11:10:27 up 3 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 21.6%sy, 0.0%ni, 65.9%id, 0.0%wa, 3.0%hi, 9.0%si, 0.0%st Mem: 2035436k total, 618012k used, 1417424k free,29972k buffers Swap: 3068372k total,0k used, 3068372k free, 386084k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3955 root -52 0 6436 636 480 S 43 0.0 0:19.74 netperf 20 root -51 0 000 S 11 0.0 0:04.86 softirq-net-rx/ 7 root -51 0 000 S7 0.0 0:03.28 softirq-net-rx/ 2370 root -51 -5 000 S6 0.0 0:02.62 IRQ-8408 3858 eadi 16 0 229m 6848 5584 S1 0.3 0:01.45 multiload-apple 3954 eadi 15 0 12712 1096 788 R0 0.1 0:00.19 top 1 root 15 0 10304 664 552 S0 0.0 0:00.75 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 6 root -51 0 000 S0 0.0 0:00.00 softirq-net-tx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 9 root -51 0 000 S0 0.0 0:00.00 softirq-tasklet 10 root -51 0 000 S0 0.0 0:00.00 softirq-sched/0 I think there is some kind of bad behavior happening in the Nvidia driver with respect to softirq-net-tx and IRQ-8406. Any thoughts? If you want I can post the oprofile from both test cases. -Dave - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On 3/3/07, Jean Delvare <[EMAIL PROTECTED]> wrote: Hi Matthew, On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote: > On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote: > > It might be more elegant but it won't work. We don't want to prevent > > ACPI from accessing these I/O ports. If we need to choose only one > > "driver" accessing the I/O port, it must be acpi, at leat for now, > > despite the fact that acpi provides very weak hardware monitoring > > capabilities compared to the specific drivers. > > Assuming arbitration of access, what's the problem with having two > drivers accessing the same hardware? Do these chips generally have any > significant internal state other than trip points and the like? The "assuming arbitration of access" is the key part of your sentence ;) The problem is that currently no arbitration is done. If it was done, then state would probably not be a problem. Most hardware monitoring drivers don't assume any state is preserved between accesses, and those which do can easily be changed not to. The ACPI side is another story though, I guess we can't assume anything about the AML code's assumption on states, as it differs from one machine to the next. But we can try to be cooperative and restore the sensible registers (e.g. bank selector) in the same state we found them. I recall that one of the stated drawbacks of a lock was that no ACPI code could execute while the hwmon driver was doing its fairly lengthy conversation with the hardware. It seems that using transactional concepts here would solve that problem. For example, the hwmon driver issues a start transaction request. The first write request to any given location (bank register for example) causes the previous memory value to be saved. Then, instead of locking AML out, AML is allowed to execute, but any access to the memory/port ranges reserved by the driver (when the transaction is set up) cause the hwmon transaction to be rolled back so the AML sees the expected state. Then AML proceeds as usual. When hwmon tries additional operations, they fail with some "transaction interrupted" error message, indicating to the hwmon driver to start over. The only issue with this that I can see, is that if AML isn['t executed atomically wrt hwmon, then knowing when it is safe for hwmon to retry is going to be difficult. This probably requires changes to every hwmon driver, but they can be updated piecemeal, starting with the ones most commonly found in notebooks, where ACPI is most important. - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On 3/3/07, Jean Delvare [EMAIL PROTECTED] wrote: Hi Matthew, On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote: On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote: It might be more elegant but it won't work. We don't want to prevent ACPI from accessing these I/O ports. If we need to choose only one driver accessing the I/O port, it must be acpi, at leat for now, despite the fact that acpi provides very weak hardware monitoring capabilities compared to the specific drivers. Assuming arbitration of access, what's the problem with having two drivers accessing the same hardware? Do these chips generally have any significant internal state other than trip points and the like? The assuming arbitration of access is the key part of your sentence ;) The problem is that currently no arbitration is done. If it was done, then state would probably not be a problem. Most hardware monitoring drivers don't assume any state is preserved between accesses, and those which do can easily be changed not to. The ACPI side is another story though, I guess we can't assume anything about the AML code's assumption on states, as it differs from one machine to the next. But we can try to be cooperative and restore the sensible registers (e.g. bank selector) in the same state we found them. I recall that one of the stated drawbacks of a lock was that no ACPI code could execute while the hwmon driver was doing its fairly lengthy conversation with the hardware. It seems that using transactional concepts here would solve that problem. For example, the hwmon driver issues a start transaction request. The first write request to any given location (bank register for example) causes the previous memory value to be saved. Then, instead of locking AML out, AML is allowed to execute, but any access to the memory/port ranges reserved by the driver (when the transaction is set up) cause the hwmon transaction to be rolled back so the AML sees the expected state. Then AML proceeds as usual. When hwmon tries additional operations, they fail with some transaction interrupted error message, indicating to the hwmon driver to start over. The only issue with this that I can see, is that if AML isn['t executed atomically wrt hwmon, then knowing when it is safe for hwmon to retry is going to be difficult. This probably requires changes to every hwmon driver, but they can be updated piecemeal, starting with the ones most commonly found in notebooks, where ACPI is most important. - 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.19.1: kernel BUG at mm/slab.c:2911!
Christoph Lameter wrote: > On Tue, 30 Jan 2007, Martin MOKREJS wrote: > >> Hi, >> is this a known issue? Should I bother to upgrade to 2.6.19.2 if it >> contains the fix? >> Thank you any help. It might be related to NFS. The machine in question is >> NFSv3 client, >> udp. And used for computations. The process which died is from torque >> cluster management >> package. > >> 000: 00 00 00 00 fe ff ff ff fe ff ff ff 3a 00 00 00 > > The beginning of the slab was overwritten. The first two words should have > been list pointers. color offset is also invalid as is the pointer to the > slab memory. > > Are you using cpu hotplug by chance? No, it is a classical P4 machine, ASUS P4C800E-Deluxe motherboard. However, it might have been related to the overclocked CPU. Although 12 other, exactly same machines are running fine at the same over-clock I have decreased the settings. It did not happen since then. So I believe it was a hardware issue. Thanks for the explanation. Martin - 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.19.1: kernel BUG at mm/slab.c:2911!
Christoph Lameter wrote: On Tue, 30 Jan 2007, Martin MOKREJS wrote: Hi, is this a known issue? Should I bother to upgrade to 2.6.19.2 if it contains the fix? Thank you any help. It might be related to NFS. The machine in question is NFSv3 client, udp. And used for computations. The process which died is from torque cluster management package. 000: 00 00 00 00 fe ff ff ff fe ff ff ff 3a 00 00 00 The beginning of the slab was overwritten. The first two words should have been list pointers. color offset is also invalid as is the pointer to the slab memory. Are you using cpu hotplug by chance? No, it is a classical P4 machine, ASUS P4C800E-Deluxe motherboard. However, it might have been related to the overclocked CPU. Although 12 other, exactly same machines are running fine at the same over-clock I have decreased the settings. It did not happen since then. So I believe it was a hardware issue. Thanks for the explanation. Martin - 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] mm: fix page_mkclean_one
On Thu Dec 28 15:09 , Guillaume Chazarain sent: >I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/ >I have corruption with every Fedora release kernel except the first, that is >2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit >some corruption. Confirm that I see corruption with Fedora kernel 2.6.18-1.2239.fc5: ... Chunk 142969 corrupted (0-1459) (2580-4039) Expected 121, got 0 Written as (89632)127652(124721) Chunk 142976 corrupted (0-1459) (512-1971) Expected 128, got 0 Written as (121734)128324(108589) Checking chunk 143639/143640 (99%) $ uname -a Linux 2.6.18-1.2239.fc5 #1 Fri Nov 10 13:04:06 EST 2006 i686 athlon i386 GNU/Linux /Martin - 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] mm: fix page_mkclean_one
On Thu Dec 28 15:09 , Guillaume Chazarain sent: I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/ I have corruption with every Fedora release kernel except the first, that is 2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit some corruption. Confirm that I see corruption with Fedora kernel 2.6.18-1.2239.fc5: ... Chunk 142969 corrupted (0-1459) (2580-4039) Expected 121, got 0 Written as (89632)127652(124721) Chunk 142976 corrupted (0-1459) (512-1971) Expected 128, got 0 Written as (121734)128324(108589) Checking chunk 143639/143640 (99%) $ uname -a Linux 2.6.18-1.2239.fc5 #1 Fri Nov 10 13:04:06 EST 2006 i686 athlon i386 GNU/Linux /Martin - 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] Fix namespace conflict between w9968cf.c on MIPS
Okay, thanks.
Best regards
Luca Risolia
Scrive Ralf Baechle <[EMAIL PROTECTED]>:
> Both use __SC. Since __* is sort of private namespace I've choosen to
> fix this in the driver. For consistency I decieded to also change
> __UNSC to UNSC.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
> index ddce2fb..9f403af 100644
> --- a/drivers/media/video/w9968cf.c
> +++ b/drivers/media/video/w9968cf.c
> @@ -1827,8 +1827,8 @@ w9968cf_set_window(struct w9968cf_device
> int err = 0;
>
> /* Work around to avoid FP arithmetics */
> - #define __SC(x) ((x) << 10)
> - #define __UNSC(x) ((x) >> 10)
> + #define SC(x) ((x) << 10)
> + #define UNSC(x) ((x) >> 10)
>
> /* Make sure we are using a supported resolution */
> if ((err = w9968cf_adjust_window_size(cam, (u16*),
> @@ -1836,15 +1836,15 @@ w9968cf_set_window(struct w9968cf_device
> goto error;
>
> /* Scaling factors */
> - fw = __SC(win.width) / cam->maxwidth;
> - fh = __SC(win.height) / cam->maxheight;
> + fw = SC(win.width) / cam->maxwidth;
> + fh = SC(win.height) / cam->maxheight;
>
> /* Set up the width and height values used by the chip */
> if ((win.width > cam->maxwidth) || (win.height > cam->maxheight)) {
> cam->vpp_flag |= VPP_UPSCALE;
> /* Calculate largest w,h mantaining the same w/h ratio */
> - w = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh;
> - h = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight;
> + w = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh;
> + h = (fw >= fh) ? SC(win.height)/fw : cam->maxheight;
> if (w < cam->minwidth) /* just in case */
> w = cam->minwidth;
> if (h < cam->minheight) /* just in case */
> @@ -1861,8 +1861,8 @@ w9968cf_set_window(struct w9968cf_device
>
> /* Calculate cropped area manteining the right w/h ratio */
> if (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) {
> - cw = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh;
> - ch = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight;
> + cw = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh;
> + ch = (fw >= fh) ? SC(win.height)/fw : cam->maxheight;
> } else {
> cw = w;
> ch = h;
> @@ -1901,8 +1901,8 @@ w9968cf_set_window(struct w9968cf_device
> /* We have to scale win.x and win.y offsets */
> if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE))
>|| (cam->vpp_flag & VPP_UPSCALE) ) {
> - ax = __SC(win.x)/fw;
> - ay = __SC(win.y)/fh;
> + ax = SC(win.x)/fw;
> + ay = SC(win.y)/fh;
> } else {
> ax = win.x;
> ay = win.y;
> @@ -1917,8 +1917,8 @@ w9968cf_set_window(struct w9968cf_device
> /* Adjust win.x, win.y */
> if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE))
> || (cam->vpp_flag & VPP_UPSCALE) ) {
> - win.x = __UNSC(ax*fw);
> - win.y = __UNSC(ay*fh);
> + win.x = UNSC(ax*fw);
> + win.y = UNSC(ay*fh);
> } else {
> win.x = ax;
> win.y = ay;
>
>
-
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] Fix namespace conflict between w9968cf.c on MIPS
Okay, thanks.
Best regards
Luca Risolia
Scrive Ralf Baechle [EMAIL PROTECTED]:
Both use __SC. Since __* is sort of private namespace I've choosen to
fix this in the driver. For consistency I decieded to also change
__UNSC to UNSC.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
index ddce2fb..9f403af 100644
--- a/drivers/media/video/w9968cf.c
+++ b/drivers/media/video/w9968cf.c
@@ -1827,8 +1827,8 @@ w9968cf_set_window(struct w9968cf_device
int err = 0;
/* Work around to avoid FP arithmetics */
- #define __SC(x) ((x) 10)
- #define __UNSC(x) ((x) 10)
+ #define SC(x) ((x) 10)
+ #define UNSC(x) ((x) 10)
/* Make sure we are using a supported resolution */
if ((err = w9968cf_adjust_window_size(cam, (u16*)win.width,
@@ -1836,15 +1836,15 @@ w9968cf_set_window(struct w9968cf_device
goto error;
/* Scaling factors */
- fw = __SC(win.width) / cam-maxwidth;
- fh = __SC(win.height) / cam-maxheight;
+ fw = SC(win.width) / cam-maxwidth;
+ fh = SC(win.height) / cam-maxheight;
/* Set up the width and height values used by the chip */
if ((win.width cam-maxwidth) || (win.height cam-maxheight)) {
cam-vpp_flag |= VPP_UPSCALE;
/* Calculate largest w,h mantaining the same w/h ratio */
- w = (fw = fh) ? cam-maxwidth : __SC(win.width)/fh;
- h = (fw = fh) ? __SC(win.height)/fw : cam-maxheight;
+ w = (fw = fh) ? cam-maxwidth : SC(win.width)/fh;
+ h = (fw = fh) ? SC(win.height)/fw : cam-maxheight;
if (w cam-minwidth) /* just in case */
w = cam-minwidth;
if (h cam-minheight) /* just in case */
@@ -1861,8 +1861,8 @@ w9968cf_set_window(struct w9968cf_device
/* Calculate cropped area manteining the right w/h ratio */
if (cam-largeview !(cam-vpp_flag VPP_UPSCALE)) {
- cw = (fw = fh) ? cam-maxwidth : __SC(win.width)/fh;
- ch = (fw = fh) ? __SC(win.height)/fw : cam-maxheight;
+ cw = (fw = fh) ? cam-maxwidth : SC(win.width)/fh;
+ ch = (fw = fh) ? SC(win.height)/fw : cam-maxheight;
} else {
cw = w;
ch = h;
@@ -1901,8 +1901,8 @@ w9968cf_set_window(struct w9968cf_device
/* We have to scale win.x and win.y offsets */
if ( (cam-largeview !(cam-vpp_flag VPP_UPSCALE))
|| (cam-vpp_flag VPP_UPSCALE) ) {
- ax = __SC(win.x)/fw;
- ay = __SC(win.y)/fh;
+ ax = SC(win.x)/fw;
+ ay = SC(win.y)/fh;
} else {
ax = win.x;
ay = win.y;
@@ -1917,8 +1917,8 @@ w9968cf_set_window(struct w9968cf_device
/* Adjust win.x, win.y */
if ( (cam-largeview !(cam-vpp_flag VPP_UPSCALE))
|| (cam-vpp_flag VPP_UPSCALE) ) {
- win.x = __UNSC(ax*fw);
- win.y = __UNSC(ay*fh);
+ win.x = UNSC(ax*fw);
+ win.y = UNSC(ay*fh);
} else {
win.x = ax;
win.y = ay;
-
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: [irda-users] Is ircomm possible with smsc_ircc2?
Andrey Borzenkov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have Toshiba Portege 4000, which apparently needs smsc_ircc2 driver. Driver seems to load OK: Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. Activated ALi 1533 ISA bridge port 0x02e8. Activated ALi 1533 ISA bridge port 0x02f8. found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 smsc_superio_flat(): IrDA not enabled smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02 SMsC IrDA Controller found IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7 No transceiver found. Defaulting to Fast pin select and it registers irda0 interface but no /dev/ircomm* ever appears. I need them (or at least I /think/ I need them) for SynCE (for installing programs in my Pocket LOOX). What is missing? Do I need additional driver? How can I access ircomm on this HW? You probably need to load the ircomm-tty and ircomm modules on top of irda stack for /dev/ircomm*. Best regards, hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - 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: [irda-users] Is ircomm possible with smsc_ircc2?
Andrey Borzenkov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have Toshiba Portege 4000, which apparently needs smsc_ircc2 driver. Driver seems to load OK: Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. Activated ALi 1533 ISA bridge port 0x02e8. Activated ALi 1533 ISA bridge port 0x02f8. found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 smsc_superio_flat(): IrDA not enabled smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02 SMsC IrDA Controller found IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7 No transceiver found. Defaulting to Fast pin select and it registers irda0 interface but no /dev/ircomm* ever appears. I need them (or at least I /think/ I need them) for SynCE (for installing programs in my Pocket LOOX). What is missing? Do I need additional driver? How can I access ircomm on this HW? You probably need to load the ircomm-tty and ircomm modules on top of irda stack for /dev/ircomm*. Best regards, hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - 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/
