Re: Cross-compiling Haiku from NetBSD?
> Hi Thomas, > Thomas Mueller wrote: > > You mention Haiku. Did you ever attempt to cross-compile Haiku from NetBSD? > no, I never did cross.compile, I only installed it. Also, it never worked > reliably and stopped booting. > I see now a new CD is out, I will try it when I have a boring evening. > Right now I'd love some NetBSD bugs squeezed out :) > Riccardo > PS: Video on the Intel chipset was one of the main issues on my system > (causing boot hangs and needing to disable it for VESA), a non usable touchpad > did not help either I wrote (usibg dd) Haiku R1A4 to a 4 GB USB stick. It ran on one computer, but consistently hung on boot on the other computer: I would see the colorful letters HAIKU, but no further. I was favorably impressed, especially when I started with low expectations. Tom
Re: current - latest suspend tests T43 - T30 - R51
Yes, they are ps/2. The pckbc1 is the i8042 keyboard controller device which handles both keyboard and mouse for ps/2. The trackpoint should show up as a separate pointing device but it seems a lot of people are not seeing it show up, there must be something in the driver that is stopping it from being identified. I will have a look at that and see if I can work something out. Unfortunately, I don't have a trackpoint so it may take a bit of fumbling to get this right. - Original Message - From: "Riccardo Mottola" To:"Manuel Bouyer" Cc: Sent:Tue, 4 Dec 2018 22:59:45 +0100 Subject:Re: current - latest suspend tests T43 - T30 - R51 Hi Manuel Manuel Bouyer wrote: >> - goes correctly to sleep >> - comes up again >> - with bge0 working >> - TouchPad and TrackPoint are not working after resume (even if sleep was > Are these PS/2, USB or i2c ? I suppose they are PS/2, what is pckbc1 ? pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 5.9 pms0: Passthrough, Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 I see only the TouchPad but not the "stick", I wonder if they show up as only one device. I attach the full dmesg when running 8.0 Riccardo
daily CVS update output
Updating src tree: P src/bin/sh/sh.1 P src/bin/sh/var.c P src/bin/sh/var.h P src/distrib/sets/lists/tests/mi P src/doc/TODO.sanitizers P src/share/man/man4/mpii.4 P src/sys/arch/x86/x86/cpu.c P src/sys/arch/x86/x86/intr.c P src/sys/dev/pci/ahcisata_pci.c P src/sys/dev/pci/mpii.c P src/sys/dev/pckbport/synaptics.c P src/sys/dev/rasops/rasops.c P src/sys/dev/rasops/rasops1.c P src/sys/dev/rasops/rasops15.c P src/sys/dev/rasops/rasops2.c P src/sys/dev/rasops/rasops24.c P src/sys/dev/rasops/rasops4.c P src/sys/dev/rasops/rasops8.c P src/sys/dev/wscons/wsdisplayvar.h P src/sys/netinet6/nd6_nbr.c P src/sys/sys/cdefs.h P src/tests/bin/sh/Makefile U src/tests/bin/sh/t_builtins.sh P src/tests/bin/sh/dotcmd/scoped_command U src/tests/lib/libcurses/check_files/background1.chk P src/usr.bin/pkill/pkill.1 P src/usr.sbin/postinstall/postinstall Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): U doc/CHANGES-7.3 P sys/arch/amd64/amd64/machdep.c Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.1 P sys/arch/x86/include/specialreg.h P sys/arch/x86/x86/cpu_topology.c P sys/dev/ld.c P sys/dev/mii/inbmphyreg.h P sys/dev/mii/miidevs P sys/dev/mii/miidevs.h P sys/dev/mii/miidevs_data.h P sys/dev/pci/if_wm.c P sys/dev/pci/if_wmreg.h P sys/dev/pci/pci_subr.c P sys/dev/pci/pcidevs P sys/dev/pci/pcidevs.h P sys/dev/pci/pcidevs_data.h P sys/dev/pci/pcireg.h P usr.sbin/acpitools/acpidump/acpi.c P usr.sbin/acpitools/acpidump/acpidump.8 P usr.sbin/cpuctl/arch/i386.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52439183 Dec 5 03:09 ls-lRA.gz
Re: current - latest suspend tests T43 - T30 - R51
Hi Brett, Brett Lymn wrote: Yes, they are ps/2. The pckbc1 is the i8042 keyboard controller device which handles both keyboard and mouse for ps/2. The trackpoint should show up as a separate pointing device but it seems a lot of people are not seeing it show up, there must be something in the driver that is stopping it from being identified. I will have a look at that and see if I can work something out. Unfortunately, I don't have a trackpoint so it may take a bit of fumbling to get this right. ready to test stuff.. debug, run debug kernel (although I don't yet b uild kernels on this machine, I think it has enough power and disk space to do, in case) The original point is: the pointers are dead when resuming from sleep, also the touchpad which "shows up" Riccardo PS: BSD rocks.
Re: current - latest suspend tests T43 - T30 - R51
On Tue, Dec 04, 2018 at 10:59:45PM +0100, Riccardo Mottola wrote: > Hi Manuel > > Manuel Bouyer wrote: > > > - goes correctly to sleep > > > - comes up again > > > - with bge0 working > > > - TouchPad and TrackPoint are not working after resume (even if sleep > > > was > > Are these PS/2, USB or i2c ? > > I suppose they are PS/2, what is pckbc1 ? Yes, it's PS/2 > > pckbd0 at pckbc1 (kbd slot) > pckbc1: using irq 1 for kbd slot > wskbd0 at pckbd0: console keyboard > pms0 at pckbc1 (aux slot) > pms0: Synaptics touchpad version 5.9 > pms0: Passthrough, Palm detect, Multi-finger > pckbc1: using irq 12 for aux slot > wsmouse0 at pms0 mux 0 > > > I see only the TouchPad but not the "stick", I wonder if they show up as > only one device. They probably do -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: issues with touchpad after update
Hi guys! I just updated and rebuilt the kernel to current. It is much better now. Essentially, without using two fingers, it works fine without the need of any tweaks. Scrolling however is almost unusable, very jerky, speeds up and moves around, but really "happens" only when I put two fingers on it. It should only happen when you put two fingers on the touchpad. If you are seeing cursor movements when you have two fingers on the touchpad then you need to increase: hw.synaptics.finger_scroll-hysteresis No, the latest version doesn't jump, but it scrolls very badly, e.g. I just move two fingers slightly and I end at the bottom or the top of the scroll port, sometimes with a couple of jumps forth and back. The capabilities you see are decoded from queries made to the touchpad. On initialisation the driver asks the touchpad what it is capable of, what you see in dmesg is what the touchpad says it can do. Indeed it "works" just not coveniently, so the feature is indeed implemented. Non-multi-touch would jump badly with two fingers. Perhaps, as you write, it is sending to many scroll events or the scroll amount is too big? I don't have a scollbar so I cannot test that but I am thinking that I need to rework the handling of the two finger scroll, it is very sensitive - I am thinking I should change the scaling on it to be a divisor instead of a multiplier so that large movements don't produce too many scroll events - the X server really doesn't like lots of scroll events. It is something which worked only with the special synaptics driver, not the standard windows one, the right area of the touchbar has a bar drawn on and using that scrolled without the need of two fingers. I think it is just a software feature, maybe not even convenient - I am not accustomed to it because e.g. ThinkPads do not have it. Riccardo
Re: current - latest suspend tests T43 - T30 - R51
Hi Manuel Manuel Bouyer wrote: - goes correctly to sleep - comes up again - with bge0 working - TouchPad and TrackPoint are not working after resume (even if sleep was Are these PS/2, USB or i2c ? I suppose they are PS/2, what is pckbc1 ? pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 5.9 pms0: Passthrough, Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 I see only the TouchPad but not the "stick", I wonder if they show up as only one device. I attach the full dmesg when running 8.0 Riccardo Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.0 (GENERIC) #0: Tue Jul 17 14:59:51 UTC 2018 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/i386/compile/GENERIC total memory = 2046 MB avail memory = 1993 MB rnd: seeded with 128 bits timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 IBM 2669Z3V (ThinkPad T43) mainbus0 (root) ACPI: RSDP 0x000F6C10 24 (v02 IBM ) ACPI: XSDT 0x7FEE6FF2 5C (v01 IBMTP-1Y1230 LTP ) ACPI: FACP 0x7FEE7100 F4 (v03 IBMTP-1Y1230 IBM 0001) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20170303/tbfadt-642) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid Address but zero Length: 0x102C/0x0 (20170303/tbfadt-693) ACPI: DSDT 0x7FEE72E7 00DB08 (v01 IBMTP-1Y1230 MSFT 010E) ACPI: FACS 0x7FEF6000 40 ACPI: FACS 0x7FEF6000 40 ACPI: SSDT 0x7FEE72B4 33 (v01 IBMTP-1Y1230 MSFT 010E) ACPI: ECDT 0x7FEF4DEF 52 (v01 IBMTP-1Y1230 IBM 0001) ACPI: TCPA 0x7FEF4E41 32 (v01 IBMTP-1Y1230 PTL 0001) ACPI: APIC 0x7FEF4E73 5A (v01 IBMTP-1Y1230 IBM 0001) ACPI: MCFG 0x7FEF4ECD 3E (v01 IBMTP-1Y1230 IBM 0001) ACPI: BOOT 0x7FEF4FD8 28 (v01 IBMTP-1Y1230 LTP 0001) ACPI: 2 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 1: pa 0xfec0, version 0x20, 24 pins cpu0 at mainbus0 apid 0 cpu0: Intel(R) Pentium(R) M processor 2.26GHz, id 0x6d8 cpu0: package 0, core 0, smt 0 acpi0 at mainbus0: Intel ACPICA 20170303 acpi0: X/RSDT: OemId , AslId < LTP,> acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT acpi0: MCFG: segment 0, bus 0-255, address 0xe000 acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 acpiec0 at acpi0 (EC, PNP0C09-0): using acpiecdt0 MEM (PNP0C01) at acpi0 not configured acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button SIO (PNP0C02) at acpi0 not configured attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43 irq 0 pcppi1 at acpi0 (SPKR, PNP0800): io 0x61 midi0 at pcppi1: PC speaker sysbeep0 at pcppi1 FPU (PNP0C04) at acpi0 not configured pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1 pckbc2 at acpi0 (MOU, IBM0057) (aux port): irq 12 LPT (PNP0400) at acpi0 not configured acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery acpibat0: SANYO LION rechargeable battery acpibat0: granularity: low->warn 0.001 Wh, warn->full 0.001 Wh acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter thinkpad0 at acpi0 (HKEY, IBM0068) acpivga0 at acpi0 (VID): ACPI Display Adapter acpiout0 at acpivga0 (LCD0, 0x0110): ACPI Display Output Device acpiout1 at acpivga0 (CRT0, 0x0100): ACPI Display Output Device acpiout2 at acpivga0 (TV0, 0x0200): ACPI Display Output Device acpiout3 at acpivga0 (DVI0, 0x0210): ACPI Display Output Device acpivga0: connected output devices: acpivga0: 0x0100 (acpiout1): Ext. Monitor, head 0 acpivga0: 0x0200 (acpiout2): TV, head 0 acpivga0: 0x0210 (acpiout3): Unknown Output Device, head 0 acpivga0: 0x0110 (acpiout0): LCD Panel, head 0 acpitz0 at acpi0 (THM0): cpu0 acpitz0: levels: critical 99.0 C, passive 94.5 C, passive cooling apm0 at acpi0: Power Management spec V1.2 ACPI: Enabled 1 GPEs in block 00 to 1F attimer1: attached to pcppi1 pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 5.9 pms0: Passthrough, Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 20:22, Manuel Bouyer wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: On 03/12/2018 22:47, Manuel Bouyer wrote: Hello, I synced our mpii(4) driver with the latest OpenBSD one and commited to HEAD. I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be good if someone could test a SAS3 with some drives (the command setup is different between SAS2 and SAS3, this is the code path I can't test). Tested with my SAS3 card and an enclosure. Relevent dmesg bits are: mpii0 at pci1 dev 0 function 0: vendor 1000 product 0097 (rev. 0x01) mpii0: interrupting at msi0 vec 0 mpii0: SAS9300-8e, firmware 0.250.110.0, MPI 2.5 scsibus0 at mpii0: 768 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 0 lun 0: disk fixed sd1 at scsibus0 target 1 lun 0: disk fixed sd2 at scsibus0 target 2 lun 0: disk fixed sd3 at scsibus0 target 3 lun 0: disk fixed sd4 at scsibus0 target 4 lun 0: disk fixed sd5 at scsibus0 target 5 lun 0: disk fixed sd6 at scsibus0 target 6 lun 0: disk fixed sd7 at scsibus0 target 7 lun 0: disk fixed sd8 at scsibus0 target 8 lun 0: disk fixed sd9 at scsibus0 target 9 lun 0: disk fixed sd10 at scsibus0 target 10 lun 0: disk fixed sd11 at scsibus0 target 11 lun 0: disk fixed sd12 at scsibus0 target 12 lun 0: disk fixed sd13 at scsibus0 target 13 lun 0: disk fixed sd14 at scsibus0 target 14 lun 0: disk fixed sd15 at scsibus0 target 15 lun 0: disk fixed sd16 at scsibus0 target 16 lun 0: disk fixed sd17 at scsibus0 target 17 lun 0: disk fixed Did some IO to the disks and got read/write performance at exactly the speeds I'd expect >170MB/s read and a little less for writing. Was it with one disk, or several disks at once ? I get 80MB/s with a SATA SEAGATE ST375064 (750GB). With a newer controller and that much disk, I'd expect more than 170MB/s if several disks are used in parallel. It was just the one disk and its a SAS2 drive behind some SAS2 expanders so we aren't taking full advantage of the SAS3 speed. Sadly all the SAS3 drives I have access to are actually in use for real work. :( I will try a multi-drive test when I'm in the office again on Thursday. The 170MB is exactly the performance I'd expect for that drive and matches what it achieves in linux on the same hardware. Disk insertion are working with my controller, I've not tested removal yet (will do tomorow). More testing is always welcome :) Okay I'll also do some power down/power up cycles on some of the drive bays in the enclosure which should test removal and insertion. The driver was definately reporting the SAS discovery events. I'll have a look at the PCI IDs in the other spare SAS3 systems to see if that will test any of the other new bits of code as well. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: > > > On 03/12/2018 22:47, Manuel Bouyer wrote: > > Hello, > > I synced our mpii(4) driver with the latest OpenBSD one and commited to > > HEAD. > > I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be > > good if someone could test a SAS3 with some drives (the command setup is > > different between SAS2 and SAS3, this is the code path I can't test). > > > Tested with my SAS3 card and an enclosure. Relevent dmesg bits are: > > mpii0 at pci1 dev 0 function 0: vendor 1000 product 0097 (rev. 0x01) > mpii0: interrupting at msi0 vec 0 > mpii0: SAS9300-8e, firmware 0.250.110.0, MPI 2.5 > > scsibus0 at mpii0: 768 targets, 8 luns per target > scsibus0: waiting 2 seconds for devices to settle... > sd0 at scsibus0 target 0 lun 0: disk fixed > sd1 at scsibus0 target 1 lun 0: disk fixed > sd2 at scsibus0 target 2 lun 0: disk fixed > sd3 at scsibus0 target 3 lun 0: disk fixed > sd4 at scsibus0 target 4 lun 0: disk fixed > sd5 at scsibus0 target 5 lun 0: disk fixed > sd6 at scsibus0 target 6 lun 0: disk fixed > sd7 at scsibus0 target 7 lun 0: disk fixed > sd8 at scsibus0 target 8 lun 0: disk fixed > sd9 at scsibus0 target 9 lun 0: disk fixed > sd10 at scsibus0 target 10 lun 0: disk fixed > sd11 at scsibus0 target 11 lun 0: disk fixed > sd12 at scsibus0 target 12 lun 0: disk fixed > sd13 at scsibus0 target 13 lun 0: disk fixed > sd14 at scsibus0 target 14 lun 0: disk fixed > sd15 at scsibus0 target 15 lun 0: disk fixed > sd16 at scsibus0 target 16 lun 0: disk fixed > sd17 at scsibus0 target 17 lun 0: disk fixed > > Did some IO to the disks and got read/write performance at exactly the > speeds I'd expect >170MB/s read and a little less for writing. Was it with one disk, or several disks at once ? I get 80MB/s with a SATA SEAGATE ST375064 (750GB). With a newer controller and that much disk, I'd expect more than 170MB/s if several disks are used in parallel. > > So this tests one the cards you have brought in. I do have some other 12G > hosts but I think they are the same chip. They would be more awkward to test > with as they are serial console only machines that have only ever been > tested running linux. Actually I'm quite confident other chips working with OpenBSD will work with NetBSD too. With your card and mine, all code paths have been tested AFAIK. > > These disk are in an enclosure so if you want me to test hotplug stuff with > this setup I can. Any data on the disks is entirely sacrificial at the > moment. Disk insertion are working with my controller, I've not tested removal yet (will do tomorow). More testing is always welcome :) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Tue, Dec 04, 2018 at 07:26:09PM +, Mike Pumford wrote:
>
>
> On 04/12/2018 19:17, Mike Pumford wrote:
> o this tests one the cards you have brought in. I do have some other
> > 12G hosts but I think they are the same chip. They would be more awkward
> > to test with as they are serial console only machines that have only
> > ever been tested running linux.
> >
> Just looked at the diff. The old code had an explicit 0,0 entry at the end
> of the PCI Ids array but this has been lost from the new version of the code
> so we are now taking it on faith that the entry one past the end of the
> static array will have a 0 mpii_vendor field. Is this safe?
No, I added back the {0, 0{ entry. Thanks !
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:31, Mike Pumford wrote: On 04/12/2018 19:25, Martin Husemann wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Not sure about boot device (I don't have the console in front of me) but it definately reported the rootfs as /dev/sd23a and mounted the rootfs automatically. Is there any particular output I should look for? It is quite an ancient machine so the BIOS USB could be odd. I'm happy to do a retest on Thursday when I've next got access to the system. I had the same problem with an earlier boot of the same system (without the mpii disks powered on) in that case the rootfs was sd5 as the system has a usb multi-card reader that got detected first. Just found in the saved dmesg: [ 6.612498] boot device: sd23 [ 6.612498] root on sd23a dumps on sd23b So that all looks right. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:25, Martin Husemann wrote: On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Not sure about boot device (I don't have the console in front of me) but it definately reported the rootfs as /dev/sd23a and mounted the rootfs automatically. Is there any particular output I should look for? It is quite an ancient machine so the BIOS USB could be odd. I'm happy to do a retest on Thursday when I've next got access to the system. I had the same problem with an earlier boot of the same system (without the mpii disks powered on) in that case the rootfs was sd5 as the system has a usb multi-card reader that got detected first. Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 04/12/2018 19:17, Mike Pumford wrote: o this tests one the cards you have brought in. I do have some other 12G hosts but I think they are the same chip. They would be more awkward to test with as they are serial console only machines that have only ever been tested running linux. Just looked at the diff. The old code had an explicit 0,0 entry at the end of the PCI Ids array but this has been lost from the new version of the code so we are now taking it on faith that the entry one past the end of the static array will have a 0 mpii_vendor field. Is this safe? Mike
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On Tue, Dec 04, 2018 at 07:17:59PM +, Mike Pumford wrote: > One thing that surprised me was that I was testing with the USB install > image but instead of landing in sysinst I ended up at a a login prompt which > was unexpected. Could this be because the USB disk that was my root device > ended up as sd23 and there is a hard coded sd0 somewhere in the install > code? No hardcoded sd0, but maybe the boot device matching did not properly work for this case (depends on geometry and stuff that the bootloader gets from bios USB emulation or something). Martin
Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
On 03/12/2018 22:47, Manuel Bouyer wrote: Hello, I synced our mpii(4) driver with the latest OpenBSD one and commited to HEAD. I tested it with a SAS2 controller (I don't have SAS3 ones), so it would be good if someone could test a SAS3 with some drives (the command setup is different between SAS2 and SAS3, this is the code path I can't test). Tested with my SAS3 card and an enclosure. Relevent dmesg bits are: mpii0 at pci1 dev 0 function 0: vendor 1000 product 0097 (rev. 0x01) mpii0: interrupting at msi0 vec 0 mpii0: SAS9300-8e, firmware 0.250.110.0, MPI 2.5 scsibus0 at mpii0: 768 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 0 lun 0: disk fixed sd1 at scsibus0 target 1 lun 0: disk fixed sd2 at scsibus0 target 2 lun 0: disk fixed sd3 at scsibus0 target 3 lun 0: disk fixed sd4 at scsibus0 target 4 lun 0: disk fixed sd5 at scsibus0 target 5 lun 0: disk fixed sd6 at scsibus0 target 6 lun 0: disk fixed sd7 at scsibus0 target 7 lun 0: disk fixed sd8 at scsibus0 target 8 lun 0: disk fixed sd9 at scsibus0 target 9 lun 0: disk fixed sd10 at scsibus0 target 10 lun 0: disk fixed sd11 at scsibus0 target 11 lun 0: disk fixed sd12 at scsibus0 target 12 lun 0: disk fixed sd13 at scsibus0 target 13 lun 0: disk fixed sd14 at scsibus0 target 14 lun 0: disk fixed sd15 at scsibus0 target 15 lun 0: disk fixed sd16 at scsibus0 target 16 lun 0: disk fixed sd17 at scsibus0 target 17 lun 0: disk fixed Did some IO to the disks and got read/write performance at exactly the speeds I'd expect >170MB/s read and a little less for writing. So this tests one the cards you have brought in. I do have some other 12G hosts but I think they are the same chip. They would be more awkward to test with as they are serial console only machines that have only ever been tested running linux. These disk are in an enclosure so if you want me to test hotplug stuff with this setup I can. Any data on the disks is entirely sacrificial at the moment. One thing that surprised me was that I was testing with the USB install image but instead of landing in sysinst I ended up at a a login prompt which was unexpected. Could this be because the USB disk that was my root device ended up as sd23 and there is a hard coded sd0 somewhere in the install code? Mike
Re: Cross-compiling Haiku from NetBSD?
Hi Thomas, Thomas Mueller wrote: You mention Haiku. Did you ever attempt to cross-compile Haiku from NetBSD? no, I never did cross.compile, I only installed it. Also, it never worked reliably and stopped booting. I see now a new CD is out, I will try it when I have a boring evening. Right now I'd love some NetBSD bugs squeezed out :) Riccardo PS: Video on the Intel chipset was one of the main issues on my system (causing boot hangs and needing to disable it for VESA), a non usable touchpad did not help either
Re: current - latest suspend tests T43 - T30 - R51
On Tue, Dec 04, 2018 at 12:26:53AM +0100, Riccardo Mottola wrote: > Hi, > > given the recent commits I got the netbsd-GENERIC.gz kernel from releng as > of 3 Dec. > > ThinkPad T43 > Nothing disabled. "Reference" but still not perfect sleep: > > - goes correctly to sleep > - comes up again > - with bge0 working > - TouchPad and TrackPoint are not working after resume (even if sleep > was Are these PS/2, USB or i2c ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
