Re: Samba kernel panics.
On Tue, Nov 17, 2020 at 10:01 PM Mark Johnston wrote: > > On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote: > > On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote: > > > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server > > > craches the server. > > > I did rebuild samba 4.11 but that does not help. > > > > > > The output on the console is the following. > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid =3; apic id = 06 > > > fault virtual address= 0x803a122b8 > > > fault code = supervisor read instruction, protection > > > violation > > > instruction pointer = 0x20:0x803a122b8 > > > stack pointer = 0x28:0xfe0127733a50 > > > frame pointer = 0x28:0x803a122b0 > > > code segment = base 0x0, limit 0xf, type 0x1b > > >= DPL 0, pres 1, long 1, def32 0, gran > > > 1 > > > processor eflags = 17340 (smbd) > > > trap number= 12 > > > panic: page fault > > > cpuid =3 > > > time = 1605632521 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame > > > 0xfe0127733700 > > > vpanic() at vpanic+0x182/frame 0xfe0127733750 > > > panic() at panic+0x43/frame 0xfe01277337b0 > > > trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810 > > > trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870 > > > trap() at trap+0x27d/frame 0xfe0127733980 > > > calltrap() at caltrap+0x8/frame 0xfe0127733980 > > > --- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = > > > 0x803a122b0 > > > --- > > > KDB: enter: panic > > > [ thread pid 17340 tid 101772 ] > > > stopped atkdb_enter+0x37: movq $0,0x1fa9446(%rip) > > > db> > > > > This looks like SMEP catching an issue, but it is not clear why. > > Probably fixed by r367783? The bug would have partially overwritten the > stack frame, resulting in a jump to a user address after a return. > Ah, yes, sorry that I missed this -- smbd was in-fact the exact program that the reporter noted observed it with, and what the fix was confirmed with. Sorry for the breakage~ Kyle Evans ___ 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: Samba kernel panics.
On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote: > On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote: > > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server > > craches the server. > > I did rebuild samba 4.11 but that does not help. > > > > The output on the console is the following. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3; apic id = 06 > > fault virtual address = 0x803a122b8 > > fault code = supervisor read instruction, protection > > violation > > instruction pointer = 0x20:0x803a122b8 > > stack pointer = 0x28:0xfe0127733a50 > > frame pointer = 0x28:0x803a122b0 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = 17340 (smbd) > > trap number = 12 > > panic: page fault > > cpuid =3 > > time = 1605632521 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame > > 0xfe0127733700 > > vpanic() at vpanic+0x182/frame 0xfe0127733750 > > panic() at panic+0x43/frame 0xfe01277337b0 > > trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810 > > trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870 > > trap() at trap+0x27d/frame 0xfe0127733980 > > calltrap() at caltrap+0x8/frame 0xfe0127733980 > > --- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = 0x803a122b0 > > --- > > KDB: enter: panic > > [ thread pid 17340 tid 101772 ] > > stopped at kdb_enter+0x37: movq $0,0x1fa9446(%rip) > > db> > > This looks like SMEP catching an issue, but it is not clear why. Probably fixed by r367783? The bug would have partially overwritten the stack frame, resulting in a jump to a user address after a return. > Did you clean rebuild of the kernel ? > > What filesystems types do you use ? > > Can you bisect ? I would actually suspect not clean rebuild after recent > changes to kern_event.c. ___ 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: Samba kernel panics.
On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote: > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server > craches the server. > I did rebuild samba 4.11 but that does not help. > > The output on the console is the following. > > Fatal trap 12: page fault while in kernel mode > cpuid =3; apic id = 06 > fault virtual address = 0x803a122b8 > fault code = supervisor read instruction, protection > violation > instruction pointer = 0x20:0x803a122b8 > stack pointer = 0x28:0xfe0127733a50 > frame pointer = 0x28:0x803a122b0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = 17340 (smbd) > trap number = 12 > panic: page fault > cpuid =3 > time = 1605632521 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame > 0xfe0127733700 > vpanic() at vpanic+0x182/frame 0xfe0127733750 > panic() at panic+0x43/frame 0xfe01277337b0 > trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810 > trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870 > trap() at trap+0x27d/frame 0xfe0127733980 > calltrap() at caltrap+0x8/frame 0xfe0127733980 > --- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = 0x803a122b0 > --- > KDB: enter: panic > [ thread pid 17340 tid 101772 ] > stopped at kdb_enter+0x37: movq $0,0x1fa9446(%rip) > db> This looks like SMEP catching an issue, but it is not clear why. Did you clean rebuild of the kernel ? What filesystems types do you use ? Can you bisect ? I would actually suspect not clean rebuild after recent changes to kern_event.c. ___ 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: in -current is svn still canonical?
On Tue, Nov 17, 2020 at 2:25 AM Thomas Mueller wrote: > from Warner Losh and my last message: > > > > Thanks for the information, but if you feel the need to send me a > > > not-quite-CC, please don't send me the multipart/alternative version > when > > > you send the plain-text version to the list. > > > > I hate multipart/alternative! > > > I must apologize. Sadly, I use gmail, so I have no control over how it > > decides to encode things, sadly. I've tried in the past, and alas, > nothing > > I've tried works for any length of time. Please forgive me whatever > > unspeakable MIME atrocities it sends on my behalf. I've removed you from > > the cc line in the hopes that the FreeBSD mail server cleans things up > to > > be more to your liking. > > The message on the list had only the plain-text part. Either you sent it > differently, or the list server stripped the HTML attachment. > > > > When git becomes the source of truth on FreeBSD after the flag day, > will > > > it be necessary to git-clone the whole tree from scratch, or will > there be > > > a conversion tool to switch the svn download to proper git format? > > > > For the supported stable branches, you'll be able to download via > > subversion and switch over at any time before the end of project support > > for the branch. > > I suppose this applies only to the current stable branches (11 and 12) but > not to future stable branches, beginning with 13? > Correct. It's a migration aid for people that have svn tooling based on the supported FreeBSD branches. Future branches, as well as the main development branch, will be in git only. > > However, when you make the switch to git (either due to the flag day and > > tracking -current, or jumping from svn on a stable branch), there's no > tool > > to convert the subversion checked out tree to a git tree. The needed > > information needed to create the git tree isn't easily available from the > > subversion checkout, so you'll need to do a git clone. If bandwidth is a > > problem, you can do a shallow clone that omits all the history and just > > grabs the branch of interest. Git is a bit more link efficient than > > subversion, which is helpful. Git also has ways to help you share one > local > > repo across checked out versions, which can also help if you have to > track > > multiple branches. > > I suppose I would then git-clone the current/13 src tree separately and > delete the svn version. > Yes. If you have the space, I'd grab new sources from git, make sure they are good and then delete the svn version once you've made the switch. > > > The doc tree is much smaller than the src tree, while the ports tree is > > > much bigger than the src tree. Is that the reason for the > few-months-long > > > lag switching the ports trree to git? > > > > There's a couple of things that make it trickier. The ports tree does > > quarterly branches. So there's a window around the quarterly branch when > > it's easiest to make the switch. In addition, the character of the files > in > > the ports tree differs from src. Unlike subversion, git infers copies, > > moves, etc. The mostly similar nature of the ports tree is likely to > cause > > git grief when ports are copied, resurrected from the attic, etc. The > ports > > folks are still figuring out how to best use git to track the history > they > > need to track without creating undue issues. It's not clear if that will > > all be sorted out before the next window in December, or if they will > have > > to defer until March. This is why I hedged a bit as to the exact time, > > since it's not been nailed down yet. So it's not so much the size, as the > > difference in makeup and character between the two trees. The doc tree > is, > > as you point out, much smaller, less active and its needs are more modest > > and largely mirror the src tree, so it can be done quickly at any time. > > > Warner > > Now I see the reason for timing the switch of the ports tree from svn to > git. > > I never tracked the quarterly ports tree, just as I never followed the > quarterly (NetBSD) pkgsrc, only the current version. > > NetBSD is readying to switch src trees and pkgsrc from cvs to hg > (Mercurial), but it takes some time to prepare and not mess things up. > > I am under the impression that they intend to switch everything over at > once when ready. > > Pkgsrc has both current and quarterly, so maybe they will have issues > similar to FreeBSD ports on switching to hg. > > I have git installed on both FreeBSD and NetBSD, but no Mercurial. > > As far as I can see, git repositories greatly outnumber mercurial > repositories. > Yea. Mercurial is interesting too. It's got a saner CLI command set than git (though, honestly, that's a low bar), but doesn't have as many of the easy history rewriting tools that git does and isn't as forgiving to 'oopses' in the middle of complex operations. In researching open source repos, I found that maybe 85% were git, 10% were svn and
Re: in -current is svn still canonical?
On Mon, Nov 16, 2020 at 11:13 PM Matthias Apitz wrote: > El día lunes, noviembre 16, 2020 a las 10:32:38p. m. -0700, Warner Losh > escribió: > > > For the supported stable branches, you'll be able to download via > > subversion and switch over at any time before the end of project support > > for the branch. > > > > However, when you make the switch to git (either due to the flag day and > > tracking -current, or jumping from svn on a stable branch), there's no > tool > > to convert the subversion checked out tree to a git tree. The needed > > information needed to create the git tree isn't easily available from the > > subversion checkout, so you'll need to do a git clone. If bandwidth is a > > problem, you can do a shallow clone that omits all the history and just > > grabs the branch of interest. Git is a bit more link efficient than > > subversion, which is helpful. Git also has ways to help you share one > local > > repo across checked out versions, which can also help if you have to > track > > multiple branches. > > > > > > Warner, please forgive me my nearly off-topic question: When we move to > git, will this conserve all the FreeBSD svn history of ci's somehow? Can > you please point me to a document about FreeBSD's transition from svn to > git? > Yes. The history is preserved. As an aside, we've been exporting a git tree for a while now, but it has so many issues in it that we decided to redo the export to fix them. They weren't apparent in day-to-day grabbing of the sources. However, when you went to do vendor-branch stuff or anything at all complicated, the issues were so bad that we decided to fix them. For docs, I'd start here: https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md but in general https://github.com/bsdimp/freebsd-git-docs/blob/main/ has interesting docs that I'm working on. These are rough drafts for handbook chapters. Since docs is migrating from DocBook to AsciiDoc, I did them in markdown. Please let me know if there's bits that are missing that would be helpful to add, or drop a pull request if you think you can improve the wording of sections... Warner ___ 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: in -current is svn still canonical?
On Tue, Nov 17, 2020 at 4:04 AM Jeffrey Bouquet wrote: > > > On Tue, 17 Nov 2020 02:48:32 +, "Thomas Mueller" > wrote: > > > from tech-lists: > > > > > As subject - is svn still canonical for -current or is it git now? > > > If it's not git now, when roughly is the intended switch? > > > > I recently updated FreeBSD doc, ports, src (current), and src12 > (12-stable) using svn (not svnup or svnlite). > > > > But I read some time before that, FreeBSD current source would go on > git, while other src trees (non-current), ports and doc would stay with svn > for the time being, until git on current src is further tested and > stabilized. > > > > .. > Can this be put up in a wiki page as well as in each UPDATING, referencing > the wiki page? > something like > > src - current dec 2020 now svn up /usr/src... git > svn cleanup git ... [ other svn-git... > src - stable may 2021 dec 2020 svn up /usr/ports > src -releasejuly 2021 > ports dec 2021 > doc dec 2021 > > and an additional column as to when svn will become obsolete for each > respository? > and maybe an additional wiki page with all the svn > git translations one > can reasonably presume to >be of use ? > We'll make sure that the plans are clear. All this history has been preserved, modulo some really weird things that were done back in the CVS era with repo copies. We have a 'beta' version of this available today. I'll write up something that has these basic details in it. I've been focusing on the harder stuff. For now, though, you might want to look at https://github.com/bsdimp/freebsd-git-docs/ for the docs we do have, especially https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md which should answer most of your questions. Warner Warner ___ 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"
Samba kernel panics.
Hello all after updating FreeBSD13 from r367724 to r367755 my samba server craches the server. I did rebuild samba 4.11 but that does not help. The output on the console is the following. Fatal trap 12: page fault while in kernel mode cpuid =3; apic id = 06 fault virtual address = 0x803a122b8 fault code = supervisor read instruction, protection violation instruction pointer = 0x20:0x803a122b8 stack pointer = 0x28:0xfe0127733a50 frame pointer = 0x28:0x803a122b0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = 17340 (smbd) trap number = 12 panic: page fault cpuid =3 time = 1605632521 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame 0xfe0127733700 vpanic() at vpanic+0x182/frame 0xfe0127733750 panic() at panic+0x43/frame 0xfe01277337b0 trap_fatal() at trap_fatal+0x387/frame 0xfe0127733810 trap_pfault() at trap_pfault+0x4f/frame 0xfe0127733870 trap() at trap+0x27d/frame 0xfe0127733980 calltrap() at caltrap+0x8/frame 0xfe0127733980 --- trap 0xc, rip = 0x803a122b8, rsp = 0xfe0127733a50, rbp = 0x803a122b0 --- KDB: enter: panic [ thread pid 17340 tid 101772 ] stopped at kdb_enter+0x37: movq $0,0x1fa9446(%rip) db> regards, Johan ___ 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: in -current is svn still canonical?
For user will git be in the base system or should we install from ports/pkg?Filippo On Tuesday, November 17, 2020, 12:38:00 PM GMT+1, David Wolfskill wrote: On Mon, Nov 16, 2020 at 10:32:38PM -0700, Warner Losh wrote: > ... > However, when you make the switch to git (either due to the flag day and > tracking -current, or jumping from svn on a stable branch), there's no tool > to convert the subversion checked out tree to a git tree. The needed > information needed to create the git tree isn't easily available from the > subversion checkout, so you'll need to do a git clone. If bandwidth is a > problem, you can do a shallow clone that omits all the history and just > grabs the branch of interest. Git is a bit more link efficient than > subversion, which is helpful. Git also has ways to help you share one local > repo across checked out versions, which can also help if you have to track > multiple branches. > Folks in that position might want to consider making the switch (for a given repo -- src; ports; doc) in two stages over a period of time: the first, to get an initial copy, then (the first of a series of) incremental updates. The duration of the first need not be especially critical. Of course, this presumes adequate local storage space. (I am currently testing my approach, using cgit-beta.freebsd.org for each of the three repos; the approach I am using is described in http://www.catwhisker.org/~david/FreeBSD/repo-sync.html, in case that's of use. Please note that I am actually using both svn & git, relying on svn for now, as it is the Source of Truth.) Peace, david -- David H. Wolfskill da...@catwhisker.org Trump's continuing malfeasance is costing lives -- and 72M voted for this??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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_wmi noisy without EC
On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
> On 2020-11-17 15:29, Yuri Pankov wrote:
> > On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> >> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> >> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> >> I have started seeing the following on boot since some time:
> >> >>
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >>
> >> >> Likely following this commit:
> >> >>
> >> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> >> Author: Vladimir Kondratyev
> >> >> Date: Sat Oct 31 22:19:39 2020 +
> >> >>
> >> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >> >>
> >> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> >> looks like "something is broken" when first noticed. I wonder if we
> >> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> >> >
> >> > Following patch should ignore missing EC like Linux does. Could you
> >> > test it?
> >> >
> >> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
> >> > b/sys/dev/acpi_support/acpi_wmi.c
> >> > index 379cfd1705f1..efae96cdcc9a 100644
> >> > --- a/sys/dev/acpi_support/acpi_wmi.c
> >> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> >> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> >> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> >> > == NULL)
> >> > device_printf(dev, "cannot find EC device\n");
> >> > - else if (ACPI_FAILURE((status =
> >> > AcpiInstallNotifyHandler(sc->wmi_handle,
> >> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> >> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> >> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> >> > AcpiFormatException(status));
> >> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> >> > ACPI_PHYSICAL_ADDRESS address,
> >> > return (AE_BAD_PARAMETER);
> >> > if (address + (width / 8) - 1 > 0xFF)
> >> > return (AE_BAD_ADDRESS);
> >> > + if (sc->ec_dev == NULL)
> >> > + return (AE_NOT_FOUND);
> >> > if (function == ACPI_READ)
> >> > *value = 0;
> >> > ec_addr = address;
> >>
> >> @#@##! Web client ate all the tabs.
> >>
> >> Patch is in attachment.
> >
> > Output changed, though it's still somewhat noisy -- I guess there
> > isn't a way to NOT report the device that we are not going to attach
> > to, or do that e.g. only for verbose boot?
> >
> > acpi_wmi0: on acpi0
> > acpi_wmi0: cannot find EC device
> > acpi_wmi0: Embedded MOF found
> > ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
> > object (Buffer) (20201113/nsarguments-361)
> > acpi_wmi1: on acpi0
> > acpi_wmi1: cannot find EC device
> > acpi_wmi2: on acpi0
> > acpi_wmi2: cannot find EC device
> > acpi_wmi3: on acpi0
> > acpi_wmi3: cannot find EC device
>
> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
> in OpRegion handler.
> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
> successfully attached to 4 nodes.
Oh great, I misunderstood then. And indeed, sysctl -b dev.acpi_wmi.0.bmof |
bmf2mof provides some interesting information. All other 3 instances do not
though. In any case, it seems to work now.
> Verbosity can be reduced with attached patch if current level is too
> high for you.
Works for me both ways, I simply had the wrong impression that if we don't have
EC, we can't attach at all.
___
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: in -current is svn still canonical?
On Tue, Nov 17, 2020 at 09:25:32AM +, Thomas Mueller wrote: > from Warner Losh and my last message: > > > > Thanks for the information, but if you feel the need to send me a > > > not-quite-CC, please don't send me the multipart/alternative version when > > > you send the plain-text version to the list. > > > > I hate multipart/alternative! > > > I must apologize. Sadly, I use gmail, so I have no control over how it > > decides to encode things, sadly. I've tried in the past, and alas, nothing > > I've tried works for any length of time. Please forgive me whatever > > unspeakable MIME atrocities it sends on my behalf. I've removed you from > > the cc line in the hopes that the FreeBSD mail server cleans things up to > > be more to your liking. > > The message on the list had only the plain-text part. Either you sent it > differently, or the list server stripped the HTML attachment. > The mailing list software is set to strip all non-plain-text content. This is why you sometimes see mails with no body content. The sender sent a mail which only had a HTML part and it was stripped, and without an alternate MIME part there was nothing to send. Regards, Gary ___ 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_wmi noisy without EC
On 2020-11-17 15:29, Yuri Pankov wrote:
On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> On 2020-11-17 03:00, Yuri Pankov wrote:
>> I have started seeing the following on boot since some time:
>>
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>>
>> Likely following this commit:
>>
>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>> Author: Vladimir Kondratyev
>> Date: Sat Oct 31 22:19:39 2020 +
>>
>> acpi_wmi(4): Add ACPI_PNP_INFO
>>
>> While the reason is obvious -- there's no EC in this system (Gigabyte
>> X299X AORUS MASTER desktop motherboard), at least searching the
>> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
>> looks like "something is broken" when first noticed. I wonder if we
>> could/should handle this gracefully -- no EC, do nothing, simply exit?
>
> Following patch should ignore missing EC like Linux does. Could you
> test it?
>
> diff --git a/sys/dev/acpi_support/acpi_wmi.c
> b/sys/dev/acpi_support/acpi_wmi.c
> index 379cfd1705f1..efae96cdcc9a 100644
> --- a/sys/dev/acpi_support/acpi_wmi.c
> +++ b/sys/dev/acpi_support/acpi_wmi.c
> @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> == NULL)
> device_printf(dev, "cannot find EC device\n");
> - else if (ACPI_FAILURE((status =
> AcpiInstallNotifyHandler(sc->wmi_handle,
> + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> AcpiFormatException(status));
> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> ACPI_PHYSICAL_ADDRESS address,
> return (AE_BAD_PARAMETER);
> if (address + (width / 8) - 1 > 0xFF)
> return (AE_BAD_ADDRESS);
> + if (sc->ec_dev == NULL)
> + return (AE_NOT_FOUND);
> if (function == ACPI_READ)
> *value = 0;
> ec_addr = address;
@#@##! Web client ate all the tabs.
Patch is in attachment.
Output changed, though it's still somewhat noisy -- I guess there
isn't a way to NOT report the device that we are not going to attach
to, or do that e.g. only for verbose boot?
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
object (Buffer) (20201113/nsarguments-361)
acpi_wmi1: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: on acpi0
acpi_wmi3: cannot find EC device
acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
in OpRegion handler.
WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
successfully attached to 4 nodes.
Verbosity can be reduced with attached patch if current level is too
high for you.
--
WBR
Vladimir Kondratyevdiff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..1fddcd4f3637 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -245,8 +245,9 @@ acpi_wmi_attach(device_t dev)
/* XXX Only works with one EC, but nearly all systems only have one. */
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
- device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
+ ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
+ "cannot find EC device\n");
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
AcpiFormatException(status));
@@ -701,6 +702,8 @@ acpi_wmi_ec_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
___
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_wmi noisy without EC
On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> I have started seeing the following on boot since some time:
> >>
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >>
> >> Likely following this commit:
> >>
> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> Author: Vladimir Kondratyev
> >> Date: Sat Oct 31 22:19:39 2020 +
> >>
> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >>
> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> looks like "something is broken" when first noticed. I wonder if we
> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> >
> > Following patch should ignore missing EC like Linux does. Could you
> > test it?
> >
> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
> > b/sys/dev/acpi_support/acpi_wmi.c
> > index 379cfd1705f1..efae96cdcc9a 100644
> > --- a/sys/dev/acpi_support/acpi_wmi.c
> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> > == NULL)
> > device_printf(dev, "cannot find EC device\n");
> > - else if (ACPI_FAILURE((status =
> > AcpiInstallNotifyHandler(sc->wmi_handle,
> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> > AcpiFormatException(status));
> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> > ACPI_PHYSICAL_ADDRESS address,
> > return (AE_BAD_PARAMETER);
> > if (address + (width / 8) - 1 > 0xFF)
> > return (AE_BAD_ADDRESS);
> > + if (sc->ec_dev == NULL)
> > + return (AE_NOT_FOUND);
> > if (function == ACPI_READ)
> > *value = 0;
> > ec_addr = address;
>
> @#@##! Web client ate all the tabs.
>
> Patch is in attachment.
Output changed, though it's still somewhat noisy -- I guess there isn't a way
to NOT report the device that we are not going to attach to, or do that e.g.
only for verbose boot?
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI object
(Buffer) (20201113/nsarguments-361)
acpi_wmi1: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: on acpi0
acpi_wmi3: cannot find EC device
___
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: in -current is svn still canonical?
On Mon, Nov 16, 2020 at 10:32:38PM -0700, Warner Losh wrote: > ... > However, when you make the switch to git (either due to the flag day and > tracking -current, or jumping from svn on a stable branch), there's no tool > to convert the subversion checked out tree to a git tree. The needed > information needed to create the git tree isn't easily available from the > subversion checkout, so you'll need to do a git clone. If bandwidth is a > problem, you can do a shallow clone that omits all the history and just > grabs the branch of interest. Git is a bit more link efficient than > subversion, which is helpful. Git also has ways to help you share one local > repo across checked out versions, which can also help if you have to track > multiple branches. > Folks in that position might want to consider making the switch (for a given repo -- src; ports; doc) in two stages over a period of time: the first, to get an initial copy, then (the first of a series of) incremental updates. The duration of the first need not be especially critical. Of course, this presumes adequate local storage space. (I am currently testing my approach, using cgit-beta.freebsd.org for each of the three repos; the approach I am using is described in http://www.catwhisker.org/~david/FreeBSD/repo-sync.html, in case that's of use. Please note that I am actually using both svn & git, relying on svn for now, as it is the Source of Truth.) Peace, david -- David H. Wolfskill da...@catwhisker.org Trump's continuing malfeasance is costing lives -- and 72M voted for this??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: in -current is svn still canonical?
On Tue, 17 Nov 2020 02:48:32 +, "Thomas Mueller" wrote: > from tech-lists: > > > As subject - is svn still canonical for -current or is it git now? > > If it's not git now, when roughly is the intended switch? > > I recently updated FreeBSD doc, ports, src (current), and src12 (12-stable) > using svn (not svnup or svnlite). > > But I read some time before that, FreeBSD current source would go on git, > while other src trees (non-current), ports and doc would stay with svn for > the time being, until git on current src is further tested and stabilized. > .. Can this be put up in a wiki page as well as in each UPDATING, referencing the wiki page? something like src - current dec 2020 now svn up /usr/src... git svn cleanup git ... [ other svn-git... src - stable may 2021 dec 2020 svn up /usr/ports src -releasejuly 2021 ports dec 2021 doc dec 2021 and an additional column as to when svn will become obsolete for each respository? and maybe an additional wiki page with all the svn > git translations one can reasonably presume to be of use ? ___ 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: in -current is svn still canonical?
from Warner Losh and my last message: > > Thanks for the information, but if you feel the need to send me a > > not-quite-CC, please don't send me the multipart/alternative version when > > you send the plain-text version to the list. > > I hate multipart/alternative! > I must apologize. Sadly, I use gmail, so I have no control over how it > decides to encode things, sadly. I've tried in the past, and alas, nothing > I've tried works for any length of time. Please forgive me whatever > unspeakable MIME atrocities it sends on my behalf. I've removed you from > the cc line in the hopes that the FreeBSD mail server cleans things up to > be more to your liking. The message on the list had only the plain-text part. Either you sent it differently, or the list server stripped the HTML attachment. > > When git becomes the source of truth on FreeBSD after the flag day, will > > it be necessary to git-clone the whole tree from scratch, or will there be > > a conversion tool to switch the svn download to proper git format? > For the supported stable branches, you'll be able to download via > subversion and switch over at any time before the end of project support > for the branch. I suppose this applies only to the current stable branches (11 and 12) but not to future stable branches, beginning with 13? > However, when you make the switch to git (either due to the flag day and > tracking -current, or jumping from svn on a stable branch), there's no tool > to convert the subversion checked out tree to a git tree. The needed > information needed to create the git tree isn't easily available from the > subversion checkout, so you'll need to do a git clone. If bandwidth is a > problem, you can do a shallow clone that omits all the history and just > grabs the branch of interest. Git is a bit more link efficient than > subversion, which is helpful. Git also has ways to help you share one local > repo across checked out versions, which can also help if you have to track > multiple branches. I suppose I would then git-clone the current/13 src tree separately and delete the svn version. > > The doc tree is much smaller than the src tree, while the ports tree is > > much bigger than the src tree. Is that the reason for the few-months-long > > lag switching the ports trree to git? > There's a couple of things that make it trickier. The ports tree does > quarterly branches. So there's a window around the quarterly branch when > it's easiest to make the switch. In addition, the character of the files in > the ports tree differs from src. Unlike subversion, git infers copies, > moves, etc. The mostly similar nature of the ports tree is likely to cause > git grief when ports are copied, resurrected from the attic, etc. The ports > folks are still figuring out how to best use git to track the history they > need to track without creating undue issues. It's not clear if that will > all be sorted out before the next window in December, or if they will have > to defer until March. This is why I hedged a bit as to the exact time, > since it's not been nailed down yet. So it's not so much the size, as the > difference in makeup and character between the two trees. The doc tree is, > as you point out, much smaller, less active and its needs are more modest > and largely mirror the src tree, so it can be done quickly at any time. > Warner Now I see the reason for timing the switch of the ports tree from svn to git. I never tracked the quarterly ports tree, just as I never followed the quarterly (NetBSD) pkgsrc, only the current version. NetBSD is readying to switch src trees and pkgsrc from cvs to hg (Mercurial), but it takes some time to prepare and not mess things up. I am under the impression that they intend to switch everything over at once when ready. Pkgsrc has both current and quarterly, so maybe they will have issues similar to FreeBSD ports on switching to hg. I have git installed on both FreeBSD and NetBSD, but no Mercurial. As far as I can see, git repositories greatly outnumber mercurial repositories. Tom ___ 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_wmi noisy without EC
On 2020-11-17 10:57, Vladimir Kondratyev wrote:
On 2020-11-17 03:00, Yuri Pankov wrote:
I have started seeing the following on boot since some time:
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
acpi_wmi(4): Add ACPI_PNP_INFO
While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed. I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?
Following patch should ignore missing EC like Linux does. Could you
test it?
diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler -
%s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
@#@##! Web client ate all the tabs.
Patch is in attachment.
--
WBR
Vladimir Kondratyevdiff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
___
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_wmi noisy without EC
On 2020-11-17 03:00, Yuri Pankov wrote:
I have started seeing the following on boot since some time:
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
acpi_wmi(4): Add ACPI_PNP_INFO
While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed. I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?
Following patch should ignore missing EC like Linux does. Could you test
it?
diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler -
%s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
--
WBR
Vladimir Kondratyev
___
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"
