Re: Strange behavior of bluetooth chip

[Iain Hibbert]

On 22 December 2023 14:59:48 GMT, Iain Hibbert  wrote:
>Hello
>
>These Intel Bluetooth chips are unsupported for now. The problem with them is 
>that unfortunately they identify as a Bluetooth device but do not work as one 
>until the firmware is loaded. Alas we don't have a way as yet to provide for 
>device specific initialisations and I've been too busy lately to work on that. 
>I do have one of them in my laptop but have been using an external dongle.
>
>The reason it works after Windows initialises it, is a reset doesn't usually 
>take the power away so it remains in firmware loaded state.
>
>
>On 22 December 2023 12:18:15 GMT, Vitaly Shevtsov  
>wrote:
>>Hello.
>>
>>My wireless chip is defined as: Intel Wireless AC 9260 (different
>>network, version 0x29) on pci1 dev 0, function 0 not configured.
>>
>>When booting the system I always got an error:
>>CommanComplete opcode failed (003|0003) (status=0x01).
>>
>>When I tried to manually raise the interface via `btconfig ubt0 up`, I
>>received the error:
>>btconfig: SIOCSBTFLAGS: Resource temporarily unavailable.
>>
>>I decided that my chip was not working until I reboot into Windows and
>>then back into NetBSD, after which the bluetooth worked.
>>
>>How so? :) I suspect that the firmware is missing and Windows uploads
>>it. If so then I don't understand how it survives the reboot.
>
>On my phone
On my phone

Re: bluetooth ubt0

[Iain Hibbert]

On Tue, 16 Mar 2021, Ryo ONODERA wrote:

> Hi,
> 
> Iain Hibbert  writes:
> 
> > On Mon, 15 Mar 2021, Ryo ONODERA wrote:
> >
> >> Patrick Welche  writes:
> >> 
> >> > A first foray into bluetooth on this amd64 laptop gives me:
> >> >
> >> > ubt0: Intel (0x8087) product 0aaa (0x0aaa), rev 2.00/0.02, addr 4
> >> > ubt0: autoconfiguration error: CommandComplete opcode (003|0003) failed 
> >> > (status=
> >> > 0x01)
> >
> > btw this is a 'RESET' command sent to the adapter as the first thing when 
> > the device is marked up.
> >
> >> > and after a btconfig ubt0 up, btconfig shows
> >> >
> >> > ubt0: bdaddr 00:00:00:00:00:00 flags 
> >> > 0x2e0 >> > TURES,INIT_COMMANDS>
> >> >
> >> > which doesn't look like a valid address. (Bluetooth is "on", at least
> >> > according to OtherOS)
> >
> > the meaning of the INIT_ flags is that they are set and then when the 
> > RESET command is completed, we issue other commands and clear those flags 
> > when they have completed. because the RESET did not complete, they are 
> > still pending but I guess will not be issued.
> >
> >> > Any thoughts on how to get it going?
> >> 
> >> I have no idea about VID/PID=0x8087/0x0aaa.
> >> However newer ubt devices from Intel requires firmware loading.
> >> 
> >> My VID/PID=0x8087/0x0026 requires its firmware and
> >> I have gotten same
> >> ubt0: autoconfiguration error: CommandComplete opcode (003|0003) failed 
> >> (status=0x01)
> >> after btconfig ubt0 up.
> >
> > Do you have a reference for this?  We have nothing to handle any such 
> > firmware loading that I know of; there is sysutils/bcmfw to do that for 
> > Broadcom devices (but, they can operate as a Bluetooth device by default 
> > just better with newer firmware)
> 
> As far as I understand correctly, NetBSD's ubt device driver does not
> have firmware loading logic.
> 
> See: FreeBSD's implementation:
> src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt_intel.c
> https://cgit.freebsd.org/src/tree/sys/netgraph/bluetooth/drivers/ubt/ng_ubt_intel.c
> 
> prlw1@'s PID=0x0aaa is also listed there.
> 
> And Linux has Intel firmware logics, for example:
> https://elixir.bootlin.com/linux/v5.12-rc3/source/drivers/bluetooth/btusb.c#L2307
> Search 'firmware' string in this file.
> 
> I wish someone could implement newer Intel ubt support.

Hm I can look into it - is it possible to buy one of these intel adapters 
which is USB or do they only come built in to laptops etc?

>From the comments at the top of the file, this seems to me a bad device 
and I am surprised that it has passed qualification. It should not present 
as a Bluetooth device if it is not one until it has firmware loaded.

There is a userland utility mentioned at least to load the firmware..

iain

Re: bluetooth ubt0

[Iain Hibbert]

On Mon, 15 Mar 2021, Ryo ONODERA wrote:

> Patrick Welche  writes:
> 
> > A first foray into bluetooth on this amd64 laptop gives me:
> >
> > ubt0: Intel (0x8087) product 0aaa (0x0aaa), rev 2.00/0.02, addr 4
> > ubt0: autoconfiguration error: CommandComplete opcode (003|0003) failed 
> > (status=
> > 0x01)

btw this is a 'RESET' command sent to the adapter as the first thing when 
the device is marked up.

> > and after a btconfig ubt0 up, btconfig shows
> >
> > ubt0: bdaddr 00:00:00:00:00:00 flags 
> > 0x2e0 > TURES,INIT_COMMANDS>
> >
> > which doesn't look like a valid address. (Bluetooth is "on", at least
> > according to OtherOS)

the meaning of the INIT_ flags is that they are set and then when the 
RESET command is completed, we issue other commands and clear those flags 
when they have completed. because the RESET did not complete, they are 
still pending but I guess will not be issued.

> > Any thoughts on how to get it going?
> 
> I have no idea about VID/PID=0x8087/0x0aaa.
> However newer ubt devices from Intel requires firmware loading.
> 
> My VID/PID=0x8087/0x0026 requires its firmware and
> I have gotten same
> ubt0: autoconfiguration error: CommandComplete opcode (003|0003) failed 
> (status=0x01)
> after btconfig ubt0 up.

Do you have a reference for this?  We have nothing to handle any such 
firmware loading that I know of; there is sysutils/bcmfw to do that for 
Broadcom devices (but, they can operate as a Bluetooth device by default 
just better with newer firmware)

iain

Re: ThinkPad T42 w/-current, no mouse in X

[Iain Hibbert]

On Sat, 30 Jun 2018, John D. Baker wrote:

> Recently, I've only been using text console or SSH on my ThinkPad T42
> when using -current (via netboot).
> 
> I finally got around to starting X on it and was surprised when the mouse
> didn't work.  No motion either through the trackpoint nub or the trackpad
> and no evidence any buttons work.  The keyboard works fine once you get
> a window active (Alt-Tab in fvwm).
> 
> It used to work in -current some time back.  Mouse works fine in X under
> netbsd-7 and -8.0_RC2.

This also does not work on my T61p. I think somebody else reported that a 
while ago, not sure if there is a PR for it.

I have a workaround though, I use a Bluetooth mouse and it has never been 
a problem except when the batteries run out and I haven't got spares ready

iain

Re: New amd64 8.99.6 panic

[Iain Hibbert]

On Thu, 9 Nov 2017, bch wrote:

> On Nov 9, 2017 17:54, "Chavdar Ivanov"  wrote:
> 
>> I switched my old T61p yesterday to 8.99.6. The first 4/5 hours it 
>> seemed OK, modulo the weirdly disappearing mouse when starting gdm (I 
>> had to switch to another wscons and back to get it, or even restart 
>> gdm).
> 
> I've had same mouse experience lately, restarting X to get proper behaviour.

I've been running an 8.99.7 kernel for about a week on my T61p seems to be 
running ok (have built a release with it, not updated the system yet)

I just noticed this mouse thing though.. The the trackpad/trackpoint are 
not working but my Bluetooth mouse works fine

iain

Re: upgrade to 8.99.1 - dhcpcd woe

[Iain Hibbert]

On Tue, 6 Jun 2017, Roy Marples wrote:

> I'm sunning myself on holiday and I don't have the grey matter for serious
> though right now.

ok ta.. I'll look at it later as its working ok now (or maybe forget, and 
fix it next time it breaks :)

in the meantime, I notice in the dhcpcd(8) manpage:

   More scripts are supplied in @DATADIR@/dhcpcd/hooks and need to be copied
   to /libexec/dhcpcd-hooks if you intend to use them. 

shouldn't @DATADIR@ be converted to eg /usr/share/examples during the 
import or build for the built in version?

iain

upgrade to 8.99.1 - dhcpcd woe

[Iain Hibbert]

Hi

Upgrading to 8.99.1 (from 7.99.52) on my laptop .. network didn't work; 
what was strange that I was being set up on 10.*.*.* and never had before. 
Firefox started complaining that I might need to login but no pages would 
load.

It turns out that /libexec/dhcpcd-hooks/10-wpa_supplicant is marked as 
obsolete in the set lists; this means that postinstall will remove it, 
which is clearly wrong because *I* copied it there from the examples 
folder as I need it (otherwise dhcpcd connects to the nearest open 
network, which I don't want as it won't work for me)

I don't know how best to fix that.. clearly its at cross-purposes?

iain

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

[Iain Hibbert]

On Sat, 10 Dec 2016, co...@sdf.org wrote:

>   prop_dictionary_set_uint16(dict, "linebytes",
>   roundup2((sizes->surface_width * howmany(sizes->surface_bpp, 8)),
> - 64));
> + 256));

btw this also fixes the console on my T61p .. the only noticeable change 
in the boot message, was:

-nouveaufb0: framebuffer at 0x800049cfd000, size 1680x1050, depth 32, 
stride 6720
+nouveaufb0: framebuffer at 0x800049cfd000, size 1680x1050, depth 32, 
stride 6912

iain

adding software to base

[Iain Hibbert]

On Mon, 22 Aug 2016, Robert Elz wrote:

>   | | Please describe how nsd has a "tighter integration" or (i assume 
>   | | better?) "out of the box usability" when in -base vs pkgsrc.
> 
> Aside from what Christos said, anything in base can be installed from
> a (downloaded and burned) CD/DVD and work without any kind of network
> connection.
> 
> In this context, that's particularly relevant if you're setting up a
> DNS zone signing system - one of those wants to be 100% isolated from
> the Internet (from day 1) (unless you have one of the fancy, costly,
> hadware, signing boxes) so that the safety of the key used is ensured
> (particularly relevant if you're running one of the upper level domains.)
> 
> Of course, it is possible to get everything needed, and burn it on extra
> CDs (or USB sticks) and install it that way - but that's not nearly as
> tightly integrated (nor nearly as well tested.)

Just as note here: there is a way to build/install some external software 
in with a release by adding a reachover build into extsrc/ and setting 
MKEXTSRC=yes - I assume that this functionality was added because somebody 
uses it to create a funtional system for their own purpose.

It would be nice if one could have some packages pre-installed in the 
release but I don't think anybody ever worked on that.

iain

Re: [PATCH] control which tmpfs get unmounted at swapoff

[Iain Hibbert]

On Fri, 18 Mar 2016, Ian D. Leroux wrote:

> Here's slightly better compromise, that does the right thing by default
> in more cases.  The rc.conf variable "swapoff_umount" (name changed for
> clarity) can be either
> - an explicit list of zero or more tmpfs filesystems to umount before
> removing swap devices, or
> - "auto", in which case all tmpfs mounts containing no device nodes are
> removed, as you suggested at the beginning of the week.

I'm uneasy about a 'magic' value, which could be problematic (sorry, did 
you have a filesystem named auto?).. is it a problem to have

not set ->  auto behaviour
set ->  unmount the file systems listed, if any

?

You can do this with eg

case "${swapoff_umount+set}" in
set)
fs_to_umount="${swapoff_umount}"
;;
*)
fs_to_umount="$(dev_free_tmpfs)"
;;
esac

regards,
iain

Re: bta2dpd - advanced audio distribution profile bluetooth daemon IMPROVED

[Iain Hibbert]

On Fri, 4 Mar 2016, Nathanial Sloss wrote:

> Call for testers of the next installment of bta2dpd.

Hi

Some success.. was experiencing that same annoying clicking on the sound 
to a Kitsound Hive speaker, until I tried with an older BCM2035 dongle 
(Bluetooth v1.2) and all of a sudden it working fine!  works ok with an 
old CSR (v2.0+EDR) dongle also, not sure why the BCM2045B (v2.0+EDR) built 
into the laptop is not working, must investigate this further..  I also 
have a BCM20702A0 (v4.1) but thats still inside my T60 so can't try it out 
at the moment.

iain

Re: bta2dpd - advanced audio distribution profile bluetooth daemon IMPROVED

[Iain Hibbert]

On Fri, 4 Mar 2016, Nathanial Sloss wrote:

> I found in order for my phone to connect to bta2dpd as an audio sink I needed 
> the most recent version of sdpd(1) and had to set a pin code for my phone 
> (see 
> btpin(1)) and had to start bta2dpd as a sink with -K before pairing.

how recent do you mean? I think the NetBSD-6, NetBSD-7 and 
NetBSD-current versions should all be the same in this regard..

also, you can normally use btpin to pair with the device directly before 
connecting to any services, eg

% btpin -a  -p 1234 -P

as because this asks for a secure connection, it should set that up before 
trying to connect to any service (it asks for Service Discovery, but if it 
didn't get it then should be no problem - the secure setup has been done)

iain

Re: CVS commit: src/sys/dev/usb

[Iain Hibbert]

> Module Name:src
> Committed By:   riastradh
> Date:   Wed Feb 17 00:49:28 UTC 2016
>
> Modified Files:
> src/sys/dev/usb: ubt.c
>
> Log Message:
> Match various Apple USB Bluetooth controllers.
>
> >From mlelstv.

btw I just commited a change to this which adds matching of several 
manufacturers who use modern Broadcom Bluetooth chips which are 
upgradeable at run-time. (and I also updated the sysutils/bcmfw package to 
handle this)

I see the Linux driver does match against Vendor=Apple Class=Vendor 
Subclass=RF Proto=Bluetooth in the same way but no Apple VendorIDs are 
listed in any of the Broadcom driver files I found so I haven't added it. 
Perhaps the ones which you added would be better covered by that? I am not 
clear..

iain

Re: i915 DRMKMS GPU hang

[Iain Hibbert]

On Tue, 2 Feb 2016, John D. Baker wrote:

> the display freezes for a couple of minutes shortly after starting X
> following a reboot--usually a couple of minutes after logging in via
> 'xdm'.  I then see the following in 'dmesg' and XConsole.  It seems only
> to occur once.  If it happened more than once in a session, it's been
> too long ago for me to remember.
> 
> drm: stuck on render ring
> drm: GPU HANG: ecode 0:0x3c8160c1, reason: Ring hung, action: reset
> drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
> userspace.
> drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
> DRM/Intel
> drm: drm/i915 developers can then reassign to the right component if it's not 
> a kernel issue.
> drm: The gpu crash dump is required to analyze gpu hangs, so please always 
> attach it.
> drm: GPU crash dump saved to /sys/class/drm/card0/error
> DRM error in i915_reset: Failed to reset chip: -19
> 
> After this, it seems to operate normally essentially indefinitely.

I think after this, it is not any longer using the DRM (KMS?) magic code 
so it won't happen again.

I also see this GPU hang on a T60; from my dmesg

agp0 at pchb0: i915-family chipset
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 27a2 (rev. 0x03)
drm: Memory usable by graphics device = 256M
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: initialized overlay support
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0xdb1b9000, size 1400x1050, depth 32, stride 5632
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0
wsmux1: connecting to wsdisplay0
vendor 8086 product 27a6 (miscellaneous display, revision 0x03) at pci0 dev 2 
function 1 not configured

and then a very short time after or during boot, I usually see

DRM error in i915_irq_handler: pipe A underrun

though I have done nothing about this - I run with the intel_old driver 
instead, which works seemingly well enough.

iain

Re: build fails with libgnumalloc for evbarm

[Iain Hibbert]

On Fri, 15 Jan 2016, Rin Okuyama wrote:

> Hello,
> 
> Building release fails with libgnumalloc for evbarm:

A few years ago I looked at libgnumalloc briefly, and found that

% grep -Ri gnumalloc /usr/src /usr/xsrc

seems to reveal that there are no actual users of libgnumalloc in our 
current tree..  the XFree86 and Xorg NetBSD.cf files disable it for 
NetBSD>1.4J, and pkgsrc showed nothing explicitly referring to it.

The README file says

| This is the standalone distribution of GNU malloc.
| GNU malloc is part of the GNU C Library, but is also distributed 
| separately.

but looking at gnu.org I don't see that the latter is still true, and our 
version is very old according to the VERSION file

| this version of GNU malloc was obtained from 
| prep.ai.mit.edu on 9/22/1993.  There was no version noted."

..are there any known uses for this, is it time to remove it?

regards,
iain

Re: ip6addrctl not set

[Iain Hibbert]

On Sat, 26 Dec 2015, Christos Zoulas wrote:

> In article <20151226135926.ga26...@danbala.tuwien.ac.at>,
> Thomas Klausner   wrote:
> >I got a boot warning about $ip6addrctl not being set.
> >
> >I see that ip6addrctl_enable=NO is set in the defaults file, but this
> >name looks strange. I guess it should be "ip6addrctl=NO" instead?
> > Thomas
> 
> I thought I fixed it...

you omitted to change the defaults file (I just did it)

also, this is not mentioned in rc.conf(5) but probably should be..?

regards,
iain

Re: only one button recognised on my trackpad

[Iain Hibbert]

On Mon, 11 May 2015, Brett Lymn wrote:

 I have a fujitsu lifebook S904 laptop running a recent-ish
 netbsd-current.  Thanks to some recent changes I have gone from no
 buttons to one button on my trackpad but I am sort of demanding and
 want some more buttons.  Linux (fedora core 20-something) and windows
 provide two buttons on the trackpad so it should be possible though I am
 confused as to how they do it.  When I do a debug boot I see:

 pms0 at pckbc1 (aux slot)
 pms0: Synaptics touchpad version 8.1
 pms0: synaptics_probe: Capabilities 0xd0a3.
 pms0: pms_synaptics_probe_extended: Extended Buttons: 0.
 pms0: pms_synaptics_probe_extended: Extended Capabilities: 0x94 0x03 0x00.
 pms0: pms_synaptics_probe_extended: Continued Capabilities 0x12 0x68 0x00.
 pms0: Extended W mode, Passthrough, Palm detect, One button click pad, 
 Multi-finger Report, Multi-finger

 in the dmesg.  The capabilities reported are the same as the ones linux
 reports and if I decode them then, yes, I have a one button click pad
 but somehow linux does two buttons, though I can't work out how from
 their driver.  Anyone have any ideas?

When it gets a click, it checks where it was being touched.. if on the
left, its a left click and if on the right, its a right click..

essentially, the Apple Magic Mouse does this kind of thing, it only has a
single switch inside though it does handle the left/right differentiation
by itself. The btmagic(4) driver converts multiple finger clicks to
middle-click manually, as I found trying to delineate a central zone was
not clear enough (my finger is 25% of the width of the mouse surface)

It could be that some initialization is missing from our synaptics driver,
to enable it providing left/right clicks itself, or it could be that the
linux driver is doing it all possibly at a higher level?

regards,
iain

Re: Issues with 7.99.13 (amd64)

[Iain Hibbert]

On Sat, 2 May 2015, Paul Goyette wrote:

 On Thu, 30 Apr 2015, Paul Goyette wrote:

  I've encountered three separate issues while running -current (most
  recently, 7.99.13).
 
  1. ...
 
  2. System shutdown usually hangs while waiting for xdm to stop.  I don't
know if it would ever recover (I've waited at least a couple minutes)
but as asson as I log back in on the console and 'kill -9' the xdm
process, shutdown proceeds normally.  This happens on 60-80% of the
time.

 FWIW, the actual culprit here would seem to be the Xserver running
 underneath xdm.  When the problem occurs, the user (me) has already been
 successfully logged out, and xdm has started up a new Xserver, which according
 to top(1) is running at 100% CPU.

 If I 'kill -9' the Xserver process, then xdm exists normally and the shutdown
 proceeds.

I've seen something similar to this, but haven't had time to pin it down
exactly, or update again to see if it is gone with the most recent DRM
updates. On my T60 (i386), the laptop boots ok, but when I insert a USB 3g
dongle (or, if it is present on boot) I see

ehci0: handing over full speed device on port 7 to uhci3
DRM error in i915_irq_handler: pipe A underrun

and then, if I shutdown it does work normally UNLESS if I unplug the
offending uhso(4) device before the shutdown, then the Xserver will block,
running in a busy loop on one core (effectively 50% cpu). My wild guess
is something to do with interrupts conflicting.

iain

Re: Live Image build failure

[Iain Hibbert]

On Mon, 27 Apr 2015, Chavdar Ivanov wrote:

 I've been trying to build liveimage for i386 and amd64 the last few dayw
 without success. Today I cleaned the distdir and tried again, with the same
 result:
 ...
 --- NetBSD-7.99.13-amd64-live-wd0root.img ---
 creating MBR labels...
 dd if=/dev/zero of=work.mbr seek=$((4194304 - 1)) count=1
 1+0 records in
 1+0 records out
 512 bytes transferred in 0.001 secs (512000 bytes/sec)
 /home/sysbuild/Sysbuild/amd64/tools/bin/x86_64--netbsd-fdisk -f -i -u  -b
 261/255/63 -0 -a -s 169/2048/4192256
  -F work.mbr
 Making partition 0 active.
 /home/sysbuild/Sysbuild/amd64/tools/bin/x86_64--netbsd-fdisk -f -i -c
 work/usr/mdec/mbr -F work.mbr
 dd if=work.mbr count=2048 |  cat - imgroot.fs  work.img
 2048+0 records in
 2048+0 records out
 1048576 bytes transferred in 0.027 secs (38836148 bytes/sec)
 dd if=/dev/zero of=work.swap seek=$((262144 - 1)) count=1
 1+0 records in
 1+0 records out
 512 bytes transferred in 0.001 secs (512000 bytes/sec)
 cat work.swap  work.img
 /home/sysbuild/Sysbuild/amd64/tools/bin/nbdisklabel -R -F work.img
 work.diskproto
 nbdisklabel: unknown label: use -M/-B and $MACHINE/$MACHINE_ARCH
 *** [NetBSD-7.99.13-amd64-live-wd0root.img] Error code 1

I also saw that with i386 updated Apr 26, my previous was some months ago.

iain

Re: RPI usb can get stuck

[Iain Hibbert]

On Thu, 9 Apr 2015, Frank Kardel wrote:

 Using an USB-Serial adapter I experience ucb lockups in 7.99.9.

 Device (from dmesg):
 uslsa0 at uhub1 port 3 configuration 1 interface 0
 uslsa0: Silicon Labs ELV USB-WDE1 WetterdatenempfM-CM-$nger, rev 1.10/1.00,
 addr 4
 ucom0 at uslsa0: Silicon Labs CP210x

by chance, I just filed PR 49831 relating to a kernel panic upon closing a
ucom device. I don't know if related as different architecture, different
device :)

 ~. [stuck here]

but it dies in ucomclose() the same .. does your kernel have DIAGNOSTIC
enabled?

my workaround, was to unplug the USB device instead of closing the device,
which seemed to work properly.

regards,
iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Mon, 18 Aug 2014, William D. Jones wrote:

  also, you should probably use HAVE_GCC=48 since that is the version in
  use, and the version number is checked sometimes for various features

 I removed the conditional logic for MKGCC. I'll give a more complete update
 later, but believe it or not, setting HAVE_GCC=48 while MKGCC=no and MKPCC=yes
 actually causes the variable ${EXTERNAL_GCC_SUBDIR} (lib/Makefile, line 9) to
 not be expanded AT ALL when searching for libgcc to add to the list of build
 targets. This baffles me, because bs.own.mk in $NETBSD_SRC/share/mk has an
 else statement which should prevent this at line 86-88, but the logic is not
 firing. Setting HAVE_GCC=4 SEEMS to solve the problem- at least, libgcc gets
 added to the list of targets and is found.

I think there is too much MKGCC conditional logic

Firstly, bsd.own.mk doesn't set EXTERNAL_GCC_SUBDIR if MKGCC=no .. the
.endif could move up a paragraph I think.

Then inside the libgcc directory there is some logic. I think the libgcc
directory should not be descended into if it is not required, rather than
descending into it and deciding we want out.

iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Wed, 13 Aug 2014, William D. Jones wrote:

 The error to which I refer to (cannot find -lgcc) also occurs now, even when I
 set HAVE_PCC=1 while building libc... it seems that there is a depedency
 problem that has crept into the NetBSD source tree the past few days, because
 me receiving complaints about a missing libgcc when only building the PCC
 tools only started in the 2 to 4 days.

I am not sure about this recent addition, you might have a contaminated
objdir, do you start from empty dir?

I am thinking about this setup you are trying for..

Firstly, if GCC is being used to build something, then I think that it
will always add -lgcc to the linker command. This is because it
uses that to provide support for specific features (the code it produces
calls routines in there to do things, such as floating point math)

Then, in lib/Makefile, we don't build libgcc if MKGCC==no but perhaps we
should (if ACTIVE_CC==gcc then it will be needed during the build if not
the runtime)

if you force libgcc to be built (comment out the MKGCC conditional in
lib/Makefile) will it continue?

also, you should probably use HAVE_GCC=48 since that is the version in
use, and the version number is checked sometimes for various features

iain

Re: pcc build error that has been outstanding for a few days...

[Iain Hibbert]

On Tue, 29 Jul 2014, B Harder wrote:

 I've got an error (transcribing):

 /usr/src/external/bsd/pcc/libexec/ccom/../../dist/pcc/arch/amd64/code.c:
 In function 'amd64_builtin_v_arg':
 /usr/src/external/bsd/pcc/libexec/ccom/../../dist/pcc/arch/amd64/code/c:622:8:
 error: variable 'ap' set but not used
 [-Werror=unused-but-set-variable]
   NODE *ap, *r, *dp;
   ^

 I've re-run ./build.sh w/o -u to an implicit make clean is run, to
 no effect. Has this indeed been outstanding for a number of days, or
 am I missing a step to get over a hurdle?

This variable is actually unnecessary here (the value is used in
mkvacall() rather than this function), so I removed it

iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Sun, 10 Aug 2014, William D. Jones wrote:

 The error in the kernel happens at assym.d (Ignore the kernel name- it's a
 slightly modified GENERIC_TINY). I'm not sure what happened here, but it
 appears the preprocessor doesn't like  being invoked with the following
 command line. The only single-period I see is -I., and that works when the
 preprocessor by calling it directly:
 #create  PB_KERNEL/assym.d
 cat /mnt/lfs/NetBSD-CVS/src/sys/arch/i386/i386/genassym.cf  |
 /mnt/lfs/NetBSD-CVS/src/../tools/bin/nbgenassym --
 CC=/mnt/lfs/NetBSD-CVS/src/../tools/bin/i486--netbsdelf-pcc
 /mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmkdep -f assym.dep --  -msoft-float
 -mno-mmx -mno-sse -mno-avx -ffreestanding -fno-zero-initialized-in-bss -Os
 -Wno-error=uninitialized -Wno-error=maybe-uninitialized -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 -Wextra
 -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare
 --sysroot=/mnt/lfs/NetBSD-CVS/src/../destdir/i386-pb -Di386 -I.
 -I/mnt/lfs/NetBSD-CVS/src/sys/../common/include
 -I/mnt/lfs/NetBSD-CVS/src/sys/arch  -I/mnt/lfs/NetBSD-CVS/src/sys -nostdinc
 -DMAXUSERS=8 -D_KERNEL -D_KERNEL_OPT -std=gnu99
 -I/mnt/lfs/NetBSD-CVS/src/sys/lib/libkern/../../../common/lib/libc/quad
 -I/mnt/lfs/NetBSD-CVS/src/sys/lib/libkern/../../../common/lib/libc/string
 -I/mnt/lfs/NetBSD-CVS/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string
 -I/mnt/lfs/NetBSD-CVS/src/sys/external/bsd/ipf
 /mnt/lfs/NetBSD-CVS/src/../tools/libexec/i486--netbsdelf-cpp: invalid option
 -- '.'
 Usage: cpp [-Cdt] [-Dvar=val] [-Uvar] [-Ipath] [-Spath]
 error: /mnt/lfs/NetBSD-CVS/src/../tools/libexec/i486--netbsdelf-cpp terminated
 with status 1
 nbmkdep: compile failed.

I'm in the middle updating my system but this seems to work ok for me..

It is difficult to pin down as the error comes from cpp, which is run by
pcc, which is run by nbmkdep, which is run by nbgenassym .. can you run
the command again but add an -v option directly after the assym.dep
part? That should show what mkdep is doing, and if that seems ok, you can
also add -v into the pcc options (just before -msoft-float) which will
tell pcc to output the commands it runs

regards,
iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Sun, 3 Aug 2014, William D. Jones wrote:

 Have B. Harder's (Re: pcc build error that has been outstanding for a few
 days...) changes been added to the main tree yet?

No, I've been away sailing amongst the islands :)

 Perhaps PCC will be ready by the time NetBSD 7 is released- there's still time
 to make sure it works!

PCC is getting better all the time

 Sadly, I do not know enough about the context of replacements you are trying
 to make to feel comfortable editing this myself.

the script basically changes the RCS ID tags which are used by the PCC CVS
server to make them inactive (remove the $ at each end) and inserts RCS ID
tags for the NetBSD server to use. This means that the NetBSD server will
not modify the version number when any changes are made. This entire part
is irrelevant if you just want to work with PCC-current sources locally

Then, the script creates a config.h file and comments out several target
dependent options, which will be provided by the NetBSD build system
during compilation (so we can build for different targets without remaking
a config.h file)

iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Sun, 20 Jul 2014, Iain Hibbert wrote:

 On Sat, 19 Jul 2014, William D. Jones wrote:

   it certainly is. I think I remember that __USE() now, it was a local
   (NetBSD) addition due to a set but unused variable, which is changed in
   upstream versions now.
  Alright then. What do you suggest I do to reconcile the NetBSD version with
  the current upstream tree? Should I wait for the next major release of PCC,
  and then attempt to integrate the changes, or is there something I can do 
  now
  (to start)?

 I will try to import a new version later this week..

I have imported pcc-20140706 now, please report any problems in the usual
places (here for NetBSD build problems, or the PCC issue tracker for
compilation troubles)

regards,
iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Thu, 24 Jul 2014, William D. Jones wrote:

 First error of the night:

 #   compile  libiberty/regex.o
 /mnt/lfs/NetBSD-CVS/src/../tools/bin/i486--netbsdelf-pcc -O2-std=gnu99
 -Werror   -Os -Wno-error=uninitialized -Wno-error=maybe-uninitialized
 --sysroot=/mnt/lfs/NetBSD-CVS/src/../destdir/i386-pb -DHAVE_CONFIG_H
 -I/mnt/lfs/NetBSD-CVS/src/external/gpl3/binutils/lib/libiberty/arch/i386
 -I/mnt/lfs/NetBSD-CVS/src/external/gpl3/binutils/dist/include  -c
 -Wno-stack-protector
 /mnt/lfs/NetBSD-CVS/src/external/gpl3/binutils/dist/libiberty/regex.c -o
 regex.o
 /mnt/lfs/NetBSD-CVS/src/external/gpl3/binutils/dist/include/xregex2.h, line
 544: syntax error

I know about this one, this construct appears in a couple of places in GNU
sources..

 The relevant lines which cause an error are here:
 extern int regexec (const regex_t *__restrict __preg,
const char *__restrict __string, size_t __nmatch,
 line 544:regmatch_t __pmatch[__restrict_arr],
int __eflags);

 With that being said, I guess this is a gcc extension-related error,
 although I'm not sure how to fix it. Based upon lines 512 to 532, line
 544 should be defined to regmatch_t __pmatch[__restrict]. Perhaps pcc
 does not support that extension inside an array, but does elsewhere?

Yes, it is a GCC extension to recognise the restrict keyword in an array
declaration.  I have not fully looked into it due to lack of time but I
think it might be simple to support (ignore)

regards,
iain

Re: uhso(4) locking issues

[Iain Hibbert]

On Sat, 19 Jul 2014, Kamil Rytarowski wrote:

 plunky @ NetBSD the original commiter (and author?)

yes I wrote this originally

 Unfortunatelly, I've got issues with the driver with LOCKDEBUG turned on
 (expensive locking checks/support), and these issues result in kernel
 panics.

Is this with LOCKDEBUG and no other changes, or with LOCKDEBUG and the
addition of the MPSAFE flag?  I must admit, I have not tried LOCKDEBUG for
quite some time, since I have no way on this laptop to retrieve the dmesg
buffer after a reboot.

 Grzegorz found at least two bugs and told me that the driver has to be
 discussed with authors and most likely parly rewritten.

 I issue: spin lock held when taking mutex
 And uhso_tty_write() at src/sys/dev/usb/uhso.c takes mutex.

Hmm.. except it does not?

int
uhso_tty_write(dev_t dev, struct uio *uio, int flag)
{
struct uhso_softc *sc = device_lookup_private(uhso_cd, UHSOUNIT(dev));
struct uhso_port *hp = sc-sc_port[UHSOPORT(dev)];
struct tty *tp = hp-hp_tp;
int error;

if (!device_is_active(sc-sc_dev))
return EIO;

DPRINTF(5, sc=%p, hp=%p, tp=%p\n, sc, hp, tp);

sc-sc_refcnt++;

error = tp-t_linesw-l_write(tp, uio, flag);

if (--sc-sc_refcnt  0)
usb_detach_wakeupold(sc-sc_dev);

return error;
}

 So the general question is, has it ever been tested for
 lock-correctness? What would be the correct way to resolve it (in a
 fix-it-yourself approach)? Is possible to do so in uhso(4) without
 touching subsystems?

Nope, because the uhso driver does not do any locking directly..  there is
USB locking and TTY locking which must interact and I am not sure what
work has been done to make drivers MPSAFE in general.

iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Wed, 16 Jul 2014, William D. Jones wrote:

 I'm afraid that I am cross-compiling from a Linux system, and as to not
 contaminate my source tree, I wanted  to create a tools version of PCC that
 can be used to compile the rest of the tree. However, if your source tree does
 not have __USE (Google says you are a PCC developer), then it's probable that
 NetBSDs version of PCC is simply out of date.

it certainly is. I think I remember that __USE() now, it was a local
(NetBSD) addition due to a set but unused variable, which is changed in
upstream versions now

 I have a separate compiler (GCC) on my host machine as well... I can skip
 HAVE_PCC for now and just have the distribution ship PCC, or I can try an
 EXTERNAL_TOOLCHAIN. The latter is not trivial, since I have to create a
 cross-PCC. But I want to see JUST how much software PCC is capable of
 compiling. For example, will it compile most untarred source trees and GNU
 autoconfed trees I throw at it on the 486 without problem? The NetBSD source
 tree is a good test for this.

It does handle most of the NetBSD source tree lately, the main problems
currently are things which GCC accepts (or encourages) which are not
supported. Personally, I think it would be good for PCC to be able to
build GCC, perhaps that would be enough compatibility.

I have not tried application sources (eg pkgsrc) due to lack of time.

 As an aside, is it possible for PCC to reliably build the first stage of
 GCC = 4.7.3?

I am not sure, but it may not.. predictably the GCC developers use GCC
language features within their code, and these are not always supported. I
have been concentrating on other things lately and have not tried to build
GCC with PCC. At least I know that the binutils we have in tree won't
build, as there is an unsupported feature which causes an error (restrict
keyword in array declaration)

regards,
iain

Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

[Iain Hibbert]

On Wed, 16 Jul 2014, thor0...@comcast.net wrote:

 To free some space, I plan to rebuild and replace GCC with a PCC-built
 source tree (this should also speed up compilation, which is horrific on
 a 486, as some of you might remember :)...).

If you could manage without gcc entirely, not building that would save a
lot of time -- but pcc cannot yet compile all of NetBSD so you do need
another compiler available. I don't know how much time you save by using
pcc to build the parts that it can do, that is not something I have worked
on.

 According to the following mailing list post:
 http://mail-index.netbsd.org/tech-toolchain/2010/06/04/msg001298.html,
 the way to build a version of PCC in the tools directory is to set the
 HAVE_PCC variable in either MAKECONF or the command line. Incidentally,
 this will also build GCC in tools since it appears HAVE_GCC must also be
 set or ./build.sh will choke. Likewise, to build only PCC for
 distribution, I need to set MKPCC=yes, and MKGCC=no (the other
 environment variables for PCC are not required).

that post is still mostly accurate, though some of the other compiler
options may have changed

  MKPCC=yes  # build pcc in the distribution

  HAVE_PCC=  # build/use a tool version of pcc

but because it cannot build everything, I have not tried to fix the build
system to allow it to do that.

 gcc_compat.c:(.text+0xb6f): undefined reference to `__USE'

I haven't seen this, I don't think __USE appears in my sources

 According to this build failure in Oct 2013:
 http://mail-index.netbsd.org/current-users/2013/10/19/msg023571.html,
 this error of missing symbol __USE is not unheard of in other parts of
 the source tree, but I'm unsure what it entails. I wanted to know
 whether a developer or someone who has experience building with PCC can
 tell me the nature of this error/a potential workaround before I file a
 problem report with NetBSD or PCC? Is PCC out of date because it has not
 been used by others to compile recently?

To be honest, I don't keep up with -current as often as I would like, so
my NetBSD source may be a couple of months old.. I do work with the latest
PCC, which I update locally all the time and there doesn't seem much gain
in continually importing changes to NetBSD. The last version is two years
old though so I would like to do that again shortly, as Ragge has beaten
down the bug lists once again.

I *fully* recommend using the latest pcc before looking too deeply into
any errors. You can use the native pcc configure script and build system
(installs to /usr/local) or the lang/pcc-current package (might not always
be latest but its easy to change the date -- I just updated it)

regards,
iain

Re: update build always rebuilds freetype and friends?

[Iain Hibbert]

On Sun, 20 Apr 2014, John D. Baker wrote:

 My update (-u) release builds seem always to rebuild freetype and friends
 even though nothing has changed.  In fact, if I run two identical builds
 with no intervening cvs update, freetype and related items will be rebuilt
 both times.

 Does anyone else see this?  Is it deliberate?

I did not see this; I built a distribution last night and an update
distribution this morning, then an update release on top of that and it
has not built freetype again..

however,

% grep '===.*freetype' build.log
obj === external/mit/xorg/lib/freetype
obj === external/mit/xorg/lib/freetype/freetype
obj === external/mit/xorg/lib/freetype/freetype/config
includes === external/mit/xorg/lib/freetype
includes === external/mit/xorg/lib/freetype/freetype
includes === external/mit/xorg/lib/freetype/freetype/config
dependall === external/mit/xorg/lib/freetype
dependall === external/mit/xorg/lib/freetype/freetype
dependall === external/mit/xorg/lib/freetype/freetype/config
install === external/mit/xorg/lib/freetype
install === external/mit/xorg/lib/freetype/freetype
install === external/mit/xorg/lib/freetype/freetype/config
dependall === external/mit/xorg/lib/freetype
dependall === external/mit/xorg/lib/freetype/freetype
dependall === external/mit/xorg/lib/freetype/freetype/config
install === external/mit/xorg/lib/freetype
install === external/mit/xorg/lib/freetype/freetype
install === external/mit/xorg/lib/freetype/freetype/config

it descends into the freetype directory more than once; this is likely
because it builds this first as a lib, then just passes through while
building xorg ..

regards,
iain

Re: redefined symbols issue

[Iain Hibbert]

On Mon, 21 Apr 2014, Matt Thomas wrote:


 On Apr 21, 2014, at 3:29 AM, Anders Magnusson ra...@ludd.ltu.se wrote:

  Iain Hibbert skrev 2014-04-20 20:07:
  Hello
 
  I found an issue when compiling NetBSD sources with pcc, which I am not
  sure where the 'fault' lies, as pcc handles this slightly differently than
  gcc (and clang) though the cause of it seems strange in its own right.
 
  The problem I face is that DBL_DIG, DBL_MAX, DBL_MIN, FLT_DIG, FLT_MAX and
  FLT_MIN are defined in machine/limits.h and sys/float_ieee754.h both,
  and during a build of (eg) libc/absvdi2.o, I get an error because they are
  defined slightly differently. For example, in i386/limits.h I see:
 
  #define DBL_DIG15
 
  whereas in sys/float_ieee754.h there is effectively:
 
  #define DBL_DIG__DBL_DIG__

  This is actually disallowed in C99 6.10.3 clause 1 and 2.
  A redefinition must be literally identical to be allowed.

 I notice that pcc incorrectly defines __DBL_* and __FLT_* for vax.

I have added the correct values in the pcc repo (the way its done
currently needs some reworking)

 Everyone but vax now uses __xxx__ in machine/limits.h

thanks..

btw this might be considered to fix http://gnats.netbsd.org/48187 ?

though, it could happen again the other way around, since in some cases
the sys/float_ieee754.h file defines using numerical values directly..

regards,
iain

redefined symbols issue

[Iain Hibbert]

Hello

I found an issue when compiling NetBSD sources with pcc, which I am not
sure where the 'fault' lies, as pcc handles this slightly differently than
gcc (and clang) though the cause of it seems strange in its own right.

The problem I face is that DBL_DIG, DBL_MAX, DBL_MIN, FLT_DIG, FLT_MAX and
FLT_MIN are defined in machine/limits.h and sys/float_ieee754.h both,
and during a build of (eg) libc/absvdi2.o, I get an error because they are
defined slightly differently. For example, in i386/limits.h I see:

#define DBL_DIG 15

whereas in sys/float_ieee754.h there is effectively:

#define DBL_DIG __DBL_DIG__

which does evaluate to the same thing in the end, but is different in the
context of the preprocessor.

Now, the reason that gcc has not complained about this, is that warnings
about redefinitions inside a system header are supressed (and note that
 pcc also does this). BUT, crucially, the float_ieee754.h file that is
included by the compilation is not really a system header because we
provided -I $SRC/sys on the commandline.. meaning that the included files
were:

% cat test.c
#include float.h
% gcc -E -I /usr/src/sys test.c
# 1 test.c
# 1 command-line
# 1 test.c
# 1 /usr/include/float.h 1 3 4


# 1 /usr/include/x86/float.h 1 3 4





# 1 /usr/src/sys/sys/featuretest.h 1 3 4
# 7 /usr/include/x86/float.h 2 3 4
# 18 /usr/include/x86/float.h 3 4
# 1 /usr/src/sys/sys/float_ieee754.h 1 3 4
[...]

and so you can see (from the 3 flag), that although the float_ieee754.h
file is not in the system include path, because it was included from
within a system header then gcc does still consider it a system header.
This behaviour is not enumerated in the cpp.info file (there is a System
Headers page) and pcc does not currently behave that way. (I am not sure
if clang has a document describing its behaviour wrt this, I could not
find one)

So, there are a bunch of questions thrown up by this

1. should we be mixing /usr/include and $SRC headers in this way?
   - this does not feel right to me

2. do we really need to define such symbols in more than one place?
   - it also does not feel right to me

3. should the definitions be different?
   - the HPPA limits.h file makes an effort to use compiler
 provided constants when possible

4. do these definitions actually need to be in the machine/limits.h file?
   - the kernel does not use them anyway

5. does pcc need to be changed?
   - I can just change pcc to behave like gcc in this regard, which makes
 this issue go away

thoughts?

iain