Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 2018-11-24 at 18:33 +0100, Riccardo Mottola wrote: > On 11/21/18 6:57 AM, David H. Gutteridge wrote: > > I have access to a Toshiba Satellite Pro that's a roughly similar > > vintage to your T43; I'll see how it behaves when I have a chance. > > That would be interesting. Try it as-is, possibly with 8.0 and HEAD. If > it works fine, then try to disable audio, video and see if it helps. > > Of course I want to pinpoint which driver(s) cause me problems, so at > least I can open the correct bug (and "bug" some kind soul to fix it). > Right now the information is a little more than "it doesn't work for me > on several computers". I have good news and bad news, and it's the same thing: I was hoping the Toshiba laptop had more parity with one of your laptops in terms of hardware, but unfortunately, it's a consumer model, an M40X with an Intel Dothan CPU, integrated 915GM graphics, a RealTek Ethernet card, Atheros WiFi, etc. It's similar to the X110: it has a bit of trouble on 8.0_STABLE resuming with the i915 DRM driver, but that's addressed in 8.99.26, where it resumes as reliably as my T420. (With the same caveats about restoring hardware state that are being discussed elsewhere in this thread: I haven't tried that patch on it yet.) Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Thu, 2018-11-29 at 15:15 +0900, Masanobu SAITOH wrote: > On 2018/11/28 22:12, SAITOH Masanobu wrote: > > On 2018/11/28 14:18, Masanobu SAITOH wrote: > > > The diff says we should save/restore MSI table. > > > We also should save/restore some other registers. > > > > > > Give me one or two days to resolve the problem. > > > > Please try the following diff: > > > > http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif > > > > Even if I use this change with Thinkpad X220, it doesn't recover from > > suspend... > > But, my X61 survived from suspend with this patch! With that patch, networking devices now function reliably on my T420 after wakeup. That's a big improvement, thanks! Dave
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: lib/libc/sys/t_sendmmsg:sendmmsg_basic The above test failed in each of the last 5 test runs, and passed in at least 25 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2018.11.28.19.06.54 jmcneill src/sys/dev/pci/if_enavar.h,v 1.5 2018.11.28.19.07.49 jmcneill src/sys/dev/pci/if_ena.c,v 1.8 2018.11.28.19.13.15 ryo src/sys/arch/aarch64/aarch64/db_machdep.c,v 1.11 2018.11.28.19.15.32 jmcneill src/sys/external/bsd/ena-com/ena_plat.h,v 1.4 2018.11.28.19.36.43 mlelstv src/sys/kern/kern_synch.c,v 1.320 2018.11.28.19.46.22 mlelstv src/sys/kern/kern_synch.c,v 1.321 2018.11.28.19.46.22 mlelstv src/sys/sys/lwp.h,v 1.180 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.11.html#2018.11.28.19.46.22
daily CVS update output
Updating src tree: P src/bin/pax/gen_subs.c P src/bin/pax/tar.c P src/doc/3RDPARTY P src/lib/libedit/parse.c P src/lib/libnvmm/libnvmm.c P src/lib/libnvmm/nvmm.h P src/sys/arch/arm/sunxi/sunxi_ccu.c P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/sparc64/sparc64/pmap.c P src/sys/compat/linux/common/linux_misc_notalpha.c P src/sys/dev/pci/pcidevs P src/sys/dev/pci/pcidevs.h P src/sys/dev/pci/pcidevs_data.h P src/sys/dev/pci/pucdata.c P src/sys/dev/rasops/rasops.c P src/sys/dev/usb/if_run.c P src/sys/dev/wscons/wsdisplay.c P src/sys/kern/kern_exit.c P src/sys/kern/kern_sig.c P src/sys/kern/kern_time.c P src/sys/kern/sys_ptrace_common.c P src/sys/netinet/if_arp.c P src/sys/netinet/in.c P src/sys/netinet/in_var.h P src/sys/netinet6/in6.c P src/sys/netinet6/ip6_output.c P src/sys/netinet6/ip6_var.h P src/sys/netinet6/nd6_nbr.c P src/tests/bin/tar/t_tar.sh Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52444358 Nov 30 03:03 ls-lRA.gz
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Thu, Nov 29, 2018 at 03:15:31PM +0900, Masanobu SAITOH wrote: > On 2018/11/28 22:12, SAITOH Masanobu wrote: > > But, my X61 survived from suspend with this patch! > My fujitsu lifebook S904 came back from suspend with this patch too! Thank you very much for this. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 29/11/2018 18:16, Manuel Bouyer wrote: Do you have drives connected to this controller ? If so I can probably come up with a patch this week-end. The SAS3 has a sighly different interface, but from looking at the OpenBSD driver it's all in a single function. I've got access to a spare LSI SAS3 HBA at work and have some SAS drives I could test with. I can get the exact PCI ids to see if its supported by the OpenBSD driver. Mike
Re: Running NetBSD-current in PV mode under Xen
On Thu, Nov 29, 2018 at 08:05:28PM +, Chavdar Ivanov wrote: > Hi, > > I was trying to respond to and old pr of mine - > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=47486 - and > went through the installation of XCP-NG (after I found out about the > existence of this project and that Citrix has apparently changed some > licensing conditions after XenServer 7.2). Latest -current works in > HVM mode (after switching the network adapter emulation to e1000, > modulo the weird mouse behaviour under X, but I am not bothered about > it). If I switch the system to PV mode following the method described > in the above pr, the machine apparently starts and in some 10-15 > seconds stops, without showing any console. I checked through the > XCP-NG log files, but could not iodentify anythin obvious (I may have > missed stuff - they are copious). > > I seem to recall a relatively recent discussion about NetBSD not > working any more under AWS PV - some parameter needed to be modified, > but could not find a reference; could that be related? probably, unless you're using a Xen kernel from pkgsrc you have to boot Xen with pv-linear-pt=true -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Running NetBSD-current in PV mode under Xen
Hi, I was trying to respond to and old pr of mine - https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=47486 - and went through the installation of XCP-NG (after I found out about the existence of this project and that Citrix has apparently changed some licensing conditions after XenServer 7.2). Latest -current works in HVM mode (after switching the network adapter emulation to e1000, modulo the weird mouse behaviour under X, but I am not bothered about it). If I switch the system to PV mode following the method described in the above pr, the machine apparently starts and in some 10-15 seconds stops, without showing any console. I checked through the XCP-NG log files, but could not iodentify anythin obvious (I may have missed stuff - they are copious). I seem to recall a relatively recent discussion about NetBSD not working any more under AWS PV - some parameter needed to be modified, but could not find a reference; could that be related? --
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Thu, Nov 29, 2018 at 03:56:37PM +, Stephen Borrill wrote: > On Mon, 26 Nov 2018, Stephen Borrill wrote: > > Thanks Manuel! > > > > [ 1.048805] mfii0 at pci11 dev 0 function 0: "RAID 930-8i 2GB > > Flash", firmware 50.3.0-1075, 2048MB cache > > [ 1.048805] mfii0: interrupting at ioapic4 pin 2 > > [ 1.048805] scsibus0 at mfii0: 64 targets, 8 luns per target > > [ 2.161214] scsibus0: waiting 2 seconds for devices to settle... > > [ 2.161214] mfii0: physical disk inserted id 18 enclosure 134 > > [ 2.161214] mfii0: physical disk inserted id 19 enclosure 134 > > [ 2.161214] mfii0: physical disk inserted id 20 enclosure 134 > > [ 2.161214] mfii0: physical disk inserted id 21 enclosure 134 > > [ 4.163289] sd0 at scsibus0 target 0 lun 0: > 930-8i-2GB, 5.03> disk fixed > > [ 4.163289] sd0: fabricating a geometry > > [ 4.163289] sd0: 2234 GB, 2287864 cyl, 64 head, 32 sec, 512 > > bytes/sect x 4685545472 sectors > > [ 4.163289] sd0: fabricating a geometry > > [ 4.163289] sd0: tagged queueing > > [ 4.163289] sd1 at scsibus0 target 1 lun 0: > 930-8i-2GB, 5.03> disk fixed > > [ 4.163289] sd1: fabricating a geometry > > [ 4.163289] sd1: 744 GB, 761985 cyl, 64 head, 32 sec, 512 bytes/sect > > x 1560545280 sectors > > [ 4.163289] sd1: fabricating a geometry > > [ 4.163289] sd1: tagged queueing > > [32.192359] mfii0: critical limit on 'mfii0 BBU state' > > [32.192359] mfii0: normal state on 'mfii0:0' (online) > > [32.192359] mfii0: normal state on 'mfii0:1' (online) > > The other missing driver is handled by mpii in OpenBSD (SAS3408). Our mpii > doesn't yet support any SAS3 cards. > [ 1.048805] vendor 1000 product 00af (SAS mass storage, revision 0x01) > at pci4 dev 0 function 0 not configured Do you have drives connected to this controller ? If so I can probably come up with a patch this week-end. The SAS3 has a sighly different interface, but from looking at the OpenBSD driver it's all in a single function. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: lib/libc/sys/t_sendmmsg:sendmmsg_basic The above test failed in each of the last 3 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2018.11.28.19.06.54 jmcneill src/sys/dev/pci/if_enavar.h,v 1.5 2018.11.28.19.07.49 jmcneill src/sys/dev/pci/if_ena.c,v 1.8 2018.11.28.19.13.15 ryo src/sys/arch/aarch64/aarch64/db_machdep.c,v 1.11 2018.11.28.19.15.32 jmcneill src/sys/external/bsd/ena-com/ena_plat.h,v 1.4 2018.11.28.19.36.43 mlelstv src/sys/kern/kern_synch.c,v 1.320 2018.11.28.19.46.22 mlelstv src/sys/kern/kern_synch.c,v 1.321 2018.11.28.19.46.22 mlelstv src/sys/sys/lwp.h,v 1.180 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.11.html#2018.11.28.19.46.22
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: kernel/t_sysv:msg net/net/t_unix:sockaddr_un_local_peereid The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2018.11.28.19.06.54 jmcneill src/sys/dev/pci/if_enavar.h,v 1.5 2018.11.28.19.07.49 jmcneill src/sys/dev/pci/if_ena.c,v 1.8 2018.11.28.19.13.15 ryo src/sys/arch/aarch64/aarch64/db_machdep.c,v 1.11 2018.11.28.19.15.32 jmcneill src/sys/external/bsd/ena-com/ena_plat.h,v 1.4 2018.11.28.19.36.43 mlelstv src/sys/kern/kern_synch.c,v 1.320 2018.11.28.19.46.22 mlelstv src/sys/kern/kern_synch.c,v 1.321 2018.11.28.19.46.22 mlelstv src/sys/sys/lwp.h,v 1.180 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.11.html#2018.11.28.19.46.22
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Mon, 26 Nov 2018, Stephen Borrill wrote: Thanks Manuel! [ 1.048805] mfii0 at pci11 dev 0 function 0: "RAID 930-8i 2GB Flash", firmware 50.3.0-1075, 2048MB cache [ 1.048805] mfii0: interrupting at ioapic4 pin 2 [ 1.048805] scsibus0 at mfii0: 64 targets, 8 luns per target [ 2.161214] scsibus0: waiting 2 seconds for devices to settle... [ 2.161214] mfii0: physical disk inserted id 18 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 19 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 20 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 21 enclosure 134 [ 4.163289] sd0 at scsibus0 target 0 lun 0: 5.03> disk fixed [ 4.163289] sd0: fabricating a geometry [ 4.163289] sd0: 2234 GB, 2287864 cyl, 64 head, 32 sec, 512 bytes/sect x 4685545472 sectors [ 4.163289] sd0: fabricating a geometry [ 4.163289] sd0: tagged queueing [ 4.163289] sd1 at scsibus0 target 1 lun 0: 5.03> disk fixed [ 4.163289] sd1: fabricating a geometry [ 4.163289] sd1: 744 GB, 761985 cyl, 64 head, 32 sec, 512 bytes/sect x 1560545280 sectors [ 4.163289] sd1: fabricating a geometry [ 4.163289] sd1: tagged queueing [32.192359] mfii0: critical limit on 'mfii0 BBU state' [32.192359] mfii0: normal state on 'mfii0:0' (online) [32.192359] mfii0: normal state on 'mfii0:1' (online) The other missing driver is handled by mpii in OpenBSD (SAS3408). Our mpii doesn't yet support any SAS3 cards. [ 1.048805] vendor 1000 product 00af (SAS mass storage, revision 0x01) at pci4 dev 0 function 0 not configured -- Stephen
