Re: ThinkPad battery charge control

[Dave Tyson]

On Thu, 2024-04-25 at 21:54 -0400, Malte Dehling wrote:
> Hi,
> 
> I've added some things to the thinkpad acpi driver to allow modifying
> battery charging behavior: keep charge within a range, force
> discharge,
> disable charging on AC.  I think something like this would be good to
> have in NetBSD, but not necessarily how I implemented it.  So this is
> mainly a request for discussion :)
> 
> I've attached patches for reference and in case anyone wants to use
> them
> -- tested on my old X230 and W530 but based on my reading and
> studying
> acpidumps the same should work on most newer models.
> 
> On Linux and FreeBSD people just make acpi calls from userspace it
> seems, usually hidden away in tools like TLP.
> 
> OpenBSD recently added sysctls hw.battery.{chargestart,chargestop,
> chargemode} to provide this functionality (supported currently only
> by
> the thinkpad and apple silicon drivers.)  The approach is simple, but
> not as flexible as I would like:
> - It doesn't let you control charging behavior of individual
> batteries.
> - There are reasons to want to control charge_inhibit and
>   force_discharge modes separately.
> 
> Finally, a question: The ACPI standard has for a long time had
> (optional) _BMD & _BMC methods to control charging of control method
> batteries.  Has anyone seen these implemented in the wild?
> 
> Cheers,

Hi Malte,

I applied your patch to NetBSD-10.0_STABLE successfully and tested the
kernel on a thinkpad T420s. I set charge_stop=85 and charge_start=15. 
With the laptop on mains it stopped charging the battery at the 85%
value. I switched force_discharge=1 and ran a build release to put some
load on, the battery level dropped down and sailed past 15% towards
zero - the thinkpad alarm alerted me and a quick unplug/replug of the
power lead started recharging it. I had vaguely hoped that as the 15%
level was breached the charging of the battery might restart
automatically, i.e force_discharge would reset to zero :-)

I think this is a really useful feature as there seems to be a view
that charging li-ion cells to 100% reduces their life and it is best to
avoid discharging them below 15%. These figures are what Samsung
recommend on mobiles phones. 

Cheers,
Dave

support for Raspberry Pi zero 2 w

[Dave Tyson]

Can someone take a look at PR kern/57498 which includes patches and
links to resources to provide a native dtb for the rpi02w and also update the 
rpi firmware so it will boot up. Dmesg after updates below.
Note although the wifi chip is now visible the rpi02w uses the
synatics syn43436 and this needs different firmware. This is available
on some linux distros and does get the wifi working, but it's a bit
flaky and will need some work on the bwfm driver.

Cheers,
Dave 

[   1.000] NetBSD/evbarm (fdt) booting ...
[   1.000] [ Kernel symbol table missing! ]
[   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003,
[   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
2012, 2013,
[   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021,
2022, 2023
[   1.000] The NetBSD Foundation, Inc.  All rights reserved.
[   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.000] The Regents of the University of California.  All
rights reserved.

[   1.000] NetBSD 10.99.4 (GENERIC) #0: Wed Jun 28 20:06:55 BST
2023
[   1.000]  r...@cruncher.anduin.org.uk:/usr/obj/arm7/sys/arch/evba
rm/compile/GENERIC
[   1.000] total memory = 448 MB
[   1.000] avail memory = 422 MB
[   1.000] armfdt0 (root)
[   1.000] simplebus0 at armfdt0: Raspberry Pi Zero 2 W Rev 1.0
[   1.000] simplebus1 at simplebus0
[   1.000] simplebus2 at simplebus0
[   1.000] cpus0 at simplebus0
[   1.000] simplebus3 at simplebus0
[   1.000] cpu0 at cpus0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)
[   1.000] cpu0: DC enabled IC enabled WB enabled EABT branch
prediction enabled
[   1.000] cpu0: L1 32KB/64B 2-way (256 set) VIPT Instruction cache
[   1.000] cpu0: L1 32KB/64B 4-way (128 set) write-back-locking-C
PIPT Data cache
[   1.000] cpu0: L2 512KB/64B 16-way (512 set) write-through PIPT
Unified cache
[   1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN
propagation, denormals
[   1.000] cpu1 at cpus0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)
[   1.000] cpu1: DC enabled IC enabled WB enabled EABT branch
prediction enabled
[   1.000] cpu1: L1 32KB/64B 2-way (256 set) VIPT Instruction cache
[   1.000] cpu1: L1 32KB/64B 4-way (128 set) write-back-locking-C
PIPT Data cache
[   1.000] cpu1: L2 512KB/64B 16-way (512 set) write-through PIPT
Unified cache
[   1.000] vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN
propagation, denormals
[   1.000] cpu2 at cpus0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)
[   1.000] cpu2: DC enabled IC enabled WB enabled EABT branch
prediction enabled
[   1.000] cpu2: L1 32KB/64B 2-way (256 set) VIPT Instruction cache
[   1.000] cpu2: L1 32KB/64B 4-way (128 set) write-back-locking-C
PIPT Data cache
[   1.000] cpu2: L2 512KB/64B 16-way (512 set) write-through PIPT
Unified cache
[   1.000] vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN
propagation, denormals
[   1.000] cpu3 at cpus0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core)
[   1.000] cpu3: DC enabled IC enabled WB enabled EABT branch
prediction enabled
[   1.000] cpu3: L1 32KB/64B 2-way (256 set) VIPT Instruction cache
[   1.000] cpu3: L1 32KB/64B 4-way (128 set) write-back-locking-C
PIPT Data cache
[   1.000] cpu3: L2 512KB/64B 16-way (512 set) write-through PIPT
Unified cache
[   1.000] vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN
propagation, denormals
[   1.000] bcmicu0 at simplebus1
[   1.000] fclock0 at simplebus2: 1920 Hz fixed clock (osc)
[   1.000] bcmcprman0 at simplebus1: BCM283x Clock Controller
[   1.000] bcmaux0 at simplebus1
[   1.000] fclock1 at simplebus2: 48000 Hz fixed clock (otg)
[   1.000] bcmicu1 at simplebus1: Multiprocessor
[   1.000] syscon0 at simplebus1: couldn't get registers
[   1.000] gtmr0 at simplebus0: Generic Timer
[   1.000] gtmr0: interrupting on local_intc irq 3
[   1.000] armgtmr0 at gtmr0: Generic Timer (19200 kHz, virtual)
[   1.040] plcom0 at simplebus1: ARM PL011 UART
[   1.040] plcom0: txfifo 16 bytes
[   1.040] plcom0: interrupting on icu irq 57
[   1.040] com0 at simplebus1: BCM AUX UART, 1-byte FIFO
[   1.040] com0: console
[   1.040] com0: interrupting on icu irq 29
[   1.040] usbnopphy0 at simplebus0: USB PHY
[   1.040] /soc/thermal@7e212000 at simplebus1 not configured
[   1.040] bcmgpio0 at simplebus1: GPIO controller 2835
[   1.040] bcmgpio0: pins 0..31 interrupting on icu irq 49
[   1.040] bcmgpio0: pins 32..54 interrupting on icu irq 50
[   1.040] gpio0 at bcmgpio0: 54 pins
[   1.040] bcmdmac0 at simplebus1: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7
DMA8 DMA9 DMA10 DMA11
[   1.040] /soc/power at simplebus1 not configured
[   1.040] mmcpwrseq0 at simplebus0: Simple MMC power sequence
provider
[   1.040] bsciic0 at simplebus1: Broadcom Serial Controller
[   1.040] bsciic0: interrupting on icu irq 53
[   1.040] iic0 

Anyone having a problem with cross building arm* tools on current?

[Dave Tyson]

With a very recent checkout of NetBSD-current I am seeing a failure to
build tools on arm6, aarch64 (and probably arm7), build.sh bombs out:

dependall-dtc ===> .(with: dependall-makestrs dependall-makekeys
dependall-cvslatest)
dependall ===> makestrs
nbmake[2]: nbmake[2]: don't know how to make makestrs.c. Stop

nbmake[2]: stopped in /usr/src/tools/makestrs

*** Failed target:  dependall-makestrs
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this=""; real="/usr/src/tools" ;; *) this="${dir}/";
real="/usr/src/tools/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/arm6/bin/nbmake _THISDIR_="${this}" "$@" ${target};
}; _makedirtarget makestrs dependall
*** Error code 2

Stop.
nbmake[1]: stopped in /usr/src/tools

Dave

Re: Raspberry Pi camera under NetBSD current

[Dave Tyson]

On Monday 01 Nov 2021 09:42:57 Michael van Elst wrote:
> dty...@anduin.org.uk (Dave Tyson) writes:
> >> Trying to access the camera with raspistill however ends in a crash
> >> in the vchiq driver.
> >
> >Thanks for the data point. I guess there may be significant differences in
> >the microcode files between the RPI1B and RPI3b+, but at least the kernel
> >loaded OK for you so the sdcard driver works. I have turned on debugging
> >for the broadcom sdcard hooks and got a few hints as to where the problem
> >lies - but need to look closely at the source to pin point the failure. Of
> >course, even if I can get further I may still suffer the same crash with
> >raspistill. FreeBSD works OK and I can get pictures, so I know it is
> >achievable.
> I had a little success now with the camara and raspistill.
> 
> http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/cam.jpg
> 
> The file is slightly corrupted (truncated?) but can be displayed.

I pulled down the latest snapshot produced by  Jun Ebihara on 6th November. 
This boots fine on a Raspberry 1B & Pi zero but not on a Pi zero 2. The 
snapshot does not include start_x.elf and start_db.elf and associated fixup 
files so I used the 4 sets of start/fixup versions shipped with raspian and 
the system booted OK with start_x=1 in the config file.

The good news is raspistill worked fine with the --nopreview option and I 
could capture a reasonable image OK. (if you omit the --nopreview option it 
succeeds in displaying the image but crashes shortly after)

I tried to get it to take a sequence of still shots at a rate of 10/sec (using 
-tl 100) and that seemed to work OK, but after a while the kernel reports:

dwc2_host_complete: unknown error status -54 a couple of times 
and then a slew of usb devices detach including the ethernet, keyboard etc. 
and that seems to be game over :-(

Still at least its progress. I notice that there is an open source camera 
stack for Raspberry Pi using libcamera - might have a play with that under 
raspian and see if it can be ported to NetBSD.

https://www.raspberrypi.com/news/an-open-source-camera-stack-for-raspberry-pi-using-libcamera/

Dave

Re: Raspberry Pi camera under NetBSD current

[Dave Tyson]

On Wednesday 27 Oct 2021 20:07:53 Dave Tyson wrote:
> On Wednesday 27 Oct 2021 18:28:31 Michael van Elst wrote:
> > dty...@anduin.org.uk (Dave Tyson) writes:
> > >I have been trying to get the raspberry pi camera to work on a model B
> > >under a recent current snapshot.
> > >
> > > NetBSD 9.99.88 (RPI) #0: Fri Sep 24 18:47:29 UTC 2021
> > > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/RPI
> > >
> > >As standard booting off the sdcard works fine with the default
> > >config.txt,
> > >but to use the camera you need to modify this to add  start_x=1 and set
> > >the
> > >gpu mem to 128.  With the changed options you need different microcode
> > >files in the /boot partition start_x.elf and fixup_x.dat. NetBSD doesn't
> > >supply these, but I pulled versions from the git repository.
> > >
> > >The problem is that the system boots, but fails to attach the sdcard and
> > >thus cannot find root,

The attached diff of the boot messages shows some extra commands are issued to 
the bcmsdhost module in the failing case. I guess the calling sdmmc module 
doesn't like some of the data from the calls, tries to recover and fails. I'll 
try and understand the logic...

Dave NetBSD/evbarm (fdt) booting
 NetBSD/evbarm (fdt) booting 
 [ Kernel symbol table missing! 
 [ Kernel symbol table missing! 
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,  
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 
2002, 2003, 2004, 2005,
 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 
2014, 2015, 2016, 2017,
 2018, 2019, 2020, 2021 The NetBSD Foundation, Inc  All rights reserved 
 2018, 2019, 2020, 2021 The NetBSD Foundation, Inc  
All rights reserved
 Copyright (c) 1982, 1986, 1989, 1991, 1993 
 Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California  All rights reserved   
 The Regents of the University of California  All 
rights reserved
 NetBSD 9.99.92 (RPI) #2: Tue Oct 26 21:20:04 BST 2021  
 NetBSD 9.99.92 (RPI) #2: Tue Oct 26 21:20:04 BST 2021
root@cruncheranduinorguk:/usr/armobj/sys/arch/evbarm/compile/RPI

root@cruncheranduinorguk:/usr/armobj/sys/arch/evbarm/compile/RPI
 total memory = 384 MB  
   | total memory = 128 MB
 avail memory = 366 MB  
   | avail memory = 115 MB
 armfdt0 (root) 
 armfdt0 (root)
 simplebus0 at armfdt0: Raspberry Pi Model B Rev 2  
 simplebus0 at armfdt0: Raspberry Pi Model B Rev 2
 simplebus1 at simplebus0   
 simplebus1 at simplebus0
 simplebus2 at simplebus0   
 simplebus2 at simplebus0
 simplebus3 at simplebus0   
 simplebus3 at simplebus0
 cpus0 at simplebus0
 cpus0 at simplebus0
 cpu0 at cpus0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK core) 
 cpu0 at cpus0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK 
core)
 cpu0: DC enabled IC enabled WB enabled LABT
 cpu0: DC enabled IC enabled WB enabled LABT
 cpu0: L1 16KB/32B 4-way (128 set) VIPT Instruction cache   
 cpu0: L1 16KB/32B 4-way (128 set) VIPT Instruction 
cache
 cpu0: L1 16KB/32B 4-way (128 set) write-back-locking-C VIPT Data cache 
 cpu0: L1 16KB/32B 4-way (128 set) write-back-locking-C 
VIPT Data cache
 vfp0 at cpu0: VFP11, rounding, exceptions  
 vfp0 at cpu0: VFP11, rounding, exceptions
 fclock0 at simplebus2: 1920 Hz fixed clock (osc)   
 fclock0 at simplebus2: 1920 Hz fixed clock (osc)
 fclock1 at simplebus2: 48000 Hz fixed clock (otg)  
 fclock1 at simplebus2: 48000 Hz fixe

Re: Raspberry Pi camera under NetBSD current

[Dave Tyson]

On Wednesday 27 Oct 2021 18:28:31 Michael van Elst wrote:
> dty...@anduin.org.uk (Dave Tyson) writes:
> >I have been trying to get the raspberry pi camera to work on a model B
> >under a recent current snapshot.
> >
> > NetBSD 9.99.88 (RPI) #0: Fri Sep 24 18:47:29 UTC 2021
> > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/RPI
> >
> >As standard booting off the sdcard works fine with the default config.txt,
> >but to use the camera you need to modify this to add  start_x=1 and set the
> >gpu mem to 128.  With the changed options you need different microcode
> >files in the /boot partition start_x.elf and fixup_x.dat. NetBSD doesn't
> >supply these, but I pulled versions from the git repository.
> >
> >The problem is that the system boots, but fails to attach the sdcard and
> >thus cannot find root,
> 
> I just tried this with an older 9.99.81 installation on a RPI3b+
> and a recent snapshot of the firmware files (around August) and
> NetBSD boots without a problem.
> 
> Trying to access the camera with raspistill however ends in a crash
> in the vchiq driver.

Thanks for the data point. I guess there may be significant differences in the 
microcode files between the RPI1B and RPI3b+, but at least the kernel loaded 
OK for you so the sdcard driver works. I have turned on debugging for the 
broadcom sdcard hooks and got a few hints as to where the problem lies - but 
need to look closely at the source to pin point the failure. Of course, even 
if I can get further I may still suffer the same crash with raspistill. 
FreeBSD works OK and I can get pictures, so I know it is achievable.

Dave 

Raspberry Pi camera under NetBSD current

[Dave Tyson]

I have been trying to get the raspberry pi camera to work on a model B under a 
recent current snapshot. 

 NetBSD 9.99.88 (RPI) #0: Fri Sep 24 18:47:29 UTC 2021
 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/RPI

As standard booting off the sdcard works fine with the default config.txt,
but to use the camera you need to modify this to add  start_x=1 and set the 
gpu mem to 128.  With the changed options you need different microcode files 
in the /boot partition start_x.elf and fixup_x.dat. NetBSD doesn't supply 
these, but I pulled versions from the git repository.

The problem is that the system boots, but fails to attach the sdcard and thus 
cannot find root, Looking at the dmesg's from the two boots (screen shots for 
the failing one) it seems something goes wrong, but the error is poorly 
reported, A sort of diff between the dmesgs shows:

 -[ 1.00] total memory = 384 MB
 -[ 1.00] avail memory = 366 MB
+[ 1.00] total memory = 128 MB
+[ 1.00] avail memory = 115 MB

 -[ 1.00] genfb0: framebuffer at 0x5e6fa000, size 1280x1024, depth 32, 
stride 5120
+[ 1.00] genfb0: framebuffer at 0x4e6fa000, size 1280x1024, depth 32, 
stride 5120

 [ 1.180396] sdmmc0: direct I/O error 5, r=6 p=0xc8733f14 write
-[ 1.230495] sdmmc0: SD card status: 4-bit, C6
-[ 1.230495] ld0 at sdmmc0: <0x03:0x5344:SU08G:0x80:0x020d4db4:0x0c5>
-[ 1.230495] ld0: 7580 MB, 3850 cyl, 64 head, 63 sec, 512 bytes/sect x 
15523840 sectors
-[ 1.240524] ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
+sdmmc0: autoconfiguration error: can't get SD status 5
+sdmmc0: autoconfiguration error: mem init failed
+sdmmc0: autoconfiguration error: init failed 

At first I thought the sdmmc0: direct I/O error 5, r=6 p=0xc8733f14 write
message was the problem, but that appears on the successful boot as well.

Irritatingly FreeBSD seems to work OK with the camera - but I really would 
prefer NetBSD.

I can compile a kernel with some debugging for the sdcard, but thought others 
may have run into this problem

Cheers,
Dave

Re: help getting SPI interface to work

[Dave Tyson]

On Monday 20 Sep 2021 09:34:21 Michael van Elst wrote:
> dty...@anduin.org.uk (Dave Tyson) writes:
> >/dev/spi0 is defined which is a good start::
> >
> >[ 1.03] sun4ispi0 at simplebus1: SPI
> >[ 1.03] sun4ispi0: interrupting on GIC irq 42
> >[ 1.03] spi0 at sun4ispi0: SPI bus
> >
> >The board has the SPI mos1/miso/clk together with cs0 and cs1.
> >
> >Looking at spi(4) there is no mention of a way to control cs0/1 to select
> >devices so I guess this is down to using gpio commands to pull the
> >appropriate pin low.
> 
> The spi driver gets an address parameter that may control which cs line
> is asserted. It depends on the hardware if that is actually used.
> 
> On these devices, the SPI controller is multiplexed on GPIO pins. You
> need to activate the function. This can be done by providing the
> proper DTB file or overlay, it _could_ also be done with the gpio
> driver (selecting an alt mode), but the sunxi gpio driver doesn't
> support that.
> 
> >command = 0  ;  /*we are not sending anything */
> >spit.sit_addr =  0x00 ;
> >spit.sit_send =  ;
> 
> if you don't send anything, use NULL.
> 
> >The device just needs the register address sending and should return a
> >single byte with the contents.
> 
> Not sure what you want to control, but most devices require a
> read command to actually send data. The read command then usually
> includes the register address, sit_addr is not the register address
> but selects a slave device.

Thanks to the info - I hadn't realised the sit_addr selected the slave device 
- will have a look at the DTB file and look to see how things are wired up in 
the kernel.

Cheers,
Dave

help getting SPI interface to work

[Dave Tyson]

Having managed to get the I2C interface on a Banana pi  running a recent 
current snapshot [talking to at least one device correctly] I decided to  try 

/dev/spi0 is defined which is a good start::

[ 1.03] sun4ispi0 at simplebus1: SPI
[ 1.03] sun4ispi0: interrupting on GIC irq 42
[ 1.03] spi0 at sun4ispi0: SPI bus

The board has the SPI mos1/miso/clk together with cs0 and cs1. 

Looking at spi(4) there is no mention of a way to control cs0/1 to select 
devices so I guess this is down to using gpio commands to pull the appropriate 
pin low. As a temporary measure I tied the cs on the MAX31865 to 0v. This 
might not work if there are timing issues...

#include 
int main()
{
int spifd ;
spi_ioctl_transfer_t spit ;
uint8_t command, result ;

if ((spifd = open("/dev/spi0", O_RDWR)) == -1) {
printf("failed to open /dev/spi0 code=%d\n",errno) ;
exit(1) ;
}

command = 0  ;  /*we are not sending anything */
spit.sit_addr =  0x00 ;
spit.sit_send =  ;
spit.sit_sendlen = 0 ;
spit.sit_recv =  ;
spit.sit_recvlen = 1;
if ((ioctl(spifd, SPI_IOCTL_TRANSFER, )) !=0) {
printf("control reg read failed %d\n",errno) ;
exit(1) ;
}

printf("control reg = %X\n", result) ;
close(spifd) ;
}

First stab at reading the control register (addr 0x00) fails with errno 22. 
kdump isn't helpful:

 CALL  ioctl(3,SPI_IOCTL_TRANSFER,0x7ff94658)
  1104   1104 pt100GIO   fd 3 wrote 20 bytes
   "\0\0\0\0WF\M-y\^?\0\0\0\0VF\M-y\^?\^A\0\0\0"
  1104   1104 pt100RET   ioctl -1 errno 22 Invalid argument

The device just needs the register address sending and should return a single 
byte with the contents. I assumed that the default spi clock/mode etc. would 
be OK but I am a bit clueless at present. Anyone got the spi interface working 
on an SOC board or similar?

 (I have a raspberry pi B/orange pi's as well as the banana pi)

Cheers,
Dave

Re: Question about using I2C_IOCTL_EXEC to read data over I2C

[Dave Tyson]

On Tuesday 17 Aug 2021 10:32:50 Jason Thorpe wrote:
> > On Aug 17, 2021, at 10:28 AM, Dave Tyson  wrote:
> > 
> > The device appears at address 0x77 (it's a BMP085) with i2cscan, the data
> > sheet indicates the read address=0xEF/write address=0xEE. I just put 0x77
> > in the address field and assume the read/write bit on the wire is added
> > based on the op code (I2C_OP_WRITE, I2C_OP_READ etc).
> 
> Yes, that's correct.  NetBSD natively addresses i2c devices using the 7-bit
> address **without** the read/write bit on the wire.  As you noted, 0xef and
> 0xee shifted right 1 bit results in 0x77.
> > The device has R/O calibration data in 22 contiguous registers starting at
> > 0xAA->0xBF. Linux programs seem to grab the data in one go starting at
> > 0xAA. The other registers needed to initiate a sensor data grab are R/W -
> > you write a control byte into the 0xF4 register, wait a bit and then read
> > the data from another register set.
> > 
> > A naive attempt to read the calibration data using:
> >command = 0xAA ;
> >iie.iie_op = I2C_OP_READ ;
> >iie.iie_addr = 0x77 ;
> >iie.iie_cmd =  ;
> >iie.iie_cmdlen = 1 ;
> >iie.iie_buf = [0] ;
> >iie.iie_buflen = 22;
> >if ((ioctl(iicfd, I2C_IOCTL_EXEC, )) !=0) {
> >
> >printf("read failed %d\n",errno) ;
> >exit(1) ;
> >   
> >   }
> > 
> > actually seemed to work OK, but I don't understand why!
> 
> Looks right to me!  I can explain to you why :-)
> 
> Under the covers, NetBSD did the write and turn-around for you because you
> specified a "cmd".  It performed a START (with the READ bit as 0), wrote
> the command bytes, then performed a REPEATED START with the READ bit set
> and then performed the READ.  You probably should have used
> I2C_OP_READ_WITH_STOP because that was the end of your transaction.
> > I had expected to need a I2C_OP_WRITE first followed by a
> > I2C_OP_READ_STOP.
> > The former would send a start bit, the device addr/write bit and the
> > target
> > register. The latter would send a (re)start bit, device addr/read bit,
> > pull
> > the data back and issue a stop. Maybe because the register I am addressing
> > is R/O there is no need for a write and what I am doing is correct... (or
> > do I need a I2C_OP_READ_STOP)
> 
> > Could someone explain what actually gets sent on the wire for the various 
ops:
> Ok, gotta page this one back into my brain from the archives, but here
> 'goes...
> > I2C_OP_READ
> 
> If a "cmd" is specified, performs a START-WRITE, writes the cmd bytes, then
> performs a REPEATED-START-READ to read the data bytes (and performs a NACK
> after the last byte read).  Errors result in a STOP condition.
> 
> If no "cmd" is specified, similar to above except no START-WRITE is issued
> (REPEATED-START-READ and START-READ are the same on the wire).
> > I2C_OP_READ_WITH_STOP
> 
> As above, but sets a STOP condition afterwards always.
> 
> > I2C_OP_WRITE
> 
> Sends a START-WRITE, then writes "cmd" bytes if provided and then data
> bytes.  Errors result in a STOP condition.
> > I2C_OP_WRITE_WITH_STOP
> 
> As above, but sets a STOP condition afterwards always.
> 
> > I2C_OP_READ_BLOCK
> > I2C_OP_WRITE_BLOCK
> > 
> > and what difference block operations make as man ICC(4) is terse to say
> > the
> > least.
> 
> The BLOCK operations are specific to SMBus block mode transfers.  I don't
> know how much testing actually has been done with it (I know there are
> several i2c controller drivers that do not correctly support it).
> 
> -- thorpej

Thanks Paul and Jason! Great to know how I2C_OP_READ worked behind the scenes 
and that the block operations may not work. 

Cheers,
Dave

Question about using I2C_IOCTL_EXEC to read data over I2C

[Dave Tyson]

I am trying to get data from a temperature/pressure sensor connected via i2c 
to a banana pi running NetBSD current. I understand the I2C protocol but I am 
having a bit of difficulty understanding what appears on the wire when the 
I2C_IOCTL_EXEC is called with the various op commands. By trial and error I 
seem to have been able to read the data, but want to check a few things in 
case I am doing it all wrong :-)

The device appears at address 0x77 (it's a BMP085) with i2cscan, the data 
sheet indicates the read address=0xEF/write address=0xEE. I just put 0x77 in 
the address field and assume the read/write bit on the wire is added based on 
the op code (I2C_OP_WRITE, I2C_OP_READ etc).

The device has R/O calibration data in 22 contiguous registers starting at 
0xAA->0xBF. Linux programs seem to grab the data in one go starting at 0xAA. 
The other registers needed to initiate a sensor data grab are R/W - you write 
a control byte into the 0xF4 register, wait a bit and then read the data from 
another register set.

A naive attempt to read the calibration data using:

command = 0xAA ;
iie.iie_op = I2C_OP_READ ;
iie.iie_addr = 0x77 ;
iie.iie_cmd =  ;
iie.iie_cmdlen = 1 ;
iie.iie_buf = [0] ;
iie.iie_buflen = 22;
if ((ioctl(iicfd, I2C_IOCTL_EXEC, )) !=0) {
printf("read failed %d\n",errno) ;
exit(1) ;
   }

actually seemed to work OK, but I don't understand why!

I had expected to need a I2C_OP_WRITE first followed by a I2C_OP_READ_STOP. 
The former would send a start bit, the device addr/write bit and the target 
register. The latter would send a (re)start bit, device addr/read bit, pull 
the data back and issue a stop. Maybe because the register I am addressing is 
R/O there is no need for a write and what I am doing is correct... (or do I 
need a I2C_OP_READ_STOP)

Could someone explain what actually gets sent on the wire for the various ops:

I2C_OP_READ
I2C_OP_READ_WITH_STOP
I2C_OP_WRITE
I2C_OP_WRITE_WITH_STOP
I2C_OP_READ_BLOCK 
I2C_OP_WRITE_BLOCK

and what difference block operations make as man ICC(4) is terse to say the 
least.

Cheers,
Dave

Re: Orange pi support for i2c

[Dave Tyson]

On Sunday 08 Aug 2021 08:31:57 Martin Husemann wrote:
> On Sat, Aug 07, 2021 at 09:54:40PM +0000, Dave Tyson wrote:
> > One other issue I noted with the latter two boards is that ethernet no
> > longer works - this may be related  to changes to the phy support
> > introduced in 2019, but I will only be able to confirm this by bisecting
> > when I get a bit of free time.
> 
> FWIW: I netboot a orange pi zero regularily (I use it for testing USB device
> drivers) and don't have any problems with the ethernet.
> 
> Martin

Just pulled NetBSD 9.2 STABLE off the releng site and ethernet works fine... 
Maybe there was an issue with the snapshot of NetBSD current from a couple of 
days ago and I was unlucky :-( Thanks for the feedback.

Cheers,
Dave. 

Re: Orange pi support for i2c

[Dave Tyson]

On Saturday 07 Aug 2021 23:50:09 Tobias Nygren wrote:
> On Sat, 07 Aug 2021 21:54:40 +
> 
> Dave Tyson  wrote:
> > The Banana pi seems to work OK with i2c with light testing, but I would
> > really like a more 'lightweight' platform like the Orange pi zero or
> > Orange pi one. Under a recent current both these boot up OK, but there
> > doesn't appear to be any support for i2c - how hard would that be to add?
> 
> Already supported -- but you need to enable the i2c nodes in the device tree
> with a dtb overlay. It will be something like below. You'll have to consult
> the data sheet to see if any of the respective i2c controller's pins are
> used for conflicting purposes.
> 
> --- sys/arch/arm/dts/sun8i-h3-orangepi-one.dts  30 Nov 2017 21:39:35 -  
>1.3 +++ sys/arch/arm/dts/sun8i-h3-orangepi-one.dts  7 Aug 2021 21:47:46
> - @@ -29,3 +29,12 @@
>  #include
> "../../../external/gpl2/dts/dist/arch/arm/boot/dts/sun8i-h3-orangepi-one.dt
> s" #include "sun8i-h3.dtsi"
> 
> + {
> +status = "okay";
> +};
> + {
> +status = "okay";
> +};
> + {
> +status = "okay";
> +};

Ok, thanks for the quick response! - will consult the data sheet and give it a 
try.later in the week then report back

Cheers,
Dave

Orange pi support for i2c

[Dave Tyson]

I have been testing a few SOC systems for i2c support as I have a need to 
replace a failing weather station. Tried a raspberry pi B on the latest 
current and that seems to still suffer the problem outlined in PR48855 which 
has been closed, but need to be reopened.

The Banana pi seems to work OK with i2c with light testing, but I would really 
like a more 'lightweight' platform like the Orange pi zero or Orange pi one. 
Under a recent current both these boot up OK, but there doesn't appear to be 
any support for i2c - how hard would that be to add?

One other issue I noted with the latter two boards is that ethernet no longer 
works - this may be related  to changes to the phy support introduced in 2019, 
but I will only be able to confirm this by bisecting when I get a bit of free 
time.

Cheers,
Dave

Re: Script command under NetBSD-current

[Dave Tyson]

On Tuesday 15 Jun 2021 08:15:12 RVP wrote:
> On Mon, 14 Jun 2021, Dave Tyson wrote:
> > NetBSD cruncher2.anduin.org.uk 9.99.83 NetBSD 9.99.83 (GENERIC) #2: Tue
> > Jun  8 19:42:49 GMT 2021
> > r...@cruncher2.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
> > 
> > If you issue a script command, run a process with takes a little while and
> > then an exit command to close the script file and return to a command
> > prompt. viz:
> > 
> > cd /usr/pkgsrc
> > script /tmp/ll
> > cvs update -dP
> > exit
> > 
> > what happens is you don't get a command prompt - its like the script
> > command
> > freezes and doesn't return. Issuing a ps shows the script processes:
> The small patch below fixes it for me.
> 
> --- START PATCH ---
> --- libexec/ld.elf_so.orig/rtld.c 2020-09-22 00:41:27.0 +
> +++ libexec/ld.elf_so/rtld.c  2021-06-15 08:11:34.301709238 +
> @@ -1750,6 +1750,8 @@
>   sigdelset(, SIGTRAP); /* Allow the debugger */
>   sigprocmask(SIG_BLOCK, , mask);
> 
> + membar_enter();
> +
>   for (;;) {
>   if (atomic_cas_uint(&_rtld_mutex, 0, locked_value) == 0) {
>   membar_enter();
> --- END PATCH ---
> 
> -RVP

Thanks for the fast response and fix. I can confirm the patch fixes the 
problem. Please can this be committed

Cheers,
Dave 

Script command under NetBSD-current

[Dave Tyson]

I thought I noticed an issue with the script command under NetBSD-current a 
few weeks ago, but recently stumbled on it again.

This is under:

NetBSD cruncher2.anduin.org.uk 9.99.83 NetBSD 9.99.83 (GENERIC) #2: Tue Jun  8 
19:42:49 GMT 2021  
r...@cruncher2.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64

If you issue a script command, run a process with takes a little while and 
then an exit command to close the script file and return to a command prompt. 
viz: 

cd /usr/pkgsrc
script /tmp/ll
cvs update -dP
exit

what happens is you don't get a command prompt - its like the script command 
freezes and doesn't return. Issuing a ps shows the script processes:

USER PID %CPU %MEM   VSZ   RSS TTY   STAT STARTEDTIME COMMAND  UID  
PID PPID  CPU PRI NI   VSZ   RSS WCHAN   STAT TTY  TIME COMMAND
root1250  0.0  0.0 17812  1516 pts/0 I+5:40PM 0:00.00 script 0 
1250 11150  85  0 17812  1516 ttyraw  I+   pts/0 0:00.00 script /tmp/ll 
root1252  0.0  0.0 17924  1304 pts/0 I+5:40PM 0:00.32 script 0 
1252 12500  43  0 17924  1304 parked  I+   pts/0 0:00.32 script /tmp/ll 

Both appear to be idle. Killing the parent process returns a command prompt.

Anyone else seeing this?

Dave

Re: wip/wine64 on amd64

[Dave Tyson]

On Saturday 04 Apr 2020 21:44:42 Thomas Klausner wrote:
> Hi!
> 
> I've just fixed the compat32* packages so that they built for me. Then
> I tried running two programs with wip/wine64 (see
> https://blog.netbsd.org/tnf/entry/porting_wine_to_amd64_on1)
> 
> The first one is a c# application. wine automatically installed the
> mono and gecko packages for me, but then it kept the "please wait"
> window up forever. (Can't share this one.)
> 
> So I tried again something I expected to work, notepad++
> https://notepad-plus-plus.org/downloads/v7.8.5/
> (the 32-bit x86 version)
> 
> The installer works fine, but when I try to run it, I see
> 
> DLL signature verification failed: Unknown exception occurred. File not
> found.
> 
> Library verification failed: Authentication check failed: signing
> certificate or hash is not recognized.
> 
> Win32Exception: An exception occurred. Notepad++ cannot recover and must be
> shut down (... details ...)
> 
> Setting "sysctl -w user_va0_disable=0" doesn't fix this.
> 
> How do others fare with wine on NetBSD?
> 
> Cheers,
>  Thomas

Cannot really comment about 32bit compatibility but I've been using Wine64 
(from wip) under 9.99.23 (with NetBSD -8 userland) quite successfully. I use 
it to run Memory Map (mapping software) version 5.0 from 2005. It works really 
well and while I have had seen a few glitches, these also happen on Windows 
7...

Dave 

backporting USER_LDT to NetBSD-8

[Dave Tyson]

I've been playing with wine64 under NetBSD 8.1_STABLE and it works 
surprisingly well with a couple of windows applications I need to run. Of 
course NetBSD-8 doesn't have support for USER_LDT baked in and so I have been 
testing under a NetBSD current kernel. 

How much work would be involved in back-porting it to NetBSD-8?

I know NetBSD-9 might be a better option, but in my experience kde doesn't 
work well with it :-(

Cheers,
Dave

arm make release failure when building BEAGLEBONE

[Dave Tyson]

This is from the current source tree a little earlier today, cross 
compiling arm on amd64:

./build.sh -j 4 -U -u -x -m evbearmv7hf-el -O /home/dtyson/cross/obj -T 
/home/dtyson/cross/tools release

Might be fallout from the ata changes..
...
#   compile  compat/uipc_syscalls_30.o
/home/dtyson/cross/tools/bin/armv7--netbsdelf-eabihf-gcc -mfloat-
abi=soft -ffreestanding -fno-zero-initialized-in-bss  -O2 -fno-strict-
aliasing -fno-common -std=gnu99   -Werror -
Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-
prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow 
-Wcast-qual -Wwrite-strings -Wno-unreachable-
code -Wno-pointer-sign -Wno-attributes -Wno-sign-compare--
sysroot=/home/dtyson/cross/obj/destdir.evbarm -mcpu=cortex-a8 -mfpu=neon 
-DKERNEL_BASES_EQUAL -DKERNEL_BASE_VOFFSET=0 -I
../../. -I/home/dtyson/cross/src/sys/../common/lib/libx86emu -
I/home/dtyson/cross/src/sys/../common/include -
I/home/dtyson/cross/src/sys/arch -I/home/dtyson/cross/src/sys -nostdinc 
-
D__HAVE_CPU_COUNTER -D__HAVE_CPU_UAREA_ALLOC_IDLELWP -
D__HAVE_FAST_SOFTINTS -D__HAVE_MM_MD_DIRECT_MAPPED_PHYS -
DKERNEL_BASE_EXT="0x8000" -DARM_GENERIC_TODR -DCOMPAT_44 -DDIAGNOST
IC -DDEBUG -D_KERNEL -D_KERNEL_OPT -std=gnu99 -
I/home/dtyson/cross/src/sys/lib/libkern/../../../common/lib/libc/quad -
I/home/dtyson/cross/src/sys/lib/libkern/../../../common/lib/libc
/string -
I/home/dtyson/cross/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string
  
--sysroot=/home/dtyson/cross/obj/destdir.evbarm  -c
/home/dtyson/cross/src/sys/compat/co
mmon/uipc_syscalls_30.c -o uipc_syscalls_30.o
--- kern-BEAGLEBOARD ---
ata.o: In function `atabusioctl':
ata.c:(.text+0x26e0): undefined reference to `atabus_cd'
ata.c:(.text+0x26f0): undefined reference to `atabus_cd'
ata.o: In function `atabusopen':
ata.c:(.text+0x2a7c): undefined reference to `atabus_cd'
ata.c:(.text+0x2a8c): undefined reference to `atabus_cd'
ata.o: In function `atabusclose':
ata.c:(.text+0x2b50): undefined reference to `atabus_cd'
ata.o:ata.c:(.text+0x2b60): more undefined references to `atabus_cd' 
follow
--- kern-BEAGLEBONE ---

-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Re: Peculiar problem with kmail on AMD64 current

[Dave Tyson]

On Monday 06 February 2017 09:44:17 Martin Husemann wrote:
> On Sun, Feb 05, 2017 at 06:51:19PM +0000, Dave Tyson wrote:
> > So it would appear that a userland program which should be insulated
> > from the underlying hardware by the kernel is being affected by different
> > H/W.
> Can you show the output from
> 
>   cpuctl identify 0
> 
> on both machines?
> 
> Some userland software detects cpu features at build time and hard codes
> that decsion into the binaries. This is a bug, of course.
> 
> Martin


Hi Martin,

Idents below.

Laptop which works:

laptoproot(laptop)root$ cpuctl identify 0
cpu0: highest basic info 000d
cpu0: highest extended info 8008
cpu0: "Intel(R) Core(TM)2 Duo CPU P8600  @ 2.40GHz"
cpu0: Intel Xeon 31xx, 33xx, 52xx, 54xx, Core 2 Quad 8xxx and 9xxx (686-
class), 2394.13 MHz
cpu0: family 0x6 model 0x17 stepping 0xa (id 0x1067a)
cpu0: features 
0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE>
cpu0: features 0xbfebfbff<MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2>
cpu0: features 0xbfebfbff<SS,HTT,TM,SBF>
cpu0: features1 0xc08e3fd<SSE3,DTES64,MONITOR,DS-CPL,VMX,SMX,EST,TM2,SSSE3>
cpu0: features1 0xc08e3fd<CX16,xTPR,PDCM,SSE41,XSAVE,OSXSAVE>
cpu0: features2 0x2800
cpu0: features3 0x1
cpu0: xsave features 0x3<x87,SSE>
cpu0: xsave area size: current 576, maximum 576, xgetbv enabled
cpu0: enabled xsave 0x3<x87,SSE>
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 3MB 64B/line 12-way
cpu0: 64B prefetching
cpu0: ITLB 128 4KB entries 4-way, 8 2M/4 4M entries
cpu0: DTLB 256 4KB entries 4-way, 16 4MB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: DSPM-eax 0x3<DTS,IDA>
cpu0: DSPM-ecx 0x3
cpu0: SEF highest subleaf 
cpu0: microcode version 0xa0c, platform ID 7

Desktop which doesn't:

cruncherroot(cruncher)root$ cpuctl identify 0
cpu0: highest basic info 000d
cpu0: highest extended info 8008
cpu0: "Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz"
cpu0: Intel Xeon E3-12xx, 2nd gen i7, i5, i3 2xxx (686-class), 2993.40 MHz
cpu0: family 0x6 model 0x2a stepping 0x7 (id 0x206a7)
cpu0: features 
0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE>
cpu0: features 0xbfebfbff<MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2>
cpu0: features 0xbfebfbff<SS,HTT,TM,SBF>
cpu0: features1 0x1f9ae3bf<SSE3,PCLMULQDQ,DTES64,MONITOR,DS-CPL,VMX,EST,TM2>
cpu0: features1 0x1f9ae3bf<SSSE3,CX16,xTPR,PDCM,PCID,SSE41,SSE42,POPCNT>
cpu0: features1 0x1f9ae3bf<DEADLINE,AES,XSAVE,OSXSAVE,AVX>
cpu0: features2 0x28100800
cpu0: features3 0x1
cpu0: xsave features 0x7<x87,SSE,AVX>
cpu0: xsave instructions 0x1
cpu0: xsave area size: current 832, maximum 832, xgetbv enabled
cpu0: enabled xsave 0x7<x87,SSE,AVX>
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 256KB 64B/line 8-way
cpu0: L3 cache 6MB 64B/line 12-way
cpu0: 64B prefetching
cpu0: ITLB 128 4KB entries 4-way, 2M/4M: 8 entries
cpu0: DTLB 64 4KB entries 4-way, 2M/4M: 32 entries (L0)
cpu0: L2 STLB 512 4KB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: DSPM-eax 0x77<DTS,IDA,ARAT,PLN,ECMD,PTM>
cpu0: DSPM-ecx 0x9<HWF,EPB>
cpu0: SEF highest subleaf 
cpu0: microcode version 0x23, platform ID 1

Dave

Re: crash with latest audio changes

[Dave Tyson]

On Saturday 17 Dec 2016 10:19:18 you wrote:
> On Dec 17,  2:51pm, dty...@anduin.org.uk (Dave Tyson) wrote:
> -- Subject: Re: crash with latest audio changes
> 
> | On Friday 16 Dec 2016 17:03:57 you wrote:
> | > On Dec 16,  9:37pm, dty...@anduin.org.uk (Dave Tyson) wrote:
> | > -- Subject: Re: crash with latest audio changes
> | > 
> | > | I've put in a few DPRINT's and turned on debugging. Need to add some
> | > | more
> | > | to pin it down but it looks like a call to AUDIO_MIXER_READ triggers
> | > | the
> | > | problem
> | > 
> | > Thanks! I made it error out in audio_enter, so it should catch all the
> | > cases.
> | > 
> | > christos
> | 
> | Hi cristos,
> | It didn't fix the problem - still crashes in same area. I have had a bit
> | more of a poke around and think I know where the problem lies. If you
> | look at this
> | section of code in audio.c:
> Thank you! The logic there is obviously broken. I think I understand what
> it tries to do, and I fixed it. Really nat@ should take a look. At least
> it should stop crashing now.
> 
> christos

Hi Christos,

Thanks for the fixes. I can confirm audio.c version 1.283 has fixed the 
problem and KDE comes up fine with sound working!

Dave

-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Re: crash with latest audio changes

[Dave Tyson]

On Friday 16 Dec 2016 16:13:35 Christos Zoulas wrote:
> In article <35284500.x7lh1kd...@cruncher.anduin.org.uk>,
> 
> Dave Tyson  <dty...@anduin.org.uk> wrote:
> >I updated a DELL system from 7.99.39 (Oct 13th) to the latest current (Dec
> >16th). When I bring up KDE the newer kernel panics in the audio code, works
> >fine with older kernel. I guess this relates to the recent in-kernel mixer
> >changes.
> 
> I just committed something that should help with this. Can you try again
> and also look in dmesg about where the attach for audio fails?
> 
> thanks,
> christos

OK, CVS'ed up and rebuilt a new kernel. This crashes in the same way and the 
backtrace looked identical so I just checked that I hadn't loaded the earlier 
kernel. ident showed it had audio.c 1.280 Phew! 

uvm_fault(0xfe811cc93730, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 80641d0f cs 8 rflags 10246 cr2 71a ilevel 0 rsp 
fe8040445c00
curlwp 0xfe8118d8d1e0 pid 481.1 lowest kstack 0xfe80404422c0
panic: trap
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0xc76
--- trap (number 6) ---
audio_get_port() at netbsd:audio_get_port+0x7e
audioioctl() at netbsd:audioioctl+0x84
VOP_IOCTL() at netbsd:VOP_IOCTL+0x3b
vn_ioctl() at netbsd:vn_ioctl+0xa6
sys_ioctl() at netbsd:sys_ioctl+0x101
syscall() at netbsd:syscall+0x1df
--- syscall (number 54) ---
7aefaaae933a:
cpu1: End traceback...

Dave

-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

crash with latest audio changes

[Dave Tyson]

I updated a DELL system from 7.99.39 (Oct 13th) to the latest current (Dec 
16th). When I bring up KDE the newer kernel panics in the audio code, works 
fine with older kernel. I guess this relates to the recent in-kernel mixer 
changes.

NetBSD 7.99.50 (GENERIC) #0: Fri Dec 16 13:49:41 GMT 2016
r...@dell.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC
total memory = 4060 MB
avail memory = 3922 MB
rnd: seeded with 128 bits
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
Dell Inc. Vostro 230(00)
mainbus0 (root)
ACPI: RSDP 0x000F96F0 24 (v02 ACPIAM)
ACPI: XSDT 0xBDD30100 5C (v01 DELL   WN09 20100707 MSFT 
0097)
ACPI: FACP 0xBDD30290 F4 (v04 DELL   FACP0152 20100707 MSFT 
0097)
ACPI: DSDT 0xBDD305C0 0058F2 (v02 1  1000  INTL 
20051117)
ACPI: FACS 0xBDD3E000 40
ACPI: FACS 0xBDD3E000 40
ACPI: APIC 0xBDD30390 6C (v02 DELL   APIC0152 20100707 MSFT 
0097)
ACPI: MCFG 0xBDD30400 3C (v01 DELL   OEMMCFG  20100707 MSFT 
0097)
ACPI: SLIC 0xBDD30440 000176 (v01 DELL   WN09 20100707 MSFT 
0097)
ACPI: OEMB 0xBDD3E040 72 (v01 DELL   OEMB0152 20100707 MSFT 
0097)
ACPI: HPET 0xBDD3A5C0 38 (v01 DELL   OEMHPET  20100707 MSFT 
0097)
ACPI: GSCI 0xBDD3E0C0 002024 (v01 DELL   GMCHSCI  20100707 MSFT 
0097)
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: 1 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 24 pins
cpu0 at mainbus0 apid 0
cpu0: Pentium(R) Dual-Core  CPU  E6500  @ 2.93GHz, id 0x1067a
cpu1 at mainbus0 apid 1
cpu1: Pentium(R) Dual-Core  CPU  E6500  @ 2.93GHz, id 0x1067a
acpi0 at mainbus0: Intel ACPICA 20160930
acpi0: X/RSDT: OemId , AslId 
acpi0: MCFG: segment 0, bus 0-255, address 0xe000
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
MCH (PNP0C01) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
UAR1 (PNP0501) at acpi0 not configured
pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1
SIOR (PNP0C02) at acpi0 not configured
RMSC (PNP0C02) at acpi0 not configured
FWH (INT0800) at acpi0 not configured
FWHE (PNP0C02) at acpi0 not configured
OMSC (PNP0C02) at acpi0 not configured
PCIE (PNP0C02) at acpi0 not configured
RMEM (PNP0C01) at acpi0 not configured
acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
ACPI: Enabled 2 GPEs in block 00 to 1F
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 8086 product 2e30 (rev. 0x03)
agp0 at pchb0: G4X-family chipset
agp0: detected 32252k stolen memory
agp0: aperture at 0xd000, size 0x1000
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 2e32 (rev. 0x03)
drm: Memory usable by graphics device = 512M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0x80004819, size 1280x1024, depth 32, stride 
5120
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0
wsmux1: connecting to wsdisplay0
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdafg0 at hdaudio0: vendor 10ec product 0662
hdafg0: DAC00 2ch: Speaker [Jack]
hdafg0: DAC01 2ch: HP Out [Jack]
hdafg0: ADC02 2ch: Line In [Jack], Mic In [Jack]
hdafg0: ADC03 2ch: Mic In [Jack]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
spkr1 at audio0: PC Speaker (synthesized)
ppb0 at pci0 dev 28 function 0: vendor 8086 product 27d0 (rev. 0x01)
ppb0: PCI Express capability version 1  x1 @ 
2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 2: vendor 8086 product 27d4 (rev. 0x01)
ppb1: PCI Express capability version 1  x1 @ 
2.5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
bge0 at pci2 dev 0 function 0: Broadcom BCM57788 Fast Ethernet
bge0: interrupting at msi1 vec 0
bge0: HW config 000a0554, 4004, 0008,  
bge0: 

Re: xorg.conf is read but not acted on correctly

[Dave Tyson]

On Saturday 10 December 2016 22:51:32 Soren Jacobsen wrote:
> On 12/10 16:53, Dave Tyson wrote:
> > [  2175.541] Build Operating System: NetBSD/amd64  -
> > [...]
> > [  2175.542] (WW) The directory "/usr/X11R7/share/fonts/X11/TTF" does
> > not exist.
> 
> Update your trees (both src and xsrc) and do a clean build.  I fixed
> this about a month ago.
> 
> Soren

OK, thanks for the info, will update/rebuild once I get back home.  

A big thank you to everyone else who contributed ...

Cheers,
Dave

xorg.conf is read but not acted on correctly

[Dave Tyson]

I normally don't bother creating a /etc/X11/xorg.conf file as the built-in 
defaults generally work OK. I just tried to create one using X -configure and 
then edited it to (a) allow for ms-ttf font and (b) set the keyboard layout 
"uk"

I was slightly surprised that having the file xorg.conf present doesn't 
override any of the built-ins. What seems to happen is both are used, but some 
things in the xorg.conf are completely ignored - like things that aren't in 
the built-ins. So that the keyboard map stays at "us" and the type1 and 
freetype modules are ignored.

The built-in seems to have some unwanted paths to /usr/X11R7/share...

Maybe I am doing something stupid, but this seems to be unintuitive. Any help 
appreciated!

config file:

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath   "/usr/X11R7/lib/modules"
FontPath "/usr/X11R7/lib/X11/fonts/TTF"
FontPath "/usr/X11R7/lib/X11/fonts/Type1"
FontPath "/usr/X11R7/lib/X11/fonts/misc"
FontPath "/usr/X11R7/lib/X11/fonts/100dpi"
FontPath "/usr/X11R7/lib/X11/fonts/75dpi"
EndSection

Section "Module"
Load  "dri"
Load  "dri2"
Load  "glx"
Load  "shadow"
Load  "type1"
Load  "freetype"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
Option  "XkbdLayout" "uk"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "wsmouse"
Option  "Device" "/dev/wsmouse"
Option  "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName"Monitor Model"
EndSection

Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "NoAccel"   # []
#Option "AccelMethod"   # 
#Option "Backlight" # 
#Option "DRI"   # 
#Option "Present"   # []
#Option "ColorKey"  # 
#Option "VideoKey"  # 
#Option "Tiling"# []
#Option "LinearFramebuffer" # []
#Option "VSync" # []
#Option "PageFlip"  # []
#Option "SwapbuffersWait"   # []
#Option "TripleBuffer"  # []
#Option "XvPreferOverlay"   # []
#Option "HotPlug"   # []
#Option "ReprobeOutputs"# []
#Option "DeleteUnusedDP12Displays"  # []
#Option "XvMC"  # []
#Option "ZaphodHeads"   # 
#Option "VirtualHeads"  # 
#Option "TearFree"  # []
#Option "PerCrtcPixmaps"# []
#Option "FallbackDebug" # []
#Option "DebugFlushBatches" # []
#Option "DebugFlushCaches"  # []
#Option "DebugWait" # []
#Option "BufferCache"   # []
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
SubSection "Display"
Viewport   0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection

log file:

[  2175.541] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[  2175.541] X Protocol Version 11, Revision 0
[  2175.541] Build Operating System: NetBSD/amd64  - 
[  2175.541] Current Operating System: NetBSD dell.anduin.org.uk 7.99.39 
NetBSD 7.99.39 (GENERIC) #0: Thu Oct 13 20:46:24 BST 2016  
r...@dell.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
[  2175.541] Build Date: 14 August 2016  01:29:29AM
[  2175.541]  
[  2175.541] Current version of pixman: 0.32.6
[  2175.541]Before reporting problems, check 

Re: xorg-server 1.18 ready for testing on x86 and shark

[Dave Tyson]

On Monday 22 Aug 2016 06:52:34 matthew green wrote:
> > nbmake[13]: nbmake[13]: don't know how to make
> > /usr/obj/external/mit/xorg/server/xorg-server/glamor/libglamor.a. Stop
> 
> ah, this is a simple ordering issue i had missed due to manually
> building this once..
> 
> please try with external/mit/xorg/server/xorg-server/Makefile rev 1.27.
> 
> thanks for testing!
> 
> 
> .mrg.

Hi Matthew,

thanks, that fixed the problem... build.sh release finished (with couple of 
unrelated errors due to unbound) and installed OK.

Light testing with Firefox 47 and a few other packages revealed no problems. 
I'll get kde & libreoffice installed in a few days and hit it a bit harder.

X.Org X Server 1.18.4
Release Date: 2016-07-19
[70.840] X Protocol Version 11, Revision 0
[70.840] Build Operating System: NetBSD/amd64  - 
[70.840] Current Operating System: NetBSD dell.anduin.org.uk 7.99.36 
NetBSD 7.99.36 (GENERIC) #0: Sat Aug 20 17:33:51 BST 2016  
r...@dell.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
[70.843] Build Date: 14 August 2016  01:29:29AM
[70.843]  
[70.852] Current version of pixman: 0.32.6
[70.852]Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
[70.852] Markers: (--) probed, (**) from config file, (==) default 
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[70.852] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 22 14:04:59 
2016
[70.875] (II) Loader magic: 0x10ba96c40
[70.875] (II) Module ABI versions:
[70.875]X.Org ANSI C Emulation: 0.4
[70.875]X.Org Video Driver: 20.0
[70.875]X.Org XInput driver : 22.1
[70.875]X.Org Server Extension : 9.0
[70.891] (--) PCI:*(0:0:2:0) 8086:2e32:1028:043e rev 3, Mem @ 
0xfe40/4194304, 0xd000/268435456, I/O @ 0xec00/8
[70.891] (==) Using default built-in configuration (30 lines)
[70.892] (==) --- Start of built-in configuration ---

[71.002] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[71.002] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[71.002] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[71.002] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 
6200, P6300
[71.002] (II) VESA: driver for VESA chipsets: vesa
[71.002] (--) Using wscons driver on /dev/ttyE4 in pcvt compatibility mode 
(version 3.32)
[71.002] (--) using VT number 5
[71.035] (II) intel(0): Using Kernel Mode Setting driver: i915, version 
1.6.0 20080730
[71.040] (WW) Falling back to old probe method for vesa
[71.041] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card 
support
[71.041] (--) intel(0): Integrated Graphics Chipset: Intel(R) G41
[71.041] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3
[71.041] (II) intel(0): Creating default Display subsection in Screen 
section
"Builtin Default intel Screen 0" for depth/fbbpp 24/32
[71.041] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[71.041] (==) intel(0): RGB weight 888
[71.041] (==) intel(0): Default visual is TrueColor
[71.060] (II) intel(0): Output VGA1 has no monitor section
[71.060] (II) intel(0): Enabled output VGA1
[71.060] (--) intel(0): Using a maximum size of 256x256 for hardware 
cursors
[71.060] (II) intel(0): Output VIRTUAL1 has no monitor section
[71.061] (II) intel(0): Enabled output VIRTUAL1
[71.061] (--) intel(0): Output VGA1 using initial mode 1280x1024 on pipe 0
[71.061] (==) intel(0): TearFree disabled
[71.061] (==) intel(0): DPI set to (96, 96)
[71.061] (II) Loading sub module "dri2"
[71.061] (II) LoadModule: "dri2"
[71.061] (II) Module "dri2" already built-in
[71.061] (II) UnloadModule: "vesa"
[71.061] (II) Unloading vesa
[71.061] (==) Depth 24 pixmap format is 32 bpp
[71.069] (II) intel(0): SNA initialized with Eaglelake (gen4.5) backend
[71.069] (==) intel(0): Backing store enabled
[71.069] (==) intel(0): Silken mouse enabled
[71.077] (II) intel(0): HW Cursor enabled
[71.077] (II) intel(0): RandR 1.2 enabled, ignore the following RandR 
disabled message.
[71.081] (==) intel(0): DPMS enabled
[71.084] (II) intel(0): [XvMC] xvmc_vld driver initialized.
[71.089] (II) intel(0): [DRI2] Setup complete
[71.089] (II) intel(0): [DRI2]   DRI driver: i965
[71.089] (II) intel(0): [DRI2]   VDPAU driver: i965
[71.089] (II) intel(0): direct rendering: DRI2 enabled
[71.089] (--) RandR disabled
[71.281] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[

Re: xorg-server 1.18 ready for testing on x86 and shark

[Dave Tyson]

cvs updated current src,xsrc earlier today and just had a try at building this 
with a clean obj directory and it blows up being unable to make libglamor.a

===> build.sh command:./build.sh -V HAVE_XORG_SERVER_VER=118 -u -U -x -T 
/usr/tools -O /usr/obj -j 2 release
===> build.sh started:Sun Aug 21 12:01:37 BST 2016
===> NetBSD version:  7.99.36
===> MACHINE: amd64
===> MACHINE_ARCH:x86_64
===> Build platform:  NetBSD 7.99.36 amd64
===> HOST_SH: /bin/sh
===> MAKECONF file:   /etc/mk.conf
#objdir  /usr/obj/tools
===> TOOLDIR path:/usr/tools
===> DESTDIR path:/usr/obj/destdir.amd64
===> RELEASEDIR path: /usr/obj/releasedir
===> Updated makewrapper: /usr/tools/bin/nbmake-amd64
--- release ---
distribution ===> .
--- distribution ---
build ===> .(with: NOPOSTINSTALL=1)
--- build ---
Build started at: Sun Aug 21 12:01:38 BST 2016
...
...
...
#create  Xorg/dummy.d
CC=/usr/tools/bin/x86_64--netbsd-gcc /usr/tools/bin/nbmkdep -f dummy.d.tmp  --  
 
-std=gnu99--sysroot=/usr/obj/destdir.amd64 -I/usr/xsrc/external/mit/xorg-
server/dist/include  
-I/usr/xsrc/external/mit/xorg-server/dist/Xext  -
I/usr/obj/destdir.amd64/usr/X11R7/include/pixman-1  -
I/usr/xsrc/external/mit/xorg-server/dist/../include -I/usr/obj/destdir.amd64/
usr/X11R7/include/X11  -I/usr/xsrc/external/mit/xorg-server/dist/fb  -
I/usr/xsrc/external/mit/xorg-server/dist/mi  -I/usr/xsrc/external/mit/xorg-
server/dist/include  -I/usr/xsrc/e
xternal/mit/xorg-server/dist/os  -I/usr/xsrc/external/mit/xorg-
server/dist/Xext  -I/usr/obj/destdir.amd64/usr/X11R7/include/X11/extensions  -
I/usr/obj/destdir.amd64/usr/X11R7/incl
ude/libdrm  -I/usr/obj/destdir.amd64/usr/X11R7/include/pixman-1  -
I/usr/obj/destdir.amd64/usr/X11R7/include/xorg  -I/usr/xsrc/external/mit/xorg-
server/dist/render  -DHAVE_DIX_CONF
IG_H -DDDXOSINIT -DSERVER_LOCK -DDDXOSFATALERROR  -DDDXOSVERRORF -DDDXTIME -
DUSB_HID -DHAVE_DIX_CONFIG_H -D_BSD_SOURCE -DHAS_FCHOWN  -DHAS_STICKY_DIR_BIT 
-D_POSIX_THREAD_SAFE_FUNC
TIONS  -DHAVE_XORG_CONFIG_H  -DMITMISC -DXTEST -DXTRAP -DXSYNC -DXCMISC  -
DXRECORD -DMITSHM -DBIGREQS -DXF86VIDMODE  -DXF86MISC -DDPMSExtension -DEVI  -
DSCREENSAVER -DXV -DXVMC -D
GLXEXT  -DRES  -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP  -DXCSECURITY -DTOGCUP 
-DXF86BIGFONT  -DDPMSExtension -DPIXPRIV -DPANORAMIX  -DRENDER -DRANDR -
DXFIXES -DDAMAGE  -DCOMPOSIT
E -DXEVIE -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING  -DGLX_USE_DLOPEN -
DGLX_USE_MESA -DXF86VIDMODE -D__GLX_ALIGN64  -DCSRG_BASED -DFUNCPROTO=15 -
DNARROWPROTO -I/usr/obj/destdir.am
d64/usr/X11R7/include -D__AMD64__ dummy.c &&  mv dummy.d.tmp dummy.d
--- .depend ---
#create  Xorg/.depend
rm -f .depend
CC=/usr/tools/bin/x86_64--netbsd-gcc /usr/tools/bin/nbmkdep -s .o\ .ln\ .d -d 
-f .depend dummy.d
--- dependall ---
--- .gdbinit ---
rm -f .gdbinit
echo "set solib-absolute-prefix /usr/obj/destdir.amd64" > .gdbinit
nbmake[13]: nbmake[13]: don't know how to make 
/usr/obj/external/mit/xorg/server/xorg-server/glamor/libglamor.a. Stop
nbmake[13]: stopped in /usr/src/external/mit/xorg/server/xorg-
server/hw/xfree86/Xorg
*** [dependall] Error code 2
nbmake[12]: stopped in /usr/src/external/mit/xorg/server/xorg-
server/hw/xfree86/Xorg
1 error
nbmake[12]: stopped in /usr/src/external/mit/xorg/server/xorg-
server/hw/xfree86/Xorg
*** [dependall-Xorg] Error code 2
...

Dave

-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Issues with netstat -ia

[Dave Tyson]

Just upgraded an amd64 system to the latest current - checked out and compiled 
8/7/16.

NetBSD dell.anduin.org.uk 7.99.33 NetBSD 7.99.33 (GENERIC) #0: Fri Jul  8 
15:30:25 BST 2016  
r...@dell.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64

I was building pkgsrc firefox 17.0.1 today and it seemed to be taking an 
inordinate time to configure and this appears to be due one of tools issuing 
netstat -ia and running up CPU.

A quick check showed netstat -i seems OK:

Name  Mtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
bge0  1500b8:ac:6f:c3:50:df   656074 0   337913 0 0
bge0  1500  default fe80::baac:6fff:f   656074 0   337913 0 0
bge0  1500  192/0   dell.anduin.org.u   656074 0   337913 0 0
lo0   336246 06 0 0
lo0   33624 127.0.0.1/32 localhost   6 06 0 0
lo0   33624 default ::1  6 06 0 0
lo0   33624 default fe80::1  6 06 0 0

but netstat -ia loops:

Name  Mtu   Network  Address  Ipkts IerrsOpkts Oerrs Colls
bge0  1500 b8:ac:6f:c3:50:df   655869 0   337865 0 0
bge0  1500  default  fe80::baac:6fff:f   655869 0   337865 0 0
netstat: kvm_read: Bad address
bge0  1500  192/0dell.anduin.org.u 
netstat: kvm_read: Bad address
  default   
netstat: kvm_read: Bad address
  default 
...

Anyone else seeing this?

Dave


-- 

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Re: nick-nhusb merge coming soon

[Dave Tyson]

On Wednesday 13 Apr 2016 07:59:20 Nick Hudson wrote:
> Hi,
> 
> I think the first phase of nick-nhusb is in a state ready to be
> merged. I'd like to merge it in the next few days, but in the meantime
> I've put some kernels for testing here:
> 
>  http://www.netbsd.org/~skrll/nick-nhusb
> 
> 
> Please test and report success or failure.
> 
> I can provide kernels to other platforms on request.
> 
> Thanks,
> Nick

Hi Nick,

I've done some testing with a couple of USB video cameras on amd64. I wanted 
to see if PR 48308 could be closed.

extract from dmesg:

uvideo0 at uhub4 port 5 configuration 1 interface 0: vendor 04f2 USB2.0 2MP 
UVC Camera, rev 2.00/1.00, addr 2
video0 at uvideo0: vendor 04f2 USB2.0 2MP UVC Camera, rev 2.00/1.00, addr 2
uaudio0 at uhub4 port 5 configuration 1 interface 2
uaudio0: vendor 04f2 USB2.0 2MP UVC Camera, rev 2.00/1.00, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent
uhidev0 at uhub1 port 2 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 2.00/30.00, addr 2, iclass 3/1
ums0 at uhidev0: 16 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
uhidev1 at uhub1 port 2 configuration 1 interface 1
uhidev1: Logitech USB Receiver, rev 2.00/30.00, addr 2, iclass 3/0
uhidev1: 17 report ids
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid2 at uhidev1 reportid 17: input=19, output=19, feature=0
uvideo1 at uhub4 port 6 configuration 1 interface 0: Generic USB2.0 PC CAMERA, 
rev 2.00/1.00, addr 3
video1 at uvideo1: Generic USB2.0 PC CAMERA, rev 2.00/1.00, addr 3
ehci0: handing over full speed device on port 7 to uhci3

Both cameras worked fine under nick-usb, but they also worked fine under 
current 7.99.27 (GENERIC.201604110150Z) from a couple of days ago :-) so 
something must have changed in current since PR 48308 was filed as I couldn't 
reproduce it now.

I could trigger a panic if I unplugged a camera while mplayer was running:

video0: detached
uvideo0: detached
uvideo0: at uhub4 port 6 (addr 2) disconnected
audio1: detached
uaudio0: detached
uaudio0: at uhub4 port 6 (addr 2) disconnected
usb_disconnect_port: no device
panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file 
"/wrk/nhusb/src/sys/arch/x86/x86/pmap.c", line 3315
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
valid_user_selector() at netbsd:valid_user_selector
pmap_remove_pte() at netbsd:pmap_remove_pte+0x311
pmap_remove() at netbsd:pmap_remove+0x1ff
uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x210
sys_munmap() at netbsd:sys_munmap+0x8a
syscall() at netbsd:syscall+0xbe
--- syscall (number 73) ---
7f7feb10d80a:
cpu1: End traceback...

I guess a panic in this situation is not unexpected. I have the core dump if 
you want it.

I'll try and get around to testing USB scanners and printers in a few days.

Cheers,
Dave


-- 
=
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
=

USB scanners and PR 50340

[Dave Tyson]

I note that PR 50340 has been closed and with the latest pkgsrc under current 
(amd64) my Mustek 1200 UB scanner seems to work OK - but I have comment out 
the uscanner device in the kernel and use it as a ugen device. It seems that 
this is the 'new world order' and the sane backend code to handle uscanner 
devices is deprecated. Given this is the case is there any point in still 
keeping the 

uscanner* at uhub? port ?

in GENERIC?

I am of the same opinion as the PR originator that it is easier to control 
access permissions with a uscanner device rather than having to open up a 
whole raft of ugen devices, but I guess the sane developers feel that using 
libusb makes support easier...   

Dave

-- 
=
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
=

USB crash with recent kernel on Raspberry Pi

[Dave Tyson]

Been playing with the latest R-Pi snapshot posted by Jun Ebihara on port-arm.
Hooked up a USB webcam and tried mplayer. I thought it might fail as I have an 
outstanding PR-48308 with UVC cameras and it did, but with a different crash.
Camera attached OK, but an ordinary user can crash kernel invoking mplayer:

export DISPLAY=192.168.0.110:0.0
mplayer tv:// -tv driver=v4l2:device=/dev/video0 -fps 30 


I can submit a pr for this if wanted and am happy to compile a new kernel with 
more diagnostics and or fixes :-)

Dave

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
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.99.26 (RPI.201602172150Z)
total memory = 448 MB
avail memory = 434 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0 core 0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK core)
cpu0: DC enabled IC enabled WB enabled LABT
cpu0: 16KB/32B 4-way L1 VIPT Instruction cache
cpu0: 16KB/32B 4-way write-back-locking-C L1 VIPT Data cache
vfp0 at cpu0: VFP11, rounding, exceptions
obio0 at mainbus0
bcmicu0 at obio0
bcmmbox0 at obio0 intr 65: VC mailbox
vcmbox0 at bcmmbox0
bcmtmr0 at obio0 intr 3: VC System Timer
vchiq0 at obio0 intr 66: BCM2835 VCHIQ
bcmpm0 at obio0: Power management, Reset and Watchdog controller
bcmdmac0 at obio0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10
bcmrng0 at obio0: RNG
plcom0 at obio0 intr 57
plcom0: txfifo disabled
plcom0: console
genfb0 at obio0no data for est. mode 640x480x67
: switching to framebuffer console
genfb0: framebuffer at 0x5e402000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
wsdisplay0: screen 1-3 added (default, vt100 emulation)
sdhc0 at obio0 intr 62: SDHC controller
sdhc0: interrupting on intr 62
dwctwo0 at obio0 intr 9: USB controller
bcmspi0 at obio0 intr 54: SPI
spi0 at bcmspi0: SPI bus
bsciic0 at obio0 intr 53: BSC0
iic0 at bsciic0: I2C bus
bsciic1 at obio0 intr 53: BSC1
iic1 at bsciic1: I2C bus
bcmgpio0 at obio0: GPIO [0...31]
gpio0 at bcmgpio0: 32 pins
bcmgpio1 at obio0: GPIO [32...53]
gpio1 at bcmgpio1: 22 pins
bcmcm at obio0 not configured
bcmpwm at obio0 not configured
usb0 at dwctwo0: USB revision 2.0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "bcmtmr0" frequency 100 Hz quality 100
sdhc0: SDHC 3.0, rev 153, platform DMA, 25 kHz, HS SDR50 3.3V, re-tuning 
mode 1, 1024 byte blocks
sdmmc0 at sdhc0 slot 0
uhub0 at usb0: vendor  DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
IPsec: Initialized Security Association Processing.
ld0 at sdmmc0: <0x03:0x5344:SU08G:0x80:0x19c44f4d:0x0c6>
ld0: 7580 MB, 3850 cyl, 64 head, 63 sec, 512 bytes/sect x 15523840 sectors
ld0: 4-bit width, SDR50, 100.000 MHz
uhub1 at uhub0 port 1: vendor 0424 product 9512, class 9/0, rev 2.00/2.00, 
addr 2
uhub1: multiple transaction translators
uhub1: 3 ports with 2 removable, self powered
usmsc0 at uhub1 port 1
usmsc0: vendor 0424 product ec00, rev 2.00/2.00, addr 3
usmsc0: Ethernet address b8:27:eb:cc:63:df
ukphy0 at usmsc0 phy 1: OUI 0x00800f, model 0x000c, rev. 3
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
uhidev0 at uhub1 port 2 configuration 1 interface 0
uhidev0: vendor 04f3 product 0103, rev 2.00/1.07, addr 4, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub1 port 2 configuration 1 interface 1
uhidev1: vendor 04f3 product 0103, rev 2.00/1.07, addr 4, iclass 3/0
uhidev1: 2 report ids
uhid0 at uhidev1 reportid 1: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0
uvideo0 at uhub1 port 3 configuration 1 interface 0: vendor 04f2 USB2.0 2MP 
UVC Camera, rev 2.00/1.00, addr 5
video0 at uvideo0: vendor 04f2 USB2.0 2MP UVC Camera, rev 2.00/1.00, addr 5
uaudio0 at uhub1 port 3 configuration 1 interface 2
uaudio0: vendor 04f2 USB2.0 2MP UVC Camera, rev 2.00/1.00, addr 5
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent
boot device: ld0
root on ld0a dumps on ld0b
root file system type: ffs
kern.module.path=/stand/evbarm/7.99.26/modules
vchiq: local ver 6 (min 3), remote ver 6.
vcaudio0 at vchiq0: auds
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
audio0 at vcaudio0: half duplex, playback, capture, independent
wsdisplay0: screen 4 added (default, vt100 emulation)
panic: kernel diagnostic assertion "xfertype != UE_ISOCHRONOUS || xfer-
>nframes < DWC2_MAXISOCPACKETS" failed: file 
"/usr/src/sys/external/bsd/dwc2/dwc2.c", line 1370 
cpu0: Begin traceback...
0x9b9a3a3c: netbsd:db_panic+0xc

Re: Latest amd64 snapshot has problems with disk sizes

[Dave Tyson]

This problem disappeared when a later snapshot was tried. The nightly build 
201512080650Z installed perfectly so I suspect the original was corrupt or the 
build ran during some updates which left parts inconsistent.

Dave

-- 
=
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
=

Latest amd64 snapshot has problems with disk sizes

[Dave Tyson]

Just tried to install current using the latest AMD64  snapshot 201512071640Z 
on a blank SATA drive. Boots up off the memory stick OK and after allocating 
partitions it fails when trying to newfs the first partition rwd0a. An error:
ioctl DIOCGMEDIASIZE failed 19 appears in the log messages several times.

The first partition (rwd0a) is set to be 512M and the newfs croaks with:

/sbin/newsfs -V2 -O2 -b 8182 -f 1024 /dev/rwd0a

Newfs: size 488397168 exceeds 525168 sector filesystem size on '/dev/rwd0a'

Retrying doesn't work as the installer can no longer see the disk unless the 
install is rebooted. I haven't tried setting different partition size for wd0a 
as 512M is normally fine for root. Disk is a 232GB Western Digital. 
 
I can send-pr a bug report if required.

Cheers,
Dave

-- 
=
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
=

Re: HP Proliant Microserver N36L fails to boot under current

[Dave Tyson]

On 03/24/15 00:33, Michael van Elst wrote:

dty...@anduin.org.uk (Dave Tyson) writes:


I have an HP Proliant Microserver (N36L) which runs fine on
NetBSD 7.0_BETA. I tried booting it from a recent current
AMD64 image and it crashes out.  The last few lines of the
boot message (hand copied) are:
extent_alloc_region: start 0xfff9, end 0xfa
There are several changes between the two, but this change around line 940
seems to be related:
platform = pmf_get_platform(system-product);
  if (platform != NULL 
  strcmp(platform, ProLiant MicroServer) == 0) {
  ia-iaa_if_iospacing = 1;
  ia-iaa_if_iobase = pipmi-smipmi_base_address
- 7;
  ia-iaa_if_iotype = 'i';
  return;
I am not sure what 'platform' is set by pmf_get_platform. I am guessing it
will be HP ProLiant MicroServer and the subsequent test will fail.
Any clues as to what the fixup if true does?


Apparently that's a quirk to fixup bad information that exists
on some machine that identifies itself as ProLiant MicroServer.

From the panic you can see that the pipmi-smipmi_base_address value
is 0, so that subsequent code tries to map address -7..-6. A quick
fix, is probably to test the base address for a value larger than 7.

Maybe someone with a Microserver N36L that does require the quirk
can tell, what the expected base address is.

Can you try this patch?

--- ipmi.c  29 Dec 2014 14:00:26 -  1.60
+++ ipmi.c  24 Mar 2015 00:32:39 -
@@ -941,7 +941,8 @@
  
 platform = pmf_get_platform(system-product);

 if (platform != NULL 
-   strcmp(platform, ProLiant MicroServer) == 0) {
+   strcmp(platform, ProLiant MicroServer) == 0 
+   pipmi-smipmi_base_address = 7) {
  ia-iaa_if_iospacing = 1;
  ia-iaa_if_iobase = pipmi-smipmi_base_address - 7;
  ia-iaa_if_iotype = 'i';





That patch seems to fix the problem. I used a 7.99.5 kernel with
the above to successfully boot the machine with a NetBSD 7.0_BETA
userland. Can you commit the fix?

Cheers,
Dave


--

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

HP Proliant Microserver N36L fails to boot under current

[Dave Tyson]

I have an HP Proliant Microserver (N36L) which runs fine on
NetBSD 7.0_BETA. I tried booting it from a recent current
AMD64 image and it crashes out.  The last few lines of the
boot message (hand copied) are:

sysbeep0 at pcppi1
OMSC (PNP0C02) at acpi0 not configured
RMSC (PNP0C02) at acpi0 not configured
PCIE (PNP0C02) at acpi0 not configured
RMEM (PNP0C02) at acpi0 not configured
acpibut0 at apci0 (PWRB, PNP0C0C-170): APCI power Button
ACPI: Enabled 4 GPEs in block 00 to 1F
ASCPI Exception: AE_NOT_FOUND, while evaluating Sleep State [\_S1_] 
(20140926/hwxface-646)
ASCPI Exception: AE_NOT_FOUND, while evaluating Sleep State [\_S2_] 
(20140926/hwxface-646)
ASCPI Exception: AE_NOT_FOUND, while evaluating Sleep State [\_S3_] 
(20140926/hwxface-646)

attimer1: attached to pcppi1
extent_alloc_region: extent 'ioport' (0x0 - 0x)
extent_alloc_region: start 0xfff9, end 0xfa
panic: extent_alloc_region: region lies outside extent
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0x80289a5d cs 0 rflags 246 ilevel 9 rsp 
813359e8

curlwp 0x810c7820 pid 0.1 lowest bstack 0x813322c0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5:   leave

The 7.0_BETA dmesg is:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
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.0_BETA (HP) #6: Fri Feb 20 14:56:28 UTC 2015
r...@forglen.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/HP
total memory = 895 MB
avail memory = 853 MB
kern.module.path=/stand/amd64/7.0/modules
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter i8254 frequency 1193182 Hz quality 100
HP ProLiant MicroServer (   )
mainbus0 (root)
ACPI: RSDP 0xf8f50 14 (v00 HP)
ACPI: RSDT 0x37fa 50 (v01 HP ProLiant 20110729 HP 0097)
ACPI: FACP 0x37fa0200 84 (v01 HP ProLiant 20110729 HP 0097)
ACPI: DSDT 0x37fa0620 006947 (v01 HP ProLiant 0006 INTL 20051117)
ACPI: FACS 0x37fae000 40
ACPI: APIC 0x37fa0390 72 (v01 HP ProLiant 20110729 HP 0097)
ACPI: MCFG 0x37fa0410 3C (v01 HP ProLiant 20110729 HP 0097)
ACPI: SPMI 0x37fa0450 41 (v05 HP ProLiant 20110729 HP 0097)
ACPI: OEMB 0x37fae040 72 (v01 HP ProLiant 20110729 HP 0097)
ACPI: HPET 0x37fab4e0 38 (v01 HP ProLiant 20110729 HP 0097)
ACPI: EINJ 0x37fab520 000130 (v01  AMIER AMI_EINJ 20110729 HP 0097)
ACPI: BERT 0x37fab6b0 30 (v01  AMIER AMI_BERT 20110729 HP 0097)
ACPI: ERST 0x37fab6e0 0001B0 (v01  AMIER AMI_ERST 20110729 HP 0097)
ACPI: HEST 0x37fab890 A8 (v01  AMIER ABC_HEST 20110729 HP 0097)
ACPI: SSDT 0x37fab940 000386 (v01 HP ProLiant 0001 AMD 0001)
ACPI: All ACPI Tables successfully acquired
cpu0 at mainbus0 apid 0: AMD Athlon(tm) II Neo N36L Dual-Core Processor, 
id 0x100f63
cpu1 at mainbus0 apid 1: AMD Athlon(tm) II Neo N36L Dual-Core Processor, 
id 0x100f63

ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x21, 24 pins
acpi0 at mainbus0: Intel ACPICA 20131218
acpi0: X/RSDT: OemId HP,ProLiant,20110729, AslId HP  ,0097
ACPI: OEMN 0x37faaeb0 000624 (v01 AMDNAHP 0001 INTL 20051117)
ACPI: OEMN 0x0 000624 (v01 AMDNAHP 0001 INTL 20051117)
ACPI Error: Method parse/execution failed [\_SB_._INI] (Node 
0xfe8037a0cb18), AE_ALREADY_EXISTS (20131218/psparse-553)

ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error
acpi0: SCI interrupting at int 9
timecounter: Timecounter ACPI-Safe frequency 3579545 Hz quality 900
hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400)
timecounter: Timecounter hpet0 frequency 14318180 Hz quality 2000
BROD (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
OMSC (PNP0C02) at acpi0 not configured
RMSC (PNP0C02) at acpi0 not configured
PCIE (PNP0C02) at acpi0 not configured
RMEM (PNP0C01) at acpi0 not configured
acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
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)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] 
(20131218/hwxface-646)

attimer1: attached to pcppi1
ipmi: bus_space_map(..., 0, 2, 0, 0x810aabe8) failed
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 0x1022 product 0x9601 (rev. 0x00)
ppb0 at pci0 dev 1 function 0: vendor 0x103c product 0x9602 (rev. 0x00)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled

drmkms solid hang on T200 laptop booting GENERIC amd64

[Dave Tyson]

I have been testing current on a Lenovo T200 (type 2504) on and off for 
a while. I think the last successful boot of current was GENERIC from 
29th October before the KMS code was add the the GENERIC config. IIRC 
the DRMKMS kernel from that base would hang.


With GENERIC (AMD64) CVS'ed and compiled from a couple of days ago the 
system boots and then hangs in the KMS code. kernel messages just before 
hang:


wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus0: configuaration mode 1
pchb0 at pci0 dev 0 function 0: vendor 8086 product 2a40 (rev. 0x07)
agp0 at pchb0: G4X-family chipset
agp0: detected 32252k stolen memory
agp0: aperture at 0xd000, size 0x1000
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 2a42 (rev. 0x07)
drm: Memory usable by graphics device = 512M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
DRM error in init_ring_common: render ring initialization failed ctl 
0001f001 head 0543b084 tail  start 3000
warning: /usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_pm.c:5734: 
!power_domains-domain_use_count[domain]


I am happy to turn on/add debugging code to help pin this down as I 
really want this laptop to work!


Cheers,
Dave




--

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

NetBSD current [AMD64] on a T400 laptop

[Dave Tyson]

Installed a 30th July snapshot of Current [AMD64] on a Lenovo T400. All 
went OK till I ran:


X -configure

which resulted in an immediate panic. CVSing up to todays sources and 
building/loading a new kernel gave exactly the same panic. Crash dmesg 
from 30th July version follows, the drm_addmap failure message may be 
significant. I can put the crash dump on an ftp server if requested.


t400root(t400)crash$ crash -M netbsd.0.core  -N netbsd.0
Crash version 6.99.49, image version 6.99.49.
System panicked: trap
Backtrace from time of crash is available.
crash dmesg
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
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 6.99.49 (GENERIC.201407300840Z) #0: Wed Jul 30 09:31:48 UTC 2014
bui...@b45.netbsd.org:/home/builds/ab/HEAD/amd64/201407300840Z-obj/home/source/ab/HEAD/src/sys/arch/amd64/compile/GENERIC
total memory = 2968 MB
avail memory = 2865 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter i8254 frequency 1193182 Hz quality 100
LENOVO 7434AZ9 (ThinkPad T400)
mainbus0 (root)
ACPI: RSDP 0xf6440 24 (v02 LENOVO)
ACPI: XSDT 0xb9b49b3a 94 (v01 LENOVO TP-7U3240  LTP )
ACPI: FACP 0xb9b49c00 F4 (v03 LENOVO TP-7U3240 LNVO 0001)
ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm1aControlBlock: 16/32 (20131218/tbfadt-634)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, 
using default 16 (20131218/tbfadt-716)

ACPI: DSDT 0xb9b4a00e 00FB01 (v01 LENOVO TP-7U3240 MSFT 0300)
ACPI: FACS 0xb9b8e000 40
ACPI: SSDT 0xb9b49db4 00025A (v01 LENOVO TP-7U3240 MSFT 0300)
ACPI: ECDT 0xb9b59b0f 52 (v01 LENOVO TP-7U3240 LNVO 0001)
ACPI: APIC 0xb9b59b61 78 (v01 LENOVO TP-7U3240 LNVO 0001)
ACPI: MCFG 0xb9b59bd9 3C (v01 LENOVO TP-7U3240 LNVO 0001)
ACPI: HPET 0xb9b59c15 38 (v01 LENOVO TP-7U3240 LNVO 0001)
ACPI: SLIC 0xb9b59dc2 000176 (v01 LENOVO TP-7U3240  LTP )
ACPI: BOOT 0xb9b59f38 28 (v01 LENOVO TP-7U3240  LTP 0001)
ACPI: ASF! 0xb9b59f60 A0 (v16 LENOVO TP-7U3240 PTL 0001)
ACPI: SSDT 0xb9b8d1fa 000568 (v01 LENOVO TP-7U3240 INTL 20050513)
ACPI: TCPA 0xb9907000 32 (v00  )
ACPI: SSDT 0xb98d4000 000655 (v01  PmRefCpuPm 3000 INTL 20050624)
ACPI: SSDT 0xb98d3000 000274 (v01  PmRef  Cpu0Tst 3000 INTL 20050624)
ACPI: SSDT 0xb98d2000 000242 (v01  PmRefApTst 3000 INTL 20050624)
ACPI: All ACPI Tables successfully acquired
cpu0 at mainbus0 apid 0: Intel(R) Core(TM)2 Duo CPU P8600  @ 
2.40GHz, id 0x1067a
cpu1 at mainbus0 apid 1: Intel(R) Core(TM)2 Duo CPU P8600  @ 
2.40GHz, id 0x1067a

ioapic0 at mainbus0 apid 1: pa 0xfec0, version 0x20, 24 pins
acpi0 at mainbus0: Intel ACPICA 20131218
acpi0: X/RSDT: OemId LENOVO,TP-7U   ,3240, AslId  LTP,
acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT
ACPI: SSDT 0xb98d7c20 0002C8 (v01  PmRef  Cpu0Ist 3000 INTL 20050624)
ACPI: SSDT 0x0 0002C8 (v01  PmRef  Cpu0Ist 3000 INTL 20050624)
ACPI: SSDT 0xb98d5020 00087A (v01  PmRef  Cpu0Cst 3001 INTL 20050624)
ACPI: SSDT 0x0 00087A (v01  PmRef  Cpu0Cst 3001 INTL 20050624)
ACPI: SSDT 0xb98d6ca0 0001CF (v01  PmRefApIst 3000 INTL 20050624)
ACPI: SSDT 0x0 0001CF (v01  PmRefApIst 3000 INTL 20050624)
ACPI: SSDT 0xb98d6f20 8D (v01  PmRefApCst 3000 INTL 20050624)
ACPI: SSDT 0x0 8D (v01  PmRefApCst 3000 INTL 20050624)
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 (EC, PNP0C09-0): using acpiecdt0
MEM (PNP0C01) at acpi0 not configured
acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch
acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button
SIO (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc2 at acpi0 (MOU, IBM0057) (aux port): irq 12
TPM (INTC0102) at acpi0 not configured
acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery
acpibat0: LGC LION rechargeable battery
acpibat0: granularity: low-warn 0.001 Wh, warn-full 0.001 Wh
acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter
thinkpad0 at acpi0 (HKEY, IBM0068)
acpivga0 at acpi0 (VID): ACPI Display Adapter
acpiout0 at acpivga0 (LCD0, 0x0400): ACPI Display Output Device
acpiout0: brightness levels: 20 25 30 35 40 45 50 55 60 65 70 75 80 85 
90 100

acpiout1 at acpivga0 (CRT0, 0x0100): ACPI Display Output Device

dhcpcd, IPv6 DAD

[Dave Tyson]

I seem to be having a bit of bother getting a T60 laptop to get an IPv6 
address correctly using dhcpcd.


The basic setup I have is an ADSL router hardwired to a server 
(current-ish NetBSD amd64) which gets an ipv6 feed via a HE tunnel. The 
router hands out IPv4 addresses and the server uses rtadvd to hand out 
IPv6 prefixes etc.


The laptop is running a recent version of current:

NetBSD t60.anduin.org.uk 6.99.47 NetBSD 6.99.47 (GENERIC.201407190440Z) 
#0: Sat Jul 19 06:45:26 UTC 2014 
bui...@b48.netbsd.org:/home/builds/ab/HEAD/i386/201407190440Z-obj/home/source/ab/HEAD/src/sys/arch/i386/compile/GENERIC 
i386


The networking parts of rc.conf:

wpa_supplicant=YES  wpa_supplicant_flags=-B -i wpi0 -c 
/etc/wpa_supplicant.conf

dhcpcd=YES  dhcpcd_flags=-w
ip6mode=host

and dhcpcd.conf is as supplied.

On startup dhcpcd seems to get both IPV4 and IPV6 addresses, but DAD 
fires off twice and the resulting
IPv6 address is marked as a duplicate. What I cannot understand is why 
this occurs and what I need to do to fix it...


rc.log:

Starting dhcpcd.
dhcpcd[151]: version 6.4.2 starting
dhcpcd[151]: wm0: adding address fe80::e26c:74d7:db55:bee7
dhcpcd[151]: wm0: waiting for carrier
dhcpcd[151]: wpi0: waiting for carrier
dhcpcd[151]: wpi0: carrier acquired
dhcpcd[151]: DUID 00:01:00:01:1b:6a:a0:37:00:13:02:7b:ca:44
dhcpcd[151]: wpi0: IAID 02:7b:ca:44
dhcpcd[151]: wpi0: soliciting a DHCP lease
dhcpcd[151]: wpi0: soliciting an IPv6 router
dhcpcd[151]: wpi0: Router Advertisement from fe80::1
dhcpcd[151]: wpi0: adding default route via fe80::1
dhcpcd[151]: wpi0: soliciting a DHCPv6 lease
dhcpcd[151]: wpi0: fe80::1 is unreachable, expiring it
dhcpcd[151]: wpi0: Router Advertisement from fe80::3e4a:92ff:fe77:bc6a
dhcpcd[151]: wpi0: adding address 2001:470:1f08:a8e:455e:1100:e823:ac03/64
dhcpcd[151]: wpi0: adding route to 2001:470:1f08:a8e::/64
dhcpcd[151]: wpi0: changing default route via fe80::3e4a:92ff:fe77:bc6a
dhcpcd[151]: wpi0: fe80::3e4a:92ff:fe77:bc6a is unreachable, expiring it
dhcpcd[151]: wpi0: DAD detected 2001:470:1f08:a8e:455e:1100:e823:ac03/64
dhcpcd[151]: wpi0: deleting address 2001:470:1f08:a8e:455e:1100:e823:ac03/64
dhcpcd[151]: wpi0: adding address 2001:470:1f08:a8e:da29:27e0:601b:993/64
dhcpcd[151]: wpi0: offered 192.168.0.10 from 192.168.0.1
dhcpcd[151]: wpi0: changing default route via fe80::1
dhcpcd[151]: wpi0: fe80::1 is unreachable, expiring it
dhcpcd[151]: wpi0: changing default route via fe80::3e4a:92ff:fe77:bc6a
dhcpcd[151]: wpi0: leased 192.168.0.10 for 86400 seconds
dhcpcd[151]: wpi0: adding host route to 192.168.0.10 via 127.0.0.1
dhcpcd[151]: wpi0: adding route to 192.168.0.0/24
dhcpcd[151]: wpi0: adding default route via 192.168.0.1
dhcpcd[151]: forked to background, child pid 788

and in the message log:

Jul 29 19:11:13 t60 /netbsd: wpi0: DAD detected duplicate IPv6 address 
2001:470:1f08:a8e:455e:1100:e823:ac03: NS in/out=1/1, NA in=0
Jul 29 19:11:13 t60 /netbsd: wpi0: DAD complete for 
2001:470:1f08:a8e:455e:1100:e823:ac03 - duplicate found

Jul 29 19:11:13 t60 /netbsd: wpi0: manual intervention required
Jul 29 19:11:13 t60 /netbsd: wpi0: DAD detected duplicate IPv6 address 
2001:470:1f08:a8e:da29:27e0:601b:993: NS in/out=1/1, NA in=0
Jul 29 19:11:13 t60 /netbsd: wpi0: DAD complete for 
2001:470:1f08:a8e:da29:27e0:601b:993 - duplicate found

Jul 29 19:11:13 t60 /netbsd: wpi0: manual intervention required

Anyone got an idea of what to do?

TIA,
Dave

--

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

Re: dovecot2 broken on 6.99.40

[Dave Tyson]

On 04/15/14 16:43, Jean-Yves Moulin wrote:
 Hi,
 
 Sorry if this is not the right list. I prefer to post here before posting to 
 dovecot mailing list. 
 
 So, on a 6.99.40 from yesterday (and also with a 6.99.35), dovecot2 fails 
 with:
 
 Apr 15 14:42:16 mailsrv dovecot: auth: Error: BUG: Authentication client sent 
 unknown handshake command: 
 REQUEST?3350593537?422?1?2534ef156b4cf36aa05842b5595add1d?session_pid=392?req...
 
 The same dovecot binary was running fine on 6.99.32 (I only change the 
 kernel).
 
 Any idea ?
 
 Thanks you.
 
 Best,
 jym
 

I've been running dovecot-2.1.15nb1 compiled on 6.99.23 amd64 for a
while and its been fine. I upgraded to 6.99.40 (kernel  userland) a
couple of days ago and the dovecot binary is still working OK as far as
I can see. imap clients connect OK and mail still goes out OK. I am
hanging fire before trashing/rebuilding a newer version under the latest
gcc till I have a spare server :-)

Dave

-- 
===
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
===

consistent crashes in 6.99.40 - nfsio code?

[Dave Tyson]

I seem to be experiencing some repeatable crashes with 6.99.40 from a 
few days ago. This is a desktop amd64 system which talks to an HP 
microserver to get home filestore over NFS. The desktop had been pretty 
stable on 6.99.40 when the NFS server was running 6.99.23, but I 
upgraded the server to 6.99.40 to fix the ssl bug and the desktop system 
crashes after about 30 minutes use.


NetBSD 6.99.40 (DAVE) #0: Fri Apr 11 21:17:58 BST 2014
r...@cruncher.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/DAVE


uvm_fault(0x80f8cb60, 0x80021b47, 1) - e
fatal page fault in supervisor mode
trap type 6 code 0 rip 80263715 cs 8 rflags 10202 cr2 
80021b47 ilevel 4 rsp fe811d4917b0

curlwp 0xfe8418a03740 pid 0.74 lowest kstack 0xfe811d48e2c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
startlwp() at netbsd:startlwp
cpu0: End traceback...

dumping to dev 0,1 (offset=217511, size=4167225):
dump
crash ps
PIDLID S CPU FLAGS   STRUCT LWP *   NAME WAIT
1262   383 2   0   802   fe83e2fd24c0   npviewer.bin
1262   956 2   3   802   fe83dfba7180   npviewer.bin
1262  571 7   2   802   fe83e2312100 npviewer.bin
1262  442 7   1   802   fe83d4b90a60 npviewer.bin
1262   697 2   1   802   fe83c6d18a80   npviewer.bin
1262  1272 2   2   802   fe83cee181c0   npviewer.bin
1262  1262 2   3   802   fe83c1629b40   npviewer.bin
489  2 2   0   802   fe83cc5a32e0Chrome_ChildThr
489  1 2   0   802   fe83cc5a3700   plugin-container
106375 5   2   802   fe83d5495280   (zombie)
106368 2   3   802   fe83b7b58b60 DOM Worker
106365 2   1   802   fe83d4b90640  mozStorage #5
106359 2   0   802   fe83e247eb00  mozStorage #4
106355 2   2   802   fe83c6d18240localStorage DB
106353 2   0   802   fe83dfba75a0  mozStorage #3
106352 2   2   802   fe83d81192a0  mozStorage #2
106350 2   1   802   fe83d81196c0 URL Classifier
106349 2   0   802   fe83d8119ae0   Cache Mngmnt
106347 2   0   802   fe83d54956a0Proxy Resolutio
106346 2   3   802   fe83d54c1620  mozStorage #1
106345 2   0   802   fe83d3450680Cert Verify
106336 2   1   802   fe83d3450260 DOM Worker
106318 2   3   802   fe83d54c1200   HTML5 Parser
106316 2   2   802   fe83d54c1a40  Cache I/O
106315 2   0   802   fe83d0cd01e0 DOM Worker
106314 2   0   802   fe83d0cd0600   Network Seer
106313 2   2   802   fe83d0cd0a20  Timer
106311 2   0   802   fe83cee185e0Analysis Helper
106310 2   3   802   fe83cee18a00Analysis Helper
1063 9 2   3   802   fe840a92b2c0Analysis Helper
1063 8 2   2   802   fe83f724e240Analysis Helper
1063 7 2   0   802   fe83f467eae0 Cache2 I/O
1063 6 2   0   802   fe840207a9a0   Hang Monitor
1063 5 2   3   802   fe83e13659a0JS Watchdog
1063 4 2   0   802   fe83e58934a0   JS GC Helper
1063 3 2   0   802   fe83da0fd9e0  Socket Thread
1063 2 2   3   802   fe83da0fd5c0 Gecko_IOThread
1063 1 2   1   802   fe83e5893080firefox
118897 5   2   802   fe83e2fca0c0   (zombie)
118896 2   1   802   fe83da0fd1a0 RunProcess
118895 2   1   802   fe83dc449920thunderbird
118885 2   1   802   fe83e2fca900thunderbird
118884 2   1   802   fe83dfba79c0thunderbird
118883 2   2   802   fe83e2312940thunderbird
118882 2   1   802   fe83e1365160thunderbird
118881 2   0   802   fe83e1365580thunderbird
118880 2   1   802   fe83da810040thunderbird
118878 2   0   802   fe83e7216060  mozStorage #6
118877 2   0   802   fe83e58938c0   MediaManager
118876 2   0   802   fe83dedb1440   Image Scaler
118874 2   0   802   fe84194d06e0  mozStorage #5
118873 2   0   802   fe83e2fd20a0localStorage DB
118864 2   0   802   fe83da7c1140thunderbird
118863 2   1   802   fe83dc449500thunderbird
118862 2   2   802   fe83dc4490e0thunderbird
118860 2   0   802   fe83da7c1560thunderbird
118858 2   0   802   fe83e2fd28e0 URL Classifier
118851 2   1   802   fe83e2312520  Cache I/O
118847 2   1   802   fe83e155a120Proxy Resolutio
118846 2   0   802   fe83e155a540  mozStorage #4
118845 2   1   802   

Re: ntpq peculiarity

[Dave Tyson]

On 04/02/14 08:59, Frank Kardel wrote:

Hello Dave !

I tripped yesterday over a merge mishap concerning libntp/atouint.c and
fixed that.

It could be that this is related to what you see. Can you
checkout/recompile libntp/ and recompile ntpq?

Best regards,
Frank



Hi Frank,

I've checked out the code and recompiled ntp (build still going, but the 
ntp bits have just finished) and it looks fine now:



$ /usr/obj/external/bsd/ntp/bin/ntpq/ntpq
ntpq pe
 remote   refid  st t when poll reach   delay offset  
jitter

==
+5.9.234.5 (webs 131.188.3.2212 u   12   64  377   55.789 -9.261   0.423
+46.240.140.176  1.184.65.45  3 u2   64  377   72.892 -8.129   0.566
-snf-251261.vm.o 178.23.121.165   3 u7   64  377   99.529 -2.533   0.488
*ip0.srv25.tx-es 217.245.152.227  2 u   11   64  377   55.862 -8.673   0.376
ntpq host 192.168.0.200
current host set to 192.168.0.200
ntpq pe
 remote   refid  st t when poll reach   delay offset  
jitter

==
-garamon.von-opp 129.69.1.153 2 u  723 1024  377   60.082 -3.489   1.997
+iwik.org195.113.144.201  2 u  34m 1024  202   62.962 0.407   2.360
+2001:67c:12ac:: 172.2.53.81  2 u  708 1024  377   89.776 0.067   2.196
*panda.zeroloop. 145.238.203.14   2 u  206 1024  377   43.834 -0.625   1.960
ntpq

Thanks for your prompt fix.

Cheers,
Dave

--

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

ntpq peculiarity

[Dave Tyson]

I've noticed that the recent version of ntpq always reports peers as 
being stratum 0 regardless of what they really are:


root(cruncher)root$ ntpq
ntpq host 192.168.0.200
current host set to 192.168.0.200
ntpq pe
 remote   refid  st t when poll reach delay   offset  
jitter

==
*garamon.von-opp 129.69.1.153 0 u   34   64   17 61.750   -2.490   0.658
 iwik.org195.113.144.201  0 u  161   64   14 62.069   -1.863   
0.499

+2001:67c:12ac:: 172.2.53.81  0 u   33   64   17 90.2350.128   0.468
 panda.zeroloop. 145.238.203.14   0 u   29   64   17 42.939   23.580   
0.257

ntpq

but on 192.168.0.200

ntpq pe
 remote   refid  st t when poll reach delay   offset  
jitter

==
*garamon.von-opp 129.69.1.153 2 u   11   64   17 61.750   -2.490   0.658
 iwik.org195.113.144.201  2 u  138   64   14 62.069   -1.863   
0.499

+2001:67c:12ac:: 172.2.53.81  2 u   10   64   17 90.2350.128   0.468
 panda.zeroloop. 145.238.203.14   2 u6   64   17 42.939   23.580   
0.257


Cruncher is running a very recent current:

NetBSD cruncher.anduin.org.uk 6.99.38 NetBSD 6.99.38 (DAVE) #0: Tue Mar 
25 19:47:36 UTC 2014 
r...@cruncher.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/DAVE amd64


with ntp: ntpd 4.2.7p404-o Fri Dec 27 19:28:17 EST 2013 (import)

192,168.0.200 is running an older current:

NetBSD rakelane.anduin.org.uk 6.99.23 NetBSD 6.99.23 (HP) #1: Wed Aug  7 
11:46:04 BST 2013 
r...@rakelane.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/HP amd64


with ntp:ntpd 4.2.6p5-o Wed Feb  1 07:49:06 UTC 2012 (import)

Is this a known problem or should I send-pr it?

Cheers,
Dave


--

Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk

amd64 server upgrade failed - help

[Dave Tyson]

I have an HP proliant server (amd64) running current from about March
2013. It has all its filesystems on raid 1 sets and as well as being a
fileserver also acts as a DNS server/mailserver for a few domains. I 
decided to do an update to fix the existing bind security problem. 
CVS'ed up to current as of 31st July. Built new tools and a new GENERIC
kernel - all fine. Installed kernel and modules - kept old ones just in
case. Rebooted and everything was fine. Did a build release and when
that completed successfully did a build install=/. etcupdate. Rebooted.
Oh dear!

Kernel boots up and then panics when init died:

Panic: init died (signal 0, exit 11)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 8026a18d cs 8 flags 246 cr 2 7f7ff63b20
ilevel 0 rsp fe8002f7aaa0

OK, no problem, boot a recent amd64 image from releng from a usb stick.
Aggh - but I have a raided root and the USB kernel plows through and
uses root on the raid rather than root on the usb disk. Use the usb
keyboard to force a 'boot netbsd -a' from the usb stick. That works and
it prompts for a root device. The bloody usb keyboard doesn't work at
this point so I am a bit stuffed.

I had a slight premonition of this as I had an issue before and Brian
Burrow did suggest boot -a may work but the lack of a real keyboard is a
show stopper. Given that usb keyboards are the norm now I would have
thought the kernel (and debugger) should support them better.

My best guess is I need to build an install image with root hardwired to
sd0a so that it will pick up root off the usb stick. This will be a
tedious process as my only other amd64 machine is slow.

Any other suggestions other than a total reinstall ? (I do have a full
backup from 3 days ago but really don't want to have to waste a couple
of days...)

Cheers,
Dave

-- 
===
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
===