On Wednesday 24 January 2007 06:43, Pavel Roskin wrote:
> On Tue, 2007-01-23 at 10:21 +0100, Michael Buesch wrote:
> > On Tuesday 23 January 2007 07:14, Pavel Roskin wrote:
> > > I have tried the patch, and it doesn't fix the problem. It's a separate
> > > problem. It happens when bcm43xx_interru
On Tue, 2007-01-23 at 10:21 +0100, Michael Buesch wrote:
> On Tuesday 23 January 2007 07:14, Pavel Roskin wrote:
> > I have tried the patch, and it doesn't fix the problem. It's a separate
> > problem. It happens when bcm43xx_interrupt_handler() is called on a
> > device that has already been rem
On Tuesday 23 January 2007 07:14, Pavel Roskin wrote:
> On Mon, 2007-01-22 at 22:00 +0100, Michael Buesch wrote:
> > > No more random crashes. There is still a crash if I rmmod the driver
> > > while wlan0 is up, but it's a separate issue, and it's easy to avoid
> > > (unlike the interface going
On Mon, 2007-01-22 at 22:00 +0100, Michael Buesch wrote:
> > No more random crashes. There is still a crash if I rmmod the driver
> > while wlan0 is up, but it's a separate issue, and it's easy to avoid
> > (unlike the interface going down). I hope to look at it soon.
>
> Did you apply that d80
Michael Buesch wrote:
> On Monday 22 January 2007 21:44, Pavel Roskin wrote:
>> The problems with a MadWifi based AP turn out to be related to 802.11g.
>> If the AP is configured for 802.11b only, everything is working. If
>> 802.11g is enabled, strange things are happening. Judging by what's on
On Monday 22 January 2007 21:44, Pavel Roskin wrote:
> Hello, Michael!
>
> On Mon, 2007-01-22 at 21:06 +0100, Michael Buesch wrote:
> > It's obviously some stack/memory corruption. But I'm not
> > sure if this is a stackoverflow. I'd rather say no, it isn't.
> >
> > Could probably be triggered b
Hello, Michael!
On Mon, 2007-01-22 at 21:06 +0100, Michael Buesch wrote:
> It's obviously some stack/memory corruption. But I'm not
> sure if this is a stackoverflow. I'd rather say no, it isn't.
>
> Could probably be triggered by something like kfree()ing
> a dangling pointer or something...
Y
On Friday 19 January 2007 08:54, Pavel Roskin wrote:
> Hello, Michael!
>
> I did more testing, and the results are following. It looks like the
> oopses and panics on i386 were triggered by 4k stacks. x86_64 doesn't
> have this option.
>
> Now that I enabled other debug options on both platform
Hello, Michael!
I did more testing, and the results are following. It looks like the
oopses and panics on i386 were triggered by 4k stacks. x86_64 doesn't
have this option.
Now that I enabled other debug options on both platforms. but not 4k
stacks, I'm seeing exactly the same problem on each p
On Wed, 2007-01-17 at 10:52 +0100, Michael Buesch wrote:
> Doesn't happen for me. I have no idea what's happening.
> Care to debug it?
> But it's weird that _killing_ the supplicant calls add_interface.
> I'd expect it to call remove_interface.
I'm sorry, I was actually running wpa_supplicant aga
On Wednesday 17 January 2007 00:51, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 23:07 +0100, Michael Buesch wrote:
> > On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> > > On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> > >
> > > > A patch for that is already upstream.
> > >
> >
On Tue, 2007-01-16 at 23:07 +0100, Michael Buesch wrote:
> On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> > On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> >
> > > A patch for that is already upstream.
> >
> > I don't see it. It's not in your tree yet.
>
> It is on its way u
On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
>
> > A patch for that is already upstream.
>
> I don't see it. It's not in your tree yet.
It is on its way upstream to linville.
> > It's surprising that it doesn't happen for me,
On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> A patch for that is already upstream.
I don't see it. It's not in your tree yet.
> It's surprising that it doesn't happen for me, though.
> Neiter on PPC, nor on i386.
It did happen for me on i386, as well as on x86_64. The dump was f
On Tuesday 16 January 2007 19:29, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 18:06 +0100, Michael Buesch wrote:
> > ...the bcm43xx driver in my tree with a 4318 chip?
>
> Things are progressing for me a bit because I observed an association to
> an AP with no security. I still had to use wpa_sup
On Tuesday 16 January 2007 20:00, Andreas Schwab wrote:
> Michael Buesch <[EMAIL PROTECTED]> writes:
>
> > ...the bcm43xx driver in my tree with a 4318 chip?
> > The code there works excellent with my 4306 now, but I can't
> > get it to work with my 4318.
>
> Doesn't work for me either. I cannot
Michael Buesch <[EMAIL PROTECTED]> writes:
> ...the bcm43xx driver in my tree with a 4318 chip?
> The code there works excellent with my 4306 now, but I can't
> get it to work with my 4318.
Doesn't work for me either. I cannot get it to associate to the AP.
Andreas.
--
Andreas Schwab, SuSE La
On Tue, 2007-01-16 at 18:06 +0100, Michael Buesch wrote:
> ...the bcm43xx driver in my tree with a 4318 chip?
Things are progressing for me a bit because I observed an association to
an AP with no security. I still had to use wpa_supplicant.
Unfortunately, there is a bigger issue with the new co
18 matches
Mail list logo
