Re: [PATCH] Fix OACTIVE for an(4)
On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: J I haven't looked at the rest of the driver; is everything else around J OACTIVE locked correctly and consistently? J J As well as OACTIVE is for any other driver. Let me jump into this topic and discuss the if_drv_flags :) It seems to me that this in general was a wrong concept, both IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of the driver can be known only to the driver itself and should be stored in the softc, covered with internal lock. There is simply no way to racelessly tell the state from the outside, without obtaining driver lock. In my ifnet plans I am considering to remove if_drv_flags. Can anyone convince me that this is a wrong idea and they should be kept? -- Totus tuus, Glebius. ___ 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
About pmap_mapdev() pmap_unmapdev()
Hi,
At least in i386 9-stable, when we call pmap_mapdev() and
pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
incorrectly.
pmap_mapdev_attr()-pmap_kenter_attr():
In this path, kernel_pmap.pm_stats.resident_count is not increlmented.
pmap_unmapdev()-kmem_free(kernel_map)-vm_map_remove()-pmap_remove():
But, in this path, kernel_pmap.pm_stats.resident_count is decreased in
pmap_remove_pte().
While I called pmap_mapdev() and pmap_unmapdev() repeatedly and
kernel_pmap.pm_stats.resident_count became `0', since pmap_remove()
returned without removing ptes, I encountered various kernel panics.
And, when I enabled INVARIANTS, I looked the following panic message.
panic: vm_page_free_toq: freeing mapped page 0x.
I think, I should change the following.
What do you think about this?
diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c
index 2adc6f8..a0998e8 100644
--- a/sys/i386/i386/pmap.c
+++ b/sys/i386/i386/pmap.c
@@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode)
{
vm_offset_t va, offset;
vm_size_t tmpsize;
+ int kmem_allocated = 0;
offset = pa PAGE_MASK;
size = roundup(offset + size, PAGE_SIZE);
@@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int
mode)
if (pa KERNLOAD pa + size = KERNLOAD)
va = KERNBASE + pa;
- else
+ else {
va = kmem_alloc_nofault(kernel_map, size);
+ kmem_allocated = 1;
+ }
if (!va)
panic(pmap_mapdev: Couldn't alloc kernel virtual memory);
- for (tmpsize = 0; tmpsize size; tmpsize += PAGE_SIZE)
+ for (tmpsize = 0; tmpsize size; tmpsize += PAGE_SIZE) {
pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+ if (kmem_allocated)
+ kernel_pmap.pm_stats.resident_count++;
+ }
pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
pmap_invalidate_cache_range(va, va + size);
return ((void *)(va + offset));
___
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: [PATCH] Fix OACTIVE for an(4)
Having them as flags that can be seen from external is good for diagnostics. Having external things change behaviour (like queuing packets and running if_start) is error prone. It isn't a wrong concept. Computers just grew up a bit more. -a On 3 October 2014 01:13, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: J I haven't looked at the rest of the driver; is everything else around J OACTIVE locked correctly and consistently? J J As well as OACTIVE is for any other driver. Let me jump into this topic and discuss the if_drv_flags :) It seems to me that this in general was a wrong concept, both IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of the driver can be known only to the driver itself and should be stored in the softc, covered with internal lock. There is simply no way to racelessly tell the state from the outside, without obtaining driver lock. In my ifnet plans I am considering to remove if_drv_flags. Can anyone convince me that this is a wrong idea and they should be kept? -- Totus tuus, Glebius. ___ 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[2]: make installworld for i386 fails on Kyuafile
Hello, Seems this issue raised again in r272469, at least today and yesterday installworld fails. Last time was few minutes ago with the revision shown. install: /usr/tests/lib/libproc/Kyuafile: No such file or directory Fixed in r271950. Problem introduced in r271937 which seems to have missed part of the change sent out for review in D710. ___ 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
CURRENT: ath0: stuck beacon; resetting (bmiss count 4)
Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this WiFi hardware: [...] ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 What is this and how can I get rid of it? Regards, Oliver signature.asc Description: PGP signature
[CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?
Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd basis. But whenever I try to configure one of the above mentioned auth methods for a gateway I try to configure (CURRENT, 10.1-PRE), I get an error. What is up here? Regards, Oliver signature.asc Description: PGP signature
Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)
Quoting O. Hartmann ohart...@zedat.fu-berlin.de: Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this WiFi hardware: [...] ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 What is this and how can I get rid of it? It means that you have run into a well-known and long lasting hardware bug in Atheros Wifi chipsets, where they sometimes get stuck and stops sending out beacons. You get that message when the device driver detects that this has happened and resets the chip to get things going again. There is, AFAIK, no way of making sure the problem cannot happen, but you might be able to reduce the frequency of it happening by reducing the amount of interference you receive from other wireless devices. ___ 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: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)
Am Fri, 03 Oct 2014 15:15:54 +0200 Erik Trulsson erik.trulsson.1...@student.uu.se schrieb: Quoting O. Hartmann ohart...@zedat.fu-berlin.de: Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this WiFi hardware: [...] ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 What is this and how can I get rid of it? It means that you have run into a well-known and long lasting hardware bug in Atheros Wifi chipsets, where they sometimes get stuck and stops sending out beacons. You get that message when the device driver detects that this has happened and resets the chip to get things going again. There is, AFAIK, no way of making sure the problem cannot happen, but you might be able to reduce the frequency of it happening by reducing the amount of interference you receive from other wireless devices. Ah, I understand, so nothing to worry about. The WiFi NIC is a cheap TP Link facility. Hopefully, FreeBSD will have support for Intel's Dual Band 7260-chipset this decade, so the problem will be gone anyway (except Intel put also nice hardware bugs into their silica ...). oh signature.asc Description: PGP signature
Re: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?
On Fri, Oct 03, 2014 at 03:14:53PM +0200, O. Hartmann wrote: Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd basis. But whenever I try to configure one of the above mentioned auth methods for a gateway I try to configure (CURRENT, 10.1-PRE), I get an error. What is up here? You need to recompile source. And patching some Makefiles, AFAIR. ___ 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: [PATCH] Fix OACTIVE for an(4)
On Friday, October 03, 2014 12:13:28 PM Gleb Smirnoff wrote: On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: J I haven't looked at the rest of the driver; is everything else around J OACTIVE locked correctly and consistently? J J As well as OACTIVE is for any other driver. Let me jump into this topic and discuss the if_drv_flags :) It seems to me that this in general was a wrong concept, both IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of the driver can be known only to the driver itself and should be stored in the softc, covered with internal lock. There is simply no way to racelessly tell the state from the outside, without obtaining driver lock. In my ifnet plans I am considering to remove if_drv_flags. Can anyone convince me that this is a wrong idea and they should be kept? They used to be in if_flags. Robert moved them to if_drv_flags precisely so that drivers could control their synchronization instead of doing a crazy locking dance with the ifnet layer. They are still exported to userland as IFF_RUNNING and IFF_OACTIVE in if_flags, and they may still be somewhat useful for reporting that state to userland (and races in reading if_drv_flags for that reporting are harmless). That said, I think long term if we make the stack aware of multiple input queues we will certainly use something that does not have the same raciness as OACTIVE. Note, btw, you could fix OACTIVE in various drivers by simply grabbing the IF_LOCK on ifp-if_snd while setting or clearing OACTIVE to close the current OACTIVE race (you don't need it for all writes to if_drv_flags, you just want if_handoff() to read the current value of OACTIVE, so only locking writes to OACTIVE would be sufficient). -- 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: vt_suspend / vt_resume
On 30/09/2014 08:47, Andriy Gapon wrote:
I think that currently vt_suspend / vt_resume are called at quite unsuitable
times. For example, vt_suspend performs a vt switch which requires
cooperation
from an X server, but that could be problematic given that some devices may
already be suspended.
I believe that it is better to do what sc(4) does and use power_suspend /
power_resume event handlers instead of device_suspend / device_resume methods.
power_suspend event is posted when a kernel has not entered any special state
yet.
What do you think?
So, I am now using the following patch and suspend/resume works 100% reliable
for me, whereas previously there was a quite significant chance that the video
subsystem would be in a very confused state after resuming.
For example there could be an endless stream of error message and the screen
would be frozen:
drmn0: error: couldn't schedule ib
error: [drm:pid1492:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
Or there could be an endless GPU reset loop in the radeon driver:
drmn0: error: GPU lockup CP stall for more than 1msec
drmn0: warning: GPU lockup (waiting for 0x00269544 last fence id
0x00269523)
error: [drm:pid1492:r600_ib_test] *ERROR* radeon: fence wait failed (-11).
error: [drm:pid1492:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-11).
drmn0: error: ib ring test failed (-11).
drmn0: info: GPU softreset: 0x0003
The patch (I am not sure if fbd_attach is the right place to register the event
handlers):
diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c
index ff2488d..923292a 100644
--- a/sys/dev/fb/fbd.c
+++ b/sys/dev/fb/fbd.c
@@ -316,6 +316,11 @@ fbd_attach(device_t dev)
return (ENXIO);
err = fbd_register(sc-sc_info);
+ EVENTHANDLER_REGISTER(power_suspend, vt_fb_suspend, NULL,
+ EVENTHANDLER_PRI_ANY);
+ EVENTHANDLER_REGISTER(power_resume, vt_fb_resume, NULL,
+ EVENTHANDLER_PRI_ANY);
+
return (err);
}
@@ -332,22 +337,6 @@ fbd_detach(device_t dev)
return (err);
}
-static int
-fbd_suspend(device_t dev)
-{
-
- vt_fb_suspend();
- return (bus_generic_suspend(dev));
-}
-
-static int
-fbd_resume(device_t dev)
-{
-
- vt_fb_resume();
- return (bus_generic_resume(dev));
-}
-
static device_method_t fbd_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, fbd_probe),
@@ -355,8 +344,6 @@ static device_method_t fbd_methods[] = {
DEVMETHOD(device_detach,fbd_detach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
- DEVMETHOD(device_suspend, fbd_suspend),
- DEVMETHOD(device_resume,fbd_resume),
{ 0, 0 }
};
--
Andriy Gapon
___
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: vt_suspend / vt_resume
On 10/03/14 08:13, Andriy Gapon wrote:
On 30/09/2014 08:47, Andriy Gapon wrote:
I think that currently vt_suspend / vt_resume are called at quite unsuitable
times. For example, vt_suspend performs a vt switch which requires cooperation
from an X server, but that could be problematic given that some devices may
already be suspended.
I believe that it is better to do what sc(4) does and use power_suspend /
power_resume event handlers instead of device_suspend / device_resume methods.
power_suspend event is posted when a kernel has not entered any special state
yet.
What do you think?
So, I am now using the following patch and suspend/resume works 100% reliable
for me, whereas previously there was a quite significant chance that the video
subsystem would be in a very confused state after resuming.
For example there could be an endless stream of error message and the screen
would be frozen:
drmn0: error: couldn't schedule ib
error: [drm:pid1492:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
Or there could be an endless GPU reset loop in the radeon driver:
drmn0: error: GPU lockup CP stall for more than 1msec
drmn0: warning: GPU lockup (waiting for 0x00269544 last fence id
0x00269523)
error: [drm:pid1492:r600_ib_test] *ERROR* radeon: fence wait failed (-11).
error: [drm:pid1492:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-11).
drmn0: error: ib ring test failed (-11).
drmn0: info: GPU softreset: 0x0003
The patch (I am not sure if fbd_attach is the right place to register the event
handlers):
It's not, I don't think, since fbd_attach() isn't called for all vt
backends (e.g. the VGA and EFI backends don't call it). vt_fb_suspend()
also only calls vt_suspend(), so it's probably best to put this in the
core vt code.
-Nathan
diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c
index ff2488d..923292a 100644
--- a/sys/dev/fb/fbd.c
+++ b/sys/dev/fb/fbd.c
@@ -316,6 +316,11 @@ fbd_attach(device_t dev)
return (ENXIO);
err = fbd_register(sc-sc_info);
+ EVENTHANDLER_REGISTER(power_suspend, vt_fb_suspend, NULL,
+ EVENTHANDLER_PRI_ANY);
+ EVENTHANDLER_REGISTER(power_resume, vt_fb_resume, NULL,
+ EVENTHANDLER_PRI_ANY);
+
return (err);
}
@@ -332,22 +337,6 @@ fbd_detach(device_t dev)
return (err);
}
-static int
-fbd_suspend(device_t dev)
-{
-
- vt_fb_suspend();
- return (bus_generic_suspend(dev));
-}
-
-static int
-fbd_resume(device_t dev)
-{
-
- vt_fb_resume();
- return (bus_generic_resume(dev));
-}
-
static device_method_t fbd_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, fbd_probe),
@@ -355,8 +344,6 @@ static device_method_t fbd_methods[] = {
DEVMETHOD(device_detach,fbd_detach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
- DEVMETHOD(device_suspend, fbd_suspend),
- DEVMETHOD(device_resume,fbd_resume),
{ 0, 0 }
};
___
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
i915 driver update testing
Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. ___ 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: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)
I think you're going to be .. unhappy with what Intel's firmware is like as an AP. I still have to chase down why the AR9287 stalls and do a full chip reset when it goes RX deaf. I'm just chasing down other things at the moment. -a On 3 October 2014 06:33, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Fri, 03 Oct 2014 15:15:54 +0200 Erik Trulsson erik.trulsson.1...@student.uu.se schrieb: Quoting O. Hartmann ohart...@zedat.fu-berlin.de: Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this WiFi hardware: [...] ath0: Atheros 9287 mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 What is this and how can I get rid of it? It means that you have run into a well-known and long lasting hardware bug in Atheros Wifi chipsets, where they sometimes get stuck and stops sending out beacons. You get that message when the device driver detects that this has happened and resets the chip to get things going again. There is, AFAIK, no way of making sure the problem cannot happen, but you might be able to reduce the frequency of it happening by reducing the amount of interference you receive from other wireless devices. Ah, I understand, so nothing to worry about. The WiFi NIC is a cheap TP Link facility. Hopefully, FreeBSD will have support for Intel's Dual Band 7260-chipset this decade, so the problem will be gone anyway (except Intel put also nice hardware bugs into their silica ...). oh ___ 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: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?
Documentation updates to hostapd / wifi for the handbook and manpages are very, very welcome. -a On 3 October 2014 06:14, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd basis. But whenever I try to configure one of the above mentioned auth methods for a gateway I try to configure (CURRENT, 10.1-PRE), I get an error. What is up here? Regards, Oliver ___ 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: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
Dnia 2014-10-02, o godz. 14:07:30
Yonghyeon PYUN pyu...@gmail.com napisał(a):
On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote:
On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote:
Hi,
I've added support for QAC AR816x/AR817x ethernet controllers. It
passed my limited testing and I need more testers. You can find
patches from the following URLs.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
and
http://people.freebsd.org/~yongari/alc/alc.diff.20140930
pci.qurik.diff is to workaround silicon bug of AR816x. Without it
MSI/MSIX interrupt wouldn't work. If you just want to use
legacy INTx interrupt you don't have to apply it but you have to
tell alc(4) not to use MSI/MSIX interrupt with tunables(
hw.alc.msi.disable and hw.alc.msix_disable).
alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
and E2200 controllers. It supports all hardware features except
RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x
controllers please test and report how the diff works for you.
Thanks.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
http://people.freebsd.org/~yongari/alc/alc.diff.20141001
Patch updated to address link establishment issue.
http://people.freebsd.org/~yongari/alc/alc.diff.20141002
Patch updated again to correct wrong lock assertion.
Hi !
Thanks for your work !
Are your patches only for current ? I tried on 10 stable.
My system:
dw@dw:~ % uname -a
FreeBSD dw 10.1-RC1 FreeBSD 10.1-RC1 #1 r272477M: Fri Oct 3 20:48:05
CEST 2014 dw@dw:/usr/obj/usr/src/sys/DW amd64
I applied your patches (pci.quirk.diff alc.diff.20141002).
There was a minor problem with alc.diff.20141002 - hunk 1 failed:
@@ -111,17 +111,31 @@
Atheros AR8152 v1.1 PCIe Fast Ethernet },
{ VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8152_B2, 6 * 1024,
Atheros AR8152 v2.0 PCIe Fast Ethernet },
+ { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8161, 9 * 1024,
+ Atheros AR8161 PCIe Gigabit Ethernet },
+ { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8162, 9 * 1024,
+ Atheros AR8161 PCIe Fast Ethernet },
+ { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8171, 9 * 1024,
+ Atheros AR8161 PCIe Gigabit Ethernet },
+ { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8172, 9 * 1024,
+ Atheros AR8161 PCIe Fast Ethernet },
+ { VENDORID_ATHEROS, DEVICEID_ATHEROS_E2200, 9 * 1024,
+ Atheros AR8161 PCIe Killer E2200 Gigabit Ethernet },
{ 0, 0, 0, NULL}
};
-static voidalc_aspm(struct alc_softc *, int);
+static voidalc_aspm(struct alc_softc *, int, int);
+static voidalc_aspm_813x(struct alc_softc *, int);
+static voidalc_aspm_816x(struct alc_softc *, int);
static int alc_attach(device_t);
static int alc_check_boundary(struct alc_softc *);
+static voidalc_config_msi(struct alc_softc *);
static int alc_detach(device_t);
static voidalc_disable_l0s_l1(struct alc_softc *);
static int alc_dma_alloc(struct alc_softc *);
static voidalc_dma_free(struct alc_softc *);
static voidalc_dmamap_cb(void *, bus_dma_segment_t *, int,
int); +static void alc_dsp_fixup(struct alc_softc *, int);
static int alc_encap(struct alc_softc *, struct mbuf **);
static struct alc_ident *
alc_find_ident(device_t);
I applied that part manually. Compiled and rebooted system.
dmesg | grep alc :
alc0: could not disable Rx/Tx MAC(0x4000cb20)!
alc0: reset timeout(0x4000cb20)!
alc0: could not disable Rx/Tx MAC(0x4000cb20)!
alc0: link state changed to UP
alc0: could not disable Rx/Tx MAC(0x4000cb20)!
alc0: Qualcomm Atheros AR8161 Gigabit Ethernet port 0xd000-0xd07f mem
0xf720-0xf723 irq 18 at device 0.0 on pci3
alc0: reset timeout(0x4000cd00)!
alc0: 11776 Tx FIFO, 12032 Rx FIFO
miibus0: MII bus on alc0
alc0: Ethernet address: 74:d4:35:91:32:04
alc0: could not disable Rx/Tx MAC(0x4000cd00)!
alc0: reset timeout(0x4000cd00)!
alc0: Qualcomm Atheros AR8161 Gigabit Ethernet port 0xd000-0xd07f mem
0xf720-0xf723 irq 18 at device 0.0 on pci3
alc0: reset timeout(0x4000ca00)!
alc0: 11776 Tx FIFO, 12032 Rx FIFO
miibus0: MII bus on alc0
alc0: Ethernet address: 74:d4:35:91:32:04
alc0: Qualcomm Atheros AR8161 Gigabit Ethernet port 0xd000-0xd07f mem
0xf720-0xf723 irq 18 at device 0.0 on pci3
alc0: PCI device revision : 0x0010
alc0: Chip id/revision : 0xc002
alc0: AR816x revision : 0x2
alc0: 11776 Tx FIFO, 12032 Rx FIFO
alc0: Read request size : 512 bytes.
alc0: TLP payload size : 128 bytes.
alc0: MSIX count : 16
alc0: MSI count : 16
alc0: attempting to allocate 1 MSI-X vectors (16 supported)
alc0: using IRQ 268 for MSI-X
alc0: Using 1 MSIX message(s).
miibus0: MII bus on alc0
alc0: bpf attached
alc0: Ethernet address: 74:d4:35:91:32:04
alc0: link state changed to UP
pciconf -vlc :
alc0@pci0:3:0:0:class=0x02 card=0xe0001458
Re: About pmap_mapdev() pmap_unmapdev()
On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote:
Hi,
At least in i386 9-stable, when we call pmap_mapdev() and
pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
incorrectly.
pmap_mapdev_attr()-pmap_kenter_attr():
In this path, kernel_pmap.pm_stats.resident_count is not increlmented.
pmap_unmapdev()-kmem_free(kernel_map)-vm_map_remove()-pmap_remove():
But, in this path, kernel_pmap.pm_stats.resident_count is decreased in
pmap_remove_pte().
While I called pmap_mapdev() and pmap_unmapdev() repeatedly and
kernel_pmap.pm_stats.resident_count became `0', since pmap_remove()
returned without removing ptes, I encountered various kernel panics.
I think you are right.
The problem seems to be fixed in HEAD and 10, since mapdev was switched
to use kva_alloc/kva_free. I added stable@ to Cc:.
And, when I enabled INVARIANTS, I looked the following panic message.
panic: vm_page_free_toq: freeing mapped page 0x.
Do you mean that this panic is related to missed pmap_remove() ?
I doubt it, since pmap_mapdev() does not establish managed mappings.
I think, I should change the following.
What do you think about this?
diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c
index 2adc6f8..a0998e8 100644
--- a/sys/i386/i386/pmap.c
+++ b/sys/i386/i386/pmap.c
@@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int
mode)
{
vm_offset_t va, offset;
vm_size_t tmpsize;
+ int kmem_allocated = 0;
offset = pa PAGE_MASK;
size = roundup(offset + size, PAGE_SIZE);
@@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int
mode)
if (pa KERNLOAD pa + size = KERNLOAD)
va = KERNBASE + pa;
- else
+ else {
va = kmem_alloc_nofault(kernel_map, size);
+ kmem_allocated = 1;
You could just do
PMAP_LOCK(kernel_pmap);
kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
PMAP_UNLOCK(kernel_pmap);
there. And, the same fix is needed for amd64.
+ }
if (!va)
panic(pmap_mapdev: Couldn't alloc kernel virtual memory);
- for (tmpsize = 0; tmpsize size; tmpsize += PAGE_SIZE)
+ for (tmpsize = 0; tmpsize size; tmpsize += PAGE_SIZE) {
pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+ if (kmem_allocated)
+ kernel_pmap.pm_stats.resident_count++;
+ }
pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
pmap_invalidate_cache_range(va, va + size);
return ((void *)(va + offset));
___
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
