Problem possibly RT related?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Problem possibly RT related?

Noah Roberts
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?

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
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?

Do you have latency tracing enabled?  If so what does it say?  Can you
test without the RT patch?

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
On 12/31/05, Lee Revell <[hidden email]> 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

>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> On 12/31/05, Lee Revell <[hidden email]> 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.

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Noah Roberts
On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> >
> > 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
In reply to this post by Lee Revell
On 1/1/06, Lee Revell <[hidden email]> wrote:

> On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> > On 12/31/05, Lee Revell <[hidden email]> 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.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:

> On 1/1/06, Lee Revell <[hidden email]> wrote:
> > On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> > > On 12/31/05, Lee Revell <[hidden email]> 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.
>
> 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
On Sun, 2006-01-01 at 15:48 -0500, Lee Revell wrote:

> On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
> > On 1/1/06, Lee Revell <[hidden email]> wrote:
> > > On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> > > > On 12/31/05, Lee Revell <[hidden email]> 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.
> >
> > 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.
> >
>
> 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Alberto Botti
In reply to this post by Lee Revell
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.

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Lee Revell
On Sun, 2006-01-01 at 15:48 -0500, Lee Revell wrote:

> On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
> > On 1/1/06, Lee Revell <[hidden email]> wrote:
> > > On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> > > > On 12/31/05, Lee Revell <[hidden email]> 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.
> >
> > 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.
> >
>
> 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Alberto Botti
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:
> > 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.
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Alberto Botti
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 :)

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
In reply to this post by Lee Revell
On 1/1/06, Lee Revell <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
In reply to this post by Alberto Botti
On 1/1/06, Alberto Botti <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
On Sun, 2006-01-01 at 16:29 -0800, Noah Roberts wrote:

> On 1/1/06, Alberto Botti <[hidden email]> 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

I think it does not much attention because wireless on Linux right now
has much bigger problems that poor documentation.

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
In reply to this post by Noah Roberts
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?

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Noah Roberts
In reply to this post by Lee Revell
On 1/1/06, Lee Revell <[hidden email]> 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...

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Noah Roberts
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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Noah Roberts
On Sun, 2006-01-01 at 17:06 -0800, Noah Roberts wrote:
> On 1/1/06, Lee Revell <[hidden email]> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Problem possibly RT related?

Lee Revell
In reply to this post by Noah Roberts
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

12