daily CVS update output

[NetBSD source update]

Updating src tree:
cvs [update aborted]: permission denied for src

Updating xsrc tree:
cvs [update aborted]: permission denied for xsrc


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  43121672 May 12 03:01 ls-lRA.gz

Re: Radeon HD 5450?

[Robert Elz]

Date:Wed, 11 May 2022 22:00:03 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | Would be interesting to see what happens, when in EFI mode you
  | switch to the graphics mode with the gop command before booting
  | the kernel

Not sure that my efiboot is up to that, but I can upgrade it
if needed.  When I get a chance, I will try, see if I duplicate
RVP's results.  It may still need to be an old (9.99.92) kernel if
testing X is to be included, my (-8'ish version) X server simply
references *0 with the expected result if run with a post DRM
update kernel.  Upgrading that is not happening soon.

kre

Automated report: NetBSD-current/i386 test failure

[NetBSD Test Fixture]

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

usr.bin/xlint/lint1/t_integration:d_alignof
usr.bin/xlint/lint1/t_integration:msg_014

The above tests failed in each of the last 4 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:

2022.05.11.15.30.33 msaitoh src/sys/dev/ic/mfireg.h,v 1.18
2022.05.11.15.30.33 msaitoh src/sys/dev/pci/mfii.c,v 1.13
2022.05.11.15.46.25 christos src/usr.bin/xlint/lint1/lex.c,v 1.129

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2022.05.html#2022.05.11.15.46.25

CVS broken/down/changed?

[Greywolf]

Hi, all!

cvs up -AdP in my source tree yields the message

cvs [update aborted]: permission denied for src

What's up?

--
--*greywolf;

Re: Radeon HD 5450?

[RVP]

On Wed, 11 May 2022, Michael van Elst wrote:


Would be interesting to see what happens, when in EFI mode you
switch to the graphics mode with the gop command before booting
the kernel



One of the first things I tried with my integrated IvyBridge Intel
GPU. No change with the gop command in UEFI mode. (I set a 1024x768
mode which was what DRMKMS seems to go for on my HW.) I only got
a usable console in UEFI mode with this hack:

https://mail-index.netbsd.org/tech-kern/2022/04/12/msg028065.html

In CSM mode, the modesetting driver works OK except for minor
glitches.  But, if you try the `wsfb' Xorg driver on top of `intelfb'
you get what I can only describe as a 1-line framebuffer (graphics
mode). The same thing with a FB test program on the console. The
framebuffer looks like a single line of 1024? pixels right at the
top of the screen.

And, compiling-in some fonts (notably SPLEEN12x24--anything which
doesn't seem to be a multiple of 8x8) causes the kernel to reboot
right at the start.

Haven't had the time to hunt any of these snarks yet...

-RVP

Re: Radeon HD 5450?

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>My suspicion when I first saw this was that in legacy mode
>the BIOS is doing some console graphics init (and leaving it
>that way) which NetBSD is depending upon, which at least
>some firmware either does not do at all, or undoes, or
>fails to pass along to the OS, or similar, in EFI mode.

Would be interesting to see what happens, when in EFI mode you
switch to the graphics mode with the gop command before booting
the kernel

Re: Radeon HD 5450?

[Robert Elz]

Date:Wed, 11 May 2022 18:48:16 +0200
From:Rhialto 
Message-ID:  

  | I have one of those too in my "new" machine, and I also noticed that
  | when I booted in UEFI mode, it didn't work properly; but it has been a
  | while, I don't remember exactly what the issue was.  I'm booting in
  | "BIOS mode" and with that it works fine.

I have that issue with my laptop's Intel graphics.  Works fine
with a legacy BIOS boot, not at all with an EFI boot.  This
predates the DRM update from December, it is an old issue.

My suspicion when I first saw this was that in legacy mode
the BIOS is doing some console graphics init (and leaving it
that way) which NetBSD is depending upon, which at least
some firmware either does not do at all, or undoes, or
fails to pass along to the OS, or similar, in EFI mode.

When I first saw this (ages ago), I tried adding all the
PCI FIXUP options to the kernel, those did not help.

kre

core-dump on 9.99.96

[pin]

Hi,

First of all, the system is much more stable then back in January, thanks to 
@riastradh

Now I get a core-dump maybe once a week.
Today I got one an thought it would be good to report.

$ uname -a
NetBSD mybox 9.99.96 NetBSD 9.99.96 (GENERIC) #0: Mon May  9 21:41:49 UTC 2022  
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

$ sysctl hw.machine_arch hw.model hw.ncpu
hw.machine_arch = x86_64
hw.model = Intel 686-class
hw.ncpu = 4

pin:var/crash/ $ ls
.rw--- root wheel   2 B  Wed May 11 20:55:28 2022   bounds
.rw--- root wheel  93 MB Wed May 11 20:55:58 2022   netbsd.0.core.gz
.rw--- root wheel 840 KB Wed May 11 20:55:59 2022   netbsd.0.gz
pin:var/crash/ $ su
Password:
pin:var/crash/ # gunzip -d *.gz
pin:var/crash/ # gdb --eval-command="file /netbsd" --eval-command="target kvm 
netbsd.0.core" --eval-command "bt"
GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Reading symbols from /netbsd...
Reading symbols from /usr/libdata/debug//netbsd-GENERIC.debug...
0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
720 /usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
#0  0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
#1  0x80da58a4 in kern_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:73
#2  0x80deb7bd in vpanic (fmt=0x81393f88 "kernel %sassertion 
\"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xa280c93d8eb8) at 
/usr/src/sys/kern/subr_prf.c:293
#3  0x80fad72f in kern_assert (fmt=fmt@entry=0x81393f88 "kernel 
%sassertion \"%s\" failed: file \"%s\", line %d ") at 
/usr/src/sys/lib/libkern/kern_assert.c:51
#4  0x80d718e2 in cv_broadcast (cv=0xa280db7b2c50) at 
/usr/src/sys/kern/kern_condvar.c:511
#5  0x80f3ee3f in linux___dma_fence_signal_wake 
(fence=0xe1f3f61da340, timestamp=) at 
/usr/src/sys/external/bsd/drm2/linux/linux_dma_fence.c:1176
#6  0x807a510f in signal_irq_work (work=0xa280128691e8) at 
/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_breadcrumbs.c:218
#7  0x80f43a38 in irq_work_intr (cookie=) at 
/usr/src/sys/external/bsd/drm2/linux/linux_irq_work.c:74
#8  0x80db49c2 in softint_execute (s=5, l=0xe1f57bb1c4c0) at 
/usr/src/sys/kern/kern_softint.c:565
#9  softint_dispatch (pinned=, s=5) at 
/usr/src/sys/kern/kern_softint.c:818
#10 0x80220e3f in Xsoftintr ()
#11 0x653f27eb12da58b1 in ?? ()
#12 0xf347c8997f24105f in ?? ()
#13 0x05ba5d38acb62eec in ?? ()
#14 0x390d9c24d676c2d3 in ?? ()
#15 0xeb56dadab8c27ff3 in ?? ()
#16 0x66e9e74123dc0b24 in ?? ()
#17 0xa2c6a286a2c6a2c6 in ?? ()
#18 0xbb4197f5b69f7d3b in ?? ()
#19 0xdb8920536683a17b in ?? ()
#20 0xb6c7d59f13ee9d8d in ?? ()
#21 0x9a9c634158953b33 in ?? ()
#22 0x4ce88ad906ba1e7c in ?? ()
#23 0x199230d8724cc765 in ?? ()
#24 0x6ab9d258afb07cad in ?? ()
#25 0x6983698fe9c36983 in ?? ()
#26 0xeaf94a9ac027fd8a in ?? ()
#27 0xe37827082bbab3ec in ?? ()
--Type  for more, q to quit, c to continue without paging--

Re: Radeon HD 5450?

[Rhialto]

On Tue 10 May 2022 at 15:44:19 -0700, Phil Nelson wrote:
> Is the 5450 too old a device for the UEFI boot only machine or 
> is there a way to get the BIOS address for the autoconfiguration?

I have one of those too in my "new" machine, and I also noticed that
when I booted in UEFI mode, it didn't work properly; but it has been a
while, I don't remember exactly what the issue was.  I'm booting in
"BIOS mode" and with that it works fine.

> --Phil 
-Olaf.
-- 
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/  have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto


signature.asc
Description: PGP signature

Re: Configure Serial Adapter

[Rin Okuyama]

On 2022/05/11 22:06, Rin Okuyama wrote:

Alternatively, you can buy a well-supported product. I'm using one from
CableCreation with uftdi(4) driver. This is sold worldwide, e.g.:

https://www.amazon.com/dp/B075YHFMC7


Robert tells me that CableCreation has PL2303 models besides FTDI ones,
which I meant in the previous message.

If you want to use uftdi(4) driver, you have to choose the latter.

Thanks,
rin

Re: Kernel panic: gpioctl list + odroid-c1

[Brook Milligan]

> On May 10, 2022, at 8:46 PM, Brook Milligan  wrote:
> 
> One more piece of information.
> 
> src/sys/arch/arm/amlogic/meson8b_pinctrl.c includes the following code:
> 
> static const struct meson_pinctrl_gpio meson8b_cbus_gpios[] = {
> 
>   … < deleted sections > …
> 
>   /* GPIODV */
>   CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
>   CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
>   CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),
>   CBUS_GPIO(GPIODV_27, 6, 27, 0, 27),
>   CBUS_GPIO(GPIODV_28, 6, 28, 0, 28),
>   CBUS_GPIO(GPIODV_29, 6, 29, 0, 29),
> 
> It seems that GPIODV_9 does not occur in the second list; I would have 
> expected it to the be first entry.  Is there a reason for it to be missing?
> 
> Could this be the cause of the panic?

Further along: the short answer is yes.  The following patch fixes the 
immediate problem of the panic, although I have no idea if the data here are 
correct; I’m just following the pattern of the other entries.

Index: meson8b_pinctrl.c
===
RCS file: /cvsroot/src/sys/arch/arm/amlogic/meson8b_pinctrl.c,v
retrieving revision 1.2
diff -u -r1.2 meson8b_pinctrl.c
--- meson8b_pinctrl.c   14 Aug 2019 09:50:20 -  1.2
+++ meson8b_pinctrl.c   11 May 2022 13:08:29 -
@@ -226,6 +226,7 @@
CBUS_GPIO(GPIOY_14, 3, 14, 3, 14),
 
/* GPIODV */
+   CBUS_GPIO(GPIODV_9, 6, 9, 0, 9),
CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),

I would appreciate confirmation that the data this patch adds to the lookup 
table is correct.

Clearly, however, there is a hidden problem somewhere else in the code.  This 
is a lookup table; the pin number (or potentially name) is the key.  Almost 
certainly, the problem was a missing entry causing the lookup to not match 
anything.  The presumably bogus information returned led to the panic.  This 
means that somewhere else in the code is lookup logic that is not detecting the 
“missing key” case, which means that there are potential panics lurking in the 
future whenever a table like this is incomplete.  Unfortunately, I have no idea 
where that lookup code is; ideas?

Unless I hear otherwise, I will commit this patch sometime soon.  In the 
meantime, I would appreciate feedback.

Thanks a lot.

Cheers,
Brook

Re: Configure Serial Adapter

[Rin Okuyama]

On 2022/05/11 20:36, Robert Nestor wrote:

First, I was mistaken about this Prolific PL2303 USB Serial Adapter cable being 
a null modem.  It’s just a straight turn cable but I have a null modem dongle 
attached to it on the DB-9 end.

As for the USB port on the system it’s attached to, this port has been used for 
various other devices (disks, geek sticks, weather station) without any issues. 
 Rebooting the system with and without the DB-9 end connected always gives the 
same NOMEM results though.


Your device seems to be supported by OpenBSD's uplcom(4).

Probably, this commit does trick:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uplcom.c#rev1.76

See also this one:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uplcom.c#rev1.78

Alternatively, you can buy a well-supported product. I'm using one from
CableCreation with uftdi(4) driver. This is sold worldwide, e.g.:

https://www.amazon.com/dp/B075YHFMC7

Thanks,
rin

Re: Configure Serial Adapter

[Robert Nestor]

First, I was mistaken about this Prolific PL2303 USB Serial Adapter cable being 
a null modem.  It’s just a straight turn cable but I have a null modem dongle 
attached to it on the DB-9 end.

As for the USB port on the system it’s attached to, this port has been used for 
various other devices (disks, geek sticks, weather station) without any issues. 
 Rebooting the system with and without the DB-9 end connected always gives the 
same NOMEM results though.

Re: Configure Serial Adapter

[Michael van Elst]

rnes...@mac.com (Robert Nestor) writes:

>Following Michael=92s advice I added this line to sys/dev/usb/usbdevs =
>where other Prolific devices were defined:

>   product PROLIFIC PL2303Y 0x23c3 PL2303 Serial adapter (Null =
>modem)


I've now added a few models to usbdevs...



>I regenerated the header files and added these lines to the device table =
>in sys/dev/usb/uplcom.c:

>/* Prolific USB to serial null modem cable */
>{ USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303Y },

>Rebuilt the GENERIC kernel and copied to to / and rebooted my system.  I =
>get this result:

>[ 4.235870] uplcom0 at uhub1 port 1
>[ 4.235870] uplcom0: Prolific Technology Inc. (0x67b) USB-Serial =
>Controller (0x23c3), rev 2.00/3.05, addr 1
>[ 4.245877] uplcom0: autoconfiguration error: reset failed, NOMEM

>Did I miss something that is leading to this error?=20


No. A failed reset suggests that the chip isn't compatible to an old
PL2303. But NOMEM suggests, that this is a generic issue in the stack.
Does any other USB device work on that port ? Maybe a reboot helps.