[PATCH] pci_ids: additional NFORCE MCP61 devices - (resend)
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa <[EMAIL PROTECTED]> lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - 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] pci_ids: additional NFORCE MCP61 devices
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa <[EMAIL PROTECTED]> lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - 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] pci_ids: additional NFORCE MCP61 devices
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa [EMAIL PROTECTED] lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - 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] pci_ids: additional NFORCE MCP61 devices - (resend)
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa [EMAIL PROTECTED] lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - 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/
[FYI] Vendor interest in Unionfs
>> Is there vendor interest in unionfs? > MANY live cds seem to use it I'd like to add that also in embedded area (flash storage) the UnionFS helps in some cases. thanks, Indrek - 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/
[FYI] Vendor interest in Unionfs
Is there vendor interest in unionfs? MANY live cds seem to use it I'd like to add that also in embedded area (flash storage) the UnionFS helps in some cases. thanks, Indrek - 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.12-rc2-mm2
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Wow... it responds despite the load average of 83.63 :) http://www.tuleriit.ee/progs/img/pic1.png http://www.tuleriit.ee/progs/img/pic2.png http://www.tuleriit.ee/progs/img/pic3.png dmesg is not clean though: TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 392 messages suppressed. TCP: time wait bucket table overflow printk: 290 messages suppressed. TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 295 messages suppressed. TCP: time wait bucket table overflow What I did: - "bombing" httpd with JMeter (from another computer) - copying files from USB memory device to harddisk - copying file with scp Indrek - 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.12-rc2-mm2
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ Wow... it responds despite the load average of 83.63 :) http://www.tuleriit.ee/progs/img/pic1.png http://www.tuleriit.ee/progs/img/pic2.png http://www.tuleriit.ee/progs/img/pic3.png dmesg is not clean though: TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 392 messages suppressed. TCP: time wait bucket table overflow printk: 290 messages suppressed. TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow TCP: time wait bucket table overflow printk: 295 messages suppressed. TCP: time wait bucket table overflow What I did: - bombing httpd with JMeter (from another computer) - copying files from USB memory device to harddisk - copying file with scp Indrek - 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: make OOM more "user friendly"
Matthias-Christian Ott wrote: Diego Calleja schrieb: When people gets OOM messages, many of them don't know what is happening or what OOM means. This brief message explains it. --- stable/mm/oom_kill.c.orig2005-04-02 17:44:14.0 +0200 +++ stable/mm/oom_kill.c2005-04-02 18:01:02.0 +0200 @@ -189,7 +189,8 @@ return; } task_unlock(p); -printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm); +printk(KERN_ERR "The system has run Out Of Memory (RAM + swap), a process will be killed to free some memory\n"); +printk(KERN_ERR "OOM: Killed process %d (%s).\n", p->pid, p->comm); /* * We give our sacrificial lamb high priority and access to - 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/ I disagree this is _not_ usefull. If the user don't knows what OOM means he can use google to get this information. :) Somewhat like "Use your mobile phone to call helpdesk if your mobile phone is broken". Maybe such messages should have some kind of link to information in Documentation/ ? regards, Indrek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Jeff Garzik wrote: Indrek Kruusa wrote: Jeff Garzik wrote: Andi Kleen wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: I won't disagree with your experiences. For me, outside of one brief moment when the r8169 driver didn't work on Athlon64, it has worked flawlessly for me. RealTek 8169 is currently my favorite gigabit chip. It does not seem to support DAC (or rather it breaks with DAC enabled), which makes it not very useful on any machine with >3GB of memory. Driver bug. I can futz with it and get it to do 64-bit on my Athlon64. Continuing with off-topic questions: is this "checksum off-load" usable with r8169? Is there any other reason (performance?) to use hardware TCP/IP checksumming than just "cool, a little chunk of software is hardwired again"? It's usable, and enables "zero copy" feature. I have seen you mentioned that this causes mainly troubles if you try to set it with ethtool. Is it still true? Not sure what you are referring to. Sorry - my brains interpretation was classic rumor case: discussion I remembered was about broken NIC not about enabling hw checksum. I referred to this one: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0369.html Jeff Garzik wrote: Evgeniy Polyakov wrote: Noone will complain on Linux if NIC is broken and produces wrong checksum and HW checksum offloading is enabled using ethtools. Actually, that is a problem and people have definitely complained about it in the past. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Jeff Garzik wrote: Andi Kleen wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: I won't disagree with your experiences. For me, outside of one brief moment when the r8169 driver didn't work on Athlon64, it has worked flawlessly for me. RealTek 8169 is currently my favorite gigabit chip. It does not seem to support DAC (or rather it breaks with DAC enabled), which makes it not very useful on any machine with >3GB of memory. Driver bug. I can futz with it and get it to do 64-bit on my Athlon64. Continuing with off-topic questions: is this "checksum off-load" usable with r8169? Is there any other reason (performance?) to use hardware TCP/IP checksumming than just "cool, a little chunk of software is hardwired again"? I have seen you mentioned that this causes mainly troubles if you try to set it with ethtool. Is it still true? Indrek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Jeff Garzik wrote: Andi Kleen wrote: Jeff Garzik [EMAIL PROTECTED] writes: I won't disagree with your experiences. For me, outside of one brief moment when the r8169 driver didn't work on Athlon64, it has worked flawlessly for me. RealTek 8169 is currently my favorite gigabit chip. It does not seem to support DAC (or rather it breaks with DAC enabled), which makes it not very useful on any machine with 3GB of memory. Driver bug. I can futz with it and get it to do 64-bit on my Athlon64. Continuing with off-topic questions: is this checksum off-load usable with r8169? Is there any other reason (performance?) to use hardware TCP/IP checksumming than just cool, a little chunk of software is hardwired again? I have seen you mentioned that this causes mainly troubles if you try to set it with ethtool. Is it still true? Indrek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Jeff Garzik wrote: Indrek Kruusa wrote: Jeff Garzik wrote: Andi Kleen wrote: Jeff Garzik [EMAIL PROTECTED] writes: I won't disagree with your experiences. For me, outside of one brief moment when the r8169 driver didn't work on Athlon64, it has worked flawlessly for me. RealTek 8169 is currently my favorite gigabit chip. It does not seem to support DAC (or rather it breaks with DAC enabled), which makes it not very useful on any machine with 3GB of memory. Driver bug. I can futz with it and get it to do 64-bit on my Athlon64. Continuing with off-topic questions: is this checksum off-load usable with r8169? Is there any other reason (performance?) to use hardware TCP/IP checksumming than just cool, a little chunk of software is hardwired again? It's usable, and enables zero copy feature. I have seen you mentioned that this causes mainly troubles if you try to set it with ethtool. Is it still true? Not sure what you are referring to. Sorry - my brains interpretation was classic rumor case: discussion I remembered was about broken NIC not about enabling hw checksum. I referred to this one: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0369.html Jeff Garzik wrote: Evgeniy Polyakov wrote: Noone will complain on Linux if NIC is broken and produces wrong checksum and HW checksum offloading is enabled using ethtools. Actually, that is a problem and people have definitely complained about it in the past. - 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: Intel MB + P4 HT: bios processors logo depends on what?
Indrek Kruusa wrote: A bit silly point maybe but it is somewhat interesting what makes BIOS on Intel motherboard decide which processor's logo to display. Situation: a) Fedora Core 4 test1 + kernel-2.6.11-1.1177_FC4smp - going to reboot from fedora the bios shows always processors logo with HT marks b) Mandrake 10.2 rc1 + kernel-2.6.11-5mdksmp - after reboot there is processor logo without HT marks c) Mandrake + kernel-2.6.12-rc1-mm1 (compiled with SMP+SMT) - same as b) There is nothing wrong with those kernels but it is interesting why Fedora's kernel (acpi daemon?) is somewhat special here. There was missing d) Fedora + kernel-2.6.12-rc1-mm1 :) And bios shows that I have hyperthreading processor. It is difference between distros not kernels. Indrek - 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/
Intel MB + P4 HT: bios processors logo depends on what?
A bit silly point maybe but it is somewhat interesting what makes BIOS on Intel motherboard decide which processor's logo to display. Situation: a) Fedora Core 4 test1 + kernel-2.6.11-1.1177_FC4smp - going to reboot from fedora the bios shows always processors logo with HT marks b) Mandrake 10.2 rc1 + kernel-2.6.11-5mdksmp - after reboot there is processor logo without HT marks c) Mandrake + kernel-2.6.12-rc1-mm1 (compiled with SMP+SMT) - same as b) There is nothing wrong with those kernels but it is interesting why Fedora's kernel (acpi daemon?) is somewhat special here. thanks, Indrek - 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/
Intel MB + P4 HT: bios processors logo depends on what?
A bit silly point maybe but it is somewhat interesting what makes BIOS on Intel motherboard decide which processor's logo to display. Situation: a) Fedora Core 4 test1 + kernel-2.6.11-1.1177_FC4smp - going to reboot from fedora the bios shows always processors logo with HT marks b) Mandrake 10.2 rc1 + kernel-2.6.11-5mdksmp - after reboot there is processor logo without HT marks c) Mandrake + kernel-2.6.12-rc1-mm1 (compiled with SMP+SMT) - same as b) There is nothing wrong with those kernels but it is interesting why Fedora's kernel (acpi daemon?) is somewhat special here. thanks, Indrek - 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: Intel MB + P4 HT: bios processors logo depends on what?
Indrek Kruusa wrote: A bit silly point maybe but it is somewhat interesting what makes BIOS on Intel motherboard decide which processor's logo to display. Situation: a) Fedora Core 4 test1 + kernel-2.6.11-1.1177_FC4smp - going to reboot from fedora the bios shows always processors logo with HT marks b) Mandrake 10.2 rc1 + kernel-2.6.11-5mdksmp - after reboot there is processor logo without HT marks c) Mandrake + kernel-2.6.12-rc1-mm1 (compiled with SMP+SMT) - same as b) There is nothing wrong with those kernels but it is interesting why Fedora's kernel (acpi daemon?) is somewhat special here. There was missing d) Fedora + kernel-2.6.12-rc1-mm1 :) And bios shows that I have hyperthreading processor. It is difference between distros not kernels. Indrek - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
> Lee Revell <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > > From: [EMAIL PROTECTED] > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when > > > loading the EMU10K1 driver > > > > > > > > This one is a real mystery. No one can reproduce it. > Not quite true. This bug was current till today in Mandrake's kernel, > but with 2.6.11-5mdk they managed to get rid of it. > The problem is not with loading the driver but when alsactl tries to store/restore > mixer settings. > I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the > Gnome won't start due to this). > Below the oops part from messages. uhh...sorry about that noise. I misread your e-mail. > >/ From: [EMAIL PROTECTED]/ > >/ Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and/ > >/ / > > This one is fixed in ALSA CVS. Here is the patch. I had this problem indeed and of course this patch fixed 2.6.12-rc1-mm1 for me. Thank you and sorry again, Indrek - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: From: [EMAIL PROTECTED] Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver This one is a real mystery. No one can reproduce it. Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. uhh...sorry about that noise. I misread your e-mail. / From: [EMAIL PROTECTED]/ / Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and/ / / This one is fixed in ALSA CVS. Here is the patch. I had this problem indeed and of course this patch fixed 2.6.12-rc1-mm1 for me. Thank you and sorry again, Indrek - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell <[EMAIL PROTECTED]> wrote: > >/ On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/ >/ > From: [EMAIL PROTECTED]/ >/ > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver/ >/ > / >/ / >/ This one is a real mystery. No one can reproduce it./ Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. thanks, Indrek Mar 22 21:05:21 bedroom alsa: succeeded Mar 22 21:05:21 bedroom kernel: Unable to handle kernel NULL pointer dereference at virtual address 000c Mar 22 21:05:21 bedroom kernel: printing eip: Mar 22 21:05:21 bedroom kernel: dfa929e8 Mar 22 21:05:21 bedroom kernel: *pde = Mar 22 21:05:21 bedroom kernel: Oops: [#1] Mar 22 21:05:21 bedroom kernel: SMP Mar 22 21:05:21 bedroom kernel: Modules linked in: snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore af_packet eth1394 e100 mii ide_cd ohci1394 ieee1394 nls_iso8859_15 nls_cp850 vfat fat intel_agp agpgart hw_random emu10k1_gp gameport ata_piix libata ehci_hcd uhci_hcd usbcore evdev Mar 22 21:05:21 bedroom kernel: CPU:0 Mar 22 21:05:21 bedroom kernel: EIP: 0060:[pg0+527297000/1069851648]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EIP:0060:[]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EFLAGS: 00010002 (2.6.12-r1m1) Mar 22 21:05:21 bedroom kernel: EIP is at snd_emu10k1_efx_send_routing_put+0x98/0xd5 [snd_emu10k1] Mar 22 21:05:21 bedroom kernel: eax: ebx: dd6cb1a8 ecx: 000c edx: 0004 Mar 22 21:05:21 bedroom kernel: esi: 0004 edi: ebp: dd6ca000 esp: dce73ed4 Mar 22 21:05:21 bedroom kernel: ds: 007b es: 007b ss: 0068 Mar 22 21:05:21 bedroom kernel: Process alsactl (pid: 5019, threadinfo=dce72000 task=decaa550) Mar 22 21:05:21 bedroom kernel: Stack: dd6ca508 000f 0001 0246 ddc3c14c Mar 22 21:05:21 bedroom kernel:ddfe9200 de1a0440 ddc3c000 dfa18e30 ddfe9200 de1a0400 Mar 22 21:05:21 bedroom kernel: ddfe9200 c01b845c ddfe9200 fff3 decc1180 de1a0400 bf886950 Mar 22 21:05:21 bedroom kernel: Call Trace: Mar 22 21:05:21 bedroom kernel: [pg0+526798384/1069851648] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [copy_from_user+70/126] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [pg0+526798563/1069851648] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [do_ioctl+154/169] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [vfs_ioctl+101/481] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [sys_ioctl+69/109] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: [] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: Code: 24 10 23 4c 90 44 0f b6 04 13 39 c8 74 0b 88 0c 13 c7 44 24 14 01 00 00 00 83 c2 01 39 f2 7c da 8b 44 24 14 85 c0 74 0b 8b 43 38 <8b> 44 b8 0c 85 c0 75 19 8b 44 24 0c 8b 54 24 18 e8 c9 3c 83 e0 - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell [EMAIL PROTECTED] wrote: / On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/ / From: [EMAIL PROTECTED]/ / Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver/ / / / / / This one is a real mystery. No one can reproduce it./ Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. thanks, Indrek Mar 22 21:05:21 bedroom alsa: succeeded Mar 22 21:05:21 bedroom kernel: Unable to handle kernel NULL pointer dereference at virtual address 000c Mar 22 21:05:21 bedroom kernel: printing eip: Mar 22 21:05:21 bedroom kernel: dfa929e8 Mar 22 21:05:21 bedroom kernel: *pde = Mar 22 21:05:21 bedroom kernel: Oops: [#1] Mar 22 21:05:21 bedroom kernel: SMP Mar 22 21:05:21 bedroom kernel: Modules linked in: snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore af_packet eth1394 e100 mii ide_cd ohci1394 ieee1394 nls_iso8859_15 nls_cp850 vfat fat intel_agp agpgart hw_random emu10k1_gp gameport ata_piix libata ehci_hcd uhci_hcd usbcore evdev Mar 22 21:05:21 bedroom kernel: CPU:0 Mar 22 21:05:21 bedroom kernel: EIP: 0060:[pg0+527297000/1069851648]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EIP:0060:[dfa929e8]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EFLAGS: 00010002 (2.6.12-r1m1) Mar 22 21:05:21 bedroom kernel: EIP is at snd_emu10k1_efx_send_routing_put+0x98/0xd5 [snd_emu10k1] Mar 22 21:05:21 bedroom kernel: eax: ebx: dd6cb1a8 ecx: 000c edx: 0004 Mar 22 21:05:21 bedroom kernel: esi: 0004 edi: ebp: dd6ca000 esp: dce73ed4 Mar 22 21:05:21 bedroom kernel: ds: 007b es: 007b ss: 0068 Mar 22 21:05:21 bedroom kernel: Process alsactl (pid: 5019, threadinfo=dce72000 task=decaa550) Mar 22 21:05:21 bedroom kernel: Stack: dd6ca508 000f 0001 0246 ddc3c14c Mar 22 21:05:21 bedroom kernel:ddfe9200 de1a0440 ddc3c000 dfa18e30 ddfe9200 de1a0400 Mar 22 21:05:21 bedroom kernel: ddfe9200 c01b845c ddfe9200 fff3 decc1180 de1a0400 bf886950 Mar 22 21:05:21 bedroom kernel: Call Trace: Mar 22 21:05:21 bedroom kernel: [pg0+526798384/1069851648] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [dfa18e30] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [copy_from_user+70/126] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [c01b845c] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [pg0+526798563/1069851648] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [dfa18ee3] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [do_ioctl+154/169] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [c017352a] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [vfs_ioctl+101/481] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [c01736df] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [sys_ioctl+69/109] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [c01738a0] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: [c01030c7] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: Code: 24 10 23 4c 90 44 0f b6 04 13 39 c8 74 0b 88 0c 13 c7 44 24 14 01 00 00 00 83 c2 01 39 f2 7c da 8b 44 24 14 85 c0 74 0b 8b 43 38 8b 44 b8 0c 85 c0 75 19 8b 44 24 0c 8b 54 24 18 e8 c9 3c 83 e0 - 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: Building server-farm
> I'm looking for a way to connect multiple linux systems > into one big machine (server-farm) and I can't find any > way of enabling it in kernel. It seems that you have to analyse your problem a bit more. There are 5 main types of clusters (or server-farms as you call it): - parallel computing - high availability - load balancing - storage cluster - database cluster Of course these overlap in functionality but so they say :) In many cases those goals are achievable with "share nothing" in kernel level: lam/mpi, ipvs, hartbeat, lvm etc. Well, about filesystems I am not sure at moment :) Please analyse your need to create "as it was one big machine" because maybe it is not the solution you really need. thanks, Indrek - 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: Building server-farm
I'm looking for a way to connect multiple linux systems into one big machine (server-farm) and I can't find any way of enabling it in kernel. It seems that you have to analyse your problem a bit more. There are 5 main types of clusters (or server-farms as you call it): - parallel computing - high availability - load balancing - storage cluster - database cluster Of course these overlap in functionality but so they say :) In many cases those goals are achievable with share nothing in kernel level: lam/mpi, ipvs, hartbeat, lvm etc. Well, about filesystems I am not sure at moment :) Please analyse your need to create as it was one big machine because maybe it is not the solution you really need. thanks, Indrek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
Yes yes yes! It almost seemed that your work on thesis stuff will kill -ac :( Thank you! Indrek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
Yes yes yes! It almost seemed that your work on thesis stuff will kill -ac :( Thank you! Indrek - 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: RFD: Kernel release numbering
> I'd love for the -mm tree to get more testing, but it doesn't. So the question is how to hook up more "customers" for testing thing? mm...maybe OSDL should provide special live mini-distro weekly, which will run entirely from 256 MB USB flashdrive :) Lot of automated testing, lot of nice and colorful progressbars, graphs (it is ubelieveable how people love to watch how defragmentation goes) etc. and you are there :) If the only question is to boot my computer from CD/flash (without touching my harddrive) and pushing at the end "I'm agree to send automatically collected results to OSDL" then you can count me as a tester :) thanks, Indrek - 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: RFD: Kernel release numbering
I'd love for the -mm tree to get more testing, but it doesn't. So the question is how to hook up more customers for testing thing? mm...maybe OSDL should provide special live mini-distro weekly, which will run entirely from 256 MB USB flashdrive :) Lot of automated testing, lot of nice and colorful progressbars, graphs (it is ubelieveable how people love to watch how defragmentation goes) etc. and you are there :) If the only question is to boot my computer from CD/flash (without touching my harddrive) and pushing at the end I'm agree to send automatically collected results to OSDL then you can count me as a tester :) thanks, Indrek - 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: disabling Hyperthreading online
regatta wrote: Hi Is there anyway to disable CPU Hyperthreading without rebooting the system ? You can find possible hint here: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.0/1071.html regards, Indrek - 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: disabling Hyperthreading online
regatta wrote: Hi Is there anyway to disable CPU Hyperthreading without rebooting the system ? You can find possible hint here: http://www.ussg.iu.edu/hypermail/linux/kernel/0501.0/1071.html regards, Indrek - 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/
[QUESTION - FYI] Vectorized CRC calculation
Hi! First, sorry about the so-so topic for the kernel developers...but still there are such things inside :) Currently I am investigating how "they" divide those polynomials and which possibilities exists to use SIMD for such calculations. I have found several papers about how to do it with Altivec and my question is: does anybody knows about efforts to use Altivec for CRC calculations here? Topic itself is quite old... Or is there just any other ongoing developments which implements for example permute/shuffle instructions (Altivec: vperm/SSE2: pshufd) for table lookups? One more question: is there PCI/PCIe cards (eg. router) which implements Layer 3(-4) in hardware and which are possible to use as "hardware net accelerator"? thanks, Indrek Links --- Most latest updated C code CRC calculation I have found http://lxr.mozilla.org/seamonkey/source/modules/zlib/src/crc32.c "TCP/IP checksum vectorization using AltiVec" http://www.ibm.com/technology/power/newsletter/october2004/files/web.pdf "Altivec extension to powerpc accelerates media processing" (includes hints for table lookup code) http://ccrc.wustl.edu/~jefritts/CS525_SP03/readings/altivec.pdf - 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/
[QUESTION - FYI] Vectorized CRC calculation
Hi! First, sorry about the so-so topic for the kernel developers...but still there are such things inside :) Currently I am investigating how they divide those polynomials and which possibilities exists to use SIMD for such calculations. I have found several papers about how to do it with Altivec and my question is: does anybody knows about efforts to use Altivec for CRC calculations here? Topic itself is quite old... Or is there just any other ongoing developments which implements for example permute/shuffle instructions (Altivec: vperm/SSE2: pshufd) for table lookups? One more question: is there PCI/PCIe cards (eg. router) which implements Layer 3(-4) in hardware and which are possible to use as hardware net accelerator? thanks, Indrek Links --- Most latest updated C code CRC calculation I have found http://lxr.mozilla.org/seamonkey/source/modules/zlib/src/crc32.c TCP/IP checksum vectorization using AltiVec http://www.ibm.com/technology/power/newsletter/october2004/files/web.pdf Altivec extension to powerpc accelerates media processing (includes hints for table lookup code) http://ccrc.wustl.edu/~jefritts/CS525_SP03/readings/altivec.pdf - 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/
