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?
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?
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=8843 metric 0 mtu 2290
ether 00:13:d3:7f:f8:48
nd6 options=29
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?
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?
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: 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 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 -D"31 Mar 2011" -D"1 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: 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 "
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 -D"31 Mar 2011" -D"1 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: 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 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 -D"31 Mar 2011" -D"1 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 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 -D"31 Mar 2011" -D"1 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 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
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 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 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 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: 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: 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?
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 3 September 2011 22:32, Daniel Eischen 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?
On Sep 3, 2011, at 2:02 AM, Adrian Chadd wrote: > On 3 September 2011 12:35, Eitan Adler 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 12:35, Eitan Adler 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 Sat, Sep 3, 2011 at 12:24 AM, Adrian Chadd 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?
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 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: 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: 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 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: 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: 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?
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: 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: 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"
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: 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: 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 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: 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: 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 25 August 2011 15:50, Daniel Eischen 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 Thu, 25 Aug 2011, Adrian Chadd wrote: On 25 August 2011 08:19, Daniel Eischen 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 08:19, Daniel Eischen 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"
