On Mon, 2007-06-04 at 09:09 -0700, Stephen Hemminger wrote:
> > > I did the test with an 2.6.22-rc3-git4 kernel and the p54 driver built
> > > external as module.
> >
> > Can you look at iperf to figure out, whether it does some weird timer
> > stuff (high frequency interval timer or such) ?
On Mon, 04 Jun 2007 08:39:48 +0200
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
> > > Is there any other strange behavior of the high res enabled kernel than
> > > the b44 problem ?
> >
> > I didn't notice anything in the past (as I
On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
> > Is there any other strange behavior of the high res enabled kernel than
> > the b44 problem ?
>
> I didn't notice anything in the past (as I wrote). But today I did some tests
> for an updated version of the p54 mac80211 wlan
On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
Is there any other strange behavior of the high res enabled kernel than
the b44 problem ?
I didn't notice anything in the past (as I wrote). But today I did some tests
for an updated version of the p54 mac80211 wlan driver
On Mon, 04 Jun 2007 08:39:48 +0200
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
Is there any other strange behavior of the high res enabled kernel than
the b44 problem ?
I didn't notice anything in the past (as I wrote). But
On Mon, 2007-06-04 at 09:09 -0700, Stephen Hemminger wrote:
I did the test with an 2.6.22-rc3-git4 kernel and the p54 driver built
external as module.
Can you look at iperf to figure out, whether it does some weird timer
stuff (high frequency interval timer or such) ? Either check
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > > following combinations on the kernel command line:
> > >
> > > 1) highres=off nohz=off (should be the
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
following combinations on the kernel command line:
1) highres=off nohz=off (should be the same as your
On Tuesday 29 May 2007 23:36:51 Gary Zambrano wrote:
> On Tue, 2007-05-29 at 18:39 -0400, Jeff Garzik wrote:
>
> > We check for 0x because that is often how a fault is indicated,
> > when the memory location is read during or immediately after hotplug (or
> > if the PCI bus is truly
On Tuesday 29 May 2007 23:36:51 Gary Zambrano wrote:
On Tue, 2007-05-29 at 18:39 -0400, Jeff Garzik wrote:
We check for 0x because that is often how a fault is indicated,
when the memory location is read during or immediately after hotplug (or
if the PCI bus is truly faulty).
On Tue, 2007-05-29 at 18:39 -0400, Jeff Garzik wrote:
> We check for 0x because that is often how a fault is indicated,
> when the memory location is read during or immediately after hotplug (or
> if the PCI bus is truly faulty). So for most hardware, you see
>
> tmp = read(irq
Gary Zambrano wrote:
The b44 interrupt status reg returns a value of 0 if no interrupts are
pending. The b44 uses a mask to determine which bits (events) can
generate device interrupts on the system. If the masked interrupt status
register bits are not asserted, then the b44 will return to the
On Tue, 2007-05-29 at 22:45 +0200, Michael Buesch wrote:
> On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
> > On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
> > > On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
> > > > On Monday 28 May 2007, Michael Buesch wrote:
> > >
I am busy bisecting the real cause. Unfortunately, oprofile doesn't work
on the laptop, and build time sucks...
This how I think the IRQ should work:
--- a/drivers/net/b44.c 2007-05-29 09:47:53.0 -0700
+++ b/drivers/net/b44.c 2007-05-29 09:49:50.0 -0700
@@ -908,9 +908,11 @@
On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
> On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
> > On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
> > > On Monday 28 May 2007, Michael Buesch wrote:
> > > > Can you also test the following patch?
> > > > I think there's
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
> > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > > > Timer, but the high ping problem is still there.
> > >
> > > Hmm, that's mysterious. Wild guess is
On Tuesday 29 May 2007, Gary Zambrano wrote:
> On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote:
> > On Monday 28 May 2007, Thomas Gleixner wrote:
> > > On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > > > Can you please keep CONFIG_HIGH_RES_TIMERS and
On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
> On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
> > On Monday 28 May 2007, Michael Buesch wrote:
> > > Can you also test the following patch?
> > > I think there's a bug in b44 that is doesn't properly discard
> > > shared
On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote:
> On Monday 28 May 2007, Thomas Gleixner wrote:
> > On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > > > following combinations on the
On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote:
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
following combinations on the kernel
On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it
On Tuesday 29 May 2007, Gary Zambrano wrote:
On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote:
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
Timer, but the high ping problem is still there.
Hmm, that's mysterious. Wild guess is that highres
On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44
I am busy bisecting the real cause. Unfortunately, oprofile doesn't work
on the laptop, and build time sucks...
This how I think the IRQ should work:
--- a/drivers/net/b44.c 2007-05-29 09:47:53.0 -0700
+++ b/drivers/net/b44.c 2007-05-29 09:49:50.0 -0700
@@ -908,9 +908,11 @@
On Tue, 2007-05-29 at 22:45 +0200, Michael Buesch wrote:
On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you
Gary Zambrano wrote:
The b44 interrupt status reg returns a value of 0 if no interrupts are
pending. The b44 uses a mask to determine which bits (events) can
generate device interrupts on the system. If the masked interrupt status
register bits are not asserted, then the b44 will return to the
On Tue, 2007-05-29 at 18:39 -0400, Jeff Garzik wrote:
We check for 0x because that is often how a fault is indicated,
when the memory location is read during or immediately after hotplug (or
if the PCI bus is truly faulty). So for most hardware, you see
tmp = read(irq status)
if
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
> > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > > Timer, but the high ping problem is still there.
> >
> > Hmm, that's mysterious. Wild guess is that highres exposes the hidden
> > "feature" in a
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
> > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > > Timer, but the high ping problem is still there.
> >
> > Hmm, that's mysterious. Wild guess is that highres exposes the hidden
> > "feature" in a
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > > following combinations on the kernel command line:
> > >
> > > 1) highres=off nohz=off (should be the
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > following combinations on the kernel command line:
> >
> > 1) highres=off nohz=off (should be the same as your working config)
> > 2) highres=off
> > 3)
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
> > > The -oldconfig1 is the kernel that had no problems and the other shows
> > > the b44 problem. So if High Resolution Timer Support is disabled
> > > everything works fine and if I enable
On Monday 28 May 2007 17:32:51 Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
> > > The -oldconfig1 is the kernel that had no problems and the other shows
> > > the b44
> > > problem. So if High Resolution Timer Support is disabled everything works
> > > fine
On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
> > The -oldconfig1 is the kernel that had no problems and the other shows the
> > b44
> > problem. So if High Resolution Timer Support is disabled everything works
> > fine and if I enable it the problems do appear again.
> >
> > I
On Monday 28 May 2007 16:09:46 Maximilian Engelhardt wrote:
> On Monday 28 May 2007, Michael Buesch wrote:
> > Can you give 2.6.16 a try? The diff is not that big and we might
> > be able to find out what broke if you find out 2.6.16 works.
> > You can also try later kernels like .17, .18, .19 to
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
> On Monday 28 May 2007, Michael Buesch wrote:
> > Can you also test the following patch?
> > I think there's a bug in b44 that is doesn't properly discard
> > shared IRQs, so it might possibly generate a NAPI storm, dunno.
> > Worth a
On Monday 28 May 2007, Michael Buesch wrote:
> Can you also test the following patch?
> I think there's a bug in b44 that is doesn't properly discard
> shared IRQs, so it might possibly generate a NAPI storm, dunno.
> Worth a try.
>
> Index: linux-2.6.22-rc3/drivers/net/b44.c
>
On Monday 28 May 2007, Michael Buesch wrote:
> Can you give 2.6.16 a try? The diff is not that big and we might
> be able to find out what broke if you find out 2.6.16 works.
> You can also try later kernels like .17, .18, .19 to further
> reduce the patch. (You could also git-bisect, if you have
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try.
Index: linux-2.6.22-rc3/drivers/net/b44.c
===
---
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
reduce the patch. (You could also git-bisect, if you have the time).
git-diff v2.6.16..v2.6.22-rc3
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
reduce the patch. (You could also git-bisect, if you have the time).
git-diff v2.6.16..v2.6.22-rc3
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try.
Index: linux-2.6.22-rc3/drivers/net/b44.c
===
---
On Monday 28 May 2007, Michael Buesch wrote:
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
reduce the patch. (You could also git-bisect, if you have the
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try.
Index: linux-2.6.22-rc3/drivers/net/b44.c
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try.
On Monday 28 May 2007 16:09:46 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
The -oldconfig1 is the kernel that had no problems and the other shows the
b44
problem. So if High Resolution Timer Support is disabled everything works
fine and if I enable it the problems do appear again.
I didn't test this
On Monday 28 May 2007 17:32:51 Thomas Gleixner wrote:
On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
The -oldconfig1 is the kernel that had no problems and the other shows
the b44
problem. So if High Resolution Timer Support is disabled everything works
fine and if I
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
The -oldconfig1 is the kernel that had no problems and the other shows
the b44 problem. So if High Resolution Timer Support is disabled
everything works fine and if I enable it the
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
following combinations on the kernel command line:
1) highres=off nohz=off (should be the same as your working config)
2) highres=off
3) nohz=off
I
On Monday 28 May 2007, Thomas Gleixner wrote:
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
following combinations on the kernel command line:
1) highres=off nohz=off (should be the same as your
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
Timer, but the high ping problem is still there.
Hmm, that's mysterious. Wild guess is that highres exposes the hidden
feature in a different way than
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
Timer, but the high ping problem is still there.
Hmm, that's mysterious. Wild guess is that highres exposes the hidden
feature in a different way than
On Monday 28 May 2007, Michael Buesch wrote:
> Ok, another question: On which CPU architecture are you?
[EMAIL PROTECTED]:~$ uname -m
i686
Maxi
signature.asc
Description: This is a digitally signed message part.
Ok, another question: On which CPU architecture are you?
--
Greetings Michael.
-
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
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.21.1:
> > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> > [ 4] local 192.168.1.2 port 5001 connected
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
> > On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > > 2.6.21.1:
> > > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > > [ 5] 0.0-60.6 sec 1.13 MBytes
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
> > When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in
> > normal use I didn't notice any problems. It did work fine as I would
> > expect it. I think the wget and ping
On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.21.1:
> > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> > [ 4] local 192.168.1.2 port 5001
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> 2.6.21.1:
> [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 57837
> [ 4] 0.0-63.1 sec
On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
> When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in normal
> use I didn't notice any problems. It did work fine as I would expect it.
> I think the wget and ping tests here are as they should be.
>
> With
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.22-rc3:
> >
> > [ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
> > [ 4] local 192.168.1.2 port 5001
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> 2.6.22-rc3:
>
> [ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
> [ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
> [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 51633
> [ 4] 0.0-63.1 sec
I send this again because my first mail accidently had html code in it and
might have been filtered by some people.
On Saturday 26 May 2007, Michael Buesch wrote:
> On Saturday 26 May 2007 02:24:31 Stephen Hemminger wrote:
> > Something is broken with the b44 driver in 2.6.22-rc1 or later. Now
>
I send this again because my first mail accidently had html code in it and
might have been filtered by some people.
On Saturday 26 May 2007, Michael Buesch wrote:
On Saturday 26 May 2007 02:24:31 Stephen Hemminger wrote:
Something is broken with the b44 driver in 2.6.22-rc1 or later. Now
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.22-rc3:
[ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
[ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 51633
[ 4] 0.0-63.1 sec 7.27
On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in normal
use I didn't notice any problems. It did work fine as I would expect it.
I think the wget and ping tests here are as they should be.
With 2.6.22-rc2-mm1 I
On Sunday 27 May 2007, Michael Buesch wrote:
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.22-rc3:
[ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
[ 4] local 192.168.1.2 port 5001 connected with
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
[ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 57837
[ 4] 0.0-63.1 sec 2.82
On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
[ 4] local 192.168.1.2 port 5001 connected
On Sunday 27 May 2007, Michael Buesch wrote:
On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in
normal use I didn't notice any problems. It did work fine as I would
expect it. I think the wget and ping tests here
On Sunday 27 May 2007, Michael Buesch wrote:
On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157
On Sunday 27 May 2007, Michael Buesch wrote:
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
[ 4] local 192.168.1.2 port 5001 connected with
Ok, another question: On which CPU architecture are you?
--
Greetings Michael.
-
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
On Monday 28 May 2007, Michael Buesch wrote:
Ok, another question: On which CPU architecture are you?
[EMAIL PROTECTED]:~$ uname -m
i686
Maxi
signature.asc
Description: This is a digitally signed message part.
76 matches
Mail list logo
