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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ