On Thursday 19 March 2009 20:00:45 Francesco Gringoli wrote: > some time ago I begin seeing several of these errors, never seen > before on one of my host, with both proprietary and open firmwares. As > I never noticed those errors before, I wondered if they could be due > to some strange frame received by air, something like a frame encoded > in CCK but with a broken field that caused the firmware to ack back a > frame whose first byte (encoding) didn't match the following inside > the plcp. That was obviously not the case, indeed those errors were > not even happening on tx tries and surprisingly they were happening > also on devices configured in monitor mode. Well, they _are_ triggered by things going on in the WM. But I think they are a lot lower level than MAC or PLCP. I think it is related to the raw modulation. In the end, I'm pretty sure this is some misconfiguration of some very low level PHY part. Too bad we don't know about a debugging register to get more information on _what_ part does trigger the error. > I finally remembered that the day before starting observing errors, I > changed the minipci to pci adapter inside that host, maintaining the > same cable and antenna set. Removing the broken adapter stopped PHY > errors. Yeah well. This confirms my thoughts. There are other ways to voluntarily trigger the errors. For example try covering the antennae with your bare hands. Try to move the device to a place with extremely bad signal (Iron beams between them). Try to move the transceivers very close (20cm) together, so basic rf rules are violated. This are all pretty reliable ways to trigger these errors. > After this debug session I have some notes > - PHY error IRQs are not triggered by the firmware (both open and > proprietary) by writing to the IRQ registers Right. I don't think it's really related to what firmware is running. It may be the case that some firmware might encourage the errors by some special timing in code operations, but the firmware does not trigger them. > - these strange PHY errors are not due to tx tries, they happen also > with devices were the tx code has been cut away Well, I did not see that, so I cannot really comment on this. I never saw them in monitor mode. > - PHY errors are triggered by the hardware when the number of bytes > requested for transmission do not match the tx information stored in > the first four bytes of the plcp, this happens for both frames sent by > b43 through dma and frames composed by the firmware. If everything is This is correct and known behavior. But this is _not_ what is happening here. > consistent I never see errors on platforms not affected by noise (as > my old VIA or the broken minipci to pci adapter). Yes, less noise = less errors. That's clearly the case. > I would say this noise directly affects the irq line, or it triggers > the serializer to send out a packet with completely wrong radio/plcp/ > mac configuration that causes a PHY tx error. I don't think it triggers the IRQ line. I'd rather think that some sensitivity threshold is configured incorrectly, so the PHY will trigger the errors on completely valid stuff. So now this is your turn: Which one? :D -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
