1 Jan
2006
1 Jan
'06
12:42 a.m.
I bought a wireless PCMCIA card and had the oddest things happen when
I load the module. As soon as I do that it seems like all programs
get put on hold. When I move the mouse or press a key on the keyboard
they activate. For instance, if mozilla is loading a site you have to
move the mouse all over the place or it just hangs there doing nothing
... not even an indicator. The text input cursor in applications
stays in the on/off value it was in and starts blinking again when you
move the mouse. Trying to get out of X and reboot is not possible
because the whole system hangs as soon as it stops listening to the
mouse and keyboard.
This consistently happens when that driver is loaded but I thought
maybe it could be RT related? AFAICT the threads for the IRQs the
card is on are not currently set high ... though until I let emerge
mess up my system I think it would have because I believe that is the
same IRQ for my soundcard.
Anyway, I have never seen this type of thing happen. It seems
obviously to be an interrupt based issue (like unless the mouse or
keyboard interrupts the system the kernel seems to get stuck trying to
talk with the card or something) so right now I am wondering about the
RT patch. What do you guys think?
1:48 p.m.
On 12/31/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts wrote:
rt2500
I bought a wireless PCMCIA card and had the
oddest things happen when
I load the module.
Which module?
Do you have latency tracing enabled? If so what does it say? Can you
test without the RT patch?
I believe I have tracing enabled but I have no idea how to find out
what it says.
I suppose I could recomp the kernel w/o RT. It will take a while
though, I have to download the clean source again.
2:08 p.m.
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
On 12/31/05, Lee Revell <rlrevell(a)joe-job.com>
wrote:
I don't see this in the kernel source tree.
Lee
On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts
wrote:
rt2500 I bought a wireless PCMCIA card and had the
oddest things happen when
I load the module.
Which module?
3:19 p.m.
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
You can get it at http://rt2x00.serialmonkey.com as it isn't part of
the mainline kernel but is a special driver for this PCMCIA card. The
module I posted about was a different one (the one I tested before was
actually the rt2500 driver, the latest beta is supposed to be a catch
all for any version of these chipsets), but I just tried this one too
and it did the same thing to me so the problem is the same.
I am upgrading to the latest and greatest version of everything to see
if this helps. I had other RT problems with this kernel anyway.
Also, I apparently didn't set the trace options as those files didn't
exist for me. Big windstorm brewing too...might not get to finish
today (power might go out). I'll post more when I can. Thanks for
helping.
On 12/31/05, Lee Revell
<rlrevell(a)joe-job.com> wrote:
I don't see this in the kernel source tree. On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts
wrote:
rt2500 I bought a wireless PCMCIA card and had the
oddest things happen when
I load the module.
Which module?
3:48 p.m.
On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
That driver looks like a piece of junk. It's clearly a quick and dirty
port of Windows code (the comments refer to running in "DPC context" and
IRQ priority levels which do not exist on Linux). And there seems to be
nothing stopping it from doing a LOT of work in (soft) IRQ context, like
decryption.
I don't understand why these developers would choose to develop their
driver outside the Linux kernel. It obviously will need a LOT of work
to be mergeable.
Lee
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts
wrote:
You can get it at http://rt2x00.serialmonkey.com as it isn't part of
the mainline kernel but is a special driver for this PCMCIA card. The
module I posted about was a different one (the one I tested before was
actually the rt2500 driver, the latest beta is supposed to be a catch
all for any version of these chipsets), but I just tried this one too
and it did the same thing to me so the problem is the same.
I am upgrading to the latest and greatest version of everything to see
if this helps. I had other RT problems with this kernel anyway.
Also, I apparently didn't set the trace options as those files didn't
exist for me. Big windstorm brewing too...might not get to finish
today (power might go out). I'll post more when I can. Thanks for
helping.
On 12/31/05, Lee Revell
<rlrevell(a)joe-job.com> wrote:
I don't see this in the kernel source tree. On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts
wrote:
> I bought a wireless PCMCIA card and had the oddest things happen when
> I load the module.
Which module?
rt2500
4:25 p.m.
On Sun, 2006-01-01 at 15:48 -0500, Lee Revell wrote:
On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
It seems that the developers agree with me that the current driver is
garbage. The version you are using is not developed anymore. Upon
further inspection, rather than use a Linux bottom half mechanism like
workqueues, tasklets, or softirqs to perform the work that the comments
say should be done in DPC context, it just runs them all in hardirq
context with interrupts disabled. This would certainly make it a
problem for use in low latency systems.
Maybe you can try the beta driver:
http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00_beta
Lee
On 1/1/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
That driver looks like a piece of junk. It's clearly a quick and dirty
port of Windows code (the comments refer to running in "DPC context" and
IRQ priority levels which do not exist on Linux). And there seems to be
nothing stopping it from doing a LOT of work in (soft) IRQ context, like
decryption.
I don't understand why these developers would choose to develop their
driver outside the Linux kernel. It obviously will need a LOT of work
to be mergeable.
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts
wrote:
You can get it at http://rt2x00.serialmonkey.com as it isn't part of
the mainline kernel but is a special driver for this PCMCIA card. The
module I posted about was a different one (the one I tested before was
actually the rt2500 driver, the latest beta is supposed to be a catch
all for any version of these chipsets), but I just tried this one too
and it did the same thing to me so the problem is the same.
I am upgrading to the latest and greatest version of everything to see
if this helps. I had other RT problems with this kernel anyway.
Also, I apparently didn't set the trace options as those files didn't
exist for me. Big windstorm brewing too...might not get to finish
today (power might go out). I'll post more when I can. Thanks for
helping.
On 12/31/05, Lee Revell
<rlrevell(a)joe-job.com> wrote:
> On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts wrote:
> > I bought a wireless PCMCIA card and had the oddest things happen when
> > I load the module.
>
> Which module?
rt2500
I don't see this in the kernel source tree.
7:19 p.m.
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
Maybe you can try the beta driver:
http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00_beta
Yeah, that one has other problems and still won't connect to nothing.
It also causes serious stability problems when you send certain
commands with iwlist. Breaks something so inherent that all further
network config commands crash, ie ifconfig, iwconfig, etc...
I actually thought I was running that one earlier but I was wrong, I
had inadvertently left the old one in and was loading it.
I'm just going to take the damn card back. I'm not in the mood for
trying to get something like this to work right. I'm just hoping I
can find ANYTHING that will work in Linux at this point...this is the
second card I've tried.
Now, on a different note: After trying with the new kernel and such I
tried suspend to disk again and it still crashes with a mention about
PREEMPT. I wrote down some details, I am hoping it is enough but if
not I /can/ recreate and write down the whole damn oops output. Here
is what I grabbed:
First, right before the crash this message was output:
Warning: bash /8051/ changed soft IRQ flags
Then the crash:
Call trace (actuall addresses ommited):
swsusp_suspend + 6
pm_suspend_disk+80
enter_state+84
state_store+111
subsys_attr_store+34
sysfs_write_file+170
vfs_write+209
sys_write+69
system_call+126
Crash is about a null pointer derefenced at 00..0038
RIP: global_eventsource_suspend+8
PGD 35bff067 PUP 36710067
MMD 0
Oops: 0000 [1] PREEMPT <- the only place preempt is actually mentioned.
Loaded mods: 8139too mii usbhid ohci_hcd psmouse usbcore
Pid: 8051, comm: bash Not Tainted 2.6.15-rc7-rt1 #1
Lots of register values...again, I can easily recreate this bug so I
decided to see if this was enough. This an RT issue or a suspend
issue?
4:29 p.m.
Il giorno dom, 01/01/2006 alle 15.48 -0500, Lee Revell ha scritto:
That driver looks like a piece of junk. It's
clearly a quick and dirty
port of Windows code (the comments refer to running in "DPC context" and
IRQ priority levels which do not exist on Linux). And there seems to be
nothing stopping it from doing a LOT of work in (soft) IRQ context, like
decryption.
I don't understand why these developers would choose to develop their
driver outside the Linux kernel. It obviously will need a LOT of work
to be mergeable.
The current driver (divided into rt2400 and rt2500) was developed
externally by Ralink and later relicensed under the GPL, and it's
probably a direct port of their Windows driver.
The rt2x00 developers are currently rewriting the entire codebase (under
the name rt2x00 Open Source Project), bringing it closer to inclusion in
the mainstream kernel.
Don't forget that Ralink cards are some of the better supported wireless
interfaces available for Linux, having a completely GPL driver which
doesn't need external binary firmware.
4:39 p.m.
On Sun, 2006-01-01 at 22:29 +0100, Alberto Botti wrote:
Il giorno dom, 01/01/2006 alle 15.48 -0500, Lee Revell
ha scritto:
Yeah I was looking at the old driver. The old one looks like Windows
code, the new one looks like proper Linux kernel code.
Do you know what's keeping the new driver out of the kernel? Is it the
current confusion over the availability of multiple ieee80211 stacks?
Lee
Lee
That driver looks like a piece of junk. It's
clearly a quick and dirty
port of Windows code (the comments refer to running in "DPC context" and
IRQ priority levels which do not exist on Linux). And there seems to be
nothing stopping it from doing a LOT of work in (soft) IRQ context, like
decryption.
I don't understand why these developers would choose to develop their
driver outside the Linux kernel. It obviously will need a LOT of work
to be mergeable.
The current driver (divided into rt2400 and rt2500) was developed
externally by Ralink and later relicensed under the GPL, and it's
probably a direct port of their Windows driver.
The rt2x00 developers are currently rewriting the entire codebase (under
the name rt2x00 Open Source Project), bringing it closer to inclusion in
the mainstream kernel.
Don't forget that Ralink cards are some of the better supported wireless
interfaces available for Linux, having a completely GPL driver which
doesn't need external binary firmware.
4:57 p.m.
Il giorno dom, 01/01/2006 alle 16.39 -0500, Lee Revell ha scritto:
Yeah I was looking at the old driver. The old one
looks like Windows
code, the new one looks like proper Linux kernel code.
Do you know what's keeping the new driver out of the kernel? Is it the
current confusion over the availability of multiple ieee80211 stacks?
It's still a beta driver, They probably want to stabilize it further
before proposing it for inclusion.
From their latest release annuncement:
"This
will be the last BETA release before our migration to a new core ieee80211 stack."
p.s. I've recently bought one of these wireless PCI cards and I'm still using
the old driver (which appears to work perfectly). I think I've now found what was
causing so many xrun lately :)
7:29 p.m.
On 1/1/06, Alberto Botti <alberto.botti(a)gmail.com> wrote:
Don't forget that Ralink cards are some of the
better supported wireless
interfaces available for Linux, having a completely GPL driver which
doesn't need external binary firmware.
A while back I managed to get a DLink working within a few hours.
Took a LOT of searching and scrambling through convoluted (even for
unix) docs, websites, and forums to get there but once I found out
everything I needed it was pretty easy...it just worked. So anyway, I
know there is better even if you sometimes need that HAL component.
Setting up a wireless connection in Linux seems a lot harder than it
needs to be. Certainly the documentation on it could be much better.
If I knew what the hell I was doing with it maybe I could figure out
more about why it is breaking but I can't find any really good docs on
this stuff. The HOWTO kinda sucks... and people complain about audio
being hard to figure out :P
At any rate, its off topic now I think because the interrupt problem
is not what is at issue anymore now that I realized I was still
loading an old driver. That older driver actually says not to use SMP
or PREEMPT so...
Thanks for the help guys. I might try a few more things but I'm
pretty close to giving up on this card and trying a different
one...maybe I can get a DLink like the one I already got working once
before.
7:48 p.m.
On Sun, 2006-01-01 at 16:29 -0800, Noah Roberts wrote:
On 1/1/06, Alberto Botti
<alberto.botti(a)gmail.com> wrote:
I think it does not much attention because wireless on Linux right now
has much bigger problems that poor documentation.
Don't forget that Ralink cards are some of
the better supported wireless
interfaces available for Linux, having a completely GPL driver which
doesn't need external binary firmware.
A while back I managed to get a DLink working within a few hours.
Took a LOT of searching and scrambling through convoluted (even for
unix) docs, websites, and forums to get there but once I found out
everything I needed it was pretty easy...it just worked. So anyway, I
know there is better even if you sometimes need that HAL component.
Setting up a wireless connection in Linux seems a lot harder than it
needs to be. Certainly the documentation on it could be much better.
If I knew what the hell I was doing with it maybe I could figure out
more about why it is breaking but I can't find any really good docs on
this stuff. The HOWTO kinda sucks... and people complain about audio
being hard to figure out :P At any rate, its off topic now I think because the
interrupt problem
is not what is at issue anymore now that I realized I was still
loading an old driver. That older driver actually says not to use SMP
or PREEMPT so...
Thanks for the help guys. I might try a few more things but I'm
pretty close to giving up on this card and trying a different
one...maybe I can get a DLink like the one I already got working once
before.
Of course you'll have the easiest time if you get a device that the
kernel supports OOTB.
Check drivers/net/wireless/Kconfig in your kernel source for some
examples of devices that should Just Work.
Lee
8:06 p.m.
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
Check drivers/net/wireless/Kconfig in your kernel
source for some
examples of devices that should Just Work.
One major problem, and this is pretty universal for any hardware type,
is that you don't know what you are getting until you plug it in and
ask it what chipset it uses. It isn't on the box...rarely do you find
it on a website. When you are at the store and you are trying to
guess it is just really hard to figure what is going to work. I
remember one time I bought an ATI TV-Wonder *knowing* that it would
work because I used them before...HAH....the new ones had a different
"Conexant" chipset that didn't have any viable Linux drivers - all
alpha mode...
8:36 p.m.
On Sun, 2006-01-01 at 17:06 -0800, Noah Roberts wrote:
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Yes it's harder if you start from a selection of hardware and then ask
"OK what here works?". It's much easier to start with a Google search
for what wireless cards work OOTB and then shop accordingly.
Besides I don't agree that it's difficult to figure out given a device
whether it works with Linux, Google should be able to tell you this (as
long as you avoid bleeding edge just-came-out-last-week devices which is
a good idea anyway).
Lee
Check drivers/net/wireless/Kconfig in your kernel
source for some
examples of devices that should Just Work.
One major problem, and this is pretty universal for any hardware type,
is that you don't know what you are getting until you plug it in and
ask it what chipset it uses. It isn't on the box...rarely do you find
it on a website.
8:42 p.m.
On Sun, 2006-01-01 at 17:06 -0800, Noah Roberts wrote:
the new ones had a different "Conexant"
chipset that didn't have any
viable Linux drivers - all alpha mode...
It's also difficult to say what constitutes a "viable driver". Most
people consider that a driver is viable if it supports the basic
functions of the device, like playing audio, sending/receiving packets
or displaying images on the screen. Then you have a shrill minority who
consider a driver non-viable, broken or useless if it doesn't support
EVERY single little feature of the hardware or do everything the Windows
driver does.
I guess my point is YMMV as always ;-)
Lee
9:03 p.m.
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-01-01 at 17:06 -0800, Noah Roberts wrote:
My definition of non-viable is crashes a lot, doesn't work at all (as
in this case), or is missing key features, and in the case above it
was two weeks of waiting before I could even get video w/o audio from
that card. I did some modifications myself to make it even get video
from the composite input. It probably works now...I put the thing up
and its been gathering dust for about a year or more.
the new ones had a different "Conexant"
chipset that didn't have any
viable Linux drivers - all alpha mode...
It's also difficult to say what constitutes a "viable driver". Most
people consider that a driver is viable if it supports the basic
functions of the device, like playing audio, sending/receiving packets
or displaying images on the screen. Then you have a shrill minority who
consider a driver non-viable, broken or useless if it doesn't support
EVERY single little feature of the hardware or do everything the Windows
driver does.
I guess my point is YMMV as always ;-)
9:16 p.m.
On Sun, 2006-01-01 at 18:03 -0800, Noah Roberts wrote:
On 1/1/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Yeah that's a key thing to watch out for with Linux drivers: never
assume that a device is supported because the previous generation of
that device was supported - you have to match the model numbers
carefully. There's no substitute for a first person account that the
device works.
Lately I've even heard that some wireless vendors will change the
chipset in a way that breaks the old driver without changing the model
number at all.
Lee
On Sun, 2006-01-01 at 17:06 -0800, Noah Roberts
wrote:
My definition of non-viable is crashes a lot, doesn't work at all (as
in this case), or is missing key features, and in the case above it
was two weeks of waiting before I could even get video w/o audio from
that card. I did some modifications myself to make it even get video
from the composite input. It probably works now...I put the thing up
and its been gathering dust for about a year or more.
the new ones had a different "Conexant"
chipset that didn't have any
viable Linux drivers - all alpha mode...
It's also difficult to say what constitutes a "viable driver". Most
people consider that a driver is viable if it supports the basic
functions of the device, like playing audio, sending/receiving packets
or displaying images on the screen. Then you have a shrill minority who
consider a driver non-viable, broken or useless if it doesn't support
EVERY single little feature of the hardware or do everything the Windows
driver does.
I guess my point is YMMV as always ;-)
8 p.m.
Actually, looks like it might still be preempt...
Kernel BUG at kernel/rt.c:2193
invalid operand: 0000 [1] PREEMPT
CPU 0
Modules linked in: rt2500pci rt2x00core ieee80211 ieee80211_crypt
yenta_socket rsrc_nonstatic pcmcia pcmcia_core firmware_class 8139too
mii usbhid ohci_hcd psmouse usbcore
Pid: 8320, comm: ifconfig Not tainted 2.6.15-rc7-rt1 #1
RIP: 0010:[<ffffffff80144bb2>] <ffffffff80144bb2>{rt_downgrade_write+0}
RSP: 0018:ffff810028b01cf0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810028a96a68 RCX: ffff8100288e6200
RDX: ffff810028b00000 RSI: 000000000000000b RDI: ffff810028a96a68
RBP: ffff810028a96ac8 R08: 0000000000000006 R09: 0000000000000282
R10: ffff81002df4d300 R11: ffff81002b6e5ec0 R12: 00000000000003ff
R13: ffff810028a96a68 R14: 0000000000000000 R15: 0000000000000000
FS: 00002aaaaade3b00(0000) GS:ffffffff803fc800(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaacb864c CR3: 00000000289b1000 CR4: 00000000000006e0
Process ifconfig (pid: 8320, threadinfo ffff810028b00000, task
ffff810028a987c0)Stack: ffffffff880700a6 ffff810028a96ac8
ffff810028a96624 ffff810028a96b88
ffffffff88071c91 ffff81002df4d300 ffff810028a96a68 0000000000000000
0000000000000000 ffff810028a96ac8
Call Trace:<ffffffff880700a6>{:rt2x00core:rt2x00_update_config+69}
<ffffffff88071c91>{:rt2x00core:rt2x00_start_scan+773}
<ffffffff88072cbe>{:rt2x00core:rt2x00_link_up+103}
<ffffffff88075c81>{:rt2x00core:rt2x00_open+120}
<ffffffff80293153>{dev_open+51} <ffffffff80294119>{dev_change_flags+88}
<ffffffff802c8b23>{devinet_ioctl+645}
<ffffffff802c9c3e>{inet_ioctl+124}
<ffffffff8028aee4>{sock_ioctl+0} <ffffffff8028b0b9>{sock_ioctl+469}
<ffffffff8017ec41>{do_ioctl+41} <ffffffff8017eefb>{vfs_ioctl+628}
<ffffffff8017ef65>{sys_ioctl+89} <ffffffff8010e812>{system_call+126}
Code: 0f 0b 68 ed 6c 2f 80 c2 91 08 c3 0f ae f0 31 c0 48 83 7f 20
RIP <ffffffff80144bb2>{rt_downgrade_write+0} RSP <ffff810028b01cf0>
Is this an issue with realtime or the driver?
8:13 p.m.
On Sun, 2006-01-01 at 17:00 -0800, Noah Roberts wrote:
Actually, looks like it might still be preempt...
Kernel BUG at kernel/rt.c:2193
invalid operand: 0000 [1] PREEMPT
CPU 0
Modules linked in: rt2500pci rt2x00core ieee80211 ieee80211_crypt
yenta_socket rsrc_nonstatic pcmcia pcmcia_core firmware_class 8139too
mii usbhid ohci_hcd psmouse usbcore
Pid: 8320, comm: ifconfig Not tainted 2.6.15-rc7-rt1 #1
RIP: 0010:[<ffffffff80144bb2>] <ffffffff80144bb2>{rt_downgrade_write+0}
RSP: 0018:ffff810028b01cf0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810028a96a68 RCX: ffff8100288e6200
RDX: ffff810028b00000 RSI: 000000000000000b RDI: ffff810028a96a68
RBP: ffff810028a96ac8 R08: 0000000000000006 R09: 0000000000000282
R10: ffff81002df4d300 R11: ffff81002b6e5ec0 R12: 00000000000003ff
R13: ffff810028a96a68 R14: 0000000000000000 R15: 0000000000000000
FS: 00002aaaaade3b00(0000) GS:ffffffff803fc800(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaacb864c CR3: 00000000289b1000 CR4: 00000000000006e0
Process ifconfig (pid: 8320, threadinfo ffff810028b00000, task
ffff810028a987c0)Stack: ffffffff880700a6 ffff810028a96ac8
ffff810028a96624 ffff810028a96b88
ffffffff88071c91 ffff81002df4d300 ffff810028a96a68 0000000000000000
0000000000000000 ffff810028a96ac8
Call Trace:<ffffffff880700a6>{:rt2x00core:rt2x00_update_config+69}
<ffffffff88071c91>{:rt2x00core:rt2x00_start_scan+773}
<ffffffff88072cbe>{:rt2x00core:rt2x00_link_up+103}
<ffffffff88075c81>{:rt2x00core:rt2x00_open+120}
<ffffffff80293153>{dev_open+51}
<ffffffff80294119>{dev_change_flags+88}
<ffffffff802c8b23>{devinet_ioctl+645}
<ffffffff802c9c3e>{inet_ioctl+124}
<ffffffff8028aee4>{sock_ioctl+0} <ffffffff8028b0b9>{sock_ioctl+469}
<ffffffff8017ec41>{do_ioctl+41} <ffffffff8017eefb>{vfs_ioctl+628}
<ffffffff8017ef65>{sys_ioctl+89} <ffffffff8010e812>{system_call+126}
Code: 0f 0b 68 ed 6c 2f 80 c2 91 08 c3 0f ae f0 31 c0 48 83 7f 20
RIP <ffffffff80144bb2>{rt_downgrade_write+0} RSP <ffff810028b01cf0>
Is this an issue with realtime or the driver?
It's impossible for me to tell. Either it's a driver bug or the driver
is not compatible with the -rt kernel. You should report this to the
developers.
The PREEMPT line has nothing to do with the Oops other than to tell you
that it was generated by a PREEMPT enabled kernel.
Lee
4:31 p.m.
On Sun, 2006-01-01 at 15:48 -0500, Lee Revell wrote:
On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
Sorry wrong link in the last message.
This the driver you should be using:
http://prdownloads.sourceforge.net/rt2400/rt2x00-2.0.0-b3.tar.gz?download
Lee
On 1/1/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
That driver looks like a piece of junk. It's clearly a quick and dirty
port of Windows code (the comments refer to running in "DPC context" and
IRQ priority levels which do not exist on Linux). And there seems to be
nothing stopping it from doing a LOT of work in (soft) IRQ context, like
decryption.
I don't understand why these developers would choose to develop their
driver outside the Linux kernel. It obviously will need a LOT of work
to be mergeable.
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts
wrote:
You can get it at http://rt2x00.serialmonkey.com as it isn't part of
the mainline kernel but is a special driver for this PCMCIA card. The
module I posted about was a different one (the one I tested before was
actually the rt2500 driver, the latest beta is supposed to be a catch
all for any version of these chipsets), but I just tried this one too
and it did the same thing to me so the problem is the same.
I am upgrading to the latest and greatest version of everything to see
if this helps. I had other RT problems with this kernel anyway.
Also, I apparently didn't set the trace options as those files didn't
exist for me. Big windstorm brewing too...might not get to finish
today (power might go out). I'll post more when I can. Thanks for
helping.
On 12/31/05, Lee Revell
<rlrevell(a)joe-job.com> wrote:
> On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts wrote:
> > I bought a wireless PCMCIA card and had the oddest things happen when
> > I load the module.
>
> Which module?
rt2500
I don't see this in the kernel source tree.
2:09 p.m.
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
As root,
echo 0 > /proc/sys/kern/preempt_max_latency
Then do something to reproduce the hangs/pauses, then post the contents
of /proc/latency_trace.
Lee
Do you have latency tracing enabled? If so what does it say? Can
you
test without the RT patch?
I believe I have tracing enabled but I have no idea how to find out
what it says.
7039
days inactive
7039
days old
linux-audio-user@lists.linuxaudio.org
21 comments
3 participants
participants (3)
-
Alberto Botti -
Lee Revell -
Noah Roberts