Is Matrox G200e supported?
Hello,
"Why is my Matrox MGA G200e not supported?" on a Proliant ML150 G6,
OpenBSD 6.1 for I386, My full dmesg output, complete output of sysctl
and Xorg.0.log in this message. "Matrox G200e: back to software
rendering". 2d acceleration is not available. Gnome appears but the
windows of the programs move very slowly, I think it lacks a firmware
or settings for the server X.
Kinds Regards
Philippe Ponceblanc
dmesg and sysctl outputs and Xorg.0.log # dmesg
OpenBSD 6.1 (GENERIC.MP) #291: Sat Apr 1 13:53:41 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
real mem = 3211665408 (3062MB)
avail mem = 3137372160 (2992MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/31/99, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev.
2.5 @ 0xfcbf0 (80 entries)
bios0: vendor HP version "O21" date 01/18/2011
bios0: HP ProLiant ML150 G6
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC MCFG SPMI SLIC SSDT OEMB SRAT HPET DMAR
SSDT EINJ BERT ERST HEST
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4)
NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) USB1(S4)
USB2(S4) USB5(S4) EUSB(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu2:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu3:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu4 at mainbus0: apid 16 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu4:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu5 at mainbus0: apid 18 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu5:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu6 at mainbus0: apid 20 (application processor)
cpu6: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu6:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu7 at mainbus0: apid 22 (application processor)
cpu7: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu7:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu8 at mainbus0: apid 1 (application processor)
cpu8: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu8:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC,SENSOR
cpu9 at mainbus0: apid 3 (application processor)
cpu9: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz ("GenuineIntel" 686-class)
2.54 GHz
cpu9:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX
Re: raid and crypto file system
On Fri, 22 Sep 2017 22:41:22 -0300 "x9p" wrote: > > On 2017-09-20, Friedrich Locke wrote: > >> My question is: > >> > >> I would like to use hardware raid disks with disk encryption. Is that > >> possible ? Since the disk raid appears transparently to the OS. > >> > >> Is that possible ? > > > > Yes. > > > > > > Not with 6.1, right? Wrong. > installboot: invalid boot record signature (0x) @ sector 0 > > From: > > https://rohlix.wordpress.com/2016/09/16/openbsd-raid1-mirror-with-full-disk-encryption/ > This blog post is about software raid and the initial question is about hardware raid.
Re: raid and crypto file system
> On 2017-09-20, Friedrich Locke wrote: >> My question is: >> >> I would like to use hardware raid disks with disk encryption. Is that >> possible ? Since the disk raid appears transparently to the OS. >> >> Is that possible ? > > Yes. > > Not with 6.1, right? installboot: invalid boot record signature (0x) @ sector 0 From: https://rohlix.wordpress.com/2016/09/16/openbsd-raid1-mirror-with-full-disk-encryption/ x9p
Re: Xbox 360 controller emulators/snes9x hangs at startup
> Can you compile a kernel with sys/dev/usb/uhid.c reverted to > older revisions to test your hypothesis? Compiling the kernel with a patch was a good learning exercise for me. I successfully applied mpi@'s patch, as posted in the other thread. To reiterate my results, Xbox 360 and PS3 controllers on snes9x and desmume work OK. > I encourage anyone affected to test the following patch and report > back success or failure: Thank you for pointing me to the relevant thread, as I did not think of searching ports@ before posting this. > Your system has both xhci(4) USB 3 and ehci(4) USB 2 ports. > Does it matter where the input devices are plugged? Good thing you brought this up because I tested on multiple laptops and never thought about USB 3 vs USB 2. This helped me uncover an unrelated bug, which is OT and unrelated to the original issue. When plugged into USB 3, the PS4 controller registers ghost input from the left analog stick, when I am not moving it. When plugged into USB 2, it does not exhibit this ghost input behavior. This could be a bug with xhci(4). But, this can be tabled for a future discussion, as the original issue was resolved. Back to playing games. -- Nam | PGP: 0x11B50169
Re: startx fails with (EE) VESA(0): Cannot read int vect
I installed the snapshot 6.2 and X windows works fine. So I guess Intel HD Graphics 530 is supported On Sunday, 17 September 2017, 12:32, Niels Kobschaetzki wrote: On 17/09/17 09:54, Dell Sanders wrote: >Hello, > >I have freshly installed openbsd 6.1 on my PC which has a Intel HD Graphics >530 graphics chipset. > >/var/log/Xorg.1.org > >(II) VESA(0): intializing int10 >(EE) VESA(0): Cannot read int vect > >dmesg has some (perhaps relevant) messages - > >pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x190f rev 0x07 >"Intel HD Graphics 530" rev 0x06 at pci0 dev 2 function 0 not configured > >Any ideas? My Skylake-CPU has 520. And for getting that to work you need to use a snapshot and not 6.1. I don't know if 530 is then supported, too. Niels
Re: Mid-2015 MacBook Pro
I actually tried a 6.2 amd64 snap downloaded fresh yesterday first, then tried 6.1-RELEASE after that. When I installed 6.1-RELEASE, I bailed from the installer, attached to the existing softraid crypto volume, nuked the first 1M of the SR_CRYPTO volume -- sd2c in my case -- as in the FAQ and then re-partioned it, rather than re-creating that volume from scratch again. The first photo is from the 6.2 snapshot and is mostly just to highlight the hilarity that ensues when you run native resolution on a Retina display. The next two are all from that second install of 6.1-RELEASE, installed atop the crypto volume I created with the 2017-09-21 snap. I did verify that the cursor glitches and keyboard goes unresponsive at the UKC prompt ( from boot -c ) even from the install images for 6.1 and yesterday's snap. Also, before the "Copyright (c) 1982..." kernel message, I see this both in the install kernels and otherwise and it is also shown in the image dump: kbc: cmd word write error I just did a fresh install from yesterday's snapshot without using FDE or doing anything fancy. Results are now mostly the same except for a brief intermission of flashing-question-folder (missing EFI, I presume) followed by the bootloader (which I can type in) and the screen going blank and the system going unresponsive in the same way as I reported in my first post. I'm more systems and security guy than a developer, but I don't mind helping where I can. I'm just out of ideas, so additional suggestions are welcome. On Fri, Sep 22, 2017 at 12:09 PM, Dave Voutila wrote: > Ax0n, > > That RTC error seems to come from a system dependent startclocks() > function, but it was modified in August by jcs@ removing the logic > that would even print that very error: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ > amd64/isa/clock.c.diff?r1=1.24&r2=1.25 > > Commit message mentions it's probably a red herring. > > In your linked pictures it looks like you're installing a 6.2 snapshot > (older than 11 August?), but the image with the RTC BIOS error says > 6.1. The plot is indeed thickening. :-) > > On Thu, Sep 21, 2017 at 10:01 PM, Ax0n wrote: > > This one *should* be identical to the one I've been issued by my employer > > (on which I'm running OS X) -- in that case, it has the NVidia GeForce GT > > 750M and the Intel Iris Pro. The Plot Thickens. > > > > There's an error about /etc/boot.conf. The keyboard works fine at the FDE > > prompt, and at the boot> prompt. There's an RTC BIOS diagnostic error > before > > the kernel loads. At the UCK prompt, the cursor is glitching and the > > keyboard is unresponsive. External keyboard isn't helping. > > > > Photos here, if it matters: https://imgur.com/a/iL6T0 > > > > On Thu, Sep 21, 2017 at 7:22 PM, Dave Voutila > wrote: > >> > >> ax0n, > >> > >> Is that a model with both integrated Intel gpu and dedicated Radeon > >> gpu? Maybe look at drm(4) and try removing the radeon driver since the > >> intel one should work fine. > >> > >> The intel drivers work great on my early-2015 MBP (i5 Broadwell), but > >> then again it doesn't have any dedicated graphics. > >> > >> -Dave > >> > >> On Thu, Sep 21, 2017 at 6:19 PM, Ax0n wrote: > >> > I have a Mid-2015 MacBook Pro that I'm trying to get OpenBSD on. I > >> > installed from the latest snapshot and from -RELEASE (installXX.fs > >> > written > >> > to SD card). The install goes fine (using an axen(4) USB dongle for > >> > connectivity) but upon reboot, it gets part way through, then the > screen > >> > goes blank with the backlight on. Although I can briefly see the > axen(4) > >> > attach, it doesn't seem to get an IP address if I let it sit around > for > >> > a > >> > few minutes. I can't get the dmesg, and I can't determine what the > last > >> > message is before the screen blanks. It doesn't appear to respond to > the > >> > keyboard. > >> > > >> > Has anyone gotten this working? Google is pointing me to a few posts > >> > from > >> > the likes of jcs@ and others about systems that are either slightly > >> > newer > >> > or slightly older than mine. Any suggestions on getting a good dmesg > out > >> > of > >> > it? Devices I should consider disabling from UKC to get this thing off > >> > the > >> > ground? > >> > > >> > TIA- > >> > ax0n > > > > >
Re: Mid-2015 MacBook Pro
Ax0n, That RTC error seems to come from a system dependent startclocks() function, but it was modified in August by jcs@ removing the logic that would even print that very error: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/isa/clock.c.diff?r1=1.24&r2=1.25 Commit message mentions it's probably a red herring. In your linked pictures it looks like you're installing a 6.2 snapshot (older than 11 August?), but the image with the RTC BIOS error says 6.1. The plot is indeed thickening. :-) On Thu, Sep 21, 2017 at 10:01 PM, Ax0n wrote: > This one *should* be identical to the one I've been issued by my employer > (on which I'm running OS X) -- in that case, it has the NVidia GeForce GT > 750M and the Intel Iris Pro. The Plot Thickens. > > There's an error about /etc/boot.conf. The keyboard works fine at the FDE > prompt, and at the boot> prompt. There's an RTC BIOS diagnostic error before > the kernel loads. At the UCK prompt, the cursor is glitching and the > keyboard is unresponsive. External keyboard isn't helping. > > Photos here, if it matters: https://imgur.com/a/iL6T0 > > On Thu, Sep 21, 2017 at 7:22 PM, Dave Voutila wrote: >> >> ax0n, >> >> Is that a model with both integrated Intel gpu and dedicated Radeon >> gpu? Maybe look at drm(4) and try removing the radeon driver since the >> intel one should work fine. >> >> The intel drivers work great on my early-2015 MBP (i5 Broadwell), but >> then again it doesn't have any dedicated graphics. >> >> -Dave >> >> On Thu, Sep 21, 2017 at 6:19 PM, Ax0n wrote: >> > I have a Mid-2015 MacBook Pro that I'm trying to get OpenBSD on. I >> > installed from the latest snapshot and from -RELEASE (installXX.fs >> > written >> > to SD card). The install goes fine (using an axen(4) USB dongle for >> > connectivity) but upon reboot, it gets part way through, then the screen >> > goes blank with the backlight on. Although I can briefly see the axen(4) >> > attach, it doesn't seem to get an IP address if I let it sit around for >> > a >> > few minutes. I can't get the dmesg, and I can't determine what the last >> > message is before the screen blanks. It doesn't appear to respond to the >> > keyboard. >> > >> > Has anyone gotten this working? Google is pointing me to a few posts >> > from >> > the likes of jcs@ and others about systems that are either slightly >> > newer >> > or slightly older than mine. Any suggestions on getting a good dmesg out >> > of >> > it? Devices I should consider disabling from UKC to get this thing off >> > the >> > ground? >> > >> > TIA- >> > ax0n > >
Re: Xbox 360 controller emulators/snes9x hangs at startup
On 2017-09-22 12:36:56, Bryan Linton wrote: > On 2017-09-22 08:24:32, Stefan Sperling wrote: > > > > Can you compile a kernel with sys/dev/usb/uhid.c reverted to > > older revisions to test your hypothesis? > > > > This issue has already been reported and mpi@ is working on a > solution. The beginning of the relevant parts of the thread > starts with the following email: > > https://marc.info/?l=openbsd-ports&m=150563553805569&w=2 > Aaand no sooner do I send the above email and mpi@ posts a patch to ports@ which seems to fix the issue for me. I encourage anyone affected to test the following patch and report back success or failure: https://marc.info/?l=openbsd-ports&m=150608393026201&w=2 -- Bryan
Re: Xbox 360 controller emulators/snes9x hangs at startup
On 2017-09-22 08:24:32, Stefan Sperling wrote: > > Can you compile a kernel with sys/dev/usb/uhid.c reverted to > older revisions to test your hypothesis? > This issue has already been reported and mpi@ is working on a solution. The beginning of the relevant parts of the thread starts with the following email: https://marc.info/?l=openbsd-ports&m=150563553805569&w=2 To OP: I, and others, have provided mpi@ with more debugging information that he's asked for. I don't know if he needs any more information or not, but I don't think snes9x has been run with the patches he's supplied yet. It may be worthwhile to apply the patches he's sent, and then forward on the information you get so as to help debug things. -- Bryan
Re: Wireless devices for a new product
On 2017-09-22, Kevin Chadwick wrote: > On Wed, 20 Sep 2017 16:42:29 + (UTC) > > >> > Are there any opinions on a reliable or best 3G/UMTS/LTE device. A >> > ublox device was being specified but I am guessing that would have >> > been more work to get going, though it does come with open source >> > Linux drivers, I believe? >> >> Something supporting USB Communications Device Class: Mobile Broadband >> Interface Model (umb driver) would be best. umsm is old crap. > > Thanks Stuart, very helpful. Am I right, assuming an unknown device > supports this standard correctly that I would most likely simply need > to create a patch with product/device IDs and it should work? It's meant to match based on device class + subclass and shouldn't need product IDs. (In the MS world, it would be expected to work with the standard driver in newer versions of Windows and not need anything vendor specific). There's some extra setup needed on certain devices (umb_fccauth_devs in if_umb.c works for /some/ of these) but even those still match the driver, just don't enable the radio correctly. With these you get the proper external IP on the interface rather than being natted inside the LTE device as happens with many of the other newer device types (this is particularly useful for remote access if you have a SIM with static IP or that breaks out on your own L2TP infrastructure like the ones from aaisp.net.uk can do).
Re: log up or down interface end change physical address
Hello, as before discussed Ifstated is the right tool. Here you see an nice example for in kernel pppoe that runs scripts on the different states: http://www.pro-bono-publico.de/openbsd/pppoe/ Kind regards Karsten Am 21.09.2017 5:32 nachm. schrieb "George Brown" <321.geo...@gmail.com>: > There's ifstated - http://man.openbsd.org/ifstated > > On 21 September 2017 at 14:29, Krzysztof Strzeszewski > wrote: > > Hi, > > > > How to log up or down (connect or not connect cable) interface end change > > physical address on OpenBSD? > > > > > > -- > > Regards, > > Krzysztof Strzeszewski > > > >
Re: Xbox 360 controller emulators/snes9x hangs at startup
Nam Nguyen writes: > After further research, this commit[1][2] may explain what is going on. > > > Remove SIGIO support. Base tools do not implement it and ports relying > > on libusbhid, generally via SDL, shouldn't do it either since it's not > > portable. > > If I understand correctly, I should take up this issue with the > developers of the affected ports to not rely on this non-portable > code. Many emulators rely on SDL. I incorrectly viewed this as a > regression with uhid(4). Instead, it is a design decision by OpenBSD to > break backward compatibility, in favor of more portable code. Causing every single one of the dozens of ports that use SDL or SDL2 for joysticks to freeze and ignore kill(1) was not a design decision, it was an oversight. That happens occasionally. Unfortunately this particular runtime regression was not noticed until quite some time after the commit.
Re: Wireless devices for a new product
On Wed, 20 Sep 2017 16:42:29 + (UTC) > > Are there any opinions on a reliable or best 3G/UMTS/LTE device. A > > ublox device was being specified but I am guessing that would have > > been more work to get going, though it does come with open source > > Linux drivers, I believe? > > Something supporting USB Communications Device Class: Mobile Broadband > Interface Model (umb driver) would be best. umsm is old crap. Thanks Stuart, very helpful. Am I right, assuming an unknown device supports this standard correctly that I would most likely simply need to create a patch with product/device IDs and it should work?
Re: Xbox 360 controller emulators/snes9x hangs at startup
After further research, this commit[1][2] may explain what is going on.
> Remove SIGIO support. Base tools do not implement it and ports relying
> on libusbhid, generally via SDL, shouldn't do it either since it's not
> portable.
If I understand correctly, I should take up this issue with the
developers of the affected ports to not rely on this non-portable
code. Many emulators rely on SDL. I incorrectly viewed this as a
regression with uhid(4). Instead, it is a design decision by OpenBSD to
break backward compatibility, in favor of more portable code.
$ cd /usr/src
$ cvs diff -rOPENBSD_6_1 -rHEAD sys/dev/usb/uhid.c
Index: sys/dev/usb/uhid.c
===
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.66.6.1
retrieving revision 1.68
diff -u -p -r1.66.6.1 -r1.68
--- sys/dev/usb/uhid.c 1 Aug 2017 21:55:02 - 1.66.6.1
+++ sys/dev/usb/uhid.c 20 Jul 2017 16:54:45 - 1.68
@@ -1,4 +1,4 @@
-/* $OpenBSD: uhid.c,v 1.66.6.1 2017/08/01 21:55:02 bluhm Exp $ */
+/* $OpenBSD: uhid.c,v 1.68 2017/07/20 16:54:45 mpi Exp $ */
/* $NetBSD: uhid.c,v 1.57 2003/03/11 16:44:00 augustss Exp $ */
/*
@@ -237,7 +237,7 @@ uhidclose(dev_t dev, int flag, int mode,
DPRINTF(("uhidclose: sc=%p\n", sc));
clfree(&sc->sc_q);
- free(sc->sc_obuf, M_USBDEV, 0);
+ free(sc->sc_obuf, M_USBDEV, sc->sc_hdev.sc_osize);
uhidev_close(&sc->sc_hdev);
return (0);
Footnotes:
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c?rev=1.68&content-type=text/x-cvsweb-markup
[2]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c.diff?r1=1.67&r2=1.68&f=h
--
Nam | PGP: 0x11B50169
Re: Xbox 360 controller emulators/snes9x hangs at startup
On Fri, Sep 22, 2017 at 12:33:29AM -0700, Nam Nguyen wrote: > I tested 6.0 -release and 6.1 -release, and emulators/snes9x > loaded OK with all controllers. This bug appeared once I updated to a > -current snapshot. My hypothesis is that -current introduced a > regression with uhid(4). Can you compile a kernel with sys/dev/usb/uhid.c reverted to older revisions to test your hypothesis? Your system has both xhci(4) USB 3 and ehci(4) USB 2 ports. Does it matter where the input devices are plugged? > xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 > addr 1 > ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1 > ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23 > usb2 at ehci1: USB revision 2.0 > uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1
Xbox 360 controller emulators/snes9x hangs at startup
On a -current snapshot <2017-09-18 Mon>, I am getting a bug in which
emulators/snes9x-1.54.1p0 hangs at startup, waiting for uhidread.
* Pre-requisites
One of the following: Xbox 360 controller / PS4 controller / external keyboard
Install emulators/snes9x
Run a -current snapshot
* To reproduce the bug
1. Plug in Xbox 360 controller.
2. Run snes9x-gtk from emulators/snes9x.
$ snes9x-gtk
Sound buffer size: 4096 (1024 samples)
SDL sound driver initializing...
--> (Frequency: 32000hz, Latency: 32ms)...OK
3. snes9x-gtk hangs at startup.
top shows that it is sleeping, waiting for uhidread. Eventually, it goes
to idle state.
PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
0 0 35M45M sleep/2 uhidrea 0:01 1.32% snes9x-gtk
0 0 35M45M idle uhidrea 0:01 0.00% snes9x-gtk
4. Disconnect Xbox 360 controller. snes9x-gtk finishes loading.
PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
2 0 35M45M onproc/0 poll 0:01 0.68% snes9x-gtk
2 0 35M45M sleep/1 poll 0:01 0.20% snes9x-gtk
* Observations
This bug is not specific to the Xbox 360 controller, because I was able
to reproduce this bug with an external keyboard and a PS4 controller. It
is also not specific to emulators/snes9x, because emulators/desmume
exhibits similar behavior after loading a ROM file.
I tested 6.0 -release and 6.1 -release, and emulators/snes9x
loaded OK with all controllers. This bug appeared once I updated to a
-current snapshot. My hypothesis is that -current introduced a
regression with uhid(4).
$ cd /usr/src/
$ grep -ir uhidrea* *
sys/dev/usb/uhid.c:DPRINTFN(1, ("uhidread\n"));
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: sleep on %p\n", &sc->sc_q));
sys/dev/usb/uhid.c:error = tsleep(&sc->sc_q, PZERO | PCATCH, "uhidrea", 0);
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: woke, error=%d\n", error));
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: got %zu chars\n", length));
sys/dev/usb/uhid.c:uhidread(dev_t dev, struct uio *uio, int flag)
sys/dev/usb/uhid.c:int filt_uhidread(struct knote *, long);
sys/dev/usb/uhid.c:filt_uhidread(struct knote *kn, long hint)
sys/dev/usb/uhid.c:struct filterops uhidread_filtops =
sys/dev/usb/uhid.c:{ 1, NULL, filt_uhidrdetach, filt_uhidread };
sys/dev/usb/uhid.c:kn->kn_fop = &uhidread_filtops;
$ dmesg
OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16872108032 (16090MB)
avail mem = 16353759232 (15596MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries)
bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012
bios0: LENOVO 2306CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF!
UEFI UEFI POAT SSDT SSDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.77 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2494770320 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PA
