[PATCH] Against sk98lin driver from syskonnect [was: Re: PCI-Express not working/unuseable on Intel 925XE since 2.6.12-rc1[mm1-4]]
Bjorn Helgaas napisaÅ(a):
>>Version from syskonnect site require only changing usage of
>>pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After
>>that everything should work fine. So I think there is no need to post my
>>path here but if you really whant I may do this. Whole path agains
>>2.6.12-rc2 take about 1.2 MB (diffstat attached below).
>
>
> I agree, no need to post a whole 1.2MB patch (goodness, what's
> in this driver, anyway, that it would need a 1.2MB *patch*? :-))
I'm wondering too :)
> But you seem to be saying that the driver from syskonnect (and possibly
> the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have
> a small patch that makes it work.
The one that is in 2.6.12-rc1-bk2 and latest 2.6.13-rc2 doesn't work
with Marvell Yukon 88E8053 GigE.
Attached patch convert pci_dev->slot_name usage to pci_name() in skge.c
and skethtool.c. First you must apply patch generated by install script
and after that apply this patch:-)
Regards
Jacek
---
drivers/net/sk98lin/skethtool.c |2 +-
drivers/net/sk98lin/skge.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
--- linux-2.6.12-rc2/drivers/net/sk98lin/skge.c 2005-04-09 14:49:39.0
+0200
+++ linux/drivers/net/sk98lin/skge.c2005-04-09 02:04:49.0 +0200
@@ -4026,7 +4026,7 @@
*/
* ((SK_U32 *)pMemBuf) = 0;
* ((SK_U32 *)pMemBuf + 1) = pdev->bus->number;
- * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pdev->slot_name);
+ * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pci_name(pdev));
if(copy_to_user(Ioctl.pData, pMemBuf, Length) ) {
Err = -EFAULT;
goto fault_diag;
--- linux-2.6.12-rc2/drivers/net/sk98lin/skethtool.c2005-04-09
14:49:39.0 +0200
+++ linux/drivers/net/sk98lin/skethtool.c 2005-04-09 02:04:49.0
+0200
@@ -1136,7 +1136,7 @@
strncpy(edrvinfo->driver, DRIVER_FILE_NAME , 32);
strncpy(edrvinfo->version, versionString , 32);
strncpy(edrvinfo->fw_version, "N/A", 32);
- strncpy(edrvinfo->bus_info, pAC->PciDev->slot_name, 32);
+ strncpy(edrvinfo->bus_info, pci_name(pAC->PciDev), 32);
#ifdef ETHTOOL_GSTATS
edrvinfo->n_stats = SK98LIN_STATS_LEN;
#endif
[PATCH] Against sk98lin driver from syskonnect [was: Re: PCI-Express not working/unuseable on Intel 925XE since 2.6.12-rc1[mm1-4]]
Bjorn Helgaas napisa(a):
Version from syskonnect site require only changing usage of
pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After
that everything should work fine. So I think there is no need to post my
path here but if you really whant I may do this. Whole path agains
2.6.12-rc2 take about 1.2 MB (diffstat attached below).
I agree, no need to post a whole 1.2MB patch (goodness, what's
in this driver, anyway, that it would need a 1.2MB *patch*? :-))
I'm wondering too :)
But you seem to be saying that the driver from syskonnect (and possibly
the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have
a small patch that makes it work.
The one that is in 2.6.12-rc1-bk2 and latest 2.6.13-rc2 doesn't work
with Marvell Yukon 88E8053 GigE.
Attached patch convert pci_dev-slot_name usage to pci_name() in skge.c
and skethtool.c. First you must apply patch generated by install script
and after that apply this patch:-)
Regards
Jacek
---
drivers/net/sk98lin/skethtool.c |2 +-
drivers/net/sk98lin/skge.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
--- linux-2.6.12-rc2/drivers/net/sk98lin/skge.c 2005-04-09 14:49:39.0
+0200
+++ linux/drivers/net/sk98lin/skge.c2005-04-09 02:04:49.0 +0200
@@ -4026,7 +4026,7 @@
*/
* ((SK_U32 *)pMemBuf) = 0;
* ((SK_U32 *)pMemBuf + 1) = pdev-bus-number;
- * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pdev-slot_name);
+ * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pci_name(pdev));
if(copy_to_user(Ioctl.pData, pMemBuf, Length) ) {
Err = -EFAULT;
goto fault_diag;
--- linux-2.6.12-rc2/drivers/net/sk98lin/skethtool.c2005-04-09
14:49:39.0 +0200
+++ linux/drivers/net/sk98lin/skethtool.c 2005-04-09 02:04:49.0
+0200
@@ -1136,7 +1136,7 @@
strncpy(edrvinfo-driver, DRIVER_FILE_NAME , 32);
strncpy(edrvinfo-version, versionString , 32);
strncpy(edrvinfo-fw_version, N/A, 32);
- strncpy(edrvinfo-bus_info, pAC-PciDev-slot_name, 32);
+ strncpy(edrvinfo-bus_info, pci_name(pAC-PciDev), 32);
#ifdef ETHTOOL_GSTATS
edrvinfo-n_stats = SK98LIN_STATS_LEN;
#endif
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: > On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: > >>Michael Thonke napisał(a): >> >>>Hello Jacek, >>> >>>I finially got it working :-) my PCI-Express devices working now... >>>I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia >>>everything except the Marvell Yokon PCI-E device working. >>>I hope Andrew will look into the mm-line to find the bug? >>> >> >>I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by >>myself :]) driver from syskonnect. If you wont I may send it to you! > > > Please post your patch here and copy the maintainers: > > MARVELL YUKON / SYSKONNECT DRIVER > P: Mirko Lindner > M: [EMAIL PROTECTED] > P: Ralph Roesler > M: [EMAIL PROTECTED] > W: http://www.syskonnect.com > S: Supported > > > Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Please post your patch here and copy the maintainers: MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [EMAIL PROTECTED] P: Ralph Roesler M: [EMAIL PROTECTED] W: http://www.syskonnect.com S: Supported Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - 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: forkbombing Linux distributions
Natanael Copa napisał(a): > On Thu, 2005-03-31 at 12:11 -0500, Lee Revell wrote: > > >>Didn't you ever look up what a ulimit is? > > > ofcourse i did. I just think that ulimit (or other userspace tools) > should be used to *raise* the limit if you need more. Not the reverse. > > >>If you consider your distro's default ulimits unreasonable, file a bug >>report with them. But no one is going to make Linux "restrictive by >>default" to make life easier for people who don't bother to RTFM. > > > I already suggested ulimit solutions for my distro. They think that if > this is needed the kernel dev's would do something (ie its a kernel > problem) while the kernel dev's says this is a userspace prob. > > I wouldn't bother if this was a problem for one or two distros only. > Now, almost all distros seems to be vulnerable by default. > > I wouldn't bother if other *nixes would set this limit in userspace. > (the BSD's set the limit lower in kernel and let users who need more > raise with userland tools) > > I wouldn't bother if this wouldn't give Linux a bad reputation. > > I'm Sorry if I made some people upset. > > -- > Natanael Copa > > You have absolutely right!!! Even if 'good' ulimit is set there isn't anything bad in adding ulimit-like mechanism into kernel. Long live ... hmm... kernel, not ulimit:) Best regards, Jacek - 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: forkbombing Linux distributions
Natanael Copa napisa(a): On Thu, 2005-03-31 at 12:11 -0500, Lee Revell wrote: Didn't you ever look up what a ulimit is? ofcourse i did. I just think that ulimit (or other userspace tools) should be used to *raise* the limit if you need more. Not the reverse. If you consider your distro's default ulimits unreasonable, file a bug report with them. But no one is going to make Linux restrictive by default to make life easier for people who don't bother to RTFM. I already suggested ulimit solutions for my distro. They think that if this is needed the kernel dev's would do something (ie its a kernel problem) while the kernel dev's says this is a userspace prob. I wouldn't bother if this was a problem for one or two distros only. Now, almost all distros seems to be vulnerable by default. I wouldn't bother if other *nixes would set this limit in userspace. (the BSD's set the limit lower in kernel and let users who need more raise with userland tools) I wouldn't bother if this wouldn't give Linux a bad reputation. I'm Sorry if I made some people upset. -- Natanael Copa You have absolutely right!!! Even if 'good' ulimit is set there isn't anything bad in adding ulimit-like mechanism into kernel. Long live ... hmm... kernel, not ulimit:) Best regards, Jacek - 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: Something wrong with 2.6.12-rc1-RT-V0.7.43-05
Jacek Luczak napisaÅ(a): Matan Peled napisaÅ(a): Jacek Luczak wrote: Hi Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I sow in dmesg after 6 hours of computers work: Hmm... A lot of that seems to involve ndiswrapper. Is there any way you could reproduce this without ndiswrapper loaded? I will try and send it back. It seems that everything is involve by ndiswrapper. Those errors reappear after module load. Without ndiswrapper kernel works OK. Jacek - 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/
Something wrong with 2.6.12-rc1-RT-V0.7.43-05
Hi Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I sow in dmesg after 6 hours of computers work: BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] kmem_cache_alloc+0x3b/0x120 (44) [] NdisMIndicateReceivePacket+0x189/0x3d0 [ndiswrapper] (60) [] 0xdee3a58d (628) [] 0xdee35acf (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: ksoftirqd/1/0x0001/6 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] __mod_timer+0x128/0x170 (44) [] wrapper_set_timer+0x157/0x250 [ndiswrapper] (44) [] NdisSetTimer+0x43/0x50 [ndiswrapper] (24) [] 0xdee43ab7 (32) [] wrapper_timer_handler+0x119/0x250 [ndiswrapper] (44) [] run_timer_softirq+0x1f5/0x420 (56) [] ___do_softirq+0xd3/0x130 (44) [] _do_softirq+0x29/0x30 (8) [] ksoftirqd+0xd1/0x160 (28) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052344340) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] kmem_cache_alloc+0x3b/0x120 (44) [] alloc_skb+0x28/0xf0 (32) [] NdisMIndicateReceivePacket+0x64/0x3d0 [ndiswrapper] (60) [] 0xdee3a58d (628) [] 0xdee35acf (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] kmem_cache_alloc+0x3b/0x120 (44) [] NdisMIndicateReceivePacket+0x189/0x3d0 [ndiswrapper] (60) [] 0xdee3a58d (628) [] 0xdee35acf (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] kmem_cache_alloc+0x3b/0x120 (44) [] alloc_skb+0x28/0xf0 (32) [] NdisMIndicateReceivePacket+0x64/0x3d0 [ndiswrapper] (60) [] 0xdee3a58d (628) [] 0xdee35acf (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: ksoftirqd/1/0x0001/6 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] __mod_timer+0x128/0x170 (44) [] wrapper_set_timer+0x157/0x250 [ndiswrapper] (44) [] NdisSetTimer+0x43/0x50 [ndiswrapper] (24) [] 0xdee43ab7 (32) [] wrapper_timer_handler+0x119/0x250 [ndiswrapper] (44) [] run_timer_softirq+0x1f5/0x420 (56) [] ___do_softirq+0xd3/0x130 (44) [] _do_softirq+0x29/0x30 (8) [] ksoftirqd+0xd1/0x160 (28) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052344340) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] __kmalloc+0x69/0x150 (44) [] alloc_skb+0x4d/0xf0 (32) [] NdisMIndicateReceivePacket+0x64/0x3d0 [ndiswrapper] (60) [] 0xdee3a58d (628) [] 0xdee35acf (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) [] kthread+0xbb/0xc0 (48) [] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [] dump_stack+0x23/0x30 (20) [] __schedule+0xe53/0xeb0 (124) [] schedule+0x40/0x140 (36) [] __down_mutex+0x2c6/0x370 (92) [] __spin_lock+0x36/0x50 (24) [] _spin_lock+0x1d/0x30 (16) [] kfree+0x78/0x180 (48) [] free_send_packet+0x2e/0x80 [ndiswrapper] (32) [] sendpacket_done+0x49/0x60 [ndiswrapper] (24) [] NdisMSendComplete+0x20/0x40 [ndiswrapper] (20) [] 0xdee38d53 (32) [] 0xdee48683 (88) [] 0xdee35ad5 (28) [] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [] worker_thread+0x1b1/0x270 (128) []
Something wrong with 2.6.12-rc1-RT-V0.7.43-05
Hi Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I sow in dmesg after 6 hours of computers work: BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0154cdb] kmem_cache_alloc+0x3b/0x120 (44) [dede8d49] NdisMIndicateReceivePacket+0x189/0x3d0 [ndiswrapper] (60) [dee3a58d] 0xdee3a58d (628) [dee35acf] 0xdee35acf (28) [dede8583] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [c0131241] worker_thread+0x1b1/0x270 (128) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: ksoftirqd/1/0x0001/6 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0128f18] __mod_timer+0x128/0x170 (44) [dede4417] wrapper_set_timer+0x157/0x250 [ndiswrapper] (44) [dede8243] NdisSetTimer+0x43/0x50 [ndiswrapper] (24) [dee43ab7] 0xdee43ab7 (32) [dede4079] wrapper_timer_handler+0x119/0x250 [ndiswrapper] (44) [c0129a15] run_timer_softirq+0x1f5/0x420 (56) [c0125033] ___do_softirq+0xd3/0x130 (44) [c0125159] _do_softirq+0x29/0x30 (8) [c0125771] ksoftirqd+0xd1/0x160 (28) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052344340) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0154cdb] kmem_cache_alloc+0x3b/0x120 (44) [c02d2538] alloc_skb+0x28/0xf0 (32) [dede8c24] NdisMIndicateReceivePacket+0x64/0x3d0 [ndiswrapper] (60) [dee3a58d] 0xdee3a58d (628) [dee35acf] 0xdee35acf (28) [dede8583] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [c0131241] worker_thread+0x1b1/0x270 (128) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0154cdb] kmem_cache_alloc+0x3b/0x120 (44) [dede8d49] NdisMIndicateReceivePacket+0x189/0x3d0 [ndiswrapper] (60) [dee3a58d] 0xdee3a58d (628) [dee35acf] 0xdee35acf (28) [dede8583] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [c0131241] worker_thread+0x1b1/0x270 (128) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0154cdb] kmem_cache_alloc+0x3b/0x120 (44) [c02d2538] alloc_skb+0x28/0xf0 (32) [dede8c24] NdisMIndicateReceivePacket+0x64/0x3d0 [ndiswrapper] (60) [dee3a58d] 0xdee3a58d (628) [dee35acf] 0xdee35acf (28) [dede8583] ndis_irq_bh+0x63/0x100 [ndiswrapper] (24) [c0131241] worker_thread+0x1b1/0x270 (128) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052311572) BUG: scheduling while atomic: ksoftirqd/1/0x0001/6 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0128f18] __mod_timer+0x128/0x170 (44) [dede4417] wrapper_set_timer+0x157/0x250 [ndiswrapper] (44) [dede8243] NdisSetTimer+0x43/0x50 [ndiswrapper] (24) [dee43ab7] 0xdee43ab7 (32) [dede4079] wrapper_timer_handler+0x119/0x250 [ndiswrapper] (44) [c0129a15] run_timer_softirq+0x1f5/0x420 (56) [c0125033] ___do_softirq+0xd3/0x130 (44) [c0125159] _do_softirq+0x29/0x30 (8) [c0125771] ksoftirqd+0xd1/0x160 (28) [c013626b] kthread+0xbb/0xc0 (48) [c01013f9] kernel_thread_helper+0x5/0xc (1052344340) BUG: scheduling while atomic: events/0/0x0001/8 caller is schedule+0x40/0x140 [c0104333] dump_stack+0x23/0x30 (20) [c032ba03] __schedule+0xe53/0xeb0 (124) [c032baa0] schedule+0x40/0x140 (36) [c032cde6] __down_mutex+0x2c6/0x370 (92) [c013c2f6] __spin_lock+0x36/0x50 (24) [c013c32d] _spin_lock+0x1d/0x30 (16) [c0154e89] __kmalloc+0x69/0x150 (44) [c02d255d] alloc_skb+0x4d/0xf0 (32) [dede8c24] NdisMIndicateReceivePacket+0x64/0x3d0
Re: Something wrong with 2.6.12-rc1-RT-V0.7.43-05
Jacek Luczak napisa(a): Matan Peled napisa(a): Jacek Luczak wrote: Hi Early morning i made a 2.6.12-rc1 with RT-V0.7.43-05 and this is what I sow in dmesg after 6 hours of computers work: SNIP! Hmm... A lot of that seems to involve ndiswrapper. Is there any way you could reproduce this without ndiswrapper loaded? I will try and send it back. It seems that everything is involve by ndiswrapper. Those errors reappear after module load. Without ndiswrapper kernel works OK. Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisaÅ(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisaÅ(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02,
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisa(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00,
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Jacek - 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/
