So the wireless on my Macbook Air no longer seems to work with the
current -git tree.
The BRCMSMAC driver *used* to work, and no longer does. Also, very
annoyingly, it's even hard to *compile* the thing, because it used to
be
depends on BCMA=n
but now it is the exact reverse:
depends on BCMA
so there is no sane way to carry a configuration over from before, and
things like bisection is a major pain due to having to play idiotic
configuration games to get it to work across all these modifications.
Ragardless, even once you actually enable BCMA and can get the driver
to come back, it just doesn't do anything. Maybe there is some
remaining config problem, but I don't think so. I think the driver is
just buggered.
The kernel messages don't say much. A working config for me has
messages like this:
brcmsmac 0000:02:00.0: bus 2 slot 0 func 0 irq 11
brcmsmac 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
brcmsmac 0000:02:00.0: setting latency timer to 64
ieee80211 phy0: brcms_ops_config: change monitor mode: false (implement)
ieee80211 phy0: brcms_ops_config: change power-save mode: false (implement)
ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: true (implement)
ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed: associated
ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled
true, count 0 (implement)
ieee80211 phy0: brcms_ops_bss_info_changed: arp filtering: enabled
true, count 1 (implement)
while the nonworking one says:
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
ieee80211 phy0: brcmsmac: attach() failed with code 11
brcmsmac: brcms_bcma_probe: brcms_attach failed!
brcms_module_init: register returned 0
and no wireless device ever shows up.
lspci for this device says:
02:00.0 Network controller: Broadcom Corporation BCM43224
802.11a/b/g/n (rev 01)
Subsystem: Apple Computer Inc. Device 00e9
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at a0400000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: brcmsmac
00: e4 14 53 43 06 00 10 00 01 00 80 02 40 00 00 00
10: 04 00 40 a0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 6b 10 e9 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
(this is from the working kernel, obviously).
Please look into this. I'll obviously be happy test any reasonable suggestions,
Linus
From: Arend van Spriel <hidden> Date: 2012-01-11 10:44:39
On 01/10/2012 09:15 PM, Linus Torvalds wrote:
So the wireless on my Macbook Air no longer seems to work with the
current -git tree.
The BRCMSMAC driver *used* to work, and no longer does. Also, very
annoyingly, it's even hard to *compile* the thing, because it used to
be
depends on BCMA=n
but now it is the exact reverse:
depends on BCMA
so there is no sane way to carry a configuration over from before, and
things like bisection is a major pain due to having to play idiotic
configuration games to get it to work across all these modifications.
BCMA support has been added to brcmsmac so now we depend on it. As BCMA
claims the PCI device we had the BCMA=n in place before. I agree that it
makes bisecting a pain in the...
Ragardless, even once you actually enable BCMA and can get the driver
to come back, it just doesn't do anything. Maybe there is some
remaining config problem, but I don't think so. I think the driver is
just buggered.
Looking at the output I had deja-vu feeling. The issue popped up when we
published part of the patches for BCMA support. I looked into it with
Larry Finger and Rafał Miłecki. We found the reason for the failure, but
it seemed resolved after submitting the remaining patches for BCMA
support. However, it seems to have raised its ugly head.
Please look into this. I'll obviously be happy test any reasonable suggestions,
Linus
My theory is that the BAR window is not mapped to a valid address. Could
you try to revert the following commit:
commit 439678f8b0fca7aeca06c6581e3679eef618721a
Author: Rafał Miłecki [off-list ref]
Date: Mon Dec 5 19:13:39 2011 +0100
bcma: pci: use fixed windows when possible
Some cores are mapped in the fixed way, they registers can be accessed
all the time.
Signed-off-by: Rafał Miłecki [off-list ref]
Signed-off-by: John W. Linville [off-list ref]
I have attached the 'revert patch' based on your git master branch.
Gr. AvS
On Wed, Jan 11, 2012 at 2:44 AM, Arend van Spriel [off-list ref] wrote:
My theory is that the BAR window is not mapped to a valid address. Could
you try to revert the following commit:
Sadly, that one makes no difference. I'll enable BRCM/BCMA debugging
and see if that gives any more information, but will be unable to do
much for the next few hours, so it will likely not be until this
afternoon.
Linus
On Wed, Jan 11, 2012 at 7:05 AM, Linus Torvalds
[off-list ref] wrote:
Sadly, that one makes no difference. I'll enable BRCM/BCMA debugging
and see if that gives any more information, but will be unable to do
much for the next few hours, so it will likely not be until this
afternoon.
Ok, could do it now. But that really doesn't give much more
information. Here it is anyway:
[ 0.746530] bcma-pci-bridge 0000:02:00.0: PCI INT A -> GSI 17
(level, low) -> IRQ 17
[ 0.746544] bcma-pci-bridge 0000:02:00.0: setting latency timer to 64
[ 0.746617] bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800,
rev 0x22, class 0x0)
[ 0.746646] bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812,
rev 0x17, class 0x0)
[ 0.746709] bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev
0x0F, class 0x0)
[ 0.746845] bcma: Switched to core: 0x800
[ 0.746859] bcma: Found rev 6 PMU (capabilities 0x108C2606)
[ 0.746880] bcma: Switched to core: 0x820
[ 0.775510] bcma: Switched to core: 0x800
[ 0.815750] bcma: Unsupported SPROM revision: 255
[ 0.815804] bcma: No SPROM available
[ 0.815909] bcma: Bus registered
[ 41.797178] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
[ 41.952030] bcma: Switched to core: 0x820
[ 41.952050] bcma: Switched to core: 0x800
[ 41.953881] ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
[ 41.956397] ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
[ 41.958443] ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
[ 41.960468] ieee80211 phy0: brcmsmac: attach() failed with code 11
[ 41.962316] brcmsmac: brcms_bcma_probe: brcms_attach failed!
[ 41.967275] brcms_module_init: register returned 0
hopefully this gives people *some* idea, but I'm not seeing anything.
Linus
From: Larry Finger <hidden> Date: 2012-01-11 17:00:37
On 01/11/2012 10:04 AM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 7:05 AM, Linus Torvalds
Ok, could do it now. But that really doesn't give much more
information. Here it is anyway:
[ 0.746530] bcma-pci-bridge 0000:02:00.0: PCI INT A -> GSI 17
(level, low) -> IRQ 17
[ 0.746544] bcma-pci-bridge 0000:02:00.0: setting latency timer to 64
[ 0.746617] bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800,
rev 0x22, class 0x0)
[ 0.746646] bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812,
rev 0x17, class 0x0)
[ 0.746709] bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev
0x0F, class 0x0)
[ 0.746845] bcma: Switched to core: 0x800
[ 0.746859] bcma: Found rev 6 PMU (capabilities 0x108C2606)
[ 0.746880] bcma: Switched to core: 0x820
[ 0.775510] bcma: Switched to core: 0x800
[ 0.815750] bcma: Unsupported SPROM revision: 255
[ 0.815804] bcma: No SPROM available
I'm not a bcma or brcmsmac expert, but the above result of SPROM version 0xFF
looks as if the read was from a non-existent register. If you get a chance,
please try this patch, which will dump the offset that is being used.
Index: wireless-testing-new/drivers/bcma/sprom.c
===================================================================
@@ -230,6 +230,7 @@ int bcma_sprom_get(struct bcma_bus *bus)*TODO:understandthisconditionanduseit*/offset=(bus->chipinfo.id==0x4331)?BCMA_CC_SPROM:BCMA_CC_SPROM_PCIE6;+pr_debug("SPROM offset 0x%x\n",offset);bcma_sprom_read(bus,offset,sprom);if(bus->chipinfo.id==0x4331)
As the TODO indicates, this part is not understood.
One other thing to try. If the new output says that the offset is 0x830, try
forcing it to 0x800, or vice versa. I don't think you have a 4331, and I expect
that the current code is trying 0x830, but should be using 0x800.
Larry
From: Ben Hutchings <hidden> Date: 2012-01-11 17:15:38
On Wed, 2012-01-11 at 11:44 +0100, Arend van Spriel wrote:
On 01/10/2012 09:15 PM, Linus Torvalds wrote:
quoted
So the wireless on my Macbook Air no longer seems to work with the
current -git tree.
The BRCMSMAC driver *used* to work, and no longer does. Also, very
annoyingly, it's even hard to *compile* the thing, because it used to
be
depends on BCMA=n
but now it is the exact reverse:
depends on BCMA
so there is no sane way to carry a configuration over from before, and
things like bisection is a major pain due to having to play idiotic
configuration games to get it to work across all these modifications.
BCMA support has been added to brcmsmac so now we depend on it. As BCMA
claims the PCI device we had the BCMA=n in place before. I agree that it
makes bisecting a pain in the...
[...]
Maybe BRCMSMAC should select BCMA rather than depending on it. This bus
seems like kind of an implementation detail that people are unlikely to
be aware of, unlike say PCI.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
From: Arend van Spriel <hidden> Date: 2012-01-11 21:01:35
On 01/11/2012 05:04 PM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 7:05 AM, Linus Torvalds
[off-list ref] wrote:
quoted
Sadly, that one makes no difference. I'll enable BRCM/BCMA debugging
and see if that gives any more information, but will be unable to do
much for the next few hours, so it will likely not be until this
afternoon.
There goes my theory. I have no MacBook Air over here and we have
nightly testing running for this chip. I will have it run on your branch
iso wireless to see if I can reproduce it over here.
Ok, could do it now. But that really doesn't give much more
information. Here it is anyway:
[ 41.797178] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
[ 41.952030] bcma: Switched to core: 0x820
[ 41.952050] bcma: Switched to core: 0x800
[ 41.953881] ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
[ 41.956397] ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
[ 41.958443] ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
[ 41.960468] ieee80211 phy0: brcmsmac: attach() failed with code 11
[ 41.962316] brcmsmac: brcms_bcma_probe: brcms_attach failed!
[ 41.967275] brcms_module_init: register returned 0
hopefully this gives people *some* idea, but I'm not seeing anything.
Linus
I have some idea, but no success in reproducing it. Could you provide
the .config used on this?
Gr. AvS
I have some idea, but no success in reproducing it. Could you provide
the .config used on this?
Attached.
I'm also attaching the lspci output from a working configuration and a
nonworking one. The only thing that stands out is the ">TAbort+" in
the status of the broken one. Some transfer has gone wrong, it looks
like.
Linus
On Wed, Jan 11, 2012 at 9:15 AM, Ben Hutchings
[off-list ref] wrote:
Maybe BRCMSMAC should select BCMA rather than depending on it. This bus
seems like kind of an implementation detail that people are unlikely to
be aware of, unlike say PCI.
Yes, please. This is exactly the kind of thing "select" exists for.
Asking the user about some crazy proprietary broadcom bus interface is
useless, since no sane user should ever know or care about that kind
of thing.
Linus
@@ -230,6 +230,7 @@ int bcma_sprom_get(struct bcma_bus *bus)
* TODO: understand this condition and use it */
offset = (bus->chipinfo.id == 0x4331) ? BCMA_CC_SPROM :
BCMA_CC_SPROM_PCIE6;
+ pr_debug("SPROM offset 0x%x\n", offset);
bcma_sprom_read(bus, offset, sprom);
if (bus->chipinfo.id == 0x4331)
So I did that - the offset is printed out as 0x0830
(BCMA_CC_SPROM_PCIE6). And when I change the offset to 0x0800
(BCMA_CC_SPROM), the complaint about SPROM version goes away.
IOW, these messages no longer exist:
[ 0.815750] bcma: Unsupported SPROM revision: 255
[ 0.815804] bcma: No SPROM available
but that doesn't actually make anything *work*. The brcms errors still
remain the same.
So the SPROM issue seems to be real, but irrelevant.
I also noticed that the CONFIG_BRCMDBG onyl enables pr_debug(), but
doesn't actually #define DEBUG, so pr_debug() gets compiled out
anyway.
I'll try with -DDEBUG in the brcm80211 subdirectory and see if I get
more interesting output that way.
Linus
@@ -230,6 +230,7 @@ int bcma_sprom_get(struct bcma_bus *bus)*TODO:understandthisconditionanduseit*/offset=(bus->chipinfo.id==0x4331)?BCMA_CC_SPROM:BCMA_CC_SPROM_PCIE6;+pr_debug("SPROM offset 0x%x\n",offset);bcma_sprom_read(bus,offset,sprom);if(bus->chipinfo.id==0x4331)
So I did that - the offset is printed out as 0x0830
(BCMA_CC_SPROM_PCIE6). And when I change the offset to 0x0800
(BCMA_CC_SPROM), the complaint about SPROM version goes away.
IOW, these messages no longer exist:
[ 0.815750] bcma: Unsupported SPROM revision: 255
[ 0.815804] bcma: No SPROM available
but that doesn't actually make anything *work*. The brcms errors still
remain the same.
So the SPROM issue seems to be real, but irrelevant.
I also noticed that the CONFIG_BRCMDBG onyl enables pr_debug(), but
doesn't actually #define DEBUG, so pr_debug() gets compiled out
anyway.
I'll try with -DDEBUG in the brcm80211 subdirectory and see if I get
more interesting output that way.
OK. The SPROM issue is not completely irrelevant as that has to be correct, but
obviously not sufficient.
What is the PCI ID for your device?
Larry
On Wed, Jan 11, 2012 at 5:46 PM, Larry Finger [off-list ref] wrote:
OK. The SPROM issue is not completely irrelevant as that has to be correct,
but obviously not sufficient.
Hmm. Having dug a bit deeper, I do think it's kind of related.
I get -ENODATA form sprom_read_pci(), but that function actually seems
to get the offset *right*.
Some printout shows that for that chip, I have
- ai_get_ccrev(sih) = 34
- sprom_offset = 0x800
but then it apparently reads all ones anyway. At least in the first
word. So then I get that -ENODATA error.
So once more, it's somehow related to the sprom, just in a new place:
sprom_read_pci() in brcmsmac/srom.c instead of drivers/bcma/sprom.c.
Does that give people any new ideas to try out?
Linus
From: Larry Finger <hidden> Date: 2012-01-12 04:15:23
On 01/11/2012 08:11 PM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 5:46 PM, Larry Finger[off-list ref] wrote:
quoted
OK. The SPROM issue is not completely irrelevant as that has to be correct,
but obviously not sufficient.
Hmm. Having dug a bit deeper, I do think it's kind of related.
I get -ENODATA form sprom_read_pci(), but that function actually seems
to get the offset *right*.
Some printout shows that for that chip, I have
- ai_get_ccrev(sih) = 34
- sprom_offset = 0x800
but then it apparently reads all ones anyway. At least in the first
word. So then I get that -ENODATA error.
So once more, it's somehow related to the sprom, just in a new place:
sprom_read_pci() in brcmsmac/srom.c instead of drivers/bcma/sprom.c.
Does that give people any new ideas to try out?
Things are getting curious. I have a 14e4:4353 device, which works with both b43
and brcmsmac using mainline v3.2-6271-g925b5d2. The output of
dmesg | egrep "bcma|brcm"
with some extra debugging added yields:
bcma-pci-bridge 0000:06:00.0: PCI INT A -> Link[LK1E] -> GSI 22 (level, low) ->
IRQ 22
bcma-pci-bridge 0000:06:00.0: setting latency timer to 64
bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
bcma: Found rev 6 PMU (capabilities 0x108C2606)
bcma: SPROM offset 0x830
bcma: Found SPROM Revision 8
bcma: Bus registered
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
brcmsmac: Found chip type AI (0x1381a8d8)
brcmsmac: Applying 43224B0+ WARs
bcma: Switched to core: 0x812
brcms_module_init: register returned 0
I see no difference in the core revisions, etc. to explain why mine should work,
and yours fail.
Arend: Any particular place we should look?
Larry
On Wed, Jan 11, 2012 at 8:15 PM, Larry Finger [off-list ref] wrote:
I see no difference in the core revisions, etc. to explain why mine should
work, and yours fail.
Maybe your BIOS firmware sets things up, and the Apple Macbook Air
doesn't? And the driver used to initialize things sufficiently, and
the changes have broken that?
Apple is famous for being contrary. They tend to wire things up oddly,
they don't initialize things in the BIOS (they don't have a BIOS at
all, they use EFI, but even there they use their own abortion of an
EFI rather than what everybody else does), yadda yadda.
But the real point is: it used to work, and now it doesn't. This needs
to get fixed, or it will get reverted.
Linus
On Wed, Jan 11, 2012 at 9:20 PM, Linus Torvalds
[off-list ref] wrote:
Maybe your BIOS firmware sets things up, and the Apple Macbook Air
doesn't? And the driver used to initialize things sufficiently, and
the changes have broken that?
The code in v3.2 also used to support srom rev < 4, the new code
doesn't seem to do that.
Looking at the older initvars_srom_pci() (now "srom_var_init()") the
old code started out reading just SROM_WORDS, and then reading more
only if it found the srom4 signature. The new code always reads
SROM4_WORDS.
I dunno. But it looks to me like the new driver has dropped some logic
that used to exist in that driver. I don't know if it was ever used,
though, nor do I know if it's relevant. But if tat "dropped some
logic" is more widespread, it might well also cover some
initialization code.
Linus
On Wed, Jan 11, 2012 at 9:20 PM, Linus Torvalds
[off-list ref] wrote:
quoted
Maybe your BIOS firmware sets things up, and the Apple Macbook Air
doesn't? And the driver used to initialize things sufficiently, and
the changes have broken that?
The code in v3.2 also used to support srom rev < 4, the new code
doesn't seem to do that.
After hacking bcma to read SPROM from the correct location, what did
you get in dmesg? There should be info about version of SPROM.
There are 2 possible reasons for this issue:
1) bcma doesn't fully init your card
2) brcmsmac does sth wrong incorrectly as init
The story with brcmsmac is that it had code duplicated with bcma at
first. Now they partially switched to bcma, which inits bus for them,
and provide access to bus devices. However I'm afraid Broadcom didn't
remove duplicated init code (correct me if i'm wrong!). They may be
re-initializing bus and it's devices which cause some problems...
Linus: is this possible for you to give b43 a chance? It has to be compiled with
B43_BCMA
B43_PHY_N
Unfortunately you have to install firmware manually to get b43 working
:( Howto is located at:
http://wireless.kernel.org/en/users/Drivers/b43
("Install b43-fwcutter" and "If you are using the b43 driver from 3.2
kernel or newer:").
b43 doesn't re-init bus devices, so this test will check if bcma is OK or not.
--
Rafał
W dniu 12 stycznia 2012 08:08 użytkownik Rafał Miłecki
[off-list ref] napisał:
Linus: is this possible for you to give b43 a chance? It has to be compiled with
B43_BCMA
B43_PHY_N
Unfortunately you have to install firmware manually to get b43 working
:( Howto is located at:
http://wireless.kernel.org/en/users/Drivers/b43
("Install b43-fwcutter" and "If you are using the b43 driver from 3.2
kernel or newer:").
b43 doesn't re-init bus devices, so this test will check if bcma is OK or not.
That probably will require blacklisting brcmsmac for a moment to
prevent bcma auto-loading it. Testing from cold-boot is recommended.
--
Rafał
On Wed, Jan 11, 2012 at 9:30 PM, Linus Torvalds
[off-list ref] wrote:
The code in v3.2 also used to support srom rev < 4, the new code
doesn't seem to do that.
I ended up trying to bisect this, and seem to have been successful.
The problem came in not with the BCMA use, but with commit
888153b3db3f ("brcm80211: smac: avoid sprom endianess conversions for
crc8 check")
I haven't yet tried to revert this on top of the current tree, but I'm
pretty sure about the bisection. That commit changes things to be read
a byte at a time, but it *also* removes the old code that only read
SROM_WORDS from the SROM.
Might the apple parts have different SROM contents? I assume "SROM" is
just a serial rom, which may be external and contain things like the ?
All the BCMA changes make the revert somewhat non-trivial, could
somebody who knows the code better please try to do it for me? It
doesn't look complicated, and I can try to do it myself tomorrow if
nobody else steps up, but I'd *really* prefer the guilty parties
themselves to do it, ok?
Arend - it's your commit...
Linus
On Wed, Jan 11, 2012 at 9:30 PM, Linus Torvalds
[off-list ref] wrote:
quoted
The code in v3.2 also used to support srom rev < 4, the new code
doesn't seem to do that.
I ended up trying to bisect this, and seem to have been successful.
The problem came in not with the BCMA use, but with commit
888153b3db3f ("brcm80211: smac: avoid sprom endianess conversions for
crc8 check")
Uh, OK, that was tricky. BCMA switch was the biggest change and we
were assuming it has to be the guilty one. Thanks for bisecting!
--
Rafał
After hacking bcma to read SPROM from the correct location, what did
you get in dmesg? There should be info about version of SPROM.
When I changed the offset from 830 to 800, I didn't get any sprom
version information at all.
Anyway, as mentioned in another email I just sent out, I bisected it,
and the problem actually predates the move to bcma.
Linus
Uh, OK, that was tricky. BCMA switch was the biggest change and we
were assuming it has to be the guilty one. Thanks for bisecting!
Hey, I blamed the BCMA switch too, since it was the obvious big
change, and also caused the config problems I saw. So when the bisect
blithely went right past it and showed the exact same "si_attach
failed" messages even before that, I was all surprised.
Anyway, I'm done for today, and am hoping that somebody can pick up on
the revert effort.
Linus
From: Arend van Spriel <hidden> Date: 2012-01-12 10:04:08
On 01/12/2012 08:13 AM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 9:30 PM, Linus Torvalds
[off-list ref] wrote:
quoted
The code in v3.2 also used to support srom rev < 4, the new code
doesn't seem to do that.
I ended up trying to bisect this, and seem to have been successful.
The problem came in not with the BCMA use, but with commit
888153b3db3f ("brcm80211: smac: avoid sprom endianess conversions for
crc8 check")
Thanks for doing that while I had put my head on a pillow.
I haven't yet tried to revert this on top of the current tree, but I'm
pretty sure about the bisection. That commit changes things to be read
a byte at a time, but it *also* removes the old code that only read
SROM_WORDS from the SROM.
Might the apple parts have different SROM contents? I assume "SROM" is
just a serial rom, which may be external and contain things like the ?
Mostly configuration parameters for RF/PHY.
All the BCMA changes make the revert somewhat non-trivial, could
somebody who knows the code better please try to do it for me? It
doesn't look complicated, and I can try to do it myself tomorrow if
nobody else steps up, but I'd *really* prefer the guilty parties
themselves to do it, ok?
Arend - it's your commit...
From: Arend van Spriel <hidden> Date: 2012-01-12 13:13:42
On 01/12/2012 05:15 AM, Larry Finger wrote:
On 01/11/2012 08:11 PM, Linus Torvalds wrote:
quoted
On Wed, Jan 11, 2012 at 5:46 PM, Larry Finger[off-list ref] wrote:
quoted
OK. The SPROM issue is not completely irrelevant as that has to be correct,
but obviously not sufficient.
Hmm. Having dug a bit deeper, I do think it's kind of related.
I get -ENODATA form sprom_read_pci(), but that function actually seems
to get the offset *right*.
Some printout shows that for that chip, I have
- ai_get_ccrev(sih) = 34
- sprom_offset = 0x800
but then it apparently reads all ones anyway. At least in the first
word. So then I get that -ENODATA error.
So once more, it's somehow related to the sprom, just in a new place:
sprom_read_pci() in brcmsmac/srom.c instead of drivers/bcma/sprom.c.
Does that give people any new ideas to try out?
Things are getting curious. I have a 14e4:4353 device, which works with both b43
and brcmsmac using mainline v3.2-6271-g925b5d2. The output of
dmesg | egrep "bcma|brcm"
with some extra debugging added yields:
bcma-pci-bridge 0000:06:00.0: PCI INT A -> Link[LK1E] -> GSI 22 (level, low) ->
IRQ 22
bcma-pci-bridge 0000:06:00.0: setting latency timer to 64
bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
bcma: Found rev 6 PMU (capabilities 0x108C2606)
bcma: SPROM offset 0x830
bcma: Found SPROM Revision 8
bcma: Bus registered
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
brcmsmac: Found chip type AI (0x1381a8d8)
brcmsmac: Applying 43224B0+ WARs
bcma: Switched to core: 0x812
brcms_module_init: register returned 0
I see no difference in the core revisions, etc. to explain why mine should work,
and yours fail.
Arend: Any particular place we should look?
Larry
Hi, Larry
I am surprised that we end up on sprom_read_pci(). That suggests that
MacBook Air has an external sprom. Can you tell me what the function
ai_is_sprom_available() returns on your system?
Gr. AvS
From: Larry Finger <hidden> Date: 2012-01-12 15:39:17
On 01/12/2012 01:08 AM, Rafał Miłecki wrote:
2012/1/12 Linus Torvalds[off-list ref]:
quoted
On Wed, Jan 11, 2012 at 9:20 PM, Linus Torvalds
[off-list ref] wrote:
quoted
Maybe your BIOS firmware sets things up, and the Apple Macbook Air
doesn't? And the driver used to initialize things sufficiently, and
the changes have broken that?
The code in v3.2 also used to support srom rev< 4, the new code
doesn't seem to do that.
After hacking bcma to read SPROM from the correct location, what did
you get in dmesg? There should be info about version of SPROM.
In the bcma version of the SPROM reading, there is no error logging other than
the incorrect version message. In particular, there is no message when the CRC
test fails, and the version will not be logged.
Larry
W dniu 12 stycznia 2012 16:39 użytkownik Larry Finger
[off-list ref] napisał:
On 01/12/2012 01:08 AM, Rafał Miłecki wrote:
quoted
2012/1/12 Linus Torvalds[off-list ref]:
quoted
On Wed, Jan 11, 2012 at 9:20 PM, Linus Torvalds
[off-list ref] wrote:
quoted
Maybe your BIOS firmware sets things up, and the Apple Macbook Air
doesn't? And the driver used to initialize things sufficiently, and
the changes have broken that?
The code in v3.2 also used to support srom rev< 4, the new code
doesn't seem to do that.
After hacking bcma to read SPROM from the correct location, what did
you get in dmesg? There should be info about version of SPROM.
In the bcma version of the SPROM reading, there is no error logging other
than the incorrect version message. In particular, there is no message when
the CRC test fails, and the version will not be logged.
Oops, you're right. I forgot bcma doesn't have that (on the difference to ssb).
--
Rafał
From: Larry Finger <hidden> Date: 2012-01-12 16:22:53
On 01/12/2012 07:13 AM, Arend van Spriel wrote:
Hi, Larry
I am surprised that we end up on sprom_read_pci(). That suggests that
MacBook Air has an external sprom. Can you tell me what the function
ai_is_sprom_available() returns on your system?
From: Larry Finger <hidden> Date: 2012-01-12 17:18:33
On 01/12/2012 07:13 AM, Arend van Spriel wrote:
I am surprised that we end up on sprom_read_pci(). That suggests that
MacBook Air has an external sprom. Can you tell me what the function
ai_is_sprom_available() returns on your system?
For completeness, sromctrl is 0x12, thus bit 1 (SRC_PRESENT) is not set, and my
device has an OTP, not an SPROM.
I do not see anything wrong with commit 888153b3db3f, but I realize that my card
really does not test any of those changes.
Larry
On Thu, Jan 12, 2012 at 9:18 AM, Larry Finger [off-list ref] wrote:
For completeness, sromctrl is 0x12, thus bit 1 (SRC_PRESENT) is not set, and
my device has an OTP, not an SPROM.
So this is again something that apple is *famous* for.
They try to control their hardware very tightly, and OS X will (for
example) not use non-apple wireless cards as "Airport" cards, and will
do things like dropping features ("Oh, you tried to save money by
buying a generic wireless minipci card instead of the apple branded
one? Well, that's fine, but now I'll make your network flaky and will
refuse to support 802.11n just to make a point.").
Never mind that the hardware is the same - they'll literally look at
the PCI subvendor ID and things like that, and if it doesn't say
"Apple", they will simply not enable all the features, or won't even
connect to it.
They've done this forever. Others do it too (I think both HP and IBM
have done the exact same thing with minipci wireless cards - back when
WiFi used to be a "premium" thing in a laptop, and vendors charged
quite a bit extra for it, gah!). But Apple does it for a *lot* of
things, presumably because they want to make it extra hard for clone
makers (or just tinkerers that would try to run OS X on a regular PC
that just happened to have the exact same hardware as a Macbook).
Seriously. I really like my Macbook Air hardware, but the moment some
non-apple supplier makes anything comparable, I'll drop it like the
crap it is. Exactly because Apple uses software to make it harder to
use. Installing Linux on that thing is "interesting" - Linux works
perfectly fine on it, but with all the special Apple firmware crap,
you have to jump through hoops.
I do not see anything wrong with commit 888153b3db3f, but I realize that my
card really does not test any of those changes.
I suspect the big change is the version check and the size of the
sprom image. Apple probably has an older version. I assume that the
subvendor ID etc comes from the srom?
Linus
From: Larry Finger <hidden> Date: 2012-01-12 17:44:26
On 01/12/2012 11:31 AM, Linus Torvalds wrote:
On Thu, Jan 12, 2012 at 9:18 AM, Larry Finger[off-list ref] wrote:
quoted
For completeness, sromctrl is 0x12, thus bit 1 (SRC_PRESENT) is not set, and
my device has an OTP, not an SPROM.
So this is again something that apple is *famous* for.
They try to control their hardware very tightly, and OS X will (for
example) not use non-apple wireless cards as "Airport" cards, and will
do things like dropping features ("Oh, you tried to save money by
buying a generic wireless minipci card instead of the apple branded
one? Well, that's fine, but now I'll make your network flaky and will
refuse to support 802.11n just to make a point.").
Never mind that the hardware is the same - they'll literally look at
the PCI subvendor ID and things like that, and if it doesn't say
"Apple", they will simply not enable all the features, or won't even
connect to it.
They've done this forever. Others do it too (I think both HP and IBM
have done the exact same thing with minipci wireless cards - back when
WiFi used to be a "premium" thing in a laptop, and vendors charged
quite a bit extra for it, gah!). But Apple does it for a *lot* of
things, presumably because they want to make it extra hard for clone
makers (or just tinkerers that would try to run OS X on a regular PC
that just happened to have the exact same hardware as a Macbook).
Seriously. I really like my Macbook Air hardware, but the moment some
non-apple supplier makes anything comparable, I'll drop it like the
crap it is. Exactly because Apple uses software to make it harder to
use. Installing Linux on that thing is "interesting" - Linux works
perfectly fine on it, but with all the special Apple firmware crap,
you have to jump through hoops.
quoted
I do not see anything wrong with commit 888153b3db3f, but I realize that my
card really does not test any of those changes.
I suspect the big change is the version check and the size of the
sprom image. Apple probably has an older version. I assume that the
subvendor ID etc comes from the srom?
HP is not at all subtle. Their BIOS checks the hardware in the internal PCIe
slot. If it is wifi and not on their whitelist, the computer will not boot. For
my testing, Realtek sent me an extender that plugs into an Express Card slot.
When this machine dies, I'm not sure what I'll do as I have not found a modern
laptop with such a slot.
I too would like to blame Apple, but there is one factoid that I just noticed
and I'm still exploring. When I run bcma/b43, the software says I have a Rev 8
SPROM at offset 0x830, but bcma/brcmsmac says my card has no SPROM and it uses
the OTP branch! Why, and what does it mean? Any thoughts from the Broadcom guys?
Larry
On Wed, Jan 11, 2012 at 11:13 PM, Linus Torvalds
[off-list ref] wrote:
All the BCMA changes make the revert somewhat non-trivial, could
somebody who knows the code better please try to do it for me? It
doesn't look complicated, and I can try to do it myself tomorrow if
nobody else steps up, but I'd *really* prefer the guilty parties
themselves to do it, ok?
Since I had the hardware to test, I could work on this and try to
figure out exactly what went wrong in that commit.
The problem seems to be simple: the SPROM contents *have* to be read
as aligned 16-bit words. Anything else seems to return 0xff and just
fails the transaction.
I didn't check all the combinations, of course, so who knows what the
exact details are, but it does look like the sprom has very limited
pci decode and simply refuses to touch anything but the one case it
can handle.
I'll send out a patch that seems to get things to a working state for
me. At least I have wireless connectivity again, I don't know if there
are some other problems remaining.
Linus
On Thu, Jan 12, 2012 at 11:00 AM, Linus Torvalds
[off-list ref] wrote:
I'll send out a patch that seems to get things to a working state for
me. At least I have wireless connectivity again, I don't know if there
are some other problems remaining.
Ok, this is the patch that gets me going, and this is sent from the Macbook Air.
NOTE! The BCMA confusion about the sprom still exists, but doesn't
seem to matter:
bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
bcma: Found rev 6 PMU (capabilities 0x108C2606)
bcma: Unsupported SPROM revision: 255
bcma: No SPROM available
bcma: Bus registered
..
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
brcmsmac: Found chip type AI (0x1381a8d8)
brcmsmac: Applying 43224B0+ WARs
bcma: Switched to core: 0x812
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
brcms_module_init: register returned 0
so this does seem to work, but there are clearly some issues still..
Linus
From: Arend van Spriel <hidden> Date: 2012-01-12 19:46:47
On 01/12/2012 08:00 PM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 11:13 PM, Linus Torvalds
[off-list ref] wrote:
quoted
All the BCMA changes make the revert somewhat non-trivial, could
somebody who knows the code better please try to do it for me? It
doesn't look complicated, and I can try to do it myself tomorrow if
nobody else steps up, but I'd *really* prefer the guilty parties
themselves to do it, ok?
Since I had the hardware to test, I could work on this and try to
figure out exactly what went wrong in that commit.
I was trying to get my hands on a card with SPROM to dig in and I still
intend to get it because Apples are no pears.
The problem seems to be simple: the SPROM contents *have* to be read
as aligned 16-bit words. Anything else seems to return 0xff and just
fails the transaction.
I was already wondering what aspect of the patch was causing the issue.
The transaction size requirement seems likely and I was not aware.
I didn't check all the combinations, of course, so who knows what the
exact details are, but it does look like the sprom has very limited
pci decode and simply refuses to touch anything but the one case it
can handle.
I'll send out a patch that seems to get things to a working state for
me. At least I have wireless connectivity again, I don't know if there
are some other problems remaining.
Linus
Thanks for putting the effort into this in the middle of a merge window.
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-01-12 20:09:34
On 01/12/2012 08:08 PM, Linus Torvalds wrote:
On Thu, Jan 12, 2012 at 11:00 AM, Linus Torvalds
[off-list ref] wrote:
quoted
I'll send out a patch that seems to get things to a working state for
me. At least I have wireless connectivity again, I don't know if there
are some other problems remaining.
Ok, this is the patch that gets me going, and this is sent from the Macbook Air.
NOTE! The BCMA confusion about the sprom still exists, but doesn't
seem to matter:
That is because brcmsmac is not relying on the sprom logic provided by
bcma. As Rafał indicated that is duplicated code so if we are to use
bcma sprom functionality that needs to be fixed (after the merge window).
bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
bcma: Found rev 6 PMU (capabilities 0x108C2606)
bcma: Unsupported SPROM revision: 255
bcma: No SPROM available
bcma: Bus registered
..
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
brcmsmac: Found chip type AI (0x1381a8d8)
brcmsmac: Applying 43224B0+ WARs
bcma: Switched to core: 0x812
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
brcms_module_init: register returned 0
so this does seem to work, but there are clearly some issues still..
Linus
That output look fine. The patch looks fine although you can use the new
do_crc_check() function in otp_read_pci as well.
Gr. AvS
That output look fine. The patch looks fine although you can use the new
do_crc_check() function in otp_read_pci as well.
I'll leave that as a separate cleanup for somebody who has the
hardware to test it. I committed the 16-bit read fix for now.
But I'm currently also trying to work out why that macbook air no
longer comes back from a suspend alive, and it looks like it may be
another problem with that brcmsmac driver. The bisection is in its
early stages yet, but it looks like it is coming in from the network
merge, and nothing else looks relevant.
Has suspend/resume been tested exhaustively with that driver?
Linus
From: Arend van Spriel <hidden> Date: 2012-01-12 20:36:44
On 01/12/2012 09:27 PM, Linus Torvalds wrote:
2012/1/12 Arend van Spriel [off-list ref]:
quoted
That output look fine. The patch looks fine although you can use the new
do_crc_check() function in otp_read_pci as well.
I'll leave that as a separate cleanup for somebody who has the
hardware to test it. I committed the 16-bit read fix for now.
Ah. yet another hint :-p
But I'm currently also trying to work out why that macbook air no
longer comes back from a suspend alive, and it looks like it may be
another problem with that brcmsmac driver. The bisection is in its
early stages yet, but it looks like it is coming in from the network
merge, and nothing else looks relevant.
Has suspend/resume been tested exhaustively with that driver?
Linus
BCMA introduced suspend/resume after the BCMA changes in brcmsmac so
there may still be issues.
Gr. AvS
On Thu, Jan 12, 2012 at 12:27 PM, Linus Torvalds
[off-list ref] wrote:
But I'm currently also trying to work out why that macbook air no
longer comes back from a suspend alive, and it looks like it may be
another problem with that brcmsmac driver. The bisection is in its
early stages yet, but it looks like it is coming in from the network
merge, and nothing else looks relevant.
Ugh. This is nasty to bisect, because it goes back to the pre-3.2 days
that didn't support graphics properly on that Macbook Air either. So
I've been having to work around not just the "wireless doesn't work",
but also the "graphics doesn't work" issue.
But after lots of nasty bisection problems and a few false starts, it
definitely looks like the brcmsmac driver. I don't know exactly which
commit, but it's all in network drivers now, and the only network
driver on this machine is the brcmsmac one.
Linus
On Thu, Jan 12, 2012 at 12:27 PM, Linus Torvalds
[off-list ref] wrote:
quoted
But I'm currently also trying to work out why that macbook air no
longer comes back from a suspend alive, and it looks like it may be
another problem with that brcmsmac driver. The bisection is in its
early stages yet, but it looks like it is coming in from the network
merge, and nothing else looks relevant.
Ugh. This is nasty to bisect, because it goes back to the pre-3.2 days
that didn't support graphics properly on that Macbook Air either. So
I've been having to work around not just the "wireless doesn't work",
but also the "graphics doesn't work" issue.
But after lots of nasty bisection problems and a few false starts, it
definitely looks like the brcmsmac driver. I don't know exactly which
commit, but it's all in network drivers now, and the only network
driver on this machine is the brcmsmac one.
Make sure you have
commit 775ab52142b02237a54184238e922251c59a2b5c
Author: Rafał Miłecki [off-list ref]
Date: Fri Dec 9 22:16:07 2011 +0100
bcma: support for suspend and resume
applied. I believe this patch already has hit your tree, but maybe
because of bisecting you are at some old commit without this patch.
--
Rafał
Make sure you have
commit 775ab52142b02237a54184238e922251c59a2b5c
Author: Rafał Miłecki [off-list ref]
Date: Fri Dec 9 22:16:07 2011 +0100
bcma: support for suspend and resume
applied. I believe this patch already has hit your tree, but maybe
because of bisecting you are at some old commit without this patch.
That one is *not* sufficient. Current -git doesn't suspend/resume.
Linus
W dniu 12 stycznia 2012 23:45 użytkownik Linus Torvalds
[off-list ref] napisał:
2012/1/12 Rafał Miłecki [off-list ref]:
quoted
Make sure you have
commit 775ab52142b02237a54184238e922251c59a2b5c
Author: Rafał Miłecki [off-list ref]
Date: Fri Dec 9 22:16:07 2011 +0100
bcma: support for suspend and resume
applied. I believe this patch already has hit your tree, but maybe
because of bisecting you are at some old commit without this patch.
That one is *not* sufficient. Current -git doesn't suspend/resume.
Forgive me if it was already said, but I didn't see it.
Have you tried booting with bcma & brcmsmac blacklisted? Does
suspend&resume work then?
Have you tried blacklisting just brcmsmac (letting bcma load)? Does
s&r work then?
--
Rafał
Have you tried booting with bcma & brcmsmac blacklisted? Does
suspend&resume work then?
Have you tried blacklisting just brcmsmac (letting bcma load)? Does
s&r work then?
If I unload brcmsmac, I can suspend/resume. Once. It can't suspend a
second time.
I did see some message flash about "does not have a release()
function", but don't know if that was bcma or something else.
I do notice that both the bcma and suspend/resume seems quite broken.
It's using the legacy suspend/resume stuff and does the PCI resume on
its own (with no matching suspend!). That *really* isn't a good idea
these days.
The way to do it these days is to have a struct dev_pm_ops embedded in
the struct pci_driver (".driver.pm"), and let the PCI layer handle all
the generic PCI suspend/resume details - you only handle the
device-specific ones (ie in this case suspending/resuming the bcma bus
itself).
The generic PCI layer will do all the PCI stuff correctly, including
all the nasty races with shared interrupts etc. In a way that no
driver ever got it right. And it simplifies the driver too.
And the brcms driver does suspend/resume *completely* wrong, and seems
to actually re-suspend and re-resume the PCI device.
I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
Linus
From: Larry Finger <hidden> Date: 2012-01-13 01:53:20
On 01/12/2012 01:00 PM, Linus Torvalds wrote:
On Wed, Jan 11, 2012 at 11:13 PM, Linus Torvalds
[off-list ref] wrote:
quoted
All the BCMA changes make the revert somewhat non-trivial, could
somebody who knows the code better please try to do it for me? It
doesn't look complicated, and I can try to do it myself tomorrow if
nobody else steps up, but I'd *really* prefer the guilty parties
themselves to do it, ok?
Since I had the hardware to test, I could work on this and try to
figure out exactly what went wrong in that commit.
The problem seems to be simple: the SPROM contents *have* to be read
as aligned 16-bit words. Anything else seems to return 0xff and just
fails the transaction.
I didn't check all the combinations, of course, so who knows what the
exact details are, but it does look like the sprom has very limited
pci decode and simply refuses to touch anything but the one case it
can handle.
I'll send out a patch that seems to get things to a working state for
me. At least I have wireless connectivity again, I don't know if there
are some other problems remaining.
As my device has both SPROM and OTP, I hacked on it to get it to use the SPROM
rather than the default OTP.
I learned that reading by byte on my HP laptop fails the same was as did the
MacBook - it is not an Apple artifact.
Note, the patch that worked for me is as follows:
Index: linux-2.6/drivers/net/wireless/brcm80211/brcmsmac/srom.c
===================================================================
@@ -786,9 +786,12 @@ sprom_read_pci(struct si_pub *sih, u16 *sprom_offset=CHIPCREGOFFS(sromotp);}-/* read the sprom in bytes */-for(i=0;i<nbytes;i++)-bbuf[i]=bcma_read8(core,sprom_offset+i);+/* read the sprom - this operation must be done by words */+for(i=0;i<nbytes;i+=2){+u16data=bcma_read16(core,sprom_offset+i);+bbuf[i]=data&0xff;+bbuf[i+1]=(data>>8)&0xff;+}if(buf[0]==0xffff)/*
I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
So I can suspend the bcma driver on its own until the cows come home.
But after I have suspended the bcma driver even once, just doing a
"modprobe brcmsmac" will hang the machine hard. Dunno where, but this
is probably the same thing as "hangs on resume".
Linus
I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
So I can suspend the bcma driver on its own until the cows come home.
But after I have suspended the bcma driver even once, just doing a
"modprobe brcmsmac" will hang the machine hard. Dunno where, but this
is probably the same thing as "hangs on resume".
Guys, has suspend/resume with the bcma interface been tested AT ALL?
The suspend/resume fields of "struct bcma_driver" are COMPLETELY
UNUSED. The only place in the kernel that uses them is the brcmsmac
driver that does this write-only assignment:
.suspend = brcms_suspend,
.resume = brcms_resume,
nothing else uses them. NOTHING. I tested by just removing the fields
and compiling the bcma subsystem, just in case there was something
really subtle that I was missing and was hidden through some magic
hidden approach. But no.
Seriously - how was something that isn't even connected ever supposed
to work at all? And why was the BCMA conversion of that driver sent
up-stream if something as fundamental as suspend/resume had never been
done, and didn't actually work?
What am I missing now? How the hell can this ever have worked for
ANYBODY? What kind of f*&*ing sick joke is this all?
Linus
W dniu 13 stycznia 2012 06:34 użytkownik Linus Torvalds
[off-list ref] napisał:
2012/1/12 Linus Torvalds [off-list ref]:
quoted
2012/1/12 Linus Torvalds [off-list ref]:
quoted
I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
So I can suspend the bcma driver on its own until the cows come home.
But after I have suspended the bcma driver even once, just doing a
"modprobe brcmsmac" will hang the machine hard. Dunno where, but this
is probably the same thing as "hangs on resume".
Guys, has suspend/resume with the bcma interface been tested AT ALL?
The suspend/resume fields of "struct bcma_driver" are COMPLETELY
UNUSED. The only place in the kernel that uses them is the brcmsmac
driver that does this write-only assignment:
.suspend = brcms_suspend,
.resume = brcms_resume,
nothing else uses them. NOTHING. I tested by just removing the fields
and compiling the bcma subsystem, just in case there was something
really subtle that I was missing and was hidden through some magic
hidden approach. But no.
Seriously - how was something that isn't even connected ever supposed
to work at all? And why was the BCMA conversion of that driver sent
up-stream if something as fundamental as suspend/resume had never been
done, and didn't actually work?
What am I missing now? How the hell can this ever have worked for
ANYBODY? What kind of f*&*ing sick joke is this all?
The suspend&resume wasn't implemented for some time because my PC
doesn't s&r. And I don't have access to notebook with mini PCIe slot.
I've implemented support for s&r in bcma when I got to open my Sony
VAIO to replace A/C power slot. It was one time I was able to change
WiFi card in my notebook which has really-ugly-hidden mini PCIe slot.
S&r was working fine for me with bcma&b43 after writing that patch!
That includes suspending and resuming multiple times. And tests were
done with the same card you're using.
The lock up on (resume|loading brcmsmac) means bus wasn't initialized
correctly after resume. It does not have to be brcmsmac bug. We're
accessing some registers before they're ready.
Linus: can you do one trivial test for me? Please simply try unloading
bcma before suspending. Then resume and load bcma and brcmsmac. Does
it still lockup your machine?
--
Rafał
W dniu 13 stycznia 2012 07:50 użytkownik Rafał Miłecki
[off-list ref] napisał:
W dniu 13 stycznia 2012 06:34 użytkownik Linus Torvalds
[off-list ref] napisał:
quoted
2012/1/12 Linus Torvalds [off-list ref]:
quoted
2012/1/12 Linus Torvalds [off-list ref]:
quoted
I'm surprised it has ever worked for anybody. It certainly doesn't work for me.
So I can suspend the bcma driver on its own until the cows come home.
But after I have suspended the bcma driver even once, just doing a
"modprobe brcmsmac" will hang the machine hard. Dunno where, but this
is probably the same thing as "hangs on resume".
Guys, has suspend/resume with the bcma interface been tested AT ALL?
The suspend/resume fields of "struct bcma_driver" are COMPLETELY
UNUSED. The only place in the kernel that uses them is the brcmsmac
driver that does this write-only assignment:
.suspend = brcms_suspend,
.resume = brcms_resume,
nothing else uses them. NOTHING. I tested by just removing the fields
and compiling the bcma subsystem, just in case there was something
really subtle that I was missing and was hidden through some magic
hidden approach. But no.
Seriously - how was something that isn't even connected ever supposed
to work at all? And why was the BCMA conversion of that driver sent
up-stream if something as fundamental as suspend/resume had never been
done, and didn't actually work?
What am I missing now? How the hell can this ever have worked for
ANYBODY? What kind of f*&*ing sick joke is this all?
The suspend&resume wasn't implemented for some time because my PC
doesn't s&r. And I don't have access to notebook with mini PCIe slot.
I've implemented support for s&r in bcma when I got to open my Sony
VAIO to replace A/C power slot. It was one time I was able to change
WiFi card in my notebook which has really-ugly-hidden mini PCIe slot.
S&r was working fine for me with bcma&b43 after writing that patch!
That includes suspending and resuming multiple times. And tests were
done with the same card you're using.
The lock up on (resume|loading brcmsmac) means bus wasn't initialized
correctly after resume. It does not have to be brcmsmac bug. We're
accessing some registers before they're ready.
Linus: can you do one trivial test for me? Please simply try unloading
bcma before suspending. Then resume and load bcma and brcmsmac. Does
it still lockup your machine?
Actually.. I've re-read your mail and I got it wrong at first. I
though you can suspend&resume once, but then loading brcmsmac causes
lock up. I interpreted that as broken initialization after resume.
Now I see you *can't suspend for the second time*. I don't get it :/
I've no idea what wrong we may be doing in that trivial
bcma_host_pci_suspend and bcma_host_pci_resume stopping you from
suspending for the second time.
I'll take a look at that new pm ops you told me about.
--
Rafał
Linus: can you do one trivial test for me? Please simply try unloading
bcma before suspending. Then resume and load bcma and brcmsmac. Does
it still lockup your machine?
That works, but is not interesting. It just reloads everything.
The thing is, your hardware clearly never powers anything down,
because the bcma suspend/resume functions aren't hooked up to
anything, so the brcmsmac suspend/resume never gets called at all.
And it sounds like it works for you for the simple reason that your
hardware never loses power - so you don't need to do anything for
suspend/resume.
But there is absolutely zero question about it - the code does not
work. Never has. It's just that your hardware doesn't *need* any code
at all, and as far as you are concerned, suspend/resume doesn't even
really happen (the PCI layer handles the regular "set to D3 and back
to D0", so the fact that the driver doesn't do anything never shows
up)
Linus
Actually.. I've re-read your mail and I got it wrong at first. I
though you can suspend&resume once, but then loading brcmsmac causes
lock up. I interpreted that as broken initialization after resume.
That is correct.
And I cannot suspend/resume AT ALL if I actually keep brcmsmac loaded
- then it will lock up at resume - exactly the same way it locks up at
loading brcmsmac time if I had unloaded it.
Now I see you *can't suspend for the second time*. I don't get it :/
No, that was an unrelated bug, I'm chasing that one down too and it
seems to be in the machine check driver.
Linus
Yup. This definitely helps.
I haven't done a lot of suspend/resume cycles, and I have my own
cleanups in my tree, but with this, I finally get a successful resume.
I'll send out a series of cleanups and fixes that will include this.
Can you test whether my series works for you too?
Linus
On Thu, Jan 12, 2012 at 11:41 PM, Rafał Miłecki [off-list ref] wrote:
So here are five cleanup/fix patches that try to make the bcma and
brcmsmac suspend/resume situation look better.
The changes do:
- use the modern PCI suspend/resume model, and let the PCI layer handle
the actual standard power state changes.
- clean up the BCMA suspend/resume infrastructure a bit in general.
- actually hook the BCMA suspend/resume callbacks up to the
suspend/resume event - it use to be that a bcma driver could set its
suspend/resume routines, but nothing would ever call them.
- and Rafał's bcma window invalidation
Comments? This gets suspend/resume working for me at least once. I'm not
going to try to hang my machine again until after I have gotten this sent
out.
Does this work for others?
Linus
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 12 Jan 2012 22:50:31 -0800
.. and connect it up with the pci host bcma driver.
Now, the next step is to connect those bcma bus-level suspend/resume
functions to the actual bcma device suspend resume functions.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/bcma/bcma_private.h | 1 +
drivers/bcma/host_pci.c | 5 ++++-
drivers/bcma/main.c | 5 +++++
3 files changed, 10 insertions(+), 1 deletions(-)
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 12 Jan 2012 23:36:52 -0800
The brcmsmac driver isn't a PCI driver any more, it's a bcma one. The
PCI device has been resumed by the PCI driver (the generic PCI layer,
really), we should be resuming just our own driver state.
Also add pr_debug() calls to show that we now actually get the
suspend/resume events.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 38 ++------------------
1 files changed, 3 insertions(+), 35 deletions(-)
From: Rafał Miłecki <zajec5@gmail.com>
Date: Thu, 12 Jan 2012 23:51:30 -0800
This clears the current mapped window when suspending, so that the
resumed state will re-map them as required.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/bcma/main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
From: Arend van Spriel <hidden> Date: 2012-01-13 09:59:17
On 01/13/2012 09:01 AM, Linus Torvalds wrote:
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 12 Jan 2012 23:36:52 -0800
The brcmsmac driver isn't a PCI driver any more, it's a bcma one. The
PCI device has been resumed by the PCI driver (the generic PCI layer,
really), we should be resuming just our own driver state.
Also add pr_debug() calls to show that we now actually get the
suspend/resume events.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I made similar change as well last night, but did not get to test it. I
will test this series instead.
Gr. AvS
W dniu 13 stycznia 2012 08:59 użytkownik Linus Torvalds
[off-list ref] napisał:
So here are five cleanup/fix patches that try to make the bcma and
brcmsmac suspend/resume situation look better.
The changes do:
- use the modern PCI suspend/resume model, and let the PCI layer handle
the actual standard power state changes.
- clean up the BCMA suspend/resume infrastructure a bit in general.
- actually hook the BCMA suspend/resume callbacks up to the
suspend/resume event - it use to be that a bcma driver could set its
suspend/resume routines, but nothing would ever call them.
- and Rafał's bcma window invalidation
Comments? This gets suspend/resume working for me at least once. I'm not
going to try to hang my machine again until after I have gotten this sent
out.
Does this work for others?
I have Asus netbook with BCM4313 since a week, so I'll able to test
this. Just give me a day when I'm back home.
Could we rearrange order of patches to make
bcma: invalidate the mapped window over suspend/resume
this first one and add stable as CC? What do you think about this?
--
Rafał
From: Arend van Spriel <hidden> Date: 2012-01-13 11:07:01
On 01/13/2012 08:59 AM, Linus Torvalds wrote:
So here are five cleanup/fix patches that try to make the bcma and
brcmsmac suspend/resume situation look better.
The changes do:
- use the modern PCI suspend/resume model, and let the PCI layer handle
the actual standard power state changes.
- clean up the BCMA suspend/resume infrastructure a bit in general.
- actually hook the BCMA suspend/resume callbacks up to the
suspend/resume event - it use to be that a bcma driver could set its
suspend/resume routines, but nothing would ever call them.
- and Rafał's bcma window invalidation
Comments? This gets suspend/resume working for me at least once. I'm not
going to try to hang my machine again until after I have gotten this sent
out.
Does this work for others?
Linus
I have a Dell Latitude E6410 over here. I applied the patches to
commit 099469502f62fbe0d7e4f0b83a2f22538367f734
Merge: 7c17d86 35f1526
Author: Linus Torvalds [off-list ref]
Date: Thu Jan 12 20:42:54 2012 -0800
Merge branch 'akpm' (aka "Andrew's patch-bomb, take two")
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Normally, the power button led will flash in suspend mode, but it stays
active and I have to force a powerdown (holding the power button).
So for now I can't say the patches are good or bad for that matter.
Gr. AvS
[ 816.878395] bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800,
rev 0x22, class 0x0)
[ 816.886898] bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812,
rev 0x17, class 0x0)
[ 816.895559] bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev
0x0F, class 0x0)
[ 816.937118] bcma: Bus registered
[ 825.953621] cfg80211: Calling CRDA to update world regulatory domain
[ 854.763733] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
[ 854.937773] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 854.938929] brcms_module_init: register returned 0
[ 854.939332] cfg80211: Calling CRDA for country: US
[ 854.942730] cfg80211: Regulatory domain changed to country: US
[ 856.045618] udev[473]: renamed network interface wlan0 to wlan2
[ 856.072472] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled:
false (implement)
[ 856.092191] ieee80211 phy0: brcms_ops_config: change power-save mode:
false (implement)
[ 856.103216] ADDRCONF(NETDEV_UP): wlan2: link is not ready
[ 856.943778] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48)
on phy0
[ 858.487656] cfg80211: Found new beacon on frequency: 5745 MHz (Ch
149) on phy0
[ 858.569901] cfg80211: Found new beacon on frequency: 5765 MHz (Ch
153) on phy0
[ 872.794509] wlan2: authenticate with c0:c1:c0:04:b8:2c (try 1)
[ 872.802028] wlan2: authenticated
[ 872.805298] wlan2: associate with c0:c1:c0:04:b8:2c (try 1)
[ 872.814451] wlan2: RX AssocResp from c0:c1:c0:04:b8:2c (capab=0x411
status=0 aid=2)
[ 872.822164] wlan2: associated
[ 872.825143] wlan2: moving STA c0:c1:c0:04:b8:2c to state 1
[ 872.830643] wlan2: moving STA c0:c1:c0:04:b8:2c to state 2
[ 872.836126] wlan2: moving STA c0:c1:c0:04:b8:2c to state 3
[ 872.842363] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled:
true (implement)
[ 872.850202] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed:
associated
[ 872.857249] ieee80211 phy0: changing basic rates failed: -22
[ 872.862902] ieee80211 phy0: brcms_ops_bss_info_changed: arp
filtering: enabled true, count 0 (implement)
[ 872.872612] ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready
[ 872.873311] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not
AMPDU
[ 872.885340] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not
AMPDU
[ 876.352453] ieee80211 phy0: brcms_ops_bss_info_changed: arp
filtering: enabled true, count 1 (implement)
[ 883.711301] wlan2: no IPv6 routers present
[ 979.497669] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,commit=0
[ 979.508400] EXT4-fs (sda7): re-mounted. Opts: commit=0
[ 980.899784] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled:
false (implement)
[ 980.907761] ieee80211 phy0: brcmsmac: brcms_ops_bss_info_changed:
disassociated
[ 980.915061] ieee80211 phy0: brcms_ops_bss_info_changed: arp
filtering: enabled false, count 1 (implement)
[ 980.924656] wlan2: deauthenticating from c0:c1:c0:04:b8:2c by local
choice (reason=3)
[ 980.932675] wlan2: moving STA c0:c1:c0:04:b8:2c to state 2
[ 980.938171] wlan2: moving STA c0:c1:c0:04:b8:2c to state 1
[ 980.943692] wlan2: moving STA c0:c1:c0:04:b8:2c to state 0
[ 980.949462] cfg80211: All devices are disconnected, going to restore
regulatory settings
[ 980.957590] cfg80211: Restoring regulatory settings
[ 980.962491] cfg80211: Calling CRDA to update world regulatory domain
[ 981.567922] cfg80211: World regulatory domain updated:
[ 982.312893] PM: Syncing filesystems ... done.
[ 982.356261] PM: Preparing system for mem sleep
[ 982.371219] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[ 982.390543] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[ 982.410514] PM: Entering mem sleep
[ 982.414712] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 982.420182] sd 0:0:0:0: [sda] Stopping disk
I have Asus netbook with BCM4313 since a week, so I'll able to test
this. Just give me a day when I'm back home.
Could we rearrange order of patches to make
bcma: invalidate the mapped window over suspend/resume
this first one and add stable as CC? What do you think about this?
I don't think it is relevant for stable - partly because in stable the
bcma suspend/resume isn't wired up anyway, but mostly because if that
patch really wants to make it into stable, it really is a different
patch than the one I munged it into. The stable bcma doesn't have
bcma_bus_suspend() at all, so it goes into that pci-specific one like
your original email had it, where it's a complete hack.
Does it fix anything in stable?
Linus
I have a Dell Latitude E6410 over here. I applied the patches to
commit 099469502f62fbe0d7e4f0b83a2f22538367f734
Merge: 7c17d86 35f1526
Author: Linus Torvalds [off-list ref]
Date: Thu Jan 12 20:42:54 2012 -0800
Merge branch 'akpm' (aka "Andrew's patch-bomb, take two")
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Ok, so it's not the bcma/brcmsmac drivers, and your hang seems to be
at suspend time.
There is at least one other suspend problem in the current merge
window, you may be hitting them. The one I know about is some oddity
with the machine check driver, so if you have CONFIG_X86_MCE enabled,
try compiling without it.
Also, try
echo devices > /sys/power/pm_test
echo mem > /sys/power/state
which doesn't do the "real" suspend, but only goes through the device
suspend. That often leaves more of a trace of what may have gone
wrong.
Linus
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Ok, I note that you do have MCE enabled.
The MCE problems should be fixed in current -git, and so it might be
worth re-testing with that.
Linus
Hi,
Sorry to hijack this thread, but I had the exact same problem Arend has
and disabling MCE fixed it.. Since it froze only after resume and it
didn't send anything to netconsole at this moment I've had this for some
time without any good debug info, so first is a thank you!
I'd like to try if the fix in current -git works, could you remind me
the exact tree name you call this?
I'm familiar with linux-2.6.git, wireless-testing.git, and
linux-next.git, but it's not resolved in linux-next.git not
linux-2.6.git's HEAD at the very least.
By the way, resume/suspend works with your patches over linux-next.git
with a bcm4313 on a eeepc1215b!
Regards,
--
Dominique Martinet | Asmadeus
By the way, resume/suspend works with your patches over linux-next.git
with a bcm4313 on a eeepc1215b!
Do you mean hibernate, AKA suspend to disk? I've Asus EEEPC 1215B with
AMD E-450 and after
echo disk > /sys/power/state
it tries to hibernate, but resumes right after, before even stopping
CPU or disabling backlight.
--
Rafał
By the way, resume/suspend works with your patches over linux-next.git
with a bcm4313 on a eeepc1215b!
Do you mean hibernate, AKA suspend to disk? I've Asus EEEPC 1215B with
AMD E-450 and after
echo disk > /sys/power/state
it tries to hibernate, but resumes right after, before even stopping
CPU or disabling backlight.
I was refering to suspend to ram, but it looks like hibernate works fine
as well with the same model (well, aside of the touchpad being unplugged
and the hard drive having been changed)
(FWIW, with MCE enabled, the computer hangs after an attempt to
synchronize SCSI cache and never gets out of hibernation nor powers off)
I'm attaching my working config file for reference. I use it on top of
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=00c0c2419d5ea8e6c558e431cf03272cd18d9c02
(linux-next.git's head from yesterday) with the 5 patches from this
thread.
Also, if it resumes right after the suspend, doesn't dmesg say something
about it?
Regards,
--
Dominique Martinet | Asmadeus
From: Arend van Spriel <hidden> Date: 2012-01-14 17:37:08
On 01/14/2012 04:50 AM, Linus Torvalds wrote:
2012/1/13 Arend van Spriel [off-list ref]:
quoted
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Ok, I note that you do have MCE enabled.
The MCE problems should be fixed in current -git, and so it might be
worth re-testing with that.
Linus
Yep. I disabled it and rebuild a kernel. Unfortunately, during the
weekend I have other obligations. So I can give it a go on monday
morning (amsterdam time).
Gr. AvS
On Sat, Jan 14, 2012 at 4:22 AM, Dominique Martinet
[off-list ref] wrote:
Sorry to hijack this thread, but I had the exact same problem Arend has
and disabling MCE fixed it.. Since it froze only after resume and it
didn't send anything to netconsole at this moment I've had this for some
time without any good debug info, so first is a thank you!
I'd like to try if the fix in current -git works, could you remind me
the exact tree name you call this?
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
is the main tree. The old "linux-2.6" name is just a symlink alias to it.
The commit that should fix MCE is just a oneliner: commit a3301b751b19
("x86/mce: Fix CPU hotplug and suspend regression related to MCE").
I'm familiar with linux-2.6.git, wireless-testing.git, and
linux-next.git, but it's not resolved in linux-next.git not
linux-2.6.git's HEAD at the very least.
If it's not resolved in linux-2.6, then you have a different problem.
Or, possibly, the mirroring hadn't quite happened yet when you fetched
it - so it's worth double-checking that you have that commit
a3301b751b19 in your tree. But kernel.org git mirroring has been
pretty fast now that it uses gitorious.
By the way, resume/suspend works with your patches over linux-next.git
with a bcm4313 on a eeepc1215b!
Good. So they probably didn't break anything. It's always hard to tell
with drivers: even if it's an "obvious fix", the old code may have
worked for random reasons, and fixing it then breaks.
But I do think the patches should be pretty safe. The PCI layer
generally does all the PCI-level suspend/resumes correctly, and
drivers that try to do it are more likely to mess it up than not (that
didn't use to be true long ago, which is why many drivers still do it
- legacy baggage).
Linus
On Sat, Jan 14, 2012 at 3:08 PM, Dominique Martinet
[off-list ref] wrote:
Right, I missed it. Suspend works as long as I don't use wireless
before.
Ok. Your suspend hang may be related to the cfg80211_wext hang that is
apparently unrelated to the issues we saw.
I still get a warning:
[ 30.256946] ------------[ cut here ]------------
[ 30.256956] WARNING: at drivers/base/core.c:194 device_release+0x6a/0x73()
Yes. This warning is annoying but harmless. We'll fix it some way
(possibly by just turning it back to a single line, like it used to
be), but for now you can just ignore it.
brcmsmac seems to have a problem that looks like it's fixed in
wireless-next, after a suspend if it's been used then all network
operation hang (i.e. 'ip addr', something like resolving an host doesn't
work but doesn't hang either, modprobe -r brcmsmac hangs as well)
Here's the revelent information about this:
[ 361.248353] INFO: task wpa_supplicant:9102 blocked for more than 120 seconds.
[ 361.248362] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 361.248367] wpa_supplicant D ffff880062d68400 0 9102 1 0x00000000
[ 361.248397] Call Trace:
[ 361.248411] [<ffffffff81313307>] ? __mutex_lock_common.clone.5+0x114/0x179
[ 361.248432] [<ffffffffa03bef8a>] ? cfg80211_wext_siwscan+0xbd/0x2dc [cfg80211]
[ 361.248439] [<ffffffff81313137>] ? mutex_lock+0x12/0x25
[ 361.248458] [<ffffffffa03f83c1>] ? ieee80211_request_scan+0x20/0x4e [mac80211]
Ok, judging by the call trace this seems to be a generic wireless bug,
likely not a brcmsmac bug. Presumably people like me (and obviously
wireless developers) avoid this by not using wpa_supplicant o
rsomething. You might want to enable LOCKDEP to verify - if it's a
deadlock (either direct, or ABBA) - lockdep should give you a big
splat immediately rather than having to wait for 2 minutes.
Linwille/David - can you please make sure the fix gets to my tree,
since it's apparently already ok in the development tree?
Linus
From: Arend van Spriel <hidden> Date: 2012-01-16 14:00:53
On 01/14/2012 04:50 AM, Linus Torvalds wrote:
2012/1/13 Arend van Spriel [off-list ref]:
quoted
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Ok, I note that you do have MCE enabled.
The MCE problems should be fixed in current -git, and so it might be
worth re-testing with that.
Linus
From: Arend van Spriel <hidden> Date: 2012-01-16 17:33:23
On 01/16/2012 03:00 PM, Arend van Spriel wrote:
On 01/14/2012 04:50 AM, Linus Torvalds wrote:
quoted
2012/1/13 Arend van Spriel [off-list ref]:
quoted
Upon suspend my laptop hangs (see trace below pulled from serial
console). I do not see the pr_debug in the suspend function (compiled
with -DDEBUG). Unfortunately the same happens when I don't insert bcma
and brcmsmac. I attached the kernel configuration.
Ok, I note that you do have MCE enabled.
The MCE problems should be fixed in current -git, and so it might be
worth re-testing with that.
Linus
Hi Linus,
I build a kernel with MCE disabled and tested that. It still hung. I
decided run the kernel with nomodeset parameter to avoid framebuffer
issues. Now the suspend worked, but resume failed. Just heard a beep and
that was it. I will refresh the tree and build another kernel with MCE
enabled.
I build a new kernel with MCE enabled. Same issue. I did not load bcma
or brcmsmac yet. Attached is trace I could pull from the kernel log
(str-test-*).
I also tried the pm_test and attached the trace for that
(str-devices-*). No bcma/brcmsmac test done with it yet.
Gr. AvS
-----------------------------------
version: 3.2.0-08699-ga93ce74
a93ce74 bcma: invalidate the mapped window over suspend/resume
d205a29 brcmsmac: remove PCI suspend/resume from bcma driver
310c9f8 bcma: connect the bcma bus suspend/resume to the bcma driver
suspend/res
6f55bd0 bcma: add stub for bcma_bus suspend()
83d836c bcma: convert suspend/resume to pm_ops
53999bf error: implicit declaration of function 'module_flags_taint'
122804e Merge branch 'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kerne
I build a new kernel with MCE enabled. Same issue. I did not load bcma
or brcmsmac yet. Attached is trace I could pull from the kernel log
(str-test-*).
Oh well. Everything looks fine in the test traces - the warnings are
annoying and nasty, but a known issue and not dangerous (and I have a
patch in my tree to fix them now).
So if the real suspend fails, it's some other subsystem that has
gotten broken. I don't think I have any other reports like that yet,
and there is not a lot to go on. If you could try to bisect it (I
assume plain Linux-3.2 works fine?) that woudl be wonderful, otherwise
I think we're stuck waiting for somebody else to hit it and figure it
out.
Linus