Ryzen public erratas
Today I noted that AMD published the public errata document for Ryzens, https://developer.amd.com/wp-content/resources/55449_1.12.pdf Some of the issues listed there looks quite relevant to the potential hangs that some people still experience with the machines. I wrote a script which should apply the recommended workarounds to the erratas that I find interesting. To run it, kldload cpuctl, then apply the latest firmware update to your CPU, then run the following shell script. Comments indicate the errata number for the workarounds. Please report the results. If the script helps, I will code the kernel change to apply the workarounds. #!/bin/sh # Enable workarounds for erratas listed in # https://developer.amd.com/wp-content/resources/55449_1.12.pdf # 1057, 1109 sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt for x in /dev/cpuctl*; do # 1021 cpucontrol -m '0xc0011029|=0x2000' $x # 1033 cpucontrol -m '0xc0011020|=0x10' $x # 1049 cpucontrol -m '0xc0011028|=0x10' $x # 1095 cpucontrol -m '0xc0011020|=0x200' $x done ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
Konstantin Belousov writes: > Today I noted that AMD published the public errata document for Ryzens, > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > Some of the issues listed there looks quite relevant to the potential > hangs that some people still experience with the machines. I wrote > a script which should apply the recommended workarounds to the erratas > that I find interesting. > > To run it, kldload cpuctl, then apply the latest firmware update to your > CPU, then run the following shell script. Comments indicate the errata > number for the workarounds. > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200' $x > done > Hi Thanks for the fix! I'm trying it now on my Ryzen 3 2200G which does experience some random occasional resets. About updating to latest firmware, is this something that's done from BIOS or from FreeBSD? If the latter, how? > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 13 June 2018 at 03:35, Konstantin Belousov wrote: > Today I noted that AMD published the public errata document for Ryzens, > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > Some of the issues listed there looks quite relevant to the potential > hangs that some people still experience with the machines. I wrote > a script which should apply the recommended workarounds to the erratas > that I find interesting. > > To run it, kldload cpuctl, then apply the latest firmware update to your > CPU, then run the following shell script. Comments indicate the errata > number for the workarounds. > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt Is this needed if it was previously machdep.idle: acpi ? -- Eitan Adler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On Wed, Jun 13, 2018 at 12:06:42PM +0100, Johannes Lundberg wrote: > > Konstantin Belousov writes: > > > Today I noted that AMD published the public errata document for Ryzens, > > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > > > Some of the issues listed there looks quite relevant to the potential > > hangs that some people still experience with the machines. I wrote > > a script which should apply the recommended workarounds to the erratas > > that I find interesting. > > > > To run it, kldload cpuctl, then apply the latest firmware update to your > > CPU, then run the following shell script. Comments indicate the errata > > number for the workarounds. > > > > Please report the results. If the script helps, I will code the kernel > > change to apply the workarounds. > > > > #!/bin/sh > > > > # Enable workarounds for erratas listed in > > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > > > # 1057, 1109 > > sysctl machdep.idle_mwait=0 > > sysctl machdep.idle=hlt > > > > for x in /dev/cpuctl*; do > > # 1021 > > cpucontrol -m '0xc0011029|=0x2000' $x > > # 1033 > > cpucontrol -m '0xc0011020|=0x10' $x > > # 1049 > > cpucontrol -m '0xc0011028|=0x10' $x > > # 1095 > > cpucontrol -m '0xc0011020|=0x200' $x > > done > > > > Hi > > Thanks for the fix! I'm trying it now on my Ryzen 3 2200G which does > experience some random occasional resets. > > About updating to latest firmware, is this something that's done from BIOS or > from FreeBSD? If the latter, how? >From FreeBSD, install sysutils/devcpu-data then do service microcode_update start and of course, you must flash latest BIOS. The microcode_update must be applied before running this script. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
update to r335024 - no mouse
subj amd64 -- -- Alex V. Petrov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On Wed, 13 Jun 2018 14:46:25 +0300 Konstantin Belousov wrote: > On Wed, Jun 13, 2018 at 12:06:42PM +0100, Johannes Lundberg wrote: > > > > Konstantin Belousov writes: > > > > > Today I noted that AMD published the public errata document for Ryzens, > > > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > > > > > Some of the issues listed there looks quite relevant to the potential > > > hangs that some people still experience with the machines. I wrote > > > a script which should apply the recommended workarounds to the erratas > > > that I find interesting. > > > > > > To run it, kldload cpuctl, then apply the latest firmware update to your > > > CPU, then run the following shell script. Comments indicate the errata > > > number for the workarounds. > > > > > > Please report the results. If the script helps, I will code the kernel > > > change to apply the workarounds. > > > > > > #!/bin/sh > > > > > > # Enable workarounds for erratas listed in > > > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > > > > > # 1057, 1109 > > > sysctl machdep.idle_mwait=0 > > > sysctl machdep.idle=hlt > > > > > > for x in /dev/cpuctl*; do > > > # 1021 > > > cpucontrol -m '0xc0011029|=0x2000' $x > > > # 1033 > > > cpucontrol -m '0xc0011020|=0x10' $x > > > # 1049 > > > cpucontrol -m '0xc0011028|=0x10' $x > > > # 1095 > > > cpucontrol -m '0xc0011020|=0x200' $x > > > done > > > > > > > Hi > > > > Thanks for the fix! I'm trying it now on my Ryzen 3 2200G which does > > experience some random occasional resets. > > > > About updating to latest firmware, is this something that's done from BIOS > > or > > from FreeBSD? If the latter, how? > From FreeBSD, install sysutils/devcpu-data then do > service microcode_update start > and of course, you must flash latest BIOS. > > The microcode_update must be applied before running this script. > I added before and after outputs to my version of the script and saw that my BIOS is setting all the relevant bits at start up. So, a BIOS update might help. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 4 Jun 2018 at 22:36, Matthew Macy wrote: > > Implementing a callback in 140 different files for the sake of a handful of > out of tree drivers and people not reading updating is pretty prohibitive. 11 > may be more your cup of tea. This was the in tree wifi drivers.. :-) Dude, we're on the same side. I'll take a look at the multicast iterator stuff once I figure out why the athp receive performance in my driver is terrible-y. -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't seem to use 5GHz APs with Intel wireless
hm. Which country are you in? india? It seems to think you're in the FCC4 regdomain and DE country, which if I read it right won't give you 5G. So somehow it determined you're in the "wrong" country? -adrian On Mon, 4 Jun 2018 at 07:15, Adam wrote: > > On Sun, Jun 3, 2018 at 9:50 PM, Dhananjay Balan wrote: > > > On Sun, Jun 03, 2018 at 07:33:30PM +0200, Christoph Moench-Tegeder wrote: > > > > > Is the regdomain/country setting correct for your area and matches your > > > AP? Especially in the 5GHz band there are some "gaps" - not all channels > > > may be used in all countries (because of possible interference with > > > radar equipment and other stuff). See: > > > https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_( > > 802.11a/h/j/n/ac/ax) > > > > > > > Thanks for taking time to explain. > > > > Turns out PEBKAC. I had this offending line burried in rc.conf > > > > create_args_wlan0="country DE regdomain FCC4" > > > > According to regdomain(5) > > > > So I was forcing my card to do 2.4Ghz it seems, removed it - everything > > worked like charm. I can see and connect to 5GHz 11a aps. > > > > wlan0: flags=8843 metric 0 mtu > > 1500 > > ether > > inet 192.168.1.13 netmask 0xff00 broadcast 192.168.1.255 > > nd6 options=29 > > media: IEEE 802.11 Wireless Ethernet MCS mode 11na > > status: associated > > ssid channel 36 (5180 MHz 11a ht/40+) bssid > > regdomain FCC country US authmode WPA2/802.11i privacy ON > > deftxkey UNDEF TKIP 2:128-bit txpower 17 bmiss 10 mcastrate 6 > > mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 4 -amsdutx > > amsdurx > > shortgi -stbc -ldpc wme roaming MANUAL > > > > > Thanks for the posting. It appears I made some errors in my previous > response. I'm using an iwm, not iwn. And after your pointer I changed my > country to NO which then allows me to see, but not associate to 5gz. > > Good yours is working. > > -- > Adam > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
GELI attach issue from r326073 -> r334996
Hi! I just tried updating current from r326073 -> r334996 and when I try 'geli attach' I get the following error: # geli attach -p -k mykey.key /dev/gpt/da14 geli: Missing keyno argument # If I boot the old kernel GELI attaches just fine. I ran into this once before but can not find the thread. I recall it being a bug... with no resolution. I mount zfs partitions over GELI - my painful solution was to nuke each GPT partition in the zpool, resilver, repeat and rinse until everything was non-encrypted and repeat the cycle to re-encrypt. NOT FUN. Looking for suggestions to supply additional information to debug and resolve. dmesg attached from working kernel. Thanks!Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #2 r326073: Tue Nov 21 18:03:29 EST 2017 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): text 80x25 CPU: Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz (3400.02-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xfa3fbff Features2=0x9e982203 AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant Hypervisor: Origin = "VMwareVMware" real memory = 17179869184 (16384 MB) avail memory = 16548577280 (15781 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 8 package(s) x 1 core(s) random: unblocking device. MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #2 Launched! random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x80f95c20, 0) error 19 kbd1 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 cpu0: numa-domain 0 on acpi0 cpu1: numa-domain 0 on acpi0 cpu2: numa-domain 0 on acpi0 cpu3: numa-domain 0 on acpi0 cpu4: numa-domain 0 on acpi0 cpu5: numa-domain 0 on acpi0 cpu6: numa-domain 0 on acpi0 cpu7: numa-domain 0 on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1060-0x106f at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 7.3 (no driver attached) vgapci0: port 0x1070-0x107f mem 0xec00-0xefff,0xfe00-0xfe7f irq 16 at device 15.0 on pci0 vgapci0: Boot video device mpt0: port 0x1400-0x14ff mem 0xfeba-0xfebb,0xfebc-0xfebd irq 17 at device 16.0 on pci0 mpt0: MPI Version=1.2.0.0 pcib2: at device 17.0 on pci0 pci2: on pcib2 em0: port 0x2000-0x203f mem 0xfd5c-0xfd5d,0xfdff-0xfdff irq 18 at device 0.0 on pci2 em0: attach_pre capping queues at 1 em0: using 1024 tx descriptors and 1024 rx descriptors em0: allocated for 1 tx_queues em0: allocated for 1 rx_queues em0: Ethernet address: 00:0c:29:cc:f7:ac Link state changed to up em0: link state changed to UP em0: netmap queues/slots: TX 1/1024, RX 1/1024 uhci0: port 0x2040-0x205f irq 16 at device 2.0 on pci2 usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 ehci0: mem 0xfd5ef000-0xfd5e irq 17 at device 3.0 on pci2 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus1: 480Mbps High Speed USB v2.0 pcib3: at device 21.0 on pci0 pcib3: [GIANT-LOCKED] pci3: on pcib3 mps0: port 0x4000-0x40ff mem 0xfd4fc000-0xfd4f,0xfd48-0xfd4b irq 18 at device 0.0 on pci3 mps0: Firmware: 19.00.00.00, Driver: 21.02.00.00-fbsd mps0: IOCCapabilities: 1285c pcib4: at device 21.1 on pci0 pcib4: [GIANT-LOCKED] pcib5: at device 21.2 on pci0 pcib5: [GIANT-LOCKED] pcib6: at device 21.3 on pci0 pcib6: [GIANT-LOCKED] pcib7: at device 21.4 on pci0 pcib7: [GIANT-LOCKED] pcib8: at device 21.5 on pci0 pcib8: [GIANT-LOCKED] pcib9: at device 21.6 on pci0 pcib9: [GIANT-LOCKED] pcib10: at device 21.7 on pci0 pcib10
Re: GELI attach issue from r326073 -> r334996
On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote: > Hi! > > I just tried updating current from r326073 -> r334996 and when > I try 'geli attach' I get the following error: > > # geli attach -p -k mykey.key /dev/gpt/da14 > geli: Missing keyno argument > # > > If I boot the old kernel GELI attaches just fine. > > I ran into this once before but can not find the thread. I recall > it being a bug... with no resolution. > > I mount zfs partitions over GELI - my painful solution was to > nuke each GPT partition in the zpool, resilver, repeat and > rinse until everything was non-encrypted and repeat the cycle > to re-encrypt. NOT FUN. > > Looking for suggestions to supply additional information to debug > and resolve. > > dmesg attached from working kernel. > > Thanks! r333439 added a '-n keyno' parameter to geli attach, but it's supposed to default to trying all keys if you don't use -n. Is it possible you're running a newer kernel (or geom_eli module) than your userland or vice versa? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/13/2018 6:35 AM, Konstantin Belousov wrote: > Today I noted that AMD published the public errata document for Ryzens, > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > Some of the issues listed there looks quite relevant to the potential > hangs that some people still experience with the machines. I wrote > a script which should apply the recommended workarounds to the erratas > that I find interesting. > > To run it, kldload cpuctl, then apply the latest firmware update to your > CPU, then run the following shell script. Comments indicate the errata > number for the workarounds. Hi, tl;dr: The Microcode changes seem to fix a hard lockup I was able to reliable reproduce back in Feb. The BIOS on my AMD is pretty up to date. I think it has the same microcode as whats in the ports. x86info -a shows root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # after running the microcode update and root@ryzenbsd11:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # However, the dmesg after the microcode update adds this line AMD Extended Feature Extensions ID EBX=0x1007 CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.36-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics I ran the script root@ryzenbsd11:/home/mdtancsa # cat fix.sh #!/bin/sh # Enable workarounds for erratas listed in # https://developer.amd.com/wp-content/resources/55449_1.12.pdf # 1057, 1109 sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt for x in /dev/cpuctl*; do # 1021 cpucontrol -m '0xc0011029|=0x2000' $x # 1033 cpucontrol -m '0xc0011020|=0x10' $x # 1049 cpucontrol -m '0xc0011028|=0x10' $x # 1095 cpucontrol -m '0xc0011020|=0x200' $x echo $x done root@ryzenbsd11:/home/mdtancsa # sh ./fix.sh machdep.idle_mwait: 1 -> 0 machdep.idle: acpi -> hlt /dev/cpuctl0 /dev/cpuctl1 /dev/cpuctl10 /dev/cpuctl11 /dev/cpuctl2 /dev/cpuctl3 /dev/cpuctl4 /dev/cpuctl5 /dev/cpuctl6 /dev/cpuctl7 /dev/cpuctl8 /dev/cpuctl9 root@ryzenbsd11:/home/mdtancsa # Using a FreeBSD stable from back in Feb, I was able to crash Ryzen and Epyc based systems (https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088439.html) by generating a lot of traffic between the hypervisor and guests. The same tests on an intel based box ran just fine. e.g. start 3 guests in bhyve (amd64) and run combos of iperf3 between them. It would not take too long, but the box would hard lock-- i.e. blank screen, no crash dump etc. With the latest micro code update, I have been running the same sort of tests and so far so good. I will let them run overnight to see if things are now stable on STABLE. ---Mike > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200' $x > done > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GELI attach issue from r326073 -> r334996
On 2018-06-13 15:27, Ian Lepore wrote: On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote: Hi! I just tried updating current from r326073 -> r334996 and when I try 'geli attach' I get the following error: # geli attach -p -k mykey.key /dev/gpt/da14 geli: Missing keyno argument # If I boot the old kernel GELI attaches just fine. I ran into this once before but can not find the thread. I recall it being a bug... with no resolution. I mount zfs partitions over GELI - my painful solution was to nuke each GPT partition in the zpool, resilver, repeat and rinse until everything was non-encrypted and repeat the cycle to re-encrypt. NOT FUN. Looking for suggestions to supply additional information to debug and resolve. dmesg attached from working kernel. Thanks! r333439 added a '-n keyno' parameter to geli attach, but it's supposed to default to trying all keys if you don't use -n. Is it possible you're running a newer kernel (or geom_eli module) than your userland or vice versa? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Ian: Yes you are correct Maybe not the best method but I normally installkernel - boot into single user mode - GELI attach, zfs mount -av, then installworld. My boot volume is UFS, but many of the mount points are on zpools. What would be the best way to test a new kernel without a full installworld with new userland geli bits? I currently don't have a way to backup my 35TB of data :-( and don't want to lose anything. and I need a back out method should a full installworld fail. Thanks for you quick reply. --mikej ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RealTek RTL8192E/RTL8192SE Wireless Support
Hello All: I have a Samsung NP-N140 with a RTL8192E card and I am having difficulty with it. I am running -current because if I read the man pages correctly, only 12-Current has the driver in rtwn (from the rtwn(4) man page). So, I built a custom kernel per the man pages: # # MYKERNEL -- Custom Kernel for FreeBSD/i386 # # Originally created for 12.0 Current 20180605 r334665 # include GENERIC ident MYKERNEL # Custom Lines for the Samsung NP-N140 device rtwn# Required for Wireless device rtwnfw # Required for Wireless device rtwn_pci# Required for Wireless and I have a statement in /boot/loader.conf legal.realtek.license_ack=1 There are no error messages in dmesg pertaining to it that I see, however, pciconf -lv shows there is no driver bound to it ... none1@pci0:2:0:0: class=0x028000 card=0x7160144f chip=0x819210ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8192E/RTL8192SE Wireless LAN Controller' class = network I realize this is probably a lack of google capabilities so I do apologize in advance, but any thoughts or suggestions to point me in the right direction? Stephen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RealTek RTL8192E/RTL8192SE Wireless Support
On 06/13/2018 17:31, Stephen Albright wrote: Hello All: I have a Samsung NP-N140 with a RTL8192E card and I am having difficulty with it. I am running -current because if I read the man pages correctly, only 12-Current has the driver in rtwn (from the rtwn(4) man page). So, I built a custom kernel per the man pages: out of curiosity have you attempted to boot 12-CURRENT with the stock GENERIC kernel and attempt to load the kernel module by hand or via /etc/rc.conf? for example you could create this line in /etc/rc.conf: kld_list="rtwn.ko" then verify it is loaded after reboot by running "kldstat". cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RealTek RTL8192E/RTL8192SE Wireless Support
Hi Pete, I did not try in /etc/rc.conf. I did however try with GENERIC and use kldload and kldstat listed them as loaded. I will try the rc.conf method momentarily. Stephen On Wed, Jun 13, 2018 at 9:12 PM, Pete Wright wrote: > > > On 06/13/2018 17:31, Stephen Albright wrote: > >> Hello All: >> >> I have a Samsung NP-N140 with a RTL8192E card and I am having difficulty >> with it. I am running -current because if I read the man pages correctly, >> only 12-Current has the driver in rtwn (from the rtwn(4) man page). So, I >> built a custom kernel per the man pages: >> > > > out of curiosity have you attempted to boot 12-CURRENT with the stock > GENERIC kernel and attempt to load the kernel module by hand or via > /etc/rc.conf? > > for example you could create this line in /etc/rc.conf: > kld_list="rtwn.ko" > > then verify it is loaded after reboot by running "kldstat". > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
