Re: amd64/148078: wireless networking stops functioning
The following reply was made to PR amd64/148078; it has been noted by GNATS.
From: Oliver Pinter
To: Paul Lambert
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/148078: wireless networking stops functioning
Date: Wed, 23 Jun 2010 11:52:47 +0200
hi!
under 7.3-STABLE is the same problem, on boot +2-3 minutes the
networking is ok, but after 2-3 minutes, it going down. The soultion
is this:
ifconfig_ath0="DHCP WPA protmode rtscts mode 11g -bgscan -burst
channel 12 -powersave"
It's an ar5212 tp-link wlan card.
On 6/23/10, Paul Lambert wrote:
>
>>Number: 148078
>>Category: amd64
>>Synopsis: wireless networking stops functioning
>>Confidential: no
>>Severity: critical
>>Priority: high
>>Responsible:freebsd-amd64
>>State: open
>>Quarter:
>>Keywords:
>>Date-Required:
>>Class: update
>>Submitter-Id: current-users
>>Arrival-Date: Wed Jun 23 03:10:05 UTC 2010
>>Closed-Date:
>>Last-Modified:
>>Originator: Paul Lambert
>>Release:8.1 prerelease
>>Organization:
> BRSINC
>>Environment:
> FreeBSD BRSINC-VM02.local 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
> 15:02:08 UTC 2009
> r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>
>>Description:
> I finally found time to work with Freebsd 8.0 release from last fall. After
> struggling to find the correct configuration I was able to get my wireless
> interface working just great. In an attempt to get Gnome 2.3 loaded I
> performed a freebsd-update to 8.1 prerelease. After running install and
> rebooting twice the system booted up with the wlan0 device stating
> "associated." However, no network response was forth coming. After
> researching this on the web I found a blog that stated to insert the line
> synchonous_dhclient="yes." I did and the network interface was able to
> perform pings and traceroutes. But when I went to download a new package
> the network froze. Again, I researched the web and found instructions to
> add if_vlan_load and vaps_ath0="wlan0". Adding these did not make matters
> any better. I then "rolled back" the Freebsd to 8.0 release and changed the
> conf files back and the network is up and running as expected.
>
> 8.0 release config files
>
> rc.conf
> wlans_ath0="wlan0"
> ifconfig_wlan0="WPA DHCP"
>
> loader.conf
> wlan_wep_load="YES"
> wlan_ccmp_load="YES"
> wlan_tkip_load="YES"
>
> wpa_supplicant.conf
> eapol_version=1
> ap_scan=1
> fast_reauth=1
> #
> network={
> ssid="my wireless AP"
> psk="my AP password"
> }
>
>
>>How-To-Repeat:
> upgrade to 8.1 prerelease
>>Fix:
>
>
>>Release-Note:
>>Audit-Trail:
>>Unformatted:
> ___
> freebsd-amd64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
>
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/153746: kernel crash with 2 X11 sessions on amd64 with radeon drm
http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html http://old.nabble.com/freebsd7,-radeon,-xorg-server-->-deadlock-or-so-td27524122.html On 1/7/11, fbsdm...@dnswatch.com wrote: > > On Thu, January 6, 2011 2:45 pm, Patrick Mackinlay wrote: >> > >>> Number: 153746 >>> Category: amd64 >>> Synopsis: kernel crash with 2 X11 sessions on amd64 with radeon >>> drm >>> Confidential: no >>> Severity: non-critical >>> Priority: medium >>> Responsible:freebsd-amd64 >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Thu Jan 06 22:50:07 UTC 2011 >>> Closed-Date: >>> Last-Modified: >>> Originator: Patrick Mackinlay >>> Release:8.1-RELEASE-p2 (affects 8.0 as well) >>> Organization: >>> Environment: >>> >> FreeBSD patrick.uknet.spacesurfer.com 8.1-RELEASE-p2 FreeBSD >> 8.1-RELEASE-p2 #3: Thu Jan 6 21:40:18 GMT 2011 >> r...@patrick.uknet.spacesurfer.com:/usr/obj/usr/src/sys/PATRICK amd64 >> >>> Description: >>> >> If I start 2 X11 sessions (startx and start -- :1). The close the >> sessions on display :1, when I switch to the session on display :0 the >> system reboots. I have an amd64 with a ATI radeon card: >> >> drm0: on vgapci0 >> >> >> Note that if I never close either X11 session there is no problem with >> stability (weeks uptime), however the only graphics intensive app I use >> is mplayer. mplayer is the only reason I need drm, however the bug will >> be triggered even if I havn't used mplayer in my X11 session. > Greetings, > Fact is, Mplayer has nothing to do with when/how drm is loaded. 2 > possibilities exist for loading; @boot via loader.conf(5), or when > starting X via xorg.conf(5). > If you're loading it via xorg.conf(5), and suspect drm to be the culprit. > The easiest solution would be to comment the line that loads it in your > xorg.conf(5) file. Then startx(1), and see if there's any difference in > behavior. FWIW I haven't been able to use HALd on _any_ 64bit box. So > against the suggested entries in rc.conf(8): > dbus_enable="YES" > hald_enable="YES" > > I need to use > > hald_enable="NO" > or I have big problems running X. I only mention it, in case this > might also apply to your situation. > > HTH > > --Chris > >> >> I will attach the output from dmesg with my full system setup and the >> output from the two xorg log files. >>> How-To-Repeat: >>> >> >>> Fix: >>> >> >> >>> Release-Note: >>> Audit-Trail: >>> Unformatted: >>> >> ___ >> freebsd-amd64@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >> To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org" >> >> > > > -- > kern: > FreeBSD 8.1-RELEASE amd64 > > > ___ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org" > ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
UEFI secure bootloader from ferdora
https://github.com/mjg59/shim http://hup.hu/cikkek/20120603/a_fedora_megoldasa_az_uefi_secure_boot_mizeriara http://mjg59.dreamwidth.org/12368.html?thread=406864 ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
amd64/179282: [PATCH] Intel SMAP for FreeBSD-CURRENT
>Number: 179282 >Category: amd64 >Synopsis: [PATCH] Intel SMAP for FreeBSD-CURRENT >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Jun 03 23:10:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Oliver Pinter >Release:FreeBSD 10-CURRENT >Organization: >Environment: >Description: As subpart of my thesis, I implemented Intel SMAP[1] support for FreeBSD. The current stable version of patch (attached) have compile time option to enable SMAP.* A feature complete dynamic version is expected by the end of the month, which patched the kernel on boot time, when the feautre presented in CPU. [1] http://lwn.net/Articles/517475/ patches: https://github.com/opntr/freebsd-patches-2013-tavasz smap-test: https://github.com/opntr/freebsd-smap-tester >How-To-Repeat: >Fix: Patch attached with submission follows: >From ae18b374b38401f736e4e13a8ab5fab82985df2b Mon Sep 17 00:00:00 2001 From: Oliver Pinter Date: Tue, 16 Apr 2013 01:32:25 +0200 Subject: [PATCH] added SMAP support for FreeBSD against r250423 This patch implemented support for Intel's new protection technology. Supervisor Mode Access Prevention (SMAP) is newest security feature from Intel, which first appears in the Haswell Line of processors. When SMAP enabled, the kernel cannot access pages that are in userspace. In some cases the kernel does have to access user pages, for this reason the technology provided two instruction, to temporarily disable this protection. When SMAP detect protection violation, the kernel must call panic(). Intel's SMAP documentation: http://software.intel.com/sites/default/files/319433-014.pdf Test case: https://github.com/opntr/freebsd-smap-tester some parts of this patch discussed with kib freebsd org and Hunger Signed-off-by: Oliver Pinter -- * added void clac(void) and void stac(void) to cpufunc.h * added STAC/CLAC instruction and added config options * added basic support for SMAP * added stac/clac in support.S around userspace memory access * added RFLAGS.AC clearing to exception.S related to SMAP * added RFLAGS.AC clearing to ia32_exception.S related to SMAP * added RFLAGS.AC clearing to asmacros.h related to SMAP * clac and stac functions depend on INTEL_SMAP * added trap handler to SMAP For security reason, when PF occured by SMAP, the kernel should paniced. " [...] The above items imply that the error code delivered by a page-fault exception due to SMAP is either 1 (for reads) or 3 (for writes). Note that the only page-fault exceptions that deliver an error code of 1 are those induced by SMAP. (If CR0.WP = 1, some page-fault exceptions may deliver an error code of 3 even if CR4.SMAP = 0.) [...]" - intel 319433-014.pdf 9.3.3 * Clear the RFLAGS.AC on the start of nmi handler suggested by kib@: > I think that NMI handler should have CLAC executed unconditionally and > much earlier then it is done in your patch. Since NMI could interrupt > the copy*() functions, you would get some kernel code unneccessary > executing with SMAP off. * added note to fault handlers related to SMAP suggested by kib@: > I believe that exception labels in the support.S, like copyout_fault > etc > deserve a comment describing that EFLAGS.AC bit gets cleared by the > exception entry point before the control reaches the label. * added AC flag checking and factor out SMAP checking in trap_pfault() to make it more readable and partially suggested by kib: > The trap_pfault() fragment should check for the error code equal to 1 or > 3, as described in the 9.3.3, instead of only checking for the present > bit set. More, I suggest you to explicitely check that the #PF exception > came from the kernel mode and that EFLAGS.AC was also set, before > decidingto panic due to SMAP-detected failure. * build fix, when INTEL_SMAP has not set in kernel config /usr/home/op/git/freebsd-base.git.http/sys/amd64/amd64/trap.c:889:1: error: unused function 'smap_access_violation' [-Werror,-Wunused-function] smap_access_violation(struct trapframe *frame, int usermode) ^ 1 error generated. *** [trap.o] Error code 1 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error * fixed smap_access_violation(...), spotted by Hunger * fix smap_access_violatrion() when the CPU does not support SMAP * use the CLAC and STAC macro, instead of the .byte sequence * added memory clobber to clac and stac inline assembly clac and stac are sensitive instructions, to prevent instruction reordering added memory clobber spotted by Hunger, PaXTeam Signed-off-
Re: amd64/179282: [PATCH] Intel SMAP for FreeBSD-CURRENT
I'm working on this, as part of FreeBSD GSoC2014. On 6/4/13, freebsd-gnats-sub...@freebsd.org wrote: > Thank you very much for your problem report. > It has the internal identification `amd64/179282'. > The individual assigned to look at your > report is: freebsd-amd64. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179282 > >>Category: amd64 >>Responsible:freebsd-amd64 >>Synopsis: [PATCH] Intel SMAP for FreeBSD-CURRENT >>Arrival-Date: Mon Jun 03 23:10:01 UTC 2013 > ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/179282: [PATCH] Intel SMAP for FreeBSD-CURRENT
The following reply was made to PR amd64/179282; it has been noted by GNATS. From: Oliver Pinter To: freebsd-gnats-sub...@freebsd.org, freebsd-amd64@freebsd.org Cc: Subject: Re: amd64/179282: [PATCH] Intel SMAP for FreeBSD-CURRENT Date: Mon, 5 May 2014 13:11:10 +0200 I'm working on this, as part of FreeBSD GSoC2014. On 6/4/13, freebsd-gnats-sub...@freebsd.org wrote: > Thank you very much for your problem report. > It has the internal identification `amd64/179282'. > The individual assigned to look at your > report is: freebsd-amd64. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179282 > >>Category: amd64 >>Responsible:freebsd-amd64 >>Synopsis: [PATCH] Intel SMAP for FreeBSD-CURRENT >>Arrival-Date: Mon Jun 03 23:10:01 UTC 2013 > ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: svn commit: r309400 - head/sys/dev/acpica
On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter wrote: > On 12/3/16, Oliver Pinter wrote: >> On 12/3/16, Oliver Pinter wrote: >>> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky >>> wrote: >>>> Author: hselasky >>>> Date: Fri Dec 2 08:21:08 2016 >>>> New Revision: 309400 >>>> URL: https://svnweb.freebsd.org/changeset/base/309400 >>>> >>>> Log: >>>> Fix for endless recursion in the ACPI GPE handler during boot. >>>> >>>> When handling a GPE ACPI interrupt object the EcSpaceHandler() >>>> function can be called which checks the EC_EVENT_SCI bit and then >>>> recurse on the EcGpeQueryHandler() function. If there are multiple GPE >>>> events pending the EC_EVENT_SCI bit will be set at the next call to >>>> EcSpaceHandler() causing it to recurse again via the >>>> EcGpeQueryHandler() function. This leads to a slow never ending >>>> recursion during boot which prevents proper system startup, because >>>> the EC_EVENT_SCI bit never gets cleared in this scenario. >>>> >>>> The behaviour is reproducible with the ALASKA AMI in combination with >>>> a newer Skylake based mainboard in the following way: >>>> >>>> Enter BIOS and adjust the clock one hour forward. Save and exit the >>>> BIOS. System fails to boot due to the above mentioned bug in >>>> EcGpeQueryHandler() which was observed recursing multiple times. >>>> >>>> This patch adds a simple recursion guard to the EcGpeQueryHandler() >>>> function and also also adds logic to detect if new GPE events occurred >>>> during the execution of EcGpeQueryHandler() and then loop on this >>>> function instead of recursing. >>>> >>>> Reviewed by: jhb >>>> MFC after:2 weeks >>>> >>>> Modified: >>>> head/sys/dev/acpica/acpi_ec.c >>> >>> >>> I have similar error since the latest BIOS update on my gigabyte >>> H170N-Wifi board. The curiosity of the BIOS update was after upgrading >>> to this version, there are no possibility to rollback to older >>> version. >>> >>> The other weird thing, is that MFCing back this patch does not help. I >>> get stucked lock in acmtx mutex, as you >>> could see from the attached log. The other interesting is the ACPI >>> error at boot time: >>> >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >>> (20160527/utmutex-386) >>> [1] ACPI Error: Could not release AML Interpreter mutex >>> (20160527/exutils-147) >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >>> (20160527/utmutex-386) >>> [1] ACPI Error: Could not release AML Interpreter mutex >>> (20160527/exutils-147) >>> [1] cpu1: on acpi0 >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >>> (20160527/utmutex-386) >>> [1] ACPI Error: Could not release AML Interpreter mutex >>> (20160527/exutils-147) >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >>> (20160527/utmutex-386) >>> [1] ACPI Error: Could not release AML Interpreter mutex >>> (20160527/exutils-147) >>> >>> (This error is on 10-STABLE.) >>> >> >> After backported the last to ACPICA update to 10-STABLE with this >> patch, the issue reducated to this warning message: > > Attached the two backport. > >> >> [1] acpi0: Power Button (fixed) >> [1] ACPI Error: Method parse/execution failed [\134_SB.PCI0.IOTR._CRS] >> (Node 0xf80006592f00), AE_AML_NO_RESOURCE_END_TAG >> (20161117/psparse-560) >> [1] ACPI Error: Method execution failed [\134_SB.PCI0.IOTR._CRS] (Node >> 0xf80006592f00), AE_AML_NO_RESOURCE_END_TAG (20161117/uteval-111) >> [1] can't fetch resources for \134_SB_.PCI0.IOTR - >> AE_AML_NO_RESOURCE_END_TAG >> >> but the lockup has gone. ;) >> CC: ACPI and AMD64 >> >> [trim] >> 0001-HBSD-MFC-pull-in-ACPICA-20160930-from-FreeBSD-12-CUR.patch.xz Description: Binary data 0002-HBSD-MFC-Merge-ACPICA-20161117.patch.xz Description: Binary data ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: svn commit: r309400 - head/sys/dev/acpica
On Tue, Dec 6, 2016 at 11:01 PM, Moore, Robert wrote: > > >> -Original Message- >> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd- >> a...@freebsd.org] On Behalf Of Oliver Pinter >> Sent: Saturday, December 3, 2016 1:11 PM >> To: Hans Petter Selasky ; j...@freebsd.org >> Cc: freebsd-a...@freebsd.org; freebsd-amd64@freebsd.org >> Subject: Re: svn commit: r309400 - head/sys/dev/acpica >> >> On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter >> wrote: >> > On 12/3/16, Oliver Pinter wrote: >> >> On 12/3/16, Oliver Pinter wrote: >> >>> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky >> >>> wrote: >> >>>> Author: hselasky >> >>>> Date: Fri Dec 2 08:21:08 2016 >> >>>> New Revision: 309400 >> >>>> URL: https://svnweb.freebsd.org/changeset/base/309400 >> >>>> >> >>>> Log: >> >>>> Fix for endless recursion in the ACPI GPE handler during boot. >> >>>> >> >>>> When handling a GPE ACPI interrupt object the EcSpaceHandler() >> >>>> function can be called which checks the EC_EVENT_SCI bit and then >> >>>> recurse on the EcGpeQueryHandler() function. If there are >> multiple GPE >> >>>> events pending the EC_EVENT_SCI bit will be set at the next call >> to >> >>>> EcSpaceHandler() causing it to recurse again via the >> >>>> EcGpeQueryHandler() function. This leads to a slow never ending >> >>>> recursion during boot which prevents proper system startup, >> because >> >>>> the EC_EVENT_SCI bit never gets cleared in this scenario. >> >>>> >> >>>> The behaviour is reproducible with the ALASKA AMI in combination >> with >> >>>> a newer Skylake based mainboard in the following way: >> >>>> >> >>>> Enter BIOS and adjust the clock one hour forward. Save and exit >> the >> >>>> BIOS. System fails to boot due to the above mentioned bug in >> >>>> EcGpeQueryHandler() which was observed recursing multiple times. >> >>>> >> >>>> This patch adds a simple recursion guard to the >> EcGpeQueryHandler() >> >>>> function and also also adds logic to detect if new GPE events >> occurred >> >>>> during the execution of EcGpeQueryHandler() and then loop on this >> >>>> function instead of recursing. >> >>>> >> >>>> Reviewed by: jhb >> >>>> MFC after:2 weeks >> >>>> >> >>>> Modified: >> >>>> head/sys/dev/acpica/acpi_ec.c >> >>> >> >>> >> >>> I have similar error since the latest BIOS update on my gigabyte >> >>> H170N-Wifi board. The curiosity of the BIOS update was after >> >>> upgrading to this version, there are no possibility to rollback to >> >>> older version. >> >>> >> >>> The other weird thing, is that MFCing back this patch does not help. >> >>> I get stucked lock in acmtx mutex, as you could see from the >> >>> attached log. The other interesting is the ACPI error at boot time: >> >>> >> >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >> >>> (20160527/utmutex-386) >> >>> [1] ACPI Error: Could not release AML Interpreter mutex >> >>> (20160527/exutils-147) >> >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >> >>> (20160527/utmutex-386) >> >>> [1] ACPI Error: Could not release AML Interpreter mutex >> >>> (20160527/exutils-147) >> >>> [1] cpu1: on acpi0 >> >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >> >>> (20160527/utmutex-386) >> >>> [1] ACPI Error: Could not release AML Interpreter mutex >> >>> (20160527/exutils-147) >> >>> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release >> >>> (20160527/utmutex-386) >> >>> [1] ACPI Error: Could not release AML Interpreter mutex >> >>> (20160527/exutils-147) >> >>> >> >>> (This error is on 10-STABLE.) >> >>> >> >> >> >> After backported the last to ACPICA update to 10-STABLE with this >> >> patch, the
