Re: modesetting vs intel in 10.0

[Mike Pumford]

On 30/08/2023 09:56, nia wrote:


I think detecting the year of manufacture is too much of a hard
problem - there are simply too many new cards and I have no idea
about a "cutoff point" where modesetting starts being OK (if it
even isn't okay for any old cards at all - it should work as long
as DRM/KMS works AFAIK)

>
Well speaking as someone whose older card worked fine under 9 and now 
just ends up as a black screen with both the intel driver and the 
modesetting one on 10.0. I'm more interesting in getting back to having 
a working accelerated X setup. I did see the tearing on the intel driver 
on 9.x but it was never bad enough to make me try the modesetting driver.


For reference my now broken hardware is:
[ 1.008474] pci1: i/o space, memory space enabled, rd/line, wr/inv ok
[ 1.008474] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell 
Integrated Graphics Device (rev. 0x06)


See kern/57268 for how my hardware fails.

Mike

Re: modesetting vs intel in 10.0

[Mike Pumford]

On 08/07/2023 23:06, David Brownlee wrote:


Would it be worth trying to collect some data on users running NetBSD
on intel display hardware, to see if there are any cases where
intel_drv works and modesetting_drv does not?

As a datapoint, on a Thinkpad T480 runs OK with the default intel_dev.
Renaming away /usr/X11R7/lib/modules/drivers/intel_drv.so and
restarting X runs fine with modesetting_drv, and "grep Mesa
/var/log/Xorg.0.log" gives




(II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R)
UHD Graphics 620 (Kabylake GT2)

Both are equally bad for me. The console works perfectly but I get stuck 
in the blank screen heartbeat death with both (see kern/57268):


[44.509] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD 
Graphics 4600
[44.509] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, 
sse4.2, avx, avx2; using a maximum of 4 threads


So fiddling with the default X driver for intel hardware is only part of 
the solution. We need to address the core issues in the i915kmsdrm that 
impact both.


Mike

Re: How to limit amount of virtual memory used for files (was: Re: Tuning ZFS memory usage on NetBSD - call for advice)

[Mike Pumford]

On 22/09/2022 06:44, Lloyd Parkes wrote:

Can we put together a catalogue of clearly defined problems so that we 
can reproduce them and investigate further? While Håvard appears to have 
solved his problem, I'm pretty sure I have an unused G4 Mac Mini of my 
own that I can try and reproduce his problem on.


So I changed vm.filemin and vm.filemax to solve my excessive swapping 
issues. Basically the system was preferring to keep file cache around 
and was evicting memory for processes that consumed swap (so data pages 
I'm assuming) rather than file cache. Under heavy memory/file usage 
(pkgsrc bulk builds) any large process running at the time of the build 
ended up going non-responsive.


So it could be that the all that needs to change here are the defaults 
for those parameters.


For the record I have:
vm.filemax=10
vm.filemin=1

in /etc/sysctl.conf on a 16GB 9.3-STABLE system. The system can 
comfortably use more memory than that for file cache. As I write this 
message its currently using 9GB for file cache (which I don't see as a 
problem as there are no other demands on the system memory at the 
moment. Starting a new process like firefox correctly dumped file cache 
over other memory with this config. Also long running firefox processes 
remained responsive both during and after the builds with this change.


Mike

Re: macppc system wedging under memory pressure

[Mike Pumford]

On 16/09/2022 06:14, Lloyd Parkes wrote:
You aren't the first person to have problems with memory pressure. We 
really are going to have to get around to documenting the memory 
management algorithms and all the tuning knobs.


I used to use this page (https://imil.net/NetBSD/mirror/vm_tune.html), 
but I have no idea how current it is. Also, I haven't used my smaller 
systems for a while now.


In the past, I used to set vm.filemax to 5 because I never want a page 
that I can simply reread to force an anonymous page to be written out to 
swap.


I've been running my build system ( an 8 core amd64 system with 16GB of 
RAM) with:


vm.filemax=10
vm.filemin=1

So its not just SMALL systems that need better tuning.

Before I set those I found that the system would prioritise file cache 
so much that any large process that ran for a long time would be forced 
to swap out so much that it would then take them ages to recover. In my 
case that was the jenkins process that was managing the build leading to 
lots of failed builds as the jenkins process fell apart. Setting those 
limits meant the file cache got evicted instead of the jenkins process.


I also found the same settings kept things like firefox from getting 
swapped out during builds as well.


This is all on 9.3 stable and all alther vm.xxx setting are at their 
default.


Mike

Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot

[Mike Pumford]

On 07/07/2022 15:40, br0nko wrote:

Hi,

0: NetBSD (sysid 169)
 start 63, size 1568384 (766 MB, Cyls 0/1/1-97/160/62), Active
 beg: cylinder0, head   1, sector  1
 end: cylinder   97, head 160, sector 62
 Information from PBR:
 Not bootable: All bytes are identical (0x00)
 Not bootable: Bad magic number (0x)

No MBR boot code in the partition table.

fdisk -i /dev/rvnd0

should resolve that I think.

Re: error upgrading packages on current / pkg database

[Mike Pumford]

On 15/04/2022 17:19, Riccardo Mottola wrote:

Hello,

I did a full system upgrade (running now ) and then got current pkgsrc.

Now I try to run pkg_rolling-replace -uv ; it compiled for days, then stops.

disc# pkg_admin check
...pkg_admin: can't open
/usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory

Hmm. Thats interesting. I've seen that happen on one of my 9.2-STABLE 
systems when doing a pkgin upgrade. Although in my case it was librsvg 
that got clobbered.


Instead of the correct pkgdb data the folder existed but contained a 
random core file. The core file wasn't from any pkg tool.

I ended up with:
/usr/pkg/pkgdb/librsvg-2.52.6/gdk-pixbuf-query.core

Which isn't even a tool I use its just something pulled in as a 
dependendency.



disc# pkg_admin rebuild
pkg_admin: glib2-2.70.2nb1: can't open `+CONTENTS'

disc# pkg_admin rebuild-tree
pkg_admin: Cannot read +CONTENTS of package glib2-2.70.2nb1


I don't know what else to try to fix.
The files in that folder are container within the pkg .tar.gz file if 
you have it around so you can extract them into the folder and then use 
pkg_admin to put things back together. That's what I did to sort myself 
out :)


Something like:

tar zxf glib-2.70.2nb1.tgz +*

Mike

Re: Unusable system during dd to USB block device

[Mike Pumford]

On 28/12/2020 14:08, Arto Huusko wrote:


Is this something known, or should I file a PR? Obviously writing a
disk image using the block device is not the right way to do it, but
neither should the system slow down the way it did.

The need to use the raw device for dd block operations is known (at 
least it is to me. Although last time I screwed up and forgot I don't 
recall it making the system run slow for other IO ops. However I'm not 
sure I particularly tried any as I was waiting for the operation to 
complete (and wondering why it was taking so long ;) ).


Mike

Re: [HEADS UP] pkgsrc default database directory changed

[Mike Pumford]

On 07/12/2020 13:17, Thomas Klausner wrote:

While that is true, pkgsrc will insist on using pkg_install 20200828
or newer, so if you want to build packages from source, you'll still
have to update your installed pkg_install.
And that requires a manual build of pkg_install (skipping the normal 
cwrappers dependency) on 9-stable and 8-stable. Not sure if that will be 
true after pullups have happened but I suspect it might still be as 
there won't be a version number bump that pkgsrc can use to detect the 
newer tool.


Mike

Re: [HEADS UP] pkgsrc default database directory changed

[Mike Pumford]

On 07/12/2020 10:06, Thomas Klausner wrote:

On Mon, Dec 07, 2020 at 09:53:46AM +, Mike Pumford wrote:

More fallout from this change:

=> Build dependency cwrappers>=20150314: NOT found
=> Verifying reinstall for ../../pkgtools/cwrappers
===> Trying to handle out-dated pkg_install...
===> Cleaning for pkg_install-20201205
ERROR: This package has set PKG_FAIL_REASON:
ERROR: Circular dependency detected

This is on an empty system trying to build cwrappers.


You must rebuild and replace pkg_install first.

What an awful user experience for a first time user. Oh pkgsrc doesn't 
work unless you do some special magic first.


Also in this particular case doing that step is actually awkward because 
the builds are being done by an script (which I've not got to modify to 
handle this ridiculous special case).


Mike

Re: [HEADS UP] pkgsrc default database directory changed

[Mike Pumford]

On 07/12/2020 02:13, Thomas Mueller wrote:

from Thomas Klausner :


I've collected specific advice outside of the basic ones here:



http://pkgsrc.org/news/pkgdb-change/



More fallout from this change:

=> Build dependency cwrappers>=20150314: NOT found
=> Verifying reinstall for ../../pkgtools/cwrappers
===> Trying to handle out-dated pkg_install...
===> Cleaning for pkg_install-20201205
ERROR: This package has set PKG_FAIL_REASON:
ERROR: Circular dependency detected

This is on an empty system trying to build cwrappers.

Also one other question. What happens to pkgin users on an update?

It doesn't treat pkg_install specally from memory. If it doesn't he 
transition from old db to new db will happen in the middle of an 
upgrade. Which will blow up spectactularly.


Mike

Re: [HEADS UP] pkgsrc default database directory changed

[Mike Pumford]

On 02/12/2020 23:41, Thomas Klausner wrote:

On Wed, Dec 02, 2020 at 03:07:55PM -0800, Paul Goyette wrote:

This is just getting too complicated.  Too many manual steps, and too
many changes to too many long-established procedures.


Yeah, I'm sorry that you spent too much time on this.

Actually, the easiest way is to just:

cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
install -c /usr/pkg/sbin/pkg_* /usr/sbin

Err. This works great until the next system update. At which point the 
system pkg_* binaries will be re-instated and break everything. Unless 
you are going to ensure that /usr/sbin/pkg_* are going to be updated not 
just in current but also in the 9, 8 and 7 release branches which are 
all still supported.


Any solution that overwrites core binaries with a binary from pkgsrc 
won't survive an OS upgrade.


As others have said this is starting to look like the consequences of 
the change have not been thought through.


Mike

Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1

[Mike Pumford]

On 06/07/2020 16:07, Martin Husemann wrote:


Stupid question: are there now actually x86 boards that do *not* have a real
serial on-board? I have not seen any so far (none of the new ones come with
an external connector of course, but they can be added easily unless it is
a notebook).

A quick look around suggests that some of the very high end gaming ones 
don't. Also assuming users will actually be able to find a cable to 
actually hook up the motherboard COM port is optimistic. You would 
probably have to get one second hand these days and if I remember 
correctly there are 2 incompatible pinouts for the 10 pin header. :(


Mike

Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1

[Mike Pumford]

On 06/07/2020 10:01, Martin Husemann wrote:

On Mon, Jul 06, 2020 at 09:52:31AM +0100, Mike Pumford wrote:

Like it or not its probably going to be a long term requirement to have
console USB support. If not for the serial output its becoming more and more
necessary just to get a console keyboard for DDB.


USB keyboards as console in ddb worked fine last I tested.
Running the usb host in polled mode however is quite a bit simpler than
doing the device part (where you have to obey timings from the host).

That hasn't been my experience. Until I turned off ddb I had several 
situations when one of my systems crashed during boot and was stuck at a 
DDB prompt that needed a PS2 keyboard for interaction.


Mike

Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1

[Mike Pumford]

On 06/07/2020 05:09, Brian Buhrow wrote:

Hello.  I agree with Mouse, except that I also think it would be very
helpful and useful to have a serial console on USB only devices.  I wonder
if we could make the console a virtual device which is attached dynamically
to a USB serial  port if and when available.  that would let the system
think it has a console, but one would only see it when the kernel and the
USB subsystem are up.  Yes, I get this would make watching things boot
challenging, but by the time you get to single user mode, the kernel is
fully up and running and USB is or should be available by then.

Like it or not its probably going to be a long term requirement to have 
console USB support. If not for the serial output its becoming more and 
more necessary just to get a console keyboard for DDB.


I don't think its possible to by an amd64 motherboard (at least in the 
consumer space) that actually has a PS2 port for a keyboard any more.


Mike

Re: NetBSD 9 on ThinkPad X220

[Mike Pumford]

On 27/05/2020 17:24, Jukka Ruohonen wrote:

On Tue, May 26, 2020 at 07:38:31AM +, nia wrote:

Yeah, we really shouldn't be using xf86-video-intel.
It's been deprecated in favour of the modesetting driver for years.


The modesetting(4) driver indeed works fine. Maybe there could be a note
for newcomers and re-comers in x11/xf86-video-intel that this driver has
been deprecated.

Does the modesetting driver support GL? If it does why is the intel 
driver the default driver used by X with no configuration on intel 
hardware. If modesetting is its replacement shouldn't that be used 
automatically in preference to the intel driver.


As a user I shouldn't have to manually configure to get the 
non-deprecated driver.

Mike

Re: github.com/NetBSD/src 5 days old?

[Mike Pumford]

On 18/05/2020 14:03, matthew sporleder wrote:


If you want small and fast you can use shallow clone and, although you
get the entire tree's bundle, it is small and fast.
You can then use --sparse to build a "sparse" (kernel only or
whatever) limited checkout (aka working dir) -- (new git feature--
https://git-scm.com/docs/git-sparse-checkout  /
https://git-scm.com/docs/git-read-tree#_sparse_checkout  ) / I don't
know about mercurial's version of this

Its also not worth getting too hung up on small systems being able to 
check out the source code. Given the memory hog that is GCC these days 
chances are if you can't check out the source tree you probably can't 
compile it anyway as GCC will need more memory than your system has.


Mike

Re: lang/rust build fails

[Mike Pumford]

On 14/05/2020 17:53, Robert Nestor wrote:


running: /pkg_comp/work/pkg/lang/rust/work/rust-bootstrap/bin/cargo build 
--manifest-path 
/pkg_comp/work/pkg/lang/rust/work/rustc-1.42.0-src/src/bootstrap/Cargo.toml 
--frozen
Compiling proc-macro2 v0.4.30

At that point there’s nothing consuming CPU time in the build and everything 
seems to be waiting on something to happen that never does.  I’ve left the 
system in that state for about 24 hours and still no progress.

Any  clues? Could this be something related to some of the recent kernel 
changes?
It might be but it also happens sometimes on 9.0-stable as well. Never 
managed to work out why.


Mike

Re: qemu emulated machine crashes due to disk timeouts

[Mike Pumford]

On 14/05/2020 14:19, m...@netbsd.org wrote:


QEMU emulation isn't a niche setup, we should aim to have it work out of
the box without adjusting sysctls, IMO.

I'd agree with that. Perhaps the real question to ask here is why is a 
QEMU ATA operation taking 30 seconds to complete in the first place? I 
know the ATA interface isn't that virtualisation friendly but an IO 
delay that long seems insane and points to either a QEMU issue or 
something the NetBSD kernel is doing to confuse the QEMU ATA emulation.


Mike

Re: firefox-74.0 crash on -current

[Mike Pumford]

On 29/03/2020 19:27, Chavdar Ivanov wrote:


I usually do the updates the long way via pkg_rolling-replace, this time
was lazy and updated only firefox, rust and cbindgen before building
firefox, so most likely it is my fault.

#0  0x7b00ceb85e8a in _lwp_kill () from /usr/lib/libc.so.12
#1  0x7b00bc9e6681 in ?? () from /usr/pkg/lib/firefox/libxul.so
#2  0x7b00bd2628a7 in ?? () from /usr/pkg/lib/firefox/libxul.so
#3  0x7b00ceab0010 in opendir () from /usr/lib/libc.so.12
#4  0x0001000b in ?? ()
#5  0x in ?? ()
...

Haven't analysed the core but webgl has gone from working to non-working 
for me after upgrading to firefox-74 on 9.0 as well.


Web GL demos used to work fine (albeit occasionally a bit slowly on some 
of the more challenging ones) on the previous firefox-73. In my case I'm 
fairly certain I can rule out package inconsistencies as I build a 
complete package set from the ground up in a chroot and then 
install/refresh everything with pkgin.


X reports the card as:
[40.980] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD 
Graphics 4600
[40.980] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, 
sse4.2, avx, avx2; using a maximum of 4 threads
[40.980] (II) intel(0): Creating default Display subsection in 
Screen section


Its the onboard graphics from a:
cpu0: "Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz"
cpu0: Intel 4th gen Core, Xeon E3-12xx v3 (Haswell) (686-class), 3997.87 MHz
cpu0: family 0x6 model 0x3c stepping 0x3 (id 0x306c3
Mike

Re: Build time measurements

[Mike Pumford]

On 24/03/2020 21:47, Andrew Doran wrote:

DIAGNOSTIC and acpicpu are disabled in all kernels but they are otherwise
GENERIC.  The 2020-04-??  kernel is HEAD plus the remaining changes from the
ad-namecache branch.

Curious to know why acpicpu is a performance hit. Is it just that it 
downclocks the CPU if you don't have estd to ramp it up or something 
more fundamental?


Mike

Re: intelfb & wsdisplay

[Mike Pumford]

On 14/10/2019 17:56, Michael van Elst wrote:

pr...@cam.ac.uk (Patrick Welche) writes:


no data for est. mode 640x480x67


That's from EDID data: 640x480 pixels at 67 Hertz.

See the same thing on 9.0_BETA. It doesn't actually seem to impact 
display operation as I seem to have fully operation X operation on that 
system as well.


Mike

Re: 9.0-BETA panic

[Mike Pumford]

On 29/09/2019 21:54, Mike Pumford wrote:

Was doing a pkgsrc build under jenkins and got the following panic:

[ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: 
file "/

work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241
[ 14305.111922] cpu5: Begin traceback...
[ 14305.111922] vpanic() at netbsd:vpanic+0x160
[ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4
[ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56
[ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a
[ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49
[ 14305.111922] closef() at netbsd:closef+0x6d
[ 14305.111922] fd_close() at netbsd:fd_close+0x1f4
[ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c
[ 14305.121926] syscall() at netbsd:syscall+0x181
[ 14305.121926] --- syscall (number 255) ---
[ 14305.121926] 7b40fce3ee6a:
[ 14305.121926] cpu5: End traceback...


Bit more info.

Kernel build time (which also represents the source tree checkout time):

NetBSD trigati.mudcovered.org.uk 9.0_BETA NetBSD 9.0_BETA (GENERIC) #0: 
Sat Sep 28 09:56:10 BST 2019 
buil...@trigati.mudcovered.org.uk:/work/netbsd/.jenkins/workspace/NetBSD-9-amd64-build/obj.amd64/sys/arch/amd64/compile/GENERIC 
amd64


Packages being compiled were for 8.1_STABLE in a pkg_comp1 chroot 
environment. Can't tell which package was being compiled at the time of 
death as I couldn't retrieve the jenkins build log. I'm re-running the 
same build to see if it happens again.


Mike

9.0-BETA panic

[Mike Pumford]

Was doing a pkgsrc build under jenkins and got the following panic:

[ 14305.111922] panic: kernel diagnostic assertion "semcnt >= 0" failed: 
file "/

work/netbsd/9-stable/src/sys/kern/kern_uidinfo.c", line 241
[ 14305.111922] cpu5: Begin traceback...
[ 14305.111922] vpanic() at netbsd:vpanic+0x160
[ 14305.111922] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4
[ 14305.111922] chgsemcnt() at netbsd:chgsemcnt+0x56
[ 14305.111922] ksem_release() at netbsd:ksem_release+0x6a
[ 14305.111922] ksem_close_fop() at netbsd:ksem_close_fop+0x49
[ 14305.111922] closef() at netbsd:closef+0x6d
[ 14305.111922] fd_close() at netbsd:fd_close+0x1f4
[ 14305.121926] sys__ksem_destroy() at netbsd:sys__ksem_destroy+0x9c
[ 14305.121926] syscall() at netbsd:syscall+0x181
[ 14305.121926] --- syscall (number 255) ---
[ 14305.121926] 7b40fce3ee6a:
[ 14305.121926] cpu5: End traceback...

Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...

[Mike Pumford]

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...

[Mike Pumford]

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...

[Mike Pumford]

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...

[Mike Pumford]

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...

[Mike Pumford]

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: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...

[Mike Pumford]

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).

Just updating my current tree and doing a build. Will then take a USB 
bootable image to work and test it with the SAS3 HBA there.


Mike

Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...

[Mike Pumford]

On 30/11/2018 08:50, Stephen Borrill wrote:

I cannot easily attach drives to it (it has external ports only, and I 
would need to drag it to our datacenter to connect it to something). 
Let's see what Mike Pumford's PCI IDs are.


Wasn't able to check as I need to take a live USB stick in as the 
current system disk in that system is broken (its an ex-devtest box) and 
I forgot to pick it up. :( Will try again on Monday but from what I an 
remember all LSI SAS3 chipsets have a totally different driver to the 
SAS2 and SAS cards.


I do have the ability to hook it up to a wide variety of disks though.

Mike

Re: mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...

[Mike Pumford]

On 29/11/2018 18:16, Manuel Bouyer wrote:


Do you have drives connected to this controller ?
If so I can probably come up with a patch this week-end.
The SAS3 has a sighly different interface, but from looking at the OpenBSD
driver it's all in a single function.

I've got access to a spare LSI SAS3 HBA at work and have some SAS drives 
I could test with. I can get the exact PCI ids to see if its supported 
by the OpenBSD driver.


Mike

apu2 SATA patch

[Mike Pumford]

On 26/11/2018 15:16, Greg Troxel wrote:

Mike Pumford  writes:


I have one of these. The msata needs needs a small patch (needs an
entry in the quirks table to be properly recognised as an ahci
controller) but other than that it seems to work. No stability issues
using sdhc as the system disk.


Could you mail a patch, or file a PR with it?  This seems like something
that should be applied in the main tree.

Heres the patch. I've not yet verified IO yet but the patch is based on 
how OpenBSD and FreeBSD handle the device and the detection messages 
match what they report.


Index: sys/dev/pci/ahcisata_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/ahcisata_pci.c,v
retrieving revision 1.38
diff -u -r1.38 ahcisata_pci.c
--- sys/dev/pci/ahcisata_pci.c  13 Oct 2016 17:11:09 -  1.38
+++ sys/dev/pci/ahcisata_pci.c  26 Nov 2018 21:24:56 -
@@ -194,6 +194,8 @@
AHCI_PCI_QUIRK_FORCE },
{ PCI_VENDOR_ASMEDIA, PCI_PRODUCT_ASMEDIA_ASM1061_12,
AHCI_PCI_QUIRK_FORCE },
+   { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_SATA,
+   AHCI_PCI_QUIRK_FORCE },
 };
 
 struct ahci_pci_softc {

Re: Rust, pkgsrc

[Mike Pumford]

On 05/11/2018 16:34, bch wrote:
The latest rust (1.30?) supporting the latest Firefox is *brutal* to 
build. I’ve blown (and then resized) /tmp multiple times, and am now 
exhausted on /usr for its build artifacts, before it’s even actually 
installed.


Does anybody have tips or tricks for dealing with rust-building (which 
has always been terribly painful CPU-wise), or should I just move to 
prebuilt packages? I think I’ve never seen a piece of software as 
horrible to build as rust...


If you are on x86 and have access to a bigger system for building on 
have you considered running pbulk in a chroot environment or using 
pkg_comp. I've save myself a lot of time on my x86 systems by doing all 
the builds on a relatively well specced system and then just installing 
binary packages on the smaller ones.


Do you use MAKEJOBS on your pkgsrc builds? If you do then add 
MAKE_JOBS_SAFE=no to the rust package Makefile.


Without that I've found that make ends up spawning multiple rustc 
processes each of which internally then spawn even more threads causing 
ridiculous cpu overcommit. If you aren't using it and you are on a small 
system I don't know what to suggest. Even with that tweak compiling rust 
on a 4core (8 threads) 4GHz 64bit CPU with 16GB of RAM is still 
painfully slow and ends up maxing out the CPU for most of the build.


Mike




-bch

Re: Panic on acorn32 current

[Mike Pumford]

On 04/03/2018 17:09, Mike Pumford wrote:

Finally had some time to bring my system up to date and found a problem.

Got a panic at start of day (transcribed from a shot of the screen):
fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000


Now raised as port-acorn32/53076

Mike

ps performance acorn32 (was Re: Panic on acorn32 current)

[Mike Pumford]

Take back the performance comment. Something is monumentally wrong with 
the 8.0-BETA ps. It takes ages to run:


For comparison:
# file /bin/ps
/bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked 
(uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped

# time ps>/dev/null
     0.22 real 0.02 user 0.18 sys

And in a chroot with the 8.0-BETA userland:

# file /bin/ps
/bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically 
linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: 
arm, not stripped

# time ps >/dev/null
     8.19 real 1.25 user 6.62 sys
#

I'd guess the bug is in the libraries as running the 8.0 ps with the 
6.99.40 libraries performs at the same speed as the native 6.99.40 binary.


Not a bug. ktrace showed what was going on. Massive repeated lstats of 
/dev. I'd not run /etc/rc.d/sysdb start in the chroot. Once that was 
done ps worked entirely sensibly with no odd performance issues. :).


Apologies for the false alarm.

Mike

Re: Panic on acorn32 current

[Mike Pumford]

On 04/03/2018 17:09, Mike Pumford wrote:

Finally had some time to bring my system up to date and found a problem.

Got a panic at start of day (transcribed from a shot of the screen):
fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000

uvmfault(0xf036f42c, 217000, 2) -> e
Fatal kernel mode ata abort: 'Translation Fault (P)'
trapframe: 0xf03ccc40
FSR=183bd007, FAR=002170ef, spsr=2093
r0 =002170ef, r1 =f02f2a65, r2 =000d, r3 =00217047
r4 =0813, r5 =0066, r6 =f02f2a65, r7 =f0351190
r8 =f02f2a64, r9 =0005, r10=f02f2a64, r11=f040
r12=f03c, ssp=f04ccc94, slr=f0027288, pc =f02d90d8

Stopped in pid 0.1 (system) at netbsd:strlcpy+0x30:strb r5, [r0], #001
db>bt
0xf038: netbsd:irq_claim+0xc
0xf03cccf0: netbsd:intr_claim+0x58
0xf03ccd28: netbsd:fdcattach+0xc0


Tracking it back it was introduced quite a while back (rev 1.13) of the 
file which made the section of the file containg the irq description 
strings read only (but the irq_claim code writes them).


The following patch fixes this issue and also corrects another bug that 
causes the interrupt names to get corrupted in systat. The legacy irq 
counter code expects all the irq names to be the same length and this 
patch restores that behaviour.


This needs a pullup to 8.0 (which has exactly the same bug). 7.1 is also 
impacted but I've not actually run the patch there. With this patch 
applied current and 8.0-BETA actually boot up and work pretty much the 
same as the previous rather ancient 6.99.40 kernel it was running before 
and there doesn't appear to be any obvious performance drop with the new 
code.


Take back the performance comment. Something is monumentally wrong with 
the 8.0-BETA ps. It takes ages to run:


For comparison:
# file /bin/ps
/bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked 
(uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped

# time ps>/dev/null
0.22 real 0.02 user 0.18 sys

And in a chroot with the 8.0-BETA userland:

# file /bin/ps
/bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically 
linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: 
arm, not stripped

# time ps >/dev/null
8.19 real 1.25 user 6.62 sys
#

I'd guess the bug is in the libraries as running the 8.0 ps with the 
6.99.40 libraries performs at the same speed as the native 6.99.40 binary.


Mike



I've spotted some other issues:
1. Slight misdetect of the NE2000 derived ethernet chip
2. Hangs when attempt is made to reboot.
3. Bad behaviour in ddb.

I've run into these before and I've got some rather hacky fixes. Once 
they are cleaned up I'll send out another message with patches for those 
as well.


Mike

Panic on acorn32 current

[Mike Pumford]

Finally had some time to bring my system up to date and found a problem.

Got a panic at start of day (transcribed from a shot of the screen):
fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000

uvmfault(0xf036f42c, 217000, 2) -> e
Fatal kernel mode ata abort: 'Translation Fault (P)'
trapframe: 0xf03ccc40
FSR=183bd007, FAR=002170ef, spsr=2093
r0 =002170ef, r1 =f02f2a65, r2 =000d, r3 =00217047
r4 =0813, r5 =0066, r6 =f02f2a65, r7 =f0351190
r8 =f02f2a64, r9 =0005, r10=f02f2a64, r11=f040
r12=f03c, ssp=f04ccc94, slr=f0027288, pc =f02d90d8

Stopped in pid 0.1 (system) at netbsd:strlcpy+0x30:strb r5, [r0], #001
db>bt
0xf038: netbsd:irq_claim+0xc
0xf03cccf0: netbsd:intr_claim+0x58
0xf03ccd28: netbsd:fdcattach+0xc0


Tracking it back it was introduced quite a while back (rev 1.13) of the 
file which made the section of the file containg the irq description 
strings read only (but the irq_claim code writes them).


The following patch fixes this issue and also corrects another bug that 
causes the interrupt names to get corrupted in systat. The legacy irq 
counter code expects all the irq names to be the same length and this 
patch restores that behaviour.


This needs a pullup to 8.0 (which has exactly the same bug). 7.1 is also 
impacted but I've not actually run the patch there. With this patch 
applied current and 8.0-BETA actually boot up and work pretty much the 
same as the previous rather ancient 6.99.40 kernel it was running before 
and there doesn't appear to be any obvious performance drop with the new 
code.


I've spotted some other issues:
1. Slight misdetect of the NE2000 derived ethernet chip
2. Hangs when attempt is made to reboot.
3. Bad behaviour in ddb.

I've run into these before and I've got some rather hacky fixes. Once 
they are cleaned up I'll send out another message with patches for those 
as well.


Mike

Index: sys/arch/arm/iomd/iomd_irq.S
===
RCS file: /cvsroot/src/sys/arch/arm/iomd/iomd_irq.S,v
retrieving revision 1.16
diff -u -r1.16 iomd_irq.S
--- sys/arch/arm/iomd/iomd_irq.S2 Dec 2013 18:36:10 -   1.16
+++ sys/arch/arm/iomd/iomd_irq.S4 Mar 2018 17:02:34 -
@@ -412,7 +412,7 @@
 #ifdef IRQSTATS
 /* These symbols are used by vmstat */
 
-   .section .rodata
+   .section .data
 
.global _C_LABEL(_intrnames)
 _C_LABEL(_intrnames):
Index: sys/arch/arm/iomd/iomd_irqhandler.c
===
RCS file: /cvsroot/src/sys/arch/arm/iomd/iomd_irqhandler.c,v
retrieving revision 1.22
diff -u -r1.22 iomd_irqhandler.c
--- sys/arch/arm/iomd/iomd_irqhandler.c 25 Oct 2014 10:58:12 -  1.22
+++ sys/arch/arm/iomd/iomd_irqhandler.c 4 Mar 2018 17:02:34 -
@@ -180,7 +180,9 @@
/* Get the interrupt name from the head of the list */
char *iptr = _intrnames + (irq * 14);
if (handler->ih_name) {
-   strlcpy(iptr, handler->ih_name, 14);
+   /* kvm code expects these to be padded to the 
+* field length (13 chars + \0 in our case) */
+   snprintf(iptr, 14, "%-13.13s", handler->ih_name );
} else {
snprintf(iptr, 14, "irq %2d ", irq);
}
@@ -290,7 +292,9 @@
/* Get the interrupt name from the head of the list */
char *iptr = _intrnames + (irq * 14);
if (irqhandlers[irq] && irqhandlers[irq]->ih_name) {
-   strlcpy(iptr, irqhandlers[irq]->ih_name, 14);
+   /* kvm code expects these to be padded to the 
+* field length (13 chars + \0 in our case) */
+   snprintf(iptr, 14, "%-13.13s", handler->ih_name );
} else {
snprintf(iptr, 14, "irq %2d ", irq);
}

Re: AMD Ryzen and NetBSD?

[Mike Pumford]

On 03/07/2017 05:34, Thor Lancelot Simon wrote:

On Sun, Jul 02, 2017 at 10:57:20PM +0100, Patrick Welche wrote:

On Fri, Jun 30, 2017 at 12:00:45PM -0400, Thor Lancelot Simon wrote:

I shoved a rather newer ST2000DM001-1CH164 in, which according to its
marketing bumpf can manage "Max SustainableTransfer Rate 210MB/s"
and not so bad:

# dd if=/dev/zero ibs=64k | progress -l 976751887b dd of=/dev/rdk15 obs=64
k
  99% |** |   465 GiB  116.74 MiB/s00:00 
ETAd


This is already effectively double buffered, because of the way you used
"progress".  You could try using a larger blocksize for the reads from
/dev/zero (1m perhaps) and also for the writes to rdk15 - the kernel
will buffer up and dispatch the MAXPHYS sized I/Os.

To get 200MB out of that drive you likely need larger writes, which we
currently can't do.  It might perform slightly better through the
filesystem, though.
I have almost the same disk in my NetBSD 8 BETA system:

wd0 at atabus0 drive 0
wd0: 

It can sustain 210MB READING but I doubt it will be as fast writing. 
Hard drive manufacturers tend to quote read speeds over write speed as 
they are much faster. Looking at the ST2000DM1 datasheet confirms that. 
The sustained read speed is indeed 210MB/s with an average data rate 
(mixed reads and writes of 150MB/s). Based on past experience the write 
speed you are seeing is about par for the course in any system. The MB 
used by disk manufacturers is decimal for capacity and I wouldn't be 
surprised if they used it for transfer rates as well as it would make 
the drives look faster.


Heres the spec I looked at.
http://www.seagate.com/staticfiles/docs/pdf/datasheet/disc/barracuda-ds1737-1-us.pdf

I can't do a write test at the sector level as its my system disk but doing:

# dd if=/dev/rwd0d bs=64k of=/dev/null
^C44897+0 records in
44897+0 records out
2942369792 bytes transferred in 14.094 secs (208767545 bytes/sec)

Pretty close to the claimed sustained transfer speed. Did a fileystem 
level write test at 2 different sizes and got:

dd if=/dev/zero of=testme bs=64k
^C18708+0 records in
18707+0 records out
1225981952 bytes transferred in 11.679 secs (104973195 bytes/sec)

dd if=/dev/zero of=testme bs=1m
^C^C3828+0 records in
3827+0 records out
4012900352 bytes transferred in 38.780 secs (103478606 bytes/sec)

For reference this is on an I i7 system:

cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3

So seems like the Ryzen has comparable IO performance to a 6th 
generation intel i7 and is being speed limited by the disk.


Mike

USB device detection problem

[Mike Pumford]

Just trying to fire up NetBSD 8-BETA on my builder machine but I've run 
into a bit of a showstopper (for me) bug in the new kernel.


On NetBSD 7-STABLE (Apr 14th) my KVM is detected as:
uhub6 at uhub1 port 6:  , class 9/0, rev 1.10/1.00, addr 1
uhub6: 4 ports with 4 removable, self powered

And then the kernel carries on an finds the keyboard and mouse 
downstream of that device.


In NetBSD 8 I get:
uhub6 at uhub1 port 6: vendor 0557 (0x557) product 8021 (0x8021), class 
9/0, rev 1.10/1.00, addr 1

uhub6: 4 ports with 4 removable, self powered


uhub6: device problem, disabling port 1

This means I have no console keyboard. Anything I can do to help track 
this down?


I've also attached full dmesg from Both 8-BETA and 7.1-STABLE.



Mike
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
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_BETA (GENERIC) #0: Sun Jun 25 01:07:37 BST 2017

buil...@trigati.mudcovered.org.uk:/work/netbsd/8-stable/obj.amd64/sys/arch/amd64/compile/GENERIC
total memory = 16259 MB
avail memory = 15766 MB
cpu_rng: RDRAND
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
ASUS All Series (System Version)
mainbus0 (root)
ACPI: RSDP 0x000F04A0 24 (v02 ALASKA)
ACPI: XSDT 0xB8DCF080 74 (v01 ALASKA A M I01072009 AMI  
00010013)
ACPI: FACP 0xB8DE18A8 00010C (v05 ALASKA A M I01072009 AMI  
00010013)
ACPI: DSDT 0xB8DCF188 01271D (v02 ALASKA A M I0006 INTL 
20120711)
ACPI: FACS 0xB9312F80 40
ACPI: APIC 0xB8DE19B8 92 (v03 ALASKA A M I01072009 AMI  
00010013)
ACPI: FPDT 0xB8DE1A50 44 (v01 ALASKA A M I01072009 AMI  
00010013)
ACPI: SSDT 0xB8DE1A98 000BEE (v01 Ther_R Ther_Rvp 1000 INTL 
20120711)
ACPI: SSDT 0xB8DE2688 000539 (v01 PmRef  Cpu0Ist  3000 INTL 
20051117)
ACPI: SSDT 0xB8DE2BC8 000B74 (v01 CpuRef CpuSsdt  3000 INTL 
20051117)
ACPI: MCFG 0xB8DE3740 3C (v01 ALASKA A M I01072009 MSFT 
0097)
ACPI: HPET 0xB8DE3780 38 (v01 ALASKA A M I01072009 AMI. 
0005)
ACPI: SSDT 0xB8DE37B8 00036D (v01 SataRe SataTabl 1000 INTL 
20120711)
ACPI: SSDT 0xB8DE3B28 005B5E (v01 SaSsdt SaSsdt   3000 INTL 
20120711)
ACPI: Executed 15 blocks of module-level executable AML code
ACPI: 6 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 8: pa 0xfec0, version 0x20, 24 pins
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu0: package 0, core 0, smt 0
cpu1 at mainbus0 apid 2
cpu1: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu1: package 0, core 1, smt 0
cpu2 at mainbus0 apid 4
cpu2: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu2: package 0, core 2, smt 0
cpu3 at mainbus0 apid 6
cpu3: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu3: package 0, core 3, smt 0
cpu4 at mainbus0 apid 1
cpu4: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu4: package 0, core 0, smt 1
cpu5 at mainbus0 apid 3
cpu5: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu5: package 0, core 1, smt 1
cpu6 at mainbus0 apid 5
cpu6: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu6: package 0, core 2, smt 1
cpu7 at mainbus0 apid 7
cpu7: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu7: package 0, core 3, smt 1
acpi0 at mainbus0: Intel ACPICA 20170303
acpi0: X/RSDT: OemId , AslId 
acpi0: MCFG: segment 0, bus 0-255, address 0xe000
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFE843BC2D810 0003D3 (v01 PmRef  Cpu0Cst  3001 INTL 
20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFE811D1C2810 0005AA (v01 PmRef  ApIst3000 INTL 
20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFE811D0675D0 000119 (v01 PmRef  ApCst3000 INTL 
20051117)
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400)
timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000
acpiec0 at acpi0 (EC0, PNP0C09): io 0x62,0x66
acpiec1 at acpi0 (H_EC, PNP0C09-1): using acpiec0
acpivga0 at acpi0 (GFX0): ACPI Display Adapter
acpiout0 at acpivga0 (DD01, 0x0100): ACPI Display Output Device
acpiout1 at acpivga0 (DD02, 0x0002): ACPI Display Output Device
acpiout2 at acpivga0 (DD03, 0x0300): ACPI Display Output Device
acpiout3 at acpivga0 (DD04, 0x0301): ACPI Display Output Device
acpiout4 at acpivga0 (DD05, 0x0302): ACPI Display Output Device
acpiout5 at acpivga0 (DD06, 0x0303): ACPI Display Output Device
acpiout6 

Re: i386 GENERIC_PAE panics (i915drmkms related?)

[Mike Pumford]

On 20/01/2017 18:18, John D. Baker wrote:


The intent of booting i386 release on this amd64 machine is to build
packages for i386 faster than even my fastest real i386 can.  It's faster,
has more CPUs and with the extra RAM and PAE, I can put WRKOBJDIR in
/tmp on tmpfs for everything except "misc/libreoffice".

If that's your primary goal have you considered using pkg_comp. That 
builds packages in chroot environments and on amd64 can build packages 
for i386. From one 7.0 amd64 machine I build packages for 6.x/i386, and 
7.0/amd64. I did also do 7.0/i386 as well until I switched that machine 
to 64bit. That might be a better alternative that trying to bludgeon a 
PAE kernel into life.


Mike

Re: pipe read returning EAGAIN

[Mike Pumford]

Christos Zoulas wrote:

In article <20160208104744.ga11...@asim.lip6.fr>,
Manuel Bouyer   wrote:


There is a call to pool. What happens is that it gets a POLLIN event
for both fd 3 (which really has data to read) and fd 4 (wich doesn't).

The read callback for fd 4 expects to be called only when there's really
data to be read, and if read returns EAGAIN it loops until it gets data.

poll is called with a set of descriptors, and returns that there is 1
descriptor ready to be read. But the POLLIN flag is set for both
descriptors 3 and 4.

Now the question is why is the POLLIN flag set when there's no data to read ?
zeroing out revents before callin poll(2) doens't help.

The man page says:
 This implementation differs from the historical one in that a given file
 descriptor may not cause poll() to return with an error.  In cases where
 this would have happened in the historical implementation (e.g. trying to
 poll a revoke(2)d descriptor), this implementation instead copies the
 events bitmask to the revents bitmask.  Attempting to perform I/O on this
 descriptor will then return an error.  This behaviour is believed to be
 more useful.

Does it do so if the file descriptor's error is EAGAIN ?
If so that's no very usefull ...


I don't think it does. If the file descriptor is revoked I believe it
returns EIO. The question is that if the read code sees an error (EAGAIN),
why does it retry? Is it because it expects to get a "full message" and it
does not? Does it get any bytes?

I think in the case of nagios yes it does (incorrectly). I ran into this 
a while back and its fixed in the nagios head so I was waiting for the 
package to update before I checked again.


Mike

Re: DRMKMS problem on i386 i915 chipset

[Mike Pumford]

Taylor R Campbell wrote:


At the point where the console should switch to graphics mode I get
a load of random colour bars on the screen. The system is still
running at that point so by typing blind I've been able to gather
some debug information.

Can you please cvs update to sys/dev/pci/agp_i810.c 1.118 and try
again?


Yes that works perfectly.

Thanks

Mike

Re: DRMKMS problem on i386 i915 chipset

[Mike Pumford]

Martin Neitzel wrote:



Having a problem getting a 7-BETA KMS kernel to work on my now quite old
Sony VAIO laptop.


Hey, at least you can **see** some dmesg output :-)

For me (attempting my very first -current installation), the kernel
from seven or ten days ago fails with blanking the screen.

Just prior to that, it manages to dump some registers/memory/device
table to the screen.  The blanking (perhaps even panicing?) happens
too fast to let me read anything, though.

This is the i386 port on an ASUS EeePc 1000H, Atom N270 with Intel
945GME graphics.  (Works just fine with Netbsd-5.x and -6.x, incl. drm)

is very helpful to me because it provides a few suggestions for disabling
drivers at userconf stage.


That worked for me. I did:
disable i915drmkms

Which got me a kernel that booted in textmode.

However I've now done some further debugging and I now have a working 
system with DRMKMS enabled including 3D accelleration in X.


The critical failure in my system was the fact that the DRM driver 
couldn't map the VGA BIOS to get parameters from it. The reason for this 
failure turned out to be a piece of memory called the flush page 
allocated in the i810 AGP driver. The kernel was creating the mapping 
for this at 0xc-0xc0fff which is the first page of the VGA BIOS. 
Whether this page needs to be allocated or not depends on the system 
BIOS so it explains why DRMKMS would work for some people on i915 
systems and not others.


To fix this I made the mod described in the attached patch to the AGP 
driver so that it won't accept an allocation for this page in the first 
1MB of memory to avoid the BIOS pages. No idea if this patch will fix it 
for others but perhaps it will. :)


Mike


Index: agp_i810.c
===
RCS file: /cvsroot/src/sys/dev/pci/agp_i810.c,v
retrieving revision 1.112.2.2
diff -u -r1.112.2.2 agp_i810.c
--- agp_i810.c  17 Mar 2015 17:52:49 -  1.112.2.2
+++ agp_i810.c  3 Apr 2015 20:53:41 -
@@ -646,7 +646,7 @@
minaddr = PAGE_SIZE;/* XXX PCIBIOS_MIN_MEM?  */
maxaddr = MIN(UINT64_MAX, ~(bus_addr_t)0);
}
-
+   minaddr = 0x10; /* Stay out of ISA mem/BIOS area */
/* Allocate or map a pre-allocated a page for it.  */
if (ISSET(addr, 1)) {
/* BIOS allocated it for us.  Use that.  */

Re: Problem with kvm utilities on acorn32

[Mike Pumford]

David Brownlee wrote:

On 23 April 2014 19:14, Mike Pumford mpumf...@black-star.demon.co.uk wrote:

Not sure how arch specific this is but I'm seeing a problem with various KVM
utilities on a 6.99.40 system on acorn32.

e.g

$ vmstat -i
vmstat: undefined symbols: _pool_head


Having searched the source code this symbol is a static variable in
subr_pool.c and looking at the .o file for that I see:
$ nm -n subr_pool.o | grep pool_head
0024 d pool_head
06d8 b pool_head_lock

However neither of these symbols appear in the output of 'nm -n netbsd'

Do we need to do some compiler magic to stop these symbols being optimized
out of the kernel or do the kvm utils need to be modified to accept the fact
that not all platforms will have the symbol?


Presumably it should be enough to make pool_head non static - eg:
change the def in subr_pool.c to

/* List of all pools. Non static as needed by vmstat */
TAILQ_HEAD(, pool) pool_head = TAILQ_HEAD_INITIALIZER(pool_head);


Yep that works.

Prebuilt kernel in case its easier to test... (my acorn32 box is at
the bottom of a very large pile of house contents)

Thanks for that but my kernel has quite a few tweaks as I'm trying to a 
little bit of modernization on the acorn32 specific code. In particular 
I'm tweaking the interrupt accounting to use event counters rather than 
the legacy method. My code was working with systat vmstat but I thought 
I ought to make sure the other kvm utilities that use those counters 
worked. :)


Mike

Problem with kvm utilities on acorn32

[Mike Pumford]

Not sure how arch specific this is but I'm seeing a problem with various 
KVM utilities on a 6.99.40 system on acorn32.


e.g

$ vmstat -i
vmstat: undefined symbols: _pool_head


Having searched the source code this symbol is a static variable in 
subr_pool.c and looking at the .o file for that I see:

$ nm -n subr_pool.o | grep pool_head
0024 d pool_head
06d8 b pool_head_lock

However neither of these symbols appear in the output of 'nm -n netbsd'

Do we need to do some compiler magic to stop these symbols being 
optimized out of the kernel or do the kvm utils need to be modified to 
accept the fact that not all platforms will have the symbol?


Mike