linux-kernel - BCM4312 Fails when xdm is started

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-next>] [day] [month] [year] [list]

Date:	Fri, 21 Nov 2008 10:25:22 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	Peter Stuge <peter@...ge.se>,
	wireless <linux-wireless@...r.kernel.org>,
	Broadcom Linux <bcm43xx-dev@...ts.berlios.de>,
	Yuval Hager <yuval@...amzon.net>
Subject: BCM4312 Fails when xdm is started

A problem was recently posted to the bcm43xx mailing list that I am unable to
solve. The machine in question is an HP Mini 2133 (HP product number FU346EA)
with a BCM4312 PCIe wireless card. This card is known to work with the b43
driver (I have one.) and it does work on this machine - at least initially.

A problem occurs when xdm/kde is started. Suddenly a read operation on device
hardware returns all ones as though the register does not exist, or if it were
suddenly mismapped. If the OP doesn't try to run xdm, the same problem will
eventually occur, it just takes longer.

This is a 32-bit system running 2.6.28-rc5, but I don't think this is a
regression from some earlier version as the problem was first reported with
kernel 2.6.27-gentoo-r2.

I have complete logs, but before spamming the list with them, I have a question
about the "Zone PFN" settings. On the problem machine, the following list occurs:

[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x000373fe
[    0.000000]   HighMem  0x000373fe -> 0x0006feb0

On my 64-bit HP machine, I see:

Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000

Is it "normal" for there not to be a DMA32 range with a 32-bit version of Linux?
Certainly all the memory is available to 32-bit DMA. This card does 64-bit DMA,
but the driver falls back to a 32-bit mask for this system.

Is there some kind of memory mapping problem in the PCIe system? Should the
entire log be posted?

Thanks,

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/