Re: ACPI Error: No handler for Region [ECOR]
On 18-11-23 13:05:00, Charlie Li wrote: > On 23/11/2018 00:02, Ben Widawsky wrote: > > Thanks both of you. Here's another shot at roughly the same thing I asked > > the > > first reporter to try (that patch was wrong). If it doesn't work, can you > > please > > post the dmesg? > > > This patch works on my machine as well. > Thanks all. Here is the differential in phabricator: https://reviews.freebsd.org/D18311 > -- > Charlie Li > Can't think of a witty .sigline today… > > (This email address is for mailing list use only; replace local-part > with vishwin for off-list communication) > ___ 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"
Kernel Panic - Sublime Text - 12.0-PRERELEASE r340650M
Hi, When trying to run sublime text via the linuxulator my system panics and reboots. Unfortunately I do not have much extra info as it crashes immediately and seems to corrupt the UFS filesystem in the process (which has to be fixed with a few runs of fsck on next boot). I've tried enabling "dumpdev=AUTO" in rc.conf but don't find anything in /var/crash/ afterwards. $ uname FreeBSD macbook 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE #0 r340650M: Mon Nov 19 23:09:39 GMT 2018 root@macbook:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 $ pkg info | grep sublime linux-sublime-2.0.2_6 Happy to provide any extra info required to help diagnose the issue! Thanks, James ___ 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: ath(4) issues?
Adrian, Thanks for the explanation. Now that I think about it my internet carrier replaced my old cable modem with a new one some 6 weeks ago. This coincidence with the appearance of these messages. It also coincided with work by Warner (and mybe others) on PnP and PCI bus, so I seem to have mistakenly thought it was a software issue. BTW, thanks for the ath(4) device. It's worked for years with this old Dlink WL-630 card. -- steve On Fri, Nov 23, 2018 at 11:28:34AM -0800, Adrian Chadd wrote: > And I think 0x1b is "1mbit CCK", so I bet that's disabled on your AP? > > > On Fri, 23 Nov 2018 at 11:28, Adrian Chadd wrote: > > > hi! > > > > No. It's a side effect of how ath_rate_sample works. The TL;DR is: > > > > * ath_rate_sample uses a fixed set of rates for each attempt - so say you > > want to transmit at 54MBit OFDM, the second/third/fourth slower rates are > > in a fixed table; > > * net80211 negotiates which rates are acceptable to the hostap; > > * a lot of hostaps these days are increasingly disabling doing the lower > > OFDM/CCK rates so slower clients don't tie up so much air; > > * .. but they'll still RECEIVE and ACK those frames, so: > > * + you'll fail say, 54mbit > > * + and 48mbit > > * + then try something like 12mbit on the third attept, which the hostap > > didn't negotiate with you; and > > * + it ACKs it, cause it still receives it fine; then > > * + ath_rate_sample complains that it got a completion for a rate it's not > > supposed to use. > > > > They're harmless. You can comment it out for now; I really need to fix > > ath_rate_sample to use a dynamic table rather than the array of static > > tables.. > > > > > > > > -adrian > > > > > > On Thu, 22 Nov 2018 at 09:05, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > >> I have an old D-Link AirPlus G (DWL-630) pccard card > >> that I have used for years with FreeBSD. Recently, > >> I see > >> > >> % dmesg | grep ath > >> mobile:kargl[201] dmesg | grep ath > >> [ath_hal] loaded > >> [ath_dfs] loaded > >> [ath_rate] loaded > >> [ath] loaded > >> ath0: irq 19 at device 0.0 on cardbus0 > >> ath0: AR2413 mac 7.8 RF2413 phy 4.5 > >> ath0: 2GHz radio: 0x; 5GHz radio: 0x0056 > >> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 > >> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 > >> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 > >> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 > >> ath0: bad series0 hwrate 0x1b, tries 2 ts_status 0x1 > >> > >> > >> The "bad series0 hwrate..." message fills syslog. This message > >> appearred with a month or so old /usr/src and an update to top > >> of tree (r340736) still produces the message. > >> > >> So, is this a hardware-about-to-die issue or did someone break > >> ath(4) with the recent changes to inet? > >> > >> % sysctl -a | grep ath | grep -v path > >> net.wlan.0.%parent: ath0 > >> net.wlan.devices: ath0 wpi0 > >> hw.ath.bstuck: 4 > >> hw.ath.txbuf_mgmt: 32 > >> hw.ath.txbuf: 200 > >> hw.ath.rxbuf: 40 > >> hw.ath.anical: 100 > >> hw.ath.resetcal: 1200 > >> hw.ath.shortcal: 100 > >> hw.ath.longcal: 30 > >> irq19: cbb0 ath0:37 @cpu0(domain0): 53227 > >> dev.ath.0.hal.serialise_reg_war: 0 > >> dev.ath.0.hal.force_full_reset: 0 > >> dev.ath.0.hal.swba_backoff: 0 > >> dev.ath.0.hal.sw_brt: 10 > >> dev.ath.0.hal.dma_brt: 2 > >> dev.ath.0.hal.ar5416_biasadj: 0 > >> dev.ath.0.hal.debug: 0 > >> dev.ath.0.stats.sync_intr.31: 0 > >> dev.ath.0.stats.sync_intr.30: 0 > >> dev.ath.0.stats.sync_intr.29: 0 > >> dev.ath.0.stats.sync_intr.28: 0 > >> dev.ath.0.stats.sync_intr.27: 0 > >> dev.ath.0.stats.sync_intr.26: 0 > >> dev.ath.0.stats.sync_intr.25: 0 > >> dev.ath.0.stats.sync_intr.24: 0 > >> dev.ath.0.stats.sync_intr.23: 0 > >> dev.ath.0.stats.sync_intr.22: 0 > >> dev.ath.0.stats.sync_intr.21: 0 > >> dev.ath.0.stats.sync_intr.20: 0 > >> dev.ath.0.stats.sync_intr.19: 0 > >> dev.ath.0.stats.sync_intr.18: 0 > >> dev.ath.0.stats.sync_intr.17: 0 > >> dev.ath.0.stats.sync_intr.16: 0 > >> dev.ath.0.stats.sync_intr.15: 0 > >> dev.ath.0.stats.sync_intr.14: 0 > >> dev.ath.0.stats.sync_intr.13: 0 > >> dev.ath.0.stats.sync_intr.12: 0 > >> dev.ath.0.stats.sync_intr.11: 0 > >> dev.ath.0.stats.sync_intr.10: 0 > >> dev.ath.0.stats.sync_intr.9: 0 > >> dev.ath.0.stats.sync_intr.8: 0 > >> dev.ath.0.stats.sync_intr.7: 0 > >> dev.ath.0.stats.sync_intr.6: 0 > >> dev.ath.0.stats.sync_intr.5: 0 > >> dev.ath.0.stats.sync_intr.4: 0 > >> dev.ath.0.stats.sync_intr.3: 0 > >> dev.ath.0.stats.sync_intr.2: 0 > >> dev.ath.0.stats.sync_intr.1: 0 > >> dev.ath.0.stats.sync_intr.0: 0 > >> dev.ath.0.stats.rx_phy_err.63: 0 > >> dev.ath.0.stats.rx_phy_err.62: 0 > >> dev.ath.0.stats.rx_phy_err.61: 0 > >> dev.ath.0.stats.rx_phy_err.60: 0 > >> dev.ath.0.stats.rx_phy_err.59: 0 > >> dev.ath.0.stats.rx_phy_err.58: 0 > >> dev.ath.0.stats.rx_phy_err.57: 0 > >> dev.ath.0.stats.rx_phy_err.56: 0 > >> dev.ath.0.stats.rx_phy_err.55: 0 > >> dev.ath.0.stats.rx_phy_err.54: 0 > >>
Re: ACPI Error: No handler for Region [ECOR]
___ 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: ath(4) issues?
hi! No. It's a side effect of how ath_rate_sample works. The TL;DR is: * ath_rate_sample uses a fixed set of rates for each attempt - so say you want to transmit at 54MBit OFDM, the second/third/fourth slower rates are in a fixed table; * net80211 negotiates which rates are acceptable to the hostap; * a lot of hostaps these days are increasingly disabling doing the lower OFDM/CCK rates so slower clients don't tie up so much air; * .. but they'll still RECEIVE and ACK those frames, so: * + you'll fail say, 54mbit * + and 48mbit * + then try something like 12mbit on the third attept, which the hostap didn't negotiate with you; and * + it ACKs it, cause it still receives it fine; then * + ath_rate_sample complains that it got a completion for a rate it's not supposed to use. They're harmless. You can comment it out for now; I really need to fix ath_rate_sample to use a dynamic table rather than the array of static tables.. -adrian On Thu, 22 Nov 2018 at 09:05, Steve Kargl wrote: > I have an old D-Link AirPlus G (DWL-630) pccard card > that I have used for years with FreeBSD. Recently, > I see > > % dmesg | grep ath > mobile:kargl[201] dmesg | grep ath > [ath_hal] loaded > [ath_dfs] loaded > [ath_rate] loaded > [ath] loaded > ath0: irq 19 at device 0.0 on cardbus0 > ath0: AR2413 mac 7.8 RF2413 phy 4.5 > ath0: 2GHz radio: 0x; 5GHz radio: 0x0056 > ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 > ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 > ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 > ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 > ath0: bad series0 hwrate 0x1b, tries 2 ts_status 0x1 > > > The "bad series0 hwrate..." message fills syslog. This message > appearred with a month or so old /usr/src and an update to top > of tree (r340736) still produces the message. > > So, is this a hardware-about-to-die issue or did someone break > ath(4) with the recent changes to inet? > > % sysctl -a | grep ath | grep -v path > net.wlan.0.%parent: ath0 > net.wlan.devices: ath0 wpi0 > hw.ath.bstuck: 4 > hw.ath.txbuf_mgmt: 32 > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.anical: 100 > hw.ath.resetcal: 1200 > hw.ath.shortcal: 100 > hw.ath.longcal: 30 > irq19: cbb0 ath0:37 @cpu0(domain0): 53227 > dev.ath.0.hal.serialise_reg_war: 0 > dev.ath.0.hal.force_full_reset: 0 > dev.ath.0.hal.swba_backoff: 0 > dev.ath.0.hal.sw_brt: 10 > dev.ath.0.hal.dma_brt: 2 > dev.ath.0.hal.ar5416_biasadj: 0 > dev.ath.0.hal.debug: 0 > dev.ath.0.stats.sync_intr.31: 0 > dev.ath.0.stats.sync_intr.30: 0 > dev.ath.0.stats.sync_intr.29: 0 > dev.ath.0.stats.sync_intr.28: 0 > dev.ath.0.stats.sync_intr.27: 0 > dev.ath.0.stats.sync_intr.26: 0 > dev.ath.0.stats.sync_intr.25: 0 > dev.ath.0.stats.sync_intr.24: 0 > dev.ath.0.stats.sync_intr.23: 0 > dev.ath.0.stats.sync_intr.22: 0 > dev.ath.0.stats.sync_intr.21: 0 > dev.ath.0.stats.sync_intr.20: 0 > dev.ath.0.stats.sync_intr.19: 0 > dev.ath.0.stats.sync_intr.18: 0 > dev.ath.0.stats.sync_intr.17: 0 > dev.ath.0.stats.sync_intr.16: 0 > dev.ath.0.stats.sync_intr.15: 0 > dev.ath.0.stats.sync_intr.14: 0 > dev.ath.0.stats.sync_intr.13: 0 > dev.ath.0.stats.sync_intr.12: 0 > dev.ath.0.stats.sync_intr.11: 0 > dev.ath.0.stats.sync_intr.10: 0 > dev.ath.0.stats.sync_intr.9: 0 > dev.ath.0.stats.sync_intr.8: 0 > dev.ath.0.stats.sync_intr.7: 0 > dev.ath.0.stats.sync_intr.6: 0 > dev.ath.0.stats.sync_intr.5: 0 > dev.ath.0.stats.sync_intr.4: 0 > dev.ath.0.stats.sync_intr.3: 0 > dev.ath.0.stats.sync_intr.2: 0 > dev.ath.0.stats.sync_intr.1: 0 > dev.ath.0.stats.sync_intr.0: 0 > dev.ath.0.stats.rx_phy_err.63: 0 > dev.ath.0.stats.rx_phy_err.62: 0 > dev.ath.0.stats.rx_phy_err.61: 0 > dev.ath.0.stats.rx_phy_err.60: 0 > dev.ath.0.stats.rx_phy_err.59: 0 > dev.ath.0.stats.rx_phy_err.58: 0 > dev.ath.0.stats.rx_phy_err.57: 0 > dev.ath.0.stats.rx_phy_err.56: 0 > dev.ath.0.stats.rx_phy_err.55: 0 > dev.ath.0.stats.rx_phy_err.54: 0 > dev.ath.0.stats.rx_phy_err.53: 0 > dev.ath.0.stats.rx_phy_err.52: 0 > dev.ath.0.stats.rx_phy_err.51: 0 > dev.ath.0.stats.rx_phy_err.50: 0 > dev.ath.0.stats.rx_phy_err.49: 0 > dev.ath.0.stats.rx_phy_err.48: 0 > dev.ath.0.stats.rx_phy_err.47: 0 > dev.ath.0.stats.rx_phy_err.46: 0 > dev.ath.0.stats.rx_phy_err.45: 0 > dev.ath.0.stats.rx_phy_err.44: 0 > dev.ath.0.stats.rx_phy_err.43: 0 > dev.ath.0.stats.rx_phy_err.42: 0 > dev.ath.0.stats.rx_phy_err.41: 0 > dev.ath.0.stats.rx_phy_err.40: 0 > dev.ath.0.stats.rx_phy_err.39: 0 > dev.ath.0.stats.rx_phy_err.38: 0 > dev.ath.0.stats.rx_phy_err.37: 0 > dev.ath.0.stats.rx_phy_err.36: 0 > dev.ath.0.stats.rx_phy_err.35: 0 > dev.ath.0.stats.rx_phy_err.34: 0 > dev.ath.0.stats.rx_phy_err.33: 0 > dev.ath.0.stats.rx_phy_err.32: 0 > dev.ath.0.stats.rx_phy_err.31: 1875 > dev.ath.0.stats.rx_phy_err.30: 0 > dev.ath.0.stats.rx_phy_err.29: 0 > dev.ath.0.stats.rx_phy_err.28: 0 > dev.ath.0.stats.rx_phy_err.27: 0 > dev.ath.0.stats.rx_phy_err.26: 0 > dev.ath.0.stats.rx_phy_err.25: 0 > dev.ath.0.stats.rx_phy_err.24: 0 >
Re: ath(4) issues?
And I think 0x1b is "1mbit CCK", so I bet that's disabled on your AP? On Fri, 23 Nov 2018 at 11:28, Adrian Chadd wrote: > hi! > > No. It's a side effect of how ath_rate_sample works. The TL;DR is: > > * ath_rate_sample uses a fixed set of rates for each attempt - so say you > want to transmit at 54MBit OFDM, the second/third/fourth slower rates are > in a fixed table; > * net80211 negotiates which rates are acceptable to the hostap; > * a lot of hostaps these days are increasingly disabling doing the lower > OFDM/CCK rates so slower clients don't tie up so much air; > * .. but they'll still RECEIVE and ACK those frames, so: > * + you'll fail say, 54mbit > * + and 48mbit > * + then try something like 12mbit on the third attept, which the hostap > didn't negotiate with you; and > * + it ACKs it, cause it still receives it fine; then > * + ath_rate_sample complains that it got a completion for a rate it's not > supposed to use. > > They're harmless. You can comment it out for now; I really need to fix > ath_rate_sample to use a dynamic table rather than the array of static > tables.. > > > > -adrian > > > On Thu, 22 Nov 2018 at 09:05, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > >> I have an old D-Link AirPlus G (DWL-630) pccard card >> that I have used for years with FreeBSD. Recently, >> I see >> >> % dmesg | grep ath >> mobile:kargl[201] dmesg | grep ath >> [ath_hal] loaded >> [ath_dfs] loaded >> [ath_rate] loaded >> [ath] loaded >> ath0: irq 19 at device 0.0 on cardbus0 >> ath0: AR2413 mac 7.8 RF2413 phy 4.5 >> ath0: 2GHz radio: 0x; 5GHz radio: 0x0056 >> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 >> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 >> ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0, final_rix=0 >> ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 >> ath0: bad series0 hwrate 0x1b, tries 2 ts_status 0x1 >> >> >> The "bad series0 hwrate..." message fills syslog. This message >> appearred with a month or so old /usr/src and an update to top >> of tree (r340736) still produces the message. >> >> So, is this a hardware-about-to-die issue or did someone break >> ath(4) with the recent changes to inet? >> >> % sysctl -a | grep ath | grep -v path >> net.wlan.0.%parent: ath0 >> net.wlan.devices: ath0 wpi0 >> hw.ath.bstuck: 4 >> hw.ath.txbuf_mgmt: 32 >> hw.ath.txbuf: 200 >> hw.ath.rxbuf: 40 >> hw.ath.anical: 100 >> hw.ath.resetcal: 1200 >> hw.ath.shortcal: 100 >> hw.ath.longcal: 30 >> irq19: cbb0 ath0:37 @cpu0(domain0): 53227 >> dev.ath.0.hal.serialise_reg_war: 0 >> dev.ath.0.hal.force_full_reset: 0 >> dev.ath.0.hal.swba_backoff: 0 >> dev.ath.0.hal.sw_brt: 10 >> dev.ath.0.hal.dma_brt: 2 >> dev.ath.0.hal.ar5416_biasadj: 0 >> dev.ath.0.hal.debug: 0 >> dev.ath.0.stats.sync_intr.31: 0 >> dev.ath.0.stats.sync_intr.30: 0 >> dev.ath.0.stats.sync_intr.29: 0 >> dev.ath.0.stats.sync_intr.28: 0 >> dev.ath.0.stats.sync_intr.27: 0 >> dev.ath.0.stats.sync_intr.26: 0 >> dev.ath.0.stats.sync_intr.25: 0 >> dev.ath.0.stats.sync_intr.24: 0 >> dev.ath.0.stats.sync_intr.23: 0 >> dev.ath.0.stats.sync_intr.22: 0 >> dev.ath.0.stats.sync_intr.21: 0 >> dev.ath.0.stats.sync_intr.20: 0 >> dev.ath.0.stats.sync_intr.19: 0 >> dev.ath.0.stats.sync_intr.18: 0 >> dev.ath.0.stats.sync_intr.17: 0 >> dev.ath.0.stats.sync_intr.16: 0 >> dev.ath.0.stats.sync_intr.15: 0 >> dev.ath.0.stats.sync_intr.14: 0 >> dev.ath.0.stats.sync_intr.13: 0 >> dev.ath.0.stats.sync_intr.12: 0 >> dev.ath.0.stats.sync_intr.11: 0 >> dev.ath.0.stats.sync_intr.10: 0 >> dev.ath.0.stats.sync_intr.9: 0 >> dev.ath.0.stats.sync_intr.8: 0 >> dev.ath.0.stats.sync_intr.7: 0 >> dev.ath.0.stats.sync_intr.6: 0 >> dev.ath.0.stats.sync_intr.5: 0 >> dev.ath.0.stats.sync_intr.4: 0 >> dev.ath.0.stats.sync_intr.3: 0 >> dev.ath.0.stats.sync_intr.2: 0 >> dev.ath.0.stats.sync_intr.1: 0 >> dev.ath.0.stats.sync_intr.0: 0 >> dev.ath.0.stats.rx_phy_err.63: 0 >> dev.ath.0.stats.rx_phy_err.62: 0 >> dev.ath.0.stats.rx_phy_err.61: 0 >> dev.ath.0.stats.rx_phy_err.60: 0 >> dev.ath.0.stats.rx_phy_err.59: 0 >> dev.ath.0.stats.rx_phy_err.58: 0 >> dev.ath.0.stats.rx_phy_err.57: 0 >> dev.ath.0.stats.rx_phy_err.56: 0 >> dev.ath.0.stats.rx_phy_err.55: 0 >> dev.ath.0.stats.rx_phy_err.54: 0 >> dev.ath.0.stats.rx_phy_err.53: 0 >> dev.ath.0.stats.rx_phy_err.52: 0 >> dev.ath.0.stats.rx_phy_err.51: 0 >> dev.ath.0.stats.rx_phy_err.50: 0 >> dev.ath.0.stats.rx_phy_err.49: 0 >> dev.ath.0.stats.rx_phy_err.48: 0 >> dev.ath.0.stats.rx_phy_err.47: 0 >> dev.ath.0.stats.rx_phy_err.46: 0 >> dev.ath.0.stats.rx_phy_err.45: 0 >> dev.ath.0.stats.rx_phy_err.44: 0 >> dev.ath.0.stats.rx_phy_err.43: 0 >> dev.ath.0.stats.rx_phy_err.42: 0 >> dev.ath.0.stats.rx_phy_err.41: 0 >> dev.ath.0.stats.rx_phy_err.40: 0 >> dev.ath.0.stats.rx_phy_err.39: 0 >> dev.ath.0.stats.rx_phy_err.38: 0 >> dev.ath.0.stats.rx_phy_err.37: 0 >> dev.ath.0.stats.rx_phy_err.36: 0 >> dev.ath.0.stats.rx_phy_err.35: 0 >> dev.ath.0.stats.rx_phy_err.34: 0 >> dev.ath.0.stats.rx_phy_err.33: 0 >>
Re: ACPI Error: No handler for Region [ECOR]
On 23/11/2018 00:02, Ben Widawsky wrote: > Thanks both of you. Here's another shot at roughly the same thing I asked the > first reporter to try (that patch was wrong). If it doesn't work, can you > please > post the dmesg? > This patch works on my machine as well. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 18-11-23 16:42:22, Mateusz Piotrowski wrote: > On Tue, 20 Nov 2018 at 15:47, Charlie Li wrote: > > > Somewhere between r340491 and r340650, probably starting from r340595, > > my ThinkPad W550s started spewing these messages repeatedly in the > > system log since boot: > > > > ... > > > > As a result, I am now unable to query battery information at the very > > least. r340490 is my last built revision with this working. > > > > There's a bug report for a similar issue after r330957: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 This is unrelated. The issue in this thread has to do with a regression I introduced when an ECDT, and an EC device is present (not uncommon). I am going to post a review momentarily for this. ___ 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"
GNU binutils 2.17.50 retirement planning
For some time we have been incrementally working to retire the use of obsolete GNU Binutils 2.17.50 tools. At present we still install three binutils by default: as ld.bfd objdump The intent is to retire all of these by FreeBSD 13. Depending on tool and architecture we will just remove it, migrate to LLVM tools, or rely on external toolchain components. Retiring GNU as requires further investigation and effort as we have some assembly files (for amd64 at least) which cannot be assembled by Clang's integrated assembler. If Clang gains support for the required functionality we'll switch to using IAS for all assembly files, and if not we could rewrite the few assembly files to work with IAS. ld.bfd is installed, but is not the default linker (/usr/bin/ld) on amd64, arm64 and arm, and soon i386 as well. We can just stop installing it at the appropriate time. For objdump I have proposed installing LLVM's llvm-obdump as objdump, in review D18307. It does not support all of the options that GNU objdump does, but is usable for many common operations. In addition, non-obsolete GNU objdump is available in the binutils port or package. Please try out llvm-objdump and see if it supports the options you need/use, and add a note in PR 229046 if not. ___ 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: ACPI Error: No handler for Region [ECOR]
On Tue, 20 Nov 2018 at 15:47, Charlie Li wrote: > Somewhere between r340491 and r340650, probably starting from r340595, > my ThinkPad W550s started spewing these messages repeatedly in the > system log since boot: > > ... > > As a result, I am now unable to query battery information at the very > least. r340490 is my last built revision with this working. > There's a bug report for a similar issue after r330957: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 ___ 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: ACPI Error: No handler for Region [ECOR]
With your patch applied, normal behavior seems back again. "dmesg" output and other relevent files are availabe at: http://imp.ovh/acpi > ___ 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: ACPI Error: No handler for Region [ECOR]
Hi all, "patch -p 1 < your_patch" gives me the following *.rej file: @@ -362,7 +362,8 @@ ret = 0; goto out; -} +} else + ecdt = 0; ret = ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids, NULL); if (ret > 0) @@ -422,16 +434,6 @@ /* Store the values we got from the namespace for attach. */ acpi_set_private(dev, params); -/* - * Check for a duplicate probe. This can happen when a probe via ECDT - * succeeded already. If this is a duplicate, disable this device. - */ -peer = devclass_get_device(acpi_ec_devclass, params->uid); -if (peer == NULL || !device_is_alive(peer)) - ret = 0; -else - device_disable(dev); - if (buf.Pointer) AcpiOsFree(buf.Pointer); out: Reject of hunk 1 and hunk 3 may be due to indentation. Anyway, I manually patched these two parts and I am now waiting for kernel build. ___ 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"
