Re: ath0 no longer attaches, cardbus problems?
On Saturday, September 10, 2011 8:13:23 am Daniel Eischen wrote:
On Fri, 9 Sep 2011, Warner Losh wrote:
On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Do you need both chunks? The second one seems redundant given the
definition of bus_alloc_reosurce_any does exactly that.
I tried it separately with the 2 chunks, and only the first
chunk is needed. To be pedantic, this was the change that
made ath work again.
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
While debugging the problem a couple of weeks ago, I did
seem to notice ath was trying to attach twice. I seem to
recall it was at different addresses. Could this possibly
cause the problem without the above patch?
No, but your patch is confusing to me. Can a BAR change to a different
size after we read the CIS? Or perhaps it should now be prefetchable when
it wasn't before?
Hmm, the bus_delete_resource() doesn't make us re-probe the BAR (perhaps
it should?). I'm still not sure how exactly this fixes it. However, I do
think this probably is more correct.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Fri, 9 Sep 2011, Warner Losh wrote:
On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Do you need both chunks? The second one seems redundant given the definition
of bus_alloc_reosurce_any does exactly that.
I tried it separately with the 2 chunks, and only the first
chunk is needed. To be pedantic, this was the change that
made ath work again.
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
While debugging the problem a couple of weeks ago, I did
seem to notice ath was trying to attach twice. I seem to
recall it was at different addresses. Could this possibly
cause the problem without the above patch?
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
Hi Daniel!
On 09.09.11 21:22, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
THANK you very much!
I was following this thread with big interest since last weekend.
Here I found a Wireless card in the trash. An MSI card with a 'Ralink
Technology RT2560, RT2525'.
Under 8.2 it worked perfectly while under current I got a crappy
ethernet address.
Went back to 220194 and could prove that it was working there.
During this process your message came in and I immediately tried the
below patch:
ral0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:13:d3:7f:f8:48
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated
Whee!!! Again, thanks a lot.
I do not know if it is the right solution, but it works.
Gruss,
Andreas
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Do you need both chunks? The second one seems redundant given the definition
of bus_alloc_reosurce_any does exactly that.
Warner
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
@@ -477,7 +478,11 @@
}
/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+ res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Wednesday, September 07, 2011 5:48:01 pm Daniel Eischen wrote: On Wed, 7 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: Looks like I had a typo in my original e-mail, try debug.acpi.disabled=hostres rather than debug.acpi.disable=hostres. Ok, I'll try that. Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? I don't see that line in a verbose dmesg. The hostres verbose dmesg is here: http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt Ok, that exonerates those changes then. I'm using a local CVS repo, so the a -D date means (I guess) the beginning of the day. So the commit that actually broke the kernel for me occurred on Mar 31. According to: cvs diff -u -D31 Mar 2011 -D1 Apr 2011 there were a lot of sys/dev/pci changes. There was one commit: Author: jhb Date: Thu Mar 31 13:22:12 2011 New Revision: 220195 URL: http://svn.freebsd.org/changeset/base/220195 Log: Explicitly track the state of all known BARs for each PCI device. The PCI bus driver will now remember the size of a BAR obtained during the initial bus scan and use that size when doing lazy resource allocation rather than resizing the BAR. The bus driver will now also report unallocated BARs to userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs (such as the implicit I/O port resources for master/slave ATA controllers) will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are restored from their new saved state instead of having the raw registers saved and restored across resume. This also fixes restoring BARs at unusual loactions if said BAR has been allocated by a driver. Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge. Tested by:jkim Modified: head/sys/dev/pci/pci.c head/sys/dev/pci/pci_user.c head/sys/dev/pci/pcireg.h head/sys/dev/pci/pcivar.h Can you get a verbose dmesg from just after this change (you will need the patch from earlier to fix the panic you saw)? The output of pciconf -lb from both before and after would also be good. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 8 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 5:48:01 pm Daniel Eischen wrote: On Wed, 7 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? I don't see that line in a verbose dmesg. The hostres verbose dmesg is here: http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt Ok, that exonerates those changes then. I'm using a local CVS repo, so the a -D date means (I guess) the beginning of the day. So the commit that actually broke the kernel for me occurred on Mar 31. According to: cvs diff -u -D31 Mar 2011 -D1 Apr 2011 there were a lot of sys/dev/pci changes. There was one commit: Author: jhb Date: Thu Mar 31 13:22:12 2011 New Revision: 220195 URL: http://svn.freebsd.org/changeset/base/220195 Log: Explicitly track the state of all known BARs for each PCI device. The PCI bus driver will now remember the size of a BAR obtained during the initial bus scan and use that size when doing lazy resource allocation rather than resizing the BAR. The bus driver will now also report unallocated BARs to userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs (such as the implicit I/O port resources for master/slave ATA controllers) will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are restored from their new saved state instead of having the raw registers saved and restored across resume. This also fixes restoring BARs at unusual loactions if said BAR has been allocated by a driver. Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge. Tested by:jkim Modified: head/sys/dev/pci/pci.c head/sys/dev/pci/pci_user.c head/sys/dev/pci/pcireg.h head/sys/dev/pci/pcivar.h Can you get a verbose dmesg from just after this change (you will need the patch from earlier to fix the panic you saw)? The output of pciconf -lb from both before and after would also be good. I can't build r220194 (just before); it seems to rely on r220195. But r220195 builds, and I've applied the patch from earlier to fix the panic. I suspect you don't really need the pciconf -lb from before r220195 because r220195 works - ath attaches and is at the correct base address (0x8800). So the commit that broke ath/cardbus must be after r220195. The verbose dmesg and pciconf -lb are here: http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt I've noticed that in the non-working kernels, pcib2/cbb0 are at address 0xf8f0, and cbb1 is at 0xf8f01000. When the PCI configuration space is printed (in the verbose boot), offset 0x10 shows 0xf8f0 and 0xf8f01000. In the working kernel, they are at 0x800 and 0x80001000. It seems like kernels post Mar 31 constrain the cardbus address range to be within the PCI bridge range. Also, I noticed that pcib2 fails to allocate a memory window in post Mar 31 kernels: pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pcib2: failed to allocate initial I/O port window: 0xe000-0x pcib2: failed to allocate initial memory window: 0xf400-0xfbff whereas in previous kernels the allocation succeeds. Just curious, how would this all work for a PCI-VME bridge where you could have a very large memory windows onto a 32(or even 64)-bit address space? -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thursday, September 08, 2011 1:19:23 pm Daniel Eischen wrote: On Thu, 8 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 5:48:01 pm Daniel Eischen wrote: On Wed, 7 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? I don't see that line in a verbose dmesg. The hostres verbose dmesg is here: http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt Ok, that exonerates those changes then. I'm using a local CVS repo, so the a -D date means (I guess) the beginning of the day. So the commit that actually broke the kernel for me occurred on Mar 31. According to: cvs diff -u -D31 Mar 2011 -D1 Apr 2011 there were a lot of sys/dev/pci changes. There was one commit: Author: jhb Date: Thu Mar 31 13:22:12 2011 New Revision: 220195 URL: http://svn.freebsd.org/changeset/base/220195 Log: Explicitly track the state of all known BARs for each PCI device. The PCI bus driver will now remember the size of a BAR obtained during the initial bus scan and use that size when doing lazy resource allocation rather than resizing the BAR. The bus driver will now also report unallocated BARs to userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs (such as the implicit I/O port resources for master/slave ATA controllers) will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are restored from their new saved state instead of having the raw registers saved and restored across resume. This also fixes restoring BARs at unusual loactions if said BAR has been allocated by a driver. Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge. Tested by:jkim Modified: head/sys/dev/pci/pci.c head/sys/dev/pci/pci_user.c head/sys/dev/pci/pcireg.h head/sys/dev/pci/pcivar.h Can you get a verbose dmesg from just after this change (you will need the patch from earlier to fix the panic you saw)? The output of pciconf -lb from both before and after would also be good. I can't build r220194 (just before); it seems to rely on r220195. But r220195 builds, and I've applied the patch from earlier to fix the panic. I suspect you don't really need the pciconf -lb from before r220195 because r220195 works - ath attaches and is at the correct base address (0x8800). So the commit that broke ath/cardbus must be after r220195. The verbose dmesg and pciconf -lb are here: http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt I've noticed that in the non-working kernels, pcib2/cbb0 are at address 0xf8f0, and cbb1 is at 0xf8f01000. When the PCI configuration space is printed (in the verbose boot), offset 0x10 shows 0xf8f0 and 0xf8f01000. In the working kernel, they are at 0x800 and 0x80001000. It seems like kernels post Mar 31 constrain the cardbus address range to be within the PCI bridge range. Yes. You can test if that is all that causes the problem by turning off 'NEW_PCIB' in your kernel config. Also, I noticed that pcib2 fails to allocate a memory window in post Mar 31 kernels: pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pcib2: failed to allocate initial I/O port window: 0xe000-0x pcib2: failed to allocate initial memory window: 0xf400-0xfbff whereas in previous kernels the allocation succeeds. That is due to the hostres stuff. Your BIOS says that the Host-PCI bridge doesn't decode those full ranges meaning they aren't available for use by downstream PCI-PCI bridges. Just curious, how would this all work for a PCI-VME bridge where you could have a very large memory windows onto a 32(or even 64)-bit address space? That should work just fine, but the PCI-PCI bridge needs to reserve its windows from its parent so that other devices on the same bus as the bridge don't try to use conflicting resources. In the case of your laptop your pcib2 bridge is a subtractively decoded bridge. I don't know if for some reason the cardbus card wants to specifically use resources that are only subtractively decoded. Was waiting for Warner to comment on that. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 8 Sep 2011, John Baldwin wrote: On Thursday, September 08, 2011 1:19:23 pm Daniel Eischen wrote: I suspect you don't really need the pciconf -lb from before r220195 because r220195 works - ath attaches and is at the correct base address (0x8800). So the commit that broke ath/cardbus must be after r220195. The verbose dmesg and pciconf -lb are here: http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt I've noticed that in the non-working kernels, pcib2/cbb0 are at address 0xf8f0, and cbb1 is at 0xf8f01000. When the PCI configuration space is printed (in the verbose boot), offset 0x10 shows 0xf8f0 and 0xf8f01000. In the working kernel, they are at 0x800 and 0x80001000. It seems like kernels post Mar 31 constrain the cardbus address range to be within the PCI bridge range. Yes. You can test if that is all that causes the problem by turning off 'NEW_PCIB' in your kernel config. I tried a recent kernel from HEAD with nooption NEW_PCIB. The addresses are back to pre-Mar 31, but ath still doesn't attach, verbose dmesg here: http://people.freebsd.org/~deischen/ath/dmesg.fails.no_new_pcib.txt The relevent ath messages are below. -- DE pcib2: requested memory range 0x8800-0x: good unknown: Lazy allocation of 0x1 bytes rid 0x10 type 3 at 0x8800 cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: found- vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 ar5212SetPowerModeAwake: Failed to wakeup in 40ms ar5212SetPowerModeAwake: Failed to wakeup in 40ms ath0: unable to attach hardware; HAL status 3 cbb0: Opening memory: device_attach: ath0 attach returned 6 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Tue, 6 Sep 2011, John Baldwin wrote:
On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote:
On Tue, 6 Sep 2011, John Baldwin wrote:
Looks like I had a typo in my original e-mail, try
debug.acpi.disabled=hostres
rather than debug.acpi.disable=hostres.
Ok, I'll try that.
Setting debug.acpi.disabled=hostres in /boot/loader.conf
did not help. I tried this with a recent kernel from HEAD.
More info. I've found that kernels:
March 31 - work, ath attaches and works
April 1 - June 6: panic on cardbus attach
June 7 - HEAD: work, but ath doesn't attach
I found the commit that fixed the panic:
Index: sys/dev/pci/pci.c
===
RCS file: /opt/FreeBSD/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.420
retrieving revision 1.421
diff -u -r1.420 -r1.421
--- sys/dev/pci/pci.c 3 May 2011 17:37:24 - 1.420
+++ sys/dev/pci/pci.c 6 Jun 2011 13:21:11 - 1.421
@@ -2576,6 +2576,17 @@
uint16_t cmd;
struct resource *res;
+ /*
+* The BAR may already exist if the device is a CardBus card
+* whose CIS is stored in this BAR.
+*/
+ pm = pci_find_bar(dev, reg);
+ if (pm != NULL) {
+ maprange = pci_maprange(pm-pm_value);
+ barlen = maprange == 64 ? 2 : 1;
+ return (barlen);
+ }
+
pci_read_bar(dev, reg, map, testval);
if (PCI_BAR_MEM(map)) {
type = SYS_RES_MEMORY;
I applied this patch to the April 1st kernel (which previously
paniced) and was able to boot the kernel. ath still does not
attach.
So the commit that broke my cardbus ath occurred on April 1.
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote:
On Tue, 6 Sep 2011, John Baldwin wrote:
On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote:
On Tue, 6 Sep 2011, John Baldwin wrote:
Looks like I had a typo in my original e-mail, try
debug.acpi.disabled=hostres
rather than debug.acpi.disable=hostres.
Ok, I'll try that.
Setting debug.acpi.disabled=hostres in /boot/loader.conf
did not help. I tried this with a recent kernel from HEAD.
Did it remove the 'pcib0: decoding ' lines from a verbose dmesg?
More info. I've found that kernels:
March 31 - work, ath attaches and works
April 1 - June 6: panic on cardbus attach
June 7 - HEAD: work, but ath doesn't attach
I found the commit that fixed the panic:
Index: sys/dev/pci/pci.c
===
RCS file: /opt/FreeBSD/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.420
retrieving revision 1.421
diff -u -r1.420 -r1.421
--- sys/dev/pci/pci.c 3 May 2011 17:37:24 - 1.420
+++ sys/dev/pci/pci.c 6 Jun 2011 13:21:11 - 1.421
@@ -2576,6 +2576,17 @@
uint16_t cmd;
struct resource *res;
+ /*
+* The BAR may already exist if the device is a CardBus card
+* whose CIS is stored in this BAR.
+*/
+ pm = pci_find_bar(dev, reg);
+ if (pm != NULL) {
+ maprange = pci_maprange(pm-pm_value);
+ barlen = maprange == 64 ? 2 : 1;
+ return (barlen);
+ }
+
pci_read_bar(dev, reg, map, testval);
if (PCI_BAR_MEM(map)) {
type = SYS_RES_MEMORY;
I applied this patch to the April 1st kernel (which previously
paniced) and was able to boot the kernel. ath still does not
attach.
So the commit that broke my cardbus ath occurred on April 1.
Hmm. There are no PCI or Cardbus commits on April 1. There are some ath(4)
changes though including two HAL changes:
Author: adrian
Date: Sat Apr 2 00:24:13 2011
New Revision: 220258
URL: http://svn.freebsd.org/changeset/base/220258
Log:
Add some more debugging
Modified:
head/sys/dev/ath/ath_hal/ar5416/ar2133.c
Modified: head/sys/dev/ath/ath_hal/ar5416/ar2133.c
==
--- head/sys/dev/ath/ath_hal/ar5416/ar2133.cSat Apr 2 00:08:32 2011
(r220257)
+++ head/sys/dev/ath/ath_hal/ar5416/ar2133.cSat Apr 2 00:24:13 2011
(r220258)
@@ -251,11 +251,19 @@ ar2133SetRfRegs(struct ath_hal *ah, cons
/* Only the 5 or 2 GHz OB/DB need to be set for a mode */
if (IEEE80211_IS_CHAN_2GHZ(chan)) {
+ HALDEBUG(ah, HAL_DEBUG_EEPROM, %s: 2ghz: OB_2:%d, DB_2:%d\n,
+ __func__,
+ ath_hal_eepromGet(ah, AR_EEP_OB_2, AH_NULL),
+ ath_hal_eepromGet(ah, AR_EEP_DB_2, AH_NULL));
ar5416ModifyRfBuffer(priv-Bank6Data,
ath_hal_eepromGet(ah, AR_EEP_OB_2, AH_NULL), 3, 197, 0);
ar5416ModifyRfBuffer(priv-Bank6Data,
ath_hal_eepromGet(ah, AR_EEP_DB_2, AH_NULL), 3, 194, 0);
} else {
+ HALDEBUG(ah, HAL_DEBUG_EEPROM, %s: 5ghz: OB_5:%d, DB_5:%d\n,
+ __func__,
+ ath_hal_eepromGet(ah, AR_EEP_OB_5, AH_NULL),
+ ath_hal_eepromGet(ah, AR_EEP_DB_5, AH_NULL));
ar5416ModifyRfBuffer(priv-Bank6Data,
ath_hal_eepromGet(ah, AR_EEP_OB_5, AH_NULL), 3, 203, 0);
ar5416ModifyRfBuffer(priv-Bank6Data,
Date: Sat Apr 2 00:27:22 2011
New Revision: 220259
URL: http://svn.freebsd.org/changeset/base/220259
Log:
From ath9k - clear the RX descriptor status before recycling it.
Modified:
head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Sat Apr 2 00:24:13
2011(r220258)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Sat Apr 2 00:27:22
2011(r220259)
@@ -67,6 +67,7 @@ ar5416SetupRxDesc(struct ath_hal *ah, st
uint32_t size, u_int flags)
{
struct ar5416_desc *ads = AR5416DESC(ds);
+ HAL_CAPABILITIES *pCap = AH_PRIVATE(ah)-ah_caps;
HALASSERT((size ~ AR_BufLen) == 0);
@@ -77,6 +78,10 @@ ar5416SetupRxDesc(struct ath_hal *ah, st
/* this should be enough */
ads-ds_rxstatus8 = ~AR_RxDone;
+ /* clear the rest of the status fields */
+ if (! pCap-halAutoSleepSupport)
+ OS_MEMZERO((ads-u), sizeof(ads-u));
+
return AH_TRUE;
}
--
DE
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
Re: ath0 no longer attaches, cardbus problems?
On Wed, 7 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: Looks like I had a typo in my original e-mail, try debug.acpi.disabled=hostres rather than debug.acpi.disable=hostres. Ok, I'll try that. Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? I don't see that line in a verbose dmesg. The hostres verbose dmesg is here: http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt More info. I've found that kernels: March 31 - work, ath attaches and works April 1 - June 6: panic on cardbus attach June 7 - HEAD: work, but ath doesn't attach I found the commit that fixed the panic: [ snip ] I applied this patch to the April 1st kernel (which previously paniced) and was able to boot the kernel. ath still does not attach. So the commit that broke my cardbus ath occurred on April 1. Hmm. There are no PCI or Cardbus commits on April 1. There are some ath(4) changes though including two HAL changes: I'm using a local CVS repo, so the a -D date means (I guess) the beginning of the day. So the commit that actually broke the kernel for me occurred on Mar 31. According to: cvs diff -u -D31 Mar 2011 -D1 Apr 2011 there were a lot of sys/dev/pci changes. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: On Thu, 25 Aug 2011, Daniel Eischen wrote: On Thu, 25 Aug 2011, John Baldwin wrote: On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x8800-0x8800 for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? Any hopes of getting this cardbus problem fixed? Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still being active. (And it does look like that is the root cause in your case perhaps.) Granted, we are asking for resources that your BIOS says work just fine, so I'm not sure why it is failing in the first place. Looks like I had a typo in my original e-mail, try debug.acpi.disabled=hostres rather than debug.acpi.disable=hostres. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Tue, 6 Sep 2011, John Baldwin wrote: On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: On Thu, 25 Aug 2011, Daniel Eischen wrote: [ snip ] Any hopes of getting this cardbus problem fixed? Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still being active. (And it does look like that is the root cause in your case perhaps.) Granted, we are asking for resources that your BIOS says work just fine, so I'm not sure why it is failing in the first place. Looks like I had a typo in my original e-mail, try debug.acpi.disabled=hostres rather than debug.acpi.disable=hostres. Ok, I'll try that. FYI, I tried a few different kernels. So far, this is what I've found (I'm using source from a local CVS repo since it's easier than having to be online all the time): cvs -d /opt/FreeBSD/cvs checkout -D 15 Mar 2011 src Works (ath0 loads) cvs -R update -P -d -A -D 22 Mar 2011 sys Works (ath0 loads) cvs -R update -P -d -A -D 1 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 10 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 14 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 15 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 15 May 2011 sys Fails (kernel works, ath0 doesn't load) I have not had the chance to find the exact endpoints of where the kernel panics, and to test ath outside of those endpoints. But somewhere between March 22 and May 15 ath stopped working. I don't have traceback for the panics, but I believe it was cardbus related. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: On Thu, 25 Aug 2011, Daniel Eischen wrote: [ snip ] Any hopes of getting this cardbus problem fixed? Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still being active. (And it does look like that is the root cause in your case perhaps.) Granted, we are asking for resources that your BIOS says work just fine, so I'm not sure why it is failing in the first place. Looks like I had a typo in my original e-mail, try debug.acpi.disabled=hostres rather than debug.acpi.disable=hostres. Ok, I'll try that. FYI, I tried a few different kernels. So far, this is what I've found (I'm using source from a local CVS repo since it's easier than having to be online all the time): cvs -d /opt/FreeBSD/cvs checkout -D 15 Mar 2011 src Works (ath0 loads) cvs -R update -P -d -A -D 22 Mar 2011 sys Works (ath0 loads) cvs -R update -P -d -A -D 1 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 10 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 14 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 15 Apr 2011 sys kernel panics cvs -R update -P -d -A -D 15 May 2011 sys Fails (kernel works, ath0 doesn't load) I have not had the chance to find the exact endpoints of where the kernel panics, and to test ath outside of those endpoints. But somewhere between March 22 and May 15 ath stopped working. Yes, there was a panic with cardbus with some of the PCI changes when they first went in. I wonder why the cardbus bit didn't work though. I wonder if there is a chance that the cardbus resources need to specifically not fit into the decoding windows of the parent bridge. Warner, does that ring a bell at all? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On 3 September 2011 12:35, Eitan Adler li...@eitanadler.com wrote: The best way to do this is to find a known working version of the kernel and then bisect the version from the known bad and known good versions until you arrive at the breaking commit. It is easier if you look at the svn log to see which commits might matter. Yes this takes a while, but is the surest way to find the regression. You shouldn't have to try many kernels. 130,000 revisions, only a max of 18 attempts needed. :) No, you don't need a whole buildworld. Just try booting the kernel and see when it attaches. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Sep 3, 2011, at 2:02 AM, Adrian Chadd adr...@freebsd.org wrote: On 3 September 2011 12:35, Eitan Adler li...@eitanadler.com wrote: The best way to do this is to find a known working version of the kernel and then bisect the version from the known bad and known good versions until you arrive at the breaking commit. It is easier if you look at the svn log to see which commits might matter. Yes this takes a while, but is the surest way to find the regression. You shouldn't have to try many kernels. 130,000 revisions, only a max of 18 attempts needed. :) No, you don't need a whole buildworld. Just try booting the kernel and see when it attaches. There's a reason I haven't upgraded this system in over a year. It takes a long time to update the src tree and a long time to build a kernel. I miss the 2.x/3.x days where you could build world on system like this in about an hour or so. -- DE___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On 3 September 2011 22:32, Daniel Eischen eisc...@vigrid.com wrote: No, you don't need a whole buildworld. Just try booting the kernel and see when it attaches. There's a reason I haven't upgraded this system in over a year. It takes a long time to update the src tree and a long time to build a kernel. I miss the 2.x/3.x days where you could build world on system like this in about an hour or so. Just build a kernel on a fast system and boot it? You don't have to boot a full buildworld+modules to see whether ath0 attaches. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
Hi, If : (1) your laptop has an Ethernet jack (2) your laptop supports booting over the network via PXE (3) you have another fast machine, where you can NFS export a directory which has the output of make buildkernel / make buildworld. then you can: (1) compile the kernel on the fast machine (2) NFS export the directory with the kernel (3) try to network boot your laptop with that kernel over Ethernet, without installing FreeBSD on your laptop. I am in the middle of writing this document for contribution to the FreeBSD Handbook: http://people.freebsd.org/~rodrigc/doc/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html which describes how to do that. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 25 Aug 2011, Daniel Eischen wrote: On Thu, 25 Aug 2011, John Baldwin wrote: On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x8800-0x8800 for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? Any hopes of getting this cardbus problem fixed? -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
Hi, The most direct way to fix this is to find the exact commit which introduced the break. Thanks, Adrian On 3 September 2011 00:27, Daniel Eischen deisc...@freebsd.org wrote: On Thu, 25 Aug 2011, Daniel Eischen wrote: On Thu, 25 Aug 2011, John Baldwin wrote: On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x8800-0x8800 for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? Any hopes of getting this cardbus problem fixed? -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Sat, Sep 3, 2011 at 12:24 AM, Adrian Chadd adr...@freebsd.org wrote: Hi, The most direct way to fix this is to find the exact commit which introduced the break. Anything else you'd like me to try? The best way to do this is to find a known working version of the kernel and then bisect the version from the known bad and known good versions until you arrive at the breaking commit. It is easier if you look at the svn log to see which commits might matter. Yes this takes a while, but is the surest way to find the regression. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 25 Aug 2011, Adrian Chadd wrote: On 25 August 2011 08:19, Daniel Eischen deisc...@freebsd.org wrote: I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: [snip] Yup, looks like another cardbus/pci allocation issue. :-) Who do I ping about it? I tried with nooption NEW_PCIB but that didn't work either. -- DE___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On 25 August 2011 15:50, Daniel Eischen deisc...@freebsd.org wrote: [snip] Yup, looks like another cardbus/pci allocation issue. :-) Who do I ping about it? I tried with nooption NEW_PCIB but that didn't work either. Whoever looks after the cardbus/pci code? I know you don't want to, but it may be worthwhile bisecting the kernel version (as booting alone is enough to see if it's working, so you don't have to build a whole world each time) and figure out when it broke. I bet that'll be a big, big help. I'd appreciate it too, you're not the first user who has a non-functioning ath cardbus nic, and I'd really like to see those resolved for 9.0. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 25 Aug 2011, John Baldwin wrote: On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x8800-0x8800 for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On Thu, 25 Aug 2011, Daniel Eischen wrote: On Thu, 25 Aug 2011, John Baldwin wrote: On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x8800-0x8800 for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. I removed all changes I made to src/sys/dev/ath/ and am now using the driver unchanged. ath0 is now back at mem 0xf8f1-0xf8f1. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ The devinfo and dmesg outputs have been updated in the above. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ath0 no longer attaches, cardbus problems?
Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: Atheros 5212 mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: Atheros 5212 mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg -- DE [deischen@orion /usr/src/sys/dev/ath]$ svn diff Index: ath_hal/ar5212/ar5212_reset.c === --- ath_hal/ar5212/ar5212_reset.c (revision 225101) +++ ath_hal/ar5212/ar5212_reset.c (working copy) @@ -1145,7 +1145,8 @@ /* track PHY power state so we don't try to r/w BB registers */ AH5212(ah)-ah_phyPowerOn = ((resetMask AR_RC_BB) == 0); - return rt; +// return rt; + return AH_TRUE; } int16_t Index: ath_hal/ar5212/ar5212_power.c === --- ath_hal/ar5212/ar5212_power.c (revision 225101) +++ ath_hal/ar5212/ar5212_power.c (working copy) @@ -77,7 +77,9 @@ ath_hal_printf(ah, %s: Failed to wakeup in %ums\n, __func__, POWER_UP_TIME/50); #endif +#if 0 return AH_FALSE; +#endif } } -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0 no longer attaches, cardbus problems?
On 25 August 2011 08:19, Daniel Eischen deisc...@freebsd.org wrote: I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: [snip] Yup, looks like another cardbus/pci allocation issue. :-) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
