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 for Android: free password hash cracker in your pocket

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

Message-Id: <200701141115.43799.mb@bu3sch.de>
Date:	Sun, 14 Jan 2007 11:15:43 +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 Sunday 14 January 2007 03:10, Pavel Roskin wrote:
> Quoting Michael Buesch <mb@...sch.de>:
> 
> > > 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.
> 
> Basically, you set up DMA on the PCI device, but use it on the SSB device.
> That's inconsistent.  dma_alloc_coherent() is very picky on x86_64 and crashes
> if dev->dma_mask is NULL, which was the case for the SSB device.
> 
> Looking at the patch, it's clear that the SSB device is used instead of the PCI
> device in some places.  I restored the old logic.  If you meant to switch to
> SSB devices, then please remove the last PCI references from that file.

Already done. Please pull my tree and check if it still crashes.

> The patch is attached.  It fixes the crash.  I didn't check that it's complete.
> I really don't like the long chain of dereferences, and I hope you'll come up
> with something better.

No. I don't think we have shorter chains in other subsystems like PCI. They
are just hidden.

We could probably get rid of one level in the DMA code, by embedding the DMA
structs into the device struct. But I think there are more important things
to do at the moment.

> I still cannot associate.  The kernel log is attached.  Notice massive assertion
> failures.
> 
> > Note that LO calibration is horribly broken in my tree.
> 
> I guess that's what the assertion failures are about.

You're right.

> > 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.
> 
> Actually, I could scan, and I got 7 access points around.  Only one is in my
> apartment.

RX sensitivity is not quite as bad.

> > But I think you should be able to assoc with a plain linville tree.
> 
> Nope.  Although I got DadWifi to work, and this message will we sent over it.
> So it's not like I'm missing something essential about d80211 stack.

Well, I don't really know what to do all about this.
It's strange. I have people reporting that exactly the same cards work
and people reporting that exactly the same cards don't work over and
over again.
So, well. What to do? :)

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