Re: cpu1: failed to start (amd64)

[Michael Taylor]

On 2018-05-26 00:21, Greg Troxel wrote:

Did you try no SMP, but leaving ACPI?

It would help to give motherboard brand/model, too,

Thanks Greg, it successfully boots with ACPI and no SMP.
  (see attached dmesg-no-smp.txt)

The motherboard is an Intel DG965WH.

I tried adding some aprint_normal_dev() calls to cpu_hatch() but was
having difficulty seeing the output as it scrolled past. So I started
removing devices from the kernel config and stumbled upon a combination
that allowed the kernel to boot. For the time being I have stopped this
printf debugging to follow up device config combinations.

The kernel boots if I remove
  uhci* at pci? dev ? function ?
but then the USB drive is not detected and the boot device is not found.

The system has five uchi entries across two dev numbers. Enabling 
specific

devices such as:
  uhci4 at pci0 dev 29 function 2
allows the kernel to boot, but I have not yet got it to detect the USB
drive in any combinations I have tried so far.

If I enable all five devices specifying dev and function numbers then it
boots but pauses for a very long time (maybe 30+ seconds). I wondered if
there USB retries/errors not being displayed so I turned on USBVERBOSE
but saw no additional output.

Any more suggestions to direct my trouble shooting?

Is it worth connecting up a serial output to capture failed boots? I can
then continue the printf debugging technique but am unsure of what I am
looking for...

Michael.Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018 The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.1.2 (GENERIC.201803151611Z)
total memory = 4021 MB
avail memory = 3887 MB
kern.module.path=/stand/amd64/7.1/modules
timecounter: Timecounters tick every 10.000 msec
RTC BIOS diagnostic error 0x80
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
  ( 
   )
mainbus0 (root)
ACPI: RSDP 0xfe020 14 (v00 INTEL )
ACPI: RSDT 0xcf6fd038 50 (v01 INTEL  DG965WH  0697  0113)
ACPI: FACP 0xcf6fc000 74 (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: DSDT 0xcf6f7000 0040ED (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: FACS 0xcf6a 40
ACPI: APIC 0xcf6f6000 78 (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: WDDT 0xcf6f5000 40 (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: MCFG 0xcf6f4000 3C (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: ASF! 0xcf6f3000 A6 (v32 INTEL  DG965WH  0697 MSFT 0113)
ACPI: HPET 0xcf6f2000 38 (v01 INTEL  DG965WH  0697 MSFT 0113)
ACPI: SSDT 0xcf6f 0001BC (v01 INTEL CpuPm 0697 MSFT 0113)
ACPI: SSDT 0xcf6ef000 000175 (v01 INTEL   Cpu0Ist 0697 MSFT 0113)
ACPI: SSDT 0xcf6ee000 000175 (v01 INTEL   Cpu1Ist 0697 MSFT 0113)
ACPI: SSDT 0xcf6ed000 000175 (v01 INTEL   Cpu2Ist 0697 MSFT 0113)
ACPI: SSDT 0xcf6ec000 000175 (v01 INTEL   Cpu3Ist 0697 MSFT 0113)
ACPI: All ACPI Tables successfully acquired
ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 24 pins
cpu0 at mainbus0 apid 0: Intel(R) Core(TM)2 Quad CPUQ6600  @ 2.40GHz, id 
0x6fb
cpu1 at mainbus0 apid 2: multiprocessor boot disabled
cpu2 at mainbus0 apid 1: multiprocessor boot disabled
cpu3 at mainbus0 apid 3: multiprocessor boot disabled
acpi0 at mainbus0: Intel ACPICA 20131218
acpi0: X/RSDT: OemId , AslId <,0113>
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
acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button
IOCM (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43,0x50-0x53 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
XTRA (PNP0C02) at acpi0 not configured
ECP (PNP0401) at acpi0 not configured
pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1
UAR1 (PNP0501) at acpi0 not configured
IELK (AWY0001) at acpi0 not configured
APIC (PNP0003) at acpi0 not configured
ACPI: Enabled 4 GPEs in block 00 to 1F
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] 
(20131218/hwxface-646)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] 
(20131218/hwxface-646)
attimer1: attached to pcppi1
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x29a0 (rev. 0x02)
agp0 at pchb0: i965-family chipset
agp0: detected 7676k stolen memory
agp0: aperture at 0x

PR kern/52468

[glitch]

I was directed toward emailing this address from IRC concerning a patch 
submitted with kern/52486 -- is there anything I need to do to get this patch 
accepted and merged in? It fixes ISA DMA's mapping of an inappropriate I/O port 
as one of the ISA DMA page registers and includes some clean-up (comments, 
replacing magic numbers with named constants). I'm running the patches in 
production for some day-job embedded hardware and would like to be able to run 
stock kernel once we go to NetBSD 8.0.

Thanks,

Jonathan Chapman
The Glitch Works
http://www.glitchwrks.com/

Re: PWM and user space API

[Jason Thorpe]

> On May 28, 2018, at 2:43 PM, Jason Thorpe  wrote:
> 
> The PCA9685 also doesn’t have a variable clock UNLESS it’s driven by an 
> external clock source, in which case a pre-scaler value can be applied 
> (though, I’m not 100% certain on this — need to re-read the data sheet).  So 
> having to configure the period as the current API requires is kind of 
> inconvenient.


Ah, I did, in fact, mis-read the data sheet.

The PWM period is set by the following formula:

pre_scale = round((clock / (4096 * period)) - 1;

…regardless of internal or external clock.

So, my objection to having to set the period is hereby withdrawn :-)

-- thorpej

Re: PWM and user space API

[Robert Swindells]

Jason Thorpe  wrote:
>I’m going to be writing a driver for the NXP PCA9685, and want to glue
>it into the PWM kernel API jmcneill@ added… but I have a bunch of uses
>for this device that won’t really be covered by FDT, so I think there
>needs to be some sort of user space API as well.

Some of the Xilinx Zynq based boards have used different .dtb files
to describe different FPGA bitstreams.

Re: PWM and user space API

[Jason Thorpe]

> On May 28, 2018, at 11:09 AM, Jason Thorpe  wrote:
> 
> I’m going to be writing a driver for the NXP PCA9685, and want to glue it 
> into the PWM kernel API jmcneill@ added… but I have a bunch of uses for this 
> device that won’t really be covered by FDT, so I think there needs to be some 
> sort of user space API as well.

Actually, while I’m at it, there are some other problems with the current API, 
trying to think of how I would adjust it…

The PCA9685 is fairly simple in that it basically has 2 comparators per channel 
that reference a 12-bit counter that’s either driven by the internal 25MHz 
oscillator, or an external clock source that can run up to 50MHz.

There an “ON” value and an “OFF” value.  When the counter is equal to the ON 
value, the output is asserted.  When the counter is equal to the OFF value, the 
counter is de-asserted.  The advantage of this is that it, if you’re 
referencing multiple PCA9685s to the same external clock, you can do any 
phase-shift compensation as necessary by setting the ON time for a group of 
channels to non-zero.  The current API doesn’t have any way to express this.

The PCA9685 also doesn’t have a variable clock UNLESS it’s driven by an 
external clock source, in which case a pre-scaler value can be applied (though, 
I’m not 100% certain on this — need to re-read the data sheet).  So having to 
configure the period as the current API requires is kind of inconvenient.

-- thorpej

Re: PWM and user space API

[Jared McNeill]

On Mon, 28 May 2018, Jason Thorpe wrote:


I’m going to be writing a driver for the NXP PCA9685, and want to glue it into 
the PWM kernel API jmcneill@ added… but I have a bunch of uses for this device 
that won’t really be covered by FDT, so I think there needs to be some sort of 
user space API as well.

I have to say that I’m growing frustrated with the proliferation of ioctl-based 
APIs and *ctl programs.  I’m tempted to start doing more of this stuff with 
sysctl(), and then perhaps hiding the details from applications inside a shared 
library API that exposes only opaque types and accessors / mutators.  (Gawd, 
historically, BSD has done such a terrible job at API design…)

My concern about sysctl(), though, is that because of the way it’s structured, 
you’ve got a latency problem, which is not a concern in my application, but 
might be an issue if you have an application that needs to control a servo 
using PWM.

Curious to hear your thoughts on this.


I do this from time to time, mostly out of laziness (sys/dev/led.c for 
example). Biggest issue I have is that with sysctl we lose the ability to 
use chmod/chown/chgrp.

PWM and user space API

[Jason Thorpe]

I’m going to be writing a driver for the NXP PCA9685, and want to glue it into 
the PWM kernel API jmcneill@ added… but I have a bunch of uses for this device 
that won’t really be covered by FDT, so I think there needs to be some sort of 
user space API as well.

I have to say that I’m growing frustrated with the proliferation of ioctl-based 
APIs and *ctl programs.  I’m tempted to start doing more of this stuff with 
sysctl(), and then perhaps hiding the details from applications inside a shared 
library API that exposes only opaque types and accessors / mutators.  (Gawd, 
historically, BSD has done such a terrible job at API design…)

My concern about sysctl(), though, is that because of the way it’s structured, 
you’ve got a latency problem, which is not a concern in my application, but 
might be an issue if you have an application that needs to control a servo 
using PWM.

Curious to hear your thoughts on this.

-- thorpej

Re: Asymmetric Disk I/O priorities in a RAIDframe RAID1?

[Greg Oster]

On Mon, 28 May 2018 10:27:46 +0200
Hauke Fath  wrote:

> All,
> 
> is there a way in RAIDframe to give a member of a RAID1 set read 
> priority, to e.g. favour reads from an SSD over rotating rust or
> iscsi?
> 
> The Linux mdadm(8) software raid config tool has the following option:
> 
> 
> "[...] devices listed in a --build, --create, or --add command will
> be flagged as 'write-mostly'. This is valid for RAID1 only and means
> that the 'md' driver will avoid reading from these devices if at all 
> possible. This can be useful if mirroring over a slow link."
> 
> 
> Can RAIDframe do anything similar?

No... RAIDframe basically selects the component with the shortest
queue.  If queue lengths are equal, then it tries to pick the component
where the data you want is 'nearest' to the last data item being
fetched in the queue (see rf_dagutils.c:rf_SelectMirrorDiskIdle()).

Later...

Greg Oster

Asymmetric Disk I/O priorities in a RAIDframe RAID1?

[Hauke Fath]

All,

is there a way in RAIDframe to give a member of a RAID1 set read 
priority, to e.g. favour reads from an SSD over rotating rust or iscsi?


The Linux mdadm(8) software raid config tool has the following option:


"[...] devices listed in a --build, --create, or --add command will be 
flagged as 'write-mostly'. This is valid for RAID1 only and means that 
the 'md' driver will avoid reading from these devices if at all 
possible. This can be useful if mirroring over a slow link."



Can RAIDframe do anything similar?

Cheerio,
hauke

--
 The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
 Respect for open standards  Ruf +49-6151-16-21344

Re: QEMU/NetBSD status wiki page

[Warner Losh]

On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski  wrote:

> On 27.05.2018 16:53, Warner Losh wrote:
> >
> >
> > On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  > > wrote:
> >
> > As requested, I've prepared a QEMU/NetBSD status page:
> >
> > http://wiki.netbsd.org/users/kamil/qemu/
> > 
> >
> > I've attempted to be rather conservative with claims that something
> > works, without detailed verification.
> >
> >
> > FreeBSD has a complete QEMU user-mode implementation in a branch right
> > now. It's sufficiently advanced we build all our arm, arm64 and mips
> > packages using it. What's in upstream QEMU is totally, totally broken.
> > The work breaks things down so the common BSD could be shared. Starting
> > from that base would be a huge leg up to getting things working.
> >
>
> Thank you for the feedback.
>
> I would like to stress that In my point of view - whether bluetooth or
> vde is 100% functional - doesn't really matter in the context of:
>
>  - user mode emulation
>  - hardware assisted virtualization
>  - virtio
>  - vhost
>  - device passthrough
>
> Once that will work well, getting this or that library for compression
> of images of GUI is a matter packaging in tools.
>
> We can consider whether to collect the native kernel implementation of
> nbd from Bitrig, as it was required for at least a single ARM evaluation
> board in a bootstrap/booting process.
>
>
> The HQEMU project can be very useful for releng, as we can boost
> emulation of e.g. ARM by a factor of 3-20x on a amd64 host (exact boost
> times depend on the type of executed code), run the tests more quickly
> and save precious time and CPU cycles.


Haven't investigated that.


>
> > I'm in the process of getting it upstream. FreeBSD's branch is a royal
> > mess that has all the usual problem with a git branch that has lots of
> > merges applied: it had become almost impossible to rebase. I've sorted
> > most of that out, and am now sorting out collapsing down all the bug
> > fixes and/or qemu API changes that happened over the years so each
> > change in my branch is buildable. That should land this summer, maybe in
> > time for 3.0, but maybe not.
> >
>
> How close is this code to linux-user? I think that maintaining a concept
> of bsd-user in 2018 is obsolete, new code in one BSD can be closer to
> Linux or Solaris than other BSDs.
>

I'm not sure I follow this logic at all. The BSDs share a base that's quite
similar, even if new bits aren't similar. Have you looked at the code I'm
upstreaming? See the bsd-user branch in
https://github.com/seanbruno/qemu-bsd-user for details. It actually works
today, so it's not obsolete. It might be better not shared, but since that
doesn't exist today, I can't judge those efforts.


> Ideally we should go for [unix-]user shared between Linux and BSDs, add
> OS specific differences in dedicated {linux,freebsd,netbsd}-user,
> splitting NetBSD and FreeBSD.
>

I used to think that but no longer. There's a lot of code to deal with
threading and vm differences that insinuates itself into a lot of code. I'm
not so sure that sharing between Linux and anything else is really all that
sane, though there's some commonality. Without substantial changes in
upstream behavior, it will also result in lots of breakage as the code
velocity there is fast and often times the changes made are no good for BSD.


> For now please ignore NetBSD code in this upstreaming process.
>

I'm upstreaming exactly what we have, which moves the current netbsd/opensd
to their own subdirectory of bsd-user. The code in upstream is currently
totally broken, and this won't break it any more. My efforts are to push up
the code we have today that works really really well and nothing further.
Any cross-bsd or pan-unix efforts will post-date my upstreaming since those
do not exist today.

Warner

Re: QEMU/NetBSD status wiki page

[Warner Losh]

On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  wrote:

> As requested, I've prepared a QEMU/NetBSD status page:
>
> http://wiki.netbsd.org/users/kamil/qemu/
>
> I've attempted to be rather conservative with claims that something
> works, without detailed verification.
>

FreeBSD has a complete QEMU user-mode implementation in a branch right now.
It's sufficiently advanced we build all our arm, arm64 and mips packages
using it. What's in upstream QEMU is totally, totally broken. The work
breaks things down so the common BSD could be shared. Starting from that
base would be a huge leg up to getting things working.

I'm in the process of getting it upstream. FreeBSD's branch is a royal mess
that has all the usual problem with a git branch that has lots of merges
applied: it had become almost impossible to rebase. I've sorted most of
that out, and am now sorting out collapsing down all the bug fixes and/or
qemu API changes that happened over the years so each change in my branch
is buildable. That should land this summer, maybe in time for 3.0, but
maybe not.

Warner