netdev - Re: What is in bcm43xx-wireless-dev.git?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200701132051.52559.mb@bu3sch.de>
Date:	Sat, 13 Jan 2007 20:51:52 +0100
From:	Michael Buesch <mb@...sch.de>
To:	Pavel Roskin <proski@....org>
Cc:	bcm43xx-dev@...ts.berlios.de, netdev@...r.kernel.org
Subject: Re: What is in bcm43xx-wireless-dev.git?

On Saturday 13 January 2007 20:30, Pavel Roskin wrote:
> Quoting Michael Buesch <mb@...sch.de>:
> 
> > I looked more closely at it, but I really can't see why it oopses.
> > Any idea what's happening there?
> 
> I haven't looked at the code yet, but I tried to locate the bad commit.  I tried
> commit a13f85d8a8eb40dfd157ab78c2fb91b5765b7b9d, which is your last merge, just
> before the SSB changes.

Yeah, sure. I know that this is the commit which introduced this.

> The kernel doesn't oops anymore!  But it doesn't connect either.  I reconfigured
> the AP to use WPA-PSK with TKIP.  MadWifi works with it, but bcm43xx fails in
> the same configuration.  The wireless-dev tip has the same problem.

Note that LO calibration is horribly broken in my tree.
So you have a very weak signal, if any. My 4318 has no signal, for example.
So basically don't expect to be able to transmit any data.
This includes association.

But I think you should be able to assoc with a plain linville tree.

> So, the oops was introduced in the transition to the new SSB. 
> bcm43xx_setup_dmaring(), which appears in the stack dump, is affected by the
> patch.

Yeah, but I don't see where we can get such an oops from :)

> I'll try to look closely at the changes.  My immediate suspect is that we have
> too many different fields called "dev".  All it takes is one cast to hide a
> horrible mistake.  Although I think it would have affected you as well (unless

We don't cast devs.

> it's casts to/from integers, something that won't be a problem on 32-bit
> kernels).

dito.

> > Well, ok. So it should work in my tree, too, once we fixed the DMA oops.
> 
> You mean there is a reason for me to think that your changes would fix
> accociation to the AP?

No.

We oops in dma_alloc_coherent, right?
Where can we get a NULL pointer there? I don't see it. Any idea?
Also, regarding to the oops message, it's oopsing somewhere at
the beginning of the function.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html