Re: drm makes X crash (only with modesetting)
On Sun, Sep 18, 2022 at 08:57:18PM +0200, Walter Alejandro Iglesias wrote: > On Sep 18 2022, Walter Alejandro Iglesias wrote: > > On Sep 18 2022, Walter Alejandro Iglesias wrote: > > > On Sep 18 2022, Jonathan Gray wrote: > > > > On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote: > > > > > I'll see if I can reproduce this on another 965 machine. > > > > > > > > I don't see any errors with fvwm2 on mobile 965 (x61). > > > > > > I can not reproduce it in my thinkpad T410 either (same snapshot). > > > > > > For me at least, it's curious that I can trigger the issue *only* > > > brousing fvwm2 menus. I don't know what fvwm2 does with its menus. > > > > As it happened to me with other fvwm2 issue recently, today I noticed > > that using fvwm2 default configuration I couldn't reproduce the bug. > > > > This time it took me an hour to discover which setting made the > > difference. It came out that adding any of the following two options to > > MenuStyle the bug is gone: > > > > MenuStyle * TrianglesSolid > > MenuStyle * TrianglesUseFore > > > > Both disable the relief in menus arrows, so the relief shape is what > > confuses drm, mesa or whatever is making X to crash. > > > > That's mean that to reproduce the bug you have to remove the following > > "That means", is what I meant. :-) > > > line in the default fvwm2 config (line 275): > > > > MenuStyle * TrianglesSolid, TrianglesUseFore that line does not appear in /usr/X11R6/lib/X11/fvwm/.fvwmrc is there another sample config?
Re: 7.2-current USB-related arm64 hang regression since approx #1818
After more testing I can no longer repro the issue. Thanks for the quick turn-around. s. On Sun, Sep 18, 2022 at 2:12 PM Marcus Glocker wrote: > On Sun, Sep 18, 2022 at 11:35:51AM -0700, Stephan Somogyi wrote: > > > I won't know for certain for a few more hours, but initially this looks > to > > have fixed it. Thank you. > > Cool, thanks for reporting and testing! The fix is committed now. > > > So far it seems that the fix has also caused a small performance > decrease ??? > > ~5-10% as measured via several sftp transfers ??? but this measurement > was > > very unscientific. > > > > When I first booted with the new kernel I did an sftp transfer where the > > throughput dropped by 90% and then very slowly recovered to ~50% normal, > > but without hanging or interrupting the transfer. It hasn't happened > since, > > so I'm not sure what to make of this. > > > > s. > > Hmm. The fix nor the previous commit will result in performance > increase for sure, since they are adding malloc and free to every xfer > request, other than before. But it also shouldn't lead to dramatic > performance decrease. > > I did test a 1GB file transfer through scp with and without the fix, > and the transfer speed did remain the same for both. > > I guess your performance drop was related to other factors. >
Re: 7.2-current USB-related arm64 hang regression since approx #1818
On Sun, Sep 18, 2022 at 11:35:51AM -0700, Stephan Somogyi wrote: > I won't know for certain for a few more hours, but initially this looks to > have fixed it. Thank you. Cool, thanks for reporting and testing! The fix is committed now. > So far it seems that the fix has also caused a small performance decrease ??? > ~5-10% as measured via several sftp transfers ??? but this measurement was > very unscientific. > > When I first booted with the new kernel I did an sftp transfer where the > throughput dropped by 90% and then very slowly recovered to ~50% normal, > but without hanging or interrupting the transfer. It hasn't happened since, > so I'm not sure what to make of this. > > s. Hmm. The fix nor the previous commit will result in performance increase for sure, since they are adding malloc and free to every xfer request, other than before. But it also shouldn't lead to dramatic performance decrease. I did test a 1GB file transfer through scp with and without the fix, and the transfer speed did remain the same for both. I guess your performance drop was related to other factors.
Re: drm makes X crash (only with modesetting)
On Sep 18 2022, Walter Alejandro Iglesias wrote: > On Sep 18 2022, Walter Alejandro Iglesias wrote: > > On Sep 18 2022, Jonathan Gray wrote: > > > On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote: > > > > I'll see if I can reproduce this on another 965 machine. > > > > > > I don't see any errors with fvwm2 on mobile 965 (x61). > > > > I can not reproduce it in my thinkpad T410 either (same snapshot). > > > > For me at least, it's curious that I can trigger the issue *only* > > brousing fvwm2 menus. I don't know what fvwm2 does with its menus. > > As it happened to me with other fvwm2 issue recently, today I noticed > that using fvwm2 default configuration I couldn't reproduce the bug. > > This time it took me an hour to discover which setting made the > difference. It came out that adding any of the following two options to > MenuStyle the bug is gone: > > MenuStyle * TrianglesSolid > MenuStyle * TrianglesUseFore > > Both disable the relief in menus arrows, so the relief shape is what > confuses drm, mesa or whatever is making X to crash. > > That's mean that to reproduce the bug you have to remove the following "That means", is what I meant. :-) > line in the default fvwm2 config (line 275): > > MenuStyle * TrianglesSolid, TrianglesUseFore > > > -- > Walter -- Walter
Re: drm makes X crash (only with modesetting)
On Sep 18 2022, Walter Alejandro Iglesias wrote: > On Sep 18 2022, Jonathan Gray wrote: > > On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote: > > > I'll see if I can reproduce this on another 965 machine. > > > > I don't see any errors with fvwm2 on mobile 965 (x61). > > I can not reproduce it in my thinkpad T410 either (same snapshot). > > For me at least, it's curious that I can trigger the issue *only* > brousing fvwm2 menus. I don't know what fvwm2 does with its menus. As it happened to me with other fvwm2 issue recently, today I noticed that using fvwm2 default configuration I couldn't reproduce the bug. This time it took me an hour to discover which setting made the difference. It came out that adding any of the following two options to MenuStyle the bug is gone: MenuStyle * TrianglesSolid MenuStyle * TrianglesUseFore Both disable the relief in menus arrows, so the relief shape is what confuses drm, mesa or whatever is making X to crash. That's mean that to reproduce the bug you have to remove the following line in the default fvwm2 config (line 275): MenuStyle * TrianglesSolid, TrianglesUseFore -- Walter
Re: 7.2-current USB-related arm64 hang regression since approx #1818
I won't know for certain for a few more hours, but initially this looks to
have fixed it. Thank you.
So far it seems that the fix has also caused a small performance decrease —
~5-10% as measured via several sftp transfers — but this measurement was
very unscientific.
When I first booted with the new kernel I did an sftp transfer where the
throughput dropped by 90% and then very slowly recovered to ~50% normal,
but without hanging or interrupting the transfer. It hasn't happened since,
so I'm not sure what to make of this.
s.
On Sun, Sep 18, 2022 at 12:44 AM Marcus Glocker wrote:
> On Sat, Sep 17, 2022 at 10:40:29PM +0200, Marcus Glocker wrote:
>
> > On Sat, Sep 17, 2022 at 11:22:41AM -0700, Stephan Somogyi wrote:
> >
> > > Starting with arm64 snapshot kernel 1818 and continuing to 1822, the
> latest
> > > snapshot, I've been experiencing a persistent problem with the RPi3's
> USB
> > > bus locking up in a way that requires physical access to power cycle,
> and
> > > is thus a fairly serious regression. This system has been running
> > > continuously on -current since about 6.8-current without anything even
> > > remotely like this happening.
> > >
> > > The 100bT interface is at smsc0 on the usb bus. Initially, it looked
> like
> > > there may have been a weird race condition since I also had a USB-based
> > > flash drive plugged in, but moving that drive around to the other
> ports,
> > > and eventual complete removal, hasn't stopped the hanging.
> > >
> > > The hang is visible in dmesg as follows:
> > >
> > > usbd_start_next: error=5
> > > usbd_start_next: error=5
> > > usbd_free_xfer: xfer=0xff8004e74a20 not free
> > > smsc0: warning: Failed to read register 0x114
> > > smsc0: warning: MII is busy
> > >
> > > Searching around, I find references to some of these errors in FreeBSD
> and
> > > OpenBSD going back at least to 2014, but no clear resolution. It's
> > > _possible_ that I have some kind of creeping hardware failure, but it
> > > doesn't seem likely.
> > >
> > > Once the error messages appear, I can no longer access the system over
> the
> > > network. I've since connected the serial console. If I try to reboot
> while
> > > it's in this state, the system will hang hard and not even respond to
> the
> > > console. If I try `ifconfig smsc0 down` it hangs in the same way.
> > >
> > > While the USB drive was still part of the repro configuration,
> attempting
> > > to sync or otherwise access the drive also resulted in the hard hang,
> > > leading me to conclude this is a USB issue rather than either a mass
> > > storage or an ethernet issue.
> > >
> > > I've also done the usual variable elimination by using different USB
> > > drives, different ethernet cables, different port & different switch,
> etc.
> > > I no longer appear to be able to isolate this further myself.
> > >
> > > My only recourse once it's in this state is to hard power cycle.
> > >
> > > I'm happy to try and help debug further; I strongly prefer that
> > > 7.2-release/-stable doesn't include this behavior.
> > >
> > > s.
> >
> > We had some changes recently in dwctwo(4). I currently think that your
> > issue might be related to the last commit to dwc2.c revision 1.67. I'll
> > prepare a diff and send it to you for testing by tomorrow. We might
> > need some iterations. Worst case we can try to revert that commit.
>
> Does this diff fix your issue?
>
>
> Index: sys/dev/usb/dwc2/dwc2.c
> ===
> RCS file: /cvs/src/sys/dev/usb/dwc2/dwc2.c,v
> retrieving revision 1.67
> diff -u -p -u -p -r1.67 dwc2.c
> --- sys/dev/usb/dwc2/dwc2.c 10 Sep 2022 08:13:16 - 1.67
> +++ sys/dev/usb/dwc2/dwc2.c 18 Sep 2022 07:41:24 -
> @@ -242,7 +242,6 @@ dwc2_allocx(struct usbd_bus *bus)
> void
> dwc2_freex(struct usbd_bus *bus, struct usbd_xfer *xfer)
> {
> - struct dwc2_xfer *dxfer = DWC2_XFER2DXFER(xfer);
> struct dwc2_softc *sc = DWC2_BUS2SC(bus);
>
> DPRINTFN(10, "\n");
> @@ -255,7 +254,6 @@ dwc2_freex(struct usbd_bus *bus, struct
> xfer->busy_free = XFER_FREE;
> #endif
> DWC2_EVCNT_INCR(sc->sc_ev_xferpoolput);
> - dwc2_hcd_urb_free(sc->sc_hsotg, dxfer->urb, xfer->nframes);
> pool_put(>sc_xferpool, xfer);
> }
>
> Index: sys/dev/usb/dwc2/dwc2_hcd.c
> ===
> RCS file: /cvs/src/sys/dev/usb/dwc2/dwc2_hcd.c,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 dwc2_hcd.c
> --- sys/dev/usb/dwc2/dwc2_hcd.c 9 Sep 2022 21:16:54 - 1.28
> +++ sys/dev/usb/dwc2/dwc2_hcd.c 18 Sep 2022 07:41:24 -
> @@ -4312,6 +4312,7 @@ void dwc2_host_complete(struct dwc2_hsot
> xfer);
> }
>
> + dwc2_hcd_urb_free(sc->sc_hsotg, dxfer->urb, xfer->nframes);
> qtd->urb = NULL;
> timeout_del(>timeout_handle);
> usb_rem_task(xfer->device, >abort_task);
>
Re: Unable to complete secure online login
All the machines use the same network? Do you have one single outwards-facing IP? Could it be that the FF under OBSD is NOT holding to the TCP connections, therefore you appear to the bank as you come from two different IP addresses (due to NAT spreading across the public IP set)? FV > -Original Message- > From: owner-b...@openbsd.org On Behalf Of > Alton Shaw > Sent: Sunday, September 18, 2022 5:04 PM > To: bugs@openbsd.org > Subject: Re: Unable to complete secure online login > > Within the original OpenBSD installation I turned off http/2 within Firefox > but > still received the same error. > > Firefox's console did not display any errors associated the website. > > On the same machine as I was running OpenBSD I installed Ubuntu 20.04 to a > new HD. After booting into Ubuntu I installed an OpenBSD 7.1 virtual > machine (Virtualbox). Firefox within the VM would allow me to login to the > bank websites though 50% of the time it would take two attempts with the > first try resulting in the same error. Firefox w/in Ubuntu itself would > consistently let me login to the bank w/o errors. > > I then installed OpenBSD 7.1 onto a WD Passport 1TB drive. On the same > machine I was running my original installation of OpenBSD & now Ubuntu I > booted onto this external drive. I was unable able to login to the bank as I > repeatedly receive the same error as earlier. > > I then moved then USB drive to another computer with the same result. On > the second computer I also tried Firefox-ESR but the same error occurred. > > I'll next install OpenBSD 7.0 to the WD drive to see if it works as I was > able to > access the bank in the past. If that doesn't work then something must have > changed at the bank and it looks like I'll be forced to abandon OpenBSD. > > I'd like to thank everyone for their time and thoughtful suggestions.
Re: Unable to complete secure online login
Within the original OpenBSD installation I turned off http/2 within Firefox but still received the same error. Firefox's console did not display any errors associated the website. On the same machine as I was running OpenBSD I installed Ubuntu 20.04 to a new HD. After booting into Ubuntu I installed an OpenBSD 7.1 virtual machine (Virtualbox). Firefox within the VM would allow me to login to the bank websites though 50% of the time it would take two attempts with the first try resulting in the same error. Firefox w/in Ubuntu itself would consistently let me login to the bank w/o errors. I then installed OpenBSD 7.1 onto a WD Passport 1TB drive. On the same machine I was running my original installation of OpenBSD & now Ubuntu I booted onto this external drive. I was unable able to login to the bank as I repeatedly receive the same error as earlier. I then moved then USB drive to another computer with the same result. On the second computer I also tried Firefox-ESR but the same error occurred. I'll next install OpenBSD 7.0 to the WD drive to see if it works as I was able to access the bank in the past. If that doesn't work then something must have changed at the bank and it looks like I'll be forced to abandon OpenBSD. I'd like to thank everyone for their time and thoughtful suggestions.
Re: arm64 (rockpro64) regression
On Sun, Sep 18, 2022 at 12:13:34PM +0200, Martin Pieuchot wrote: > The rockpro64 no longer boots in multi-user on -current. It hangs after > displaying the following lines: > > rkiis0 at mainbus0 > rkiis1 at mainbus0 > > The 8/09 snapshot works, the next one from 11/09 doesn't. Smells like a similar hang in 'rkvop0 at ...' I see on the Pinebook Pro. Reverting this sys/dev/ofw/fdt.c fixed it (I mailed them already): revision 1.31 date: 2022/09/11 08:33:03; author: kettenis; state: Exp; lines: +21 -4; Change OF_getnodebyname() such that lokking up a node using just the name without a unit number (so without the @1234 bit) works as well. ok patrick@, gkoehler@ > > bsd.rd still boots. Same on Pinebook Pro.
Re: 7.1 sparc64 softraid0 1.5TB/2TB partition limit of RAID 5 + c
On Fri, Sep 16, 2022 at 05:59:20PM -0700, Michael Truog wrote:
> Hi,
>
> I was attempting to have a RAID 5 softraid0 setup on a sparc64 machine (boot
> log output below) but ran into problems when attempting to create a single
> partition with the size 5.5TB (RAID 5 with 4 x 2TB hard drives). I found an
> interesting problem when using disklabel on the softraid0 hard drive device,
> when attempting to make this 5.5TB partition. The partition "a" would only
> be allowed as 1.5TB and any partition >= "d" would only be allowed as 2TB,
> however the limit occurred silently after disklabel had exited. When inside
> disklabel, I could allocate a single "a" partition to be 5.5TB successfully
> and was able to write the partition successfully. However, when the
> disklabel process exited, either with the q command or a kill signal 9, the
> partition would be shrunk to the limit described above. If the disklabel
> process was suspended (ctrl-Z), this wouldn't happen and newfs would see the
> 5.5TB partition, though usage of the partition wouldn't work. The partition
> would have inaccessible blocks that fsck showed extreme anger at, when it
> saw it at boot time.
It would really help to showcase your issue with commands/output.
This issue is not related to softraid(4), it is most probably an old
sparc(64) quirk:
1. create big dummy disk for a single filesystem:
$ ldomctl create-vdisk -s 10T sparse-10T.img
2. pass it to guest domain in order to have a "real" 10T sized sd(4):
# dmesg | grep ^sd2
sd2 at scsibus3 targ 0 lun 0:
sd2: 10485760MB, 512 bytes/sector, 21474836480 sectors
# echo '/ 1M-* 100%' | disklabel -wAT/dev/stdin sd2
# disklabel -h sd2
# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: Virtual Disk
duid: c4befc09bf56efed
flags: vendor
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 164804
total sectors: 21474836480 # total bytes: 10.0T
boundstart: 0
boundend: 21474836480
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 2.0T0 4.2BSD 8192 65536 1
c:10.0T0 unused
disklabel: warning, partition a: size % cylinder-size != 0
3. compare against amd64/vmm:
$ vmctl create -s 10T 10T-sparse.img
vmctl: create imagefile operation failed: File too large
$ vmctl create -s 7T 7T-sparse.img
vmctl: raw imagefile created
(Not quite sure why 7T is the maximum here... 8T wouldn't work, either)
# vmctl start -c -b /bsd.rd -d 7T-sparse.img t
...
sd0 at scsibus0 targ 0 lun 0:
sd0: 7340032MB, 512 bytes/sector, 15032385536 sectors
...
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
# cd /dev ; MAKEDEV sd0
sh: MAKEDEV: not found
# cd /dev ; sh MAKEDEV sd0
# echo '/ 1M-* 100%' | disklabel -wAT/dev/stdin sd0
# disklabel -h sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: 24ff0fe5062adbdc
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 115363
total sectors: 15032385536 # total bytes: 7.0T
boundstart: 0
boundend: 15032385536
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 7.0T0 4.2BSD 8192 65536 1
c: 7.0T0 unused
So that makes it look like a purely sparc64 related issue.
I don't *see* silent truncation on amd64.
>
> I did bump into a kernel panic when doing the sequence (kernel panic output
> is below the boot log): disklabel single partition 5.5TB written, suspend
> disklabel process, newfs on partition, kill -9 disklabel process, write a
> single file to the filesystem ("the_first_file" in the command line output
> below).
Same as above; clear steps to reproduce would be helpful.
>
> The 1.5TB/2TB partition limit is known and expected on sparc64, isn't it? I
> didn't see the limit mentioned in documentation, though the disklabel
> manpage does say "On some machines, such as Sparc64, partition tables may
> not exhibit the full functionality described above.". I bumped into the
> same limit when attempting to use softraid0 RAID c too.
This disklabel(8) CAVEATS is pretty vague; CVS log shows it originally
mentioned amiga3 and sparc, with minor tweaks arriving sparc64.
> OpenBSD 7.1 (GENERIC.MP) #1269: Mon Apr 11 22:05:10 MDT 2022
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
Can you try with a snapshot, please?
> mpi0 at pci8 dev
arm64 (rockpro64) regression
The rockpro64 no longer boots in multi-user on -current. It hangs after displaying the following lines: rkiis0 at mainbus0 rkiis1 at mainbus0 The 8/09 snapshot works, the next one from 11/09 doesn't. bsd.rd still boots. Dmesg below. OpenBSD 7.2-beta (GENERIC.MP) #1815: Thu Sep 8 13:20:08 MDT 2022 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 4038770688 (3851MB) avail mem = 3837693952 (3659MB) random: good seed from bootblocks mainbus0 at root: Pine64 RockPro64 v2.1 psci0 at mainbus0: PSCI 1.1, SMCCC 1.2, SYSTEM_SUSPEND cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu2: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache cpu3: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu4 at mainbus0 mpidr 100: ARM Cortex-A72 r0p2 cpu4: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu4: 1024KB 64b/line 16-way L2 cache cpu4: CRC32,SHA2,SHA1,AES+PMULL,ASID16 cpu5 at mainbus0 mpidr 101: ARM Cortex-A72 r0p2 cpu5: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu5: 1024KB 64b/line 16-way L2 cache cpu5: CRC32,SHA2,SHA1,AES+PMULL,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20211000 apm0 at mainbus0 agintc0 at mainbus0 sec shift 3:3 nirq 288 nredist 6 ipi: 0, 1, 2: "interrupt-controller" agintcmsi0 at agintc0 syscon0 at mainbus0: "qos" syscon1 at mainbus0: "qos" syscon2 at mainbus0: "qos" syscon3 at mainbus0: "qos" syscon4 at mainbus0: "qos" syscon5 at mainbus0: "qos" syscon6 at mainbus0: "qos" syscon7 at mainbus0: "qos" syscon8 at mainbus0: "qos" syscon9 at mainbus0: "qos" syscon10 at mainbus0: "qos" syscon11 at mainbus0: "qos" syscon12 at mainbus0: "qos" syscon13 at mainbus0: "qos" syscon14 at mainbus0: "qos" syscon15 at mainbus0: "qos" syscon16 at mainbus0: "qos" syscon17 at mainbus0: "qos" syscon18 at mainbus0: "qos" syscon19 at mainbus0: "qos" syscon20 at mainbus0: "qos" syscon21 at mainbus0: "qos" syscon22 at mainbus0: "qos" syscon23 at mainbus0: "qos" syscon24 at mainbus0: "qos" syscon25 at mainbus0: "power-management" "power-controller" at syscon25 not configured syscon26 at mainbus0: "syscon" "io-domains" at syscon26 not configured rkclock0 at mainbus0 rkclock1 at mainbus0 syscon27 at mainbus0: "syscon" "io-domains" at syscon27 not configured "usb2phy" at syscon27 not configured "usb2phy" at syscon27 not configured rkemmcphy0 at syscon27 "pcie-phy" at syscon27 not configured rktcphy0 at mainbus0 rktcphy1 at mainbus0 rkpinctrl0 at mainbus0: "pinctrl" rkgpio0 at rkpinctrl0 rkgpio1 at rkpinctrl0 rkgpio2 at rkpinctrl0 rkgpio3 at rkpinctrl0 rkgpio4 at rkpinctrl0 pwmreg0 at mainbus0 syscon28 at mainbus0: "syscon" syscon29 at mainbus0: "syscon" "fit-images" at mainbus0 not configured rkdrm0 at mainbus0 drm0 at rkdrm0 "pmu_a53" at mainbus0 not configured "pmu_a72" at mainbus0 not configured agtimer0 at mainbus0: 24000 kHz "xin24m" at mainbus0 not configured rkpcie0 at mainbus0 rkpcie0: link training timeout dwge0 at mainbus0: rev 0x35, address 7a:4c:3b:2e:91:f1 rgephy0 at dwge0 phy 0: RTL8169S/8110S/8211 PHY, rev. 6 dwmmc0 at mainbus0: 50 MHz base clock sdmmc0 at dwmmc0: 4-bit, sd high-speed, dma dwmmc1 at mainbus0: 50 MHz base clock sdmmc1 at dwmmc1: 4-bit, sd high-speed, dma sdhc0 at mainbus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc2 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma ehci0 at mainbus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci0 at mainbus0: version 1.0 ehci1 at mainbus0 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at mainbus0: version 1.0 rkdwusb0 at mainbus0: "usb" xhci0 at rkdwusb0, xHCI 1.10 usb2 at xhci0: USB revision 3.0 uhub2 at usb2 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 rkdwusb1 at mainbus0: "usb" xhci1 at rkdwusb1, xHCI 1.10 usb3 at xhci1: USB revision 3.0 uhub3 at usb3 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 "saradc" at mainbus0 not configured rkiic0 at mainbus0 iic0 at rkiic0 escodec0 at iic0 addr 0x11 rkiic1 at mainbus0 iic1 at rkiic1 com0 at mainbus0: dw16550, 64 byte fifo com1 at mainbus0: dw16550, 64 byte fifo com1: console "spi" at mainbus0 not configured rktemp0 at mainbus0 rkiic2 at mainbus0 iic2 at rkiic2 rkpmic0 at iic2 addr 0x1b: RK808
Re: drm makes X crash (only with modesetting)
On Sep 18 2022, Jonathan Gray wrote: > On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote: > > I'll see if I can reproduce this on another 965 machine. > > I don't see any errors with fvwm2 on mobile 965 (x61). I can not reproduce it in my thinkpad T410 either (same snapshot). For me at least, it's curious that I can trigger the issue *only* brousing fvwm2 menus. I don't know what fvwm2 does with its menus. No problem with fvwm(1), cwm(1) or jwm from ports. > Can you include the full dmesg taken after the error occurs? Pasted below. > Do you have any settings in xorg.conf? Nothing in /etc/X11/xorg.conf or under /etc/X11/xorg.conf.d/. Below I pasted also the Xorg.0.log after the crash. Let me know any tests you need me to do. In another message to bugs@ I mentioned that it happend also with the intel driver, but I hurried to open my mouth. Using intel drivers (SNA) on this machine a pair of times X aborted alone while doing nothing. I didn't test it long enough. Nothing happens with menus in this case. So, problably it's not even related. # dmesg OpenBSD 7.2 (GENERIC.MP) #729: Fri Sep 16 21:11:25 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4135260160 (3943MB) avail mem = 3992526848 (3807MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries) bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011 bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) PBTN(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.57 MHz, 06-0f-02 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.51 MHz, 06-0f-02 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus 32 (PCX1) acpiprt3 at acpi0: bus -1 (PCX2) acpiprt4 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS cpu0: Enhanced SpeedStep 1795 MHz: speeds: 1800, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82Q965 Host" rev 0x02 inteldrm0 at pci0 dev 2 function 0 "Intel 82Q965 Video" rev 0x02 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, I965G, gen 4 "Intel 82Q965 HECI" rev 0x02 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH8 IGP AMT" rev 0x02: apic 1 int 19, address 00:0f:fe:77:4f:df uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x02: apic 1 int 21 ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x02: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x02: apic 1 int 21 azalia0: codecs: Realtek ALC262 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x02 pci1 at ppb0 bus 32 uhci2 at pci0 dev 29 function 0 "Intel 82801H USB" rev 0x02: apic 1 int 20 uhci3 at pci0 dev 29 function 1 "Intel 82801H USB" rev 0x02: apic 1 int 21 ehci1 at pci0 dev 29 function 7 "Intel 82801H USB" rev 0x02: apic 1 int 20 usb1 at ehci1: USB
Re: 7.2-current USB-related arm64 hang regression since approx #1818
On Sat, Sep 17, 2022 at 10:40:29PM +0200, Marcus Glocker wrote:
> On Sat, Sep 17, 2022 at 11:22:41AM -0700, Stephan Somogyi wrote:
>
> > Starting with arm64 snapshot kernel 1818 and continuing to 1822, the latest
> > snapshot, I've been experiencing a persistent problem with the RPi3's USB
> > bus locking up in a way that requires physical access to power cycle, and
> > is thus a fairly serious regression. This system has been running
> > continuously on -current since about 6.8-current without anything even
> > remotely like this happening.
> >
> > The 100bT interface is at smsc0 on the usb bus. Initially, it looked like
> > there may have been a weird race condition since I also had a USB-based
> > flash drive plugged in, but moving that drive around to the other ports,
> > and eventual complete removal, hasn't stopped the hanging.
> >
> > The hang is visible in dmesg as follows:
> >
> > usbd_start_next: error=5
> > usbd_start_next: error=5
> > usbd_free_xfer: xfer=0xff8004e74a20 not free
> > smsc0: warning: Failed to read register 0x114
> > smsc0: warning: MII is busy
> >
> > Searching around, I find references to some of these errors in FreeBSD and
> > OpenBSD going back at least to 2014, but no clear resolution. It's
> > _possible_ that I have some kind of creeping hardware failure, but it
> > doesn't seem likely.
> >
> > Once the error messages appear, I can no longer access the system over the
> > network. I've since connected the serial console. If I try to reboot while
> > it's in this state, the system will hang hard and not even respond to the
> > console. If I try `ifconfig smsc0 down` it hangs in the same way.
> >
> > While the USB drive was still part of the repro configuration, attempting
> > to sync or otherwise access the drive also resulted in the hard hang,
> > leading me to conclude this is a USB issue rather than either a mass
> > storage or an ethernet issue.
> >
> > I've also done the usual variable elimination by using different USB
> > drives, different ethernet cables, different port & different switch, etc.
> > I no longer appear to be able to isolate this further myself.
> >
> > My only recourse once it's in this state is to hard power cycle.
> >
> > I'm happy to try and help debug further; I strongly prefer that
> > 7.2-release/-stable doesn't include this behavior.
> >
> > s.
>
> We had some changes recently in dwctwo(4). I currently think that your
> issue might be related to the last commit to dwc2.c revision 1.67. I'll
> prepare a diff and send it to you for testing by tomorrow. We might
> need some iterations. Worst case we can try to revert that commit.
Does this diff fix your issue?
Index: sys/dev/usb/dwc2/dwc2.c
===
RCS file: /cvs/src/sys/dev/usb/dwc2/dwc2.c,v
retrieving revision 1.67
diff -u -p -u -p -r1.67 dwc2.c
--- sys/dev/usb/dwc2/dwc2.c 10 Sep 2022 08:13:16 - 1.67
+++ sys/dev/usb/dwc2/dwc2.c 18 Sep 2022 07:41:24 -
@@ -242,7 +242,6 @@ dwc2_allocx(struct usbd_bus *bus)
void
dwc2_freex(struct usbd_bus *bus, struct usbd_xfer *xfer)
{
- struct dwc2_xfer *dxfer = DWC2_XFER2DXFER(xfer);
struct dwc2_softc *sc = DWC2_BUS2SC(bus);
DPRINTFN(10, "\n");
@@ -255,7 +254,6 @@ dwc2_freex(struct usbd_bus *bus, struct
xfer->busy_free = XFER_FREE;
#endif
DWC2_EVCNT_INCR(sc->sc_ev_xferpoolput);
- dwc2_hcd_urb_free(sc->sc_hsotg, dxfer->urb, xfer->nframes);
pool_put(>sc_xferpool, xfer);
}
Index: sys/dev/usb/dwc2/dwc2_hcd.c
===
RCS file: /cvs/src/sys/dev/usb/dwc2/dwc2_hcd.c,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 dwc2_hcd.c
--- sys/dev/usb/dwc2/dwc2_hcd.c 9 Sep 2022 21:16:54 - 1.28
+++ sys/dev/usb/dwc2/dwc2_hcd.c 18 Sep 2022 07:41:24 -
@@ -4312,6 +4312,7 @@ void dwc2_host_complete(struct dwc2_hsot
xfer);
}
+ dwc2_hcd_urb_free(sc->sc_hsotg, dxfer->urb, xfer->nframes);
qtd->urb = NULL;
timeout_del(>timeout_handle);
usb_rem_task(xfer->device, >abort_task);
