Re: suspend-to-RAM intel-x86 issues and tests
On Tue, Oct 09, 2018 at 05:32:57PM +, m...@netbsd.org wrote: > Invalid TSS (this might be the right one) It's probably not! it's probably "invalid TSS" :-)
Re: suspend-to-RAM intel-x86 issues and tests
On Wed, Sep 26, 2018 at 11:33:49PM +0200, Riccardo Mottola wrote: > T43 "new": does go to sleep, but does not resume (while stock 8 does). Better strategy: since we you have a machine that worked at some point, you should try to bisect it. it's a somewhat tedious process of testing ~13 different kernels, but it is easier to do. 1. do a full clone of the netbsd git mirror: git clone https://github.com/netbsd/src git checkout 219a1cc39c1610407f456c7a08a21d6e951cfb1c # netbsd-8 branch Do a build of this and confirm it works. git checkout trunk git bisect start git bisect bad HEAD # HEAD doesn't work git bisect good 219a1cc39c1610407f456c7a08a21d6e951cfb1c Now, you are bisecting, you need to do a clean build of tools and kernel most of the time. use ./build.sh ... -O ~/obj tools kernel=GENERIC and delete ~/obj between attempts. If a change can suspend, use 'git bisect good'. If it fails, 'git bisect bad' If it fails to build, use 'git bisect skip' Personally my first 2-3 attempts at bisect I confused something and got to the wrong commit, but when it worked, it really did pinpoint the problem very efficiently.
Re: suspend-to-RAM intel-x86 issues and tests
On Tue, Oct 09, 2018 at 01:12:31AM +0200, Riccardo Mottola wrote: > yet on sleep it crashes. I was able to catch the error. > I add that even if it says "flushing disk" at the next reboot, the > filesystem is dirty. > That's expected: I think we write a bit to the filesystem at mount and only un-write it on a clean unmount. Flushing to disk is to clear anything in RAM to disk, but it isn't an unmount (reboot isn't expected!) But your filesystem should be unaffected.
Re: suspend-to-RAM intel-x86 issues and tests
On Tue, Oct 09, 2018 at 01:12:31AM +0200, Riccardo Mottola wrote: > acpi0: entering state S3 > flushing disk caches: 16 done > fatal protection fault in supervisor mode > trap type 4 code 0 eip 0xc0135ea3 cd 0x8 eflags 0x210046 cr2 0xdac2b0c4 > ilevel 0x8 esp 0xc1210c80 > curlwp 0xc36422c0 pid 658 lid 1 lowest kstack 0xdb8702c0 > panic: trap > cpu0 Begin traceback... > vpanic (.) at netbsd:vpanic+0x132 > snprintf() at netbsd:snprintf > trap_tss() at netbsd:trap_tss > --- trap via task gate --- > netbsd: cpu_info_primary: Hey, useful info! cpu_info_primary isn't a function though, which is weird. eip 0xc0135ea3 is also an interesting thing to note and we should search by hand if it is in a function too what does gdb /path/to/netbsd gdb> disas 0xc0135ea3 say? osdev wiki says: Invalid TSS (this might be the right one) An Invalid TSS exception occurs when an invalid segment selector is referenced as part of a task which, or as a result of a control transfer through a gate descriptor, which results in an invalid stack-segment reference using an SS selector in the TSS. When the exception occurred before loading the segment selectors from the TSS, the saved instruction pointer points to the instruction which caused the exception. Otherwise, and this is more common, it points to the first instruction in the new task. Error code: The Invalid TSS exception sets an error code, which is a selector index. so that says it's expected that the eip won't be useful. I'm currently trying to see (with my limited x86 clue) what code is touching tss. does anyone have a better clue how to debug this?
uchcom USB-serial
I purchased a couple of USB-serial adapters. Unfortunately, given the lack of detail in the descriptions, they turned out to be uchcom0: QinHeng Electronics (0x1a86) USB2.0-Ser! (0x7523), rev 1.10/2.54 According to https://nxr.netbsd.org/xref/src/sys/dev/usb/uchcom.c#40 this is "the worst USB-serial chip in the world." Do these work at all? (Get "tip: link down", then change to a uplcom0: Prolific Technology Inc. and all is well.) Cheers, Patrick
RE: libgcc.a vs libgcc_s.so
Looks like it might be C++ related: http://lists.gnu.org/archive/html/libtool/2016-06/msg7.html suggestion later in the thread was to use the libtool script from pkgsrc instead of the one built by autoconf.
