Re: reboot hangs at "uhid2 at uhidev9 report id 7 ..."

[Robert Elz]

Date:Wed, 5 May 2021 18:55:38 +0200
From:Rhialto 
Message-ID:  

  | On Wed 05 May 2021 at 15:18:03 +0900, Henry wrote:
  | > The system kept booting into single user mode, but searching around I
  | > finally figured out that I needed to edit /etc/rc.conf.  I thought I
  | > had successfully changed to rc_configured=YES.
  |
  | The installer is also supposed to do that for you, so there must have
  | been something weird there.

Which might also explain the current problem.  If the final stages of the
system setup weren't done correctly, /dev might not have been setup either.
In that case, no-one is going to be able to open /dev/console to output
any further (from userlevel) messages.  That last message you're seeing is
often one of the last from the kernel before you start getting messages from
running /etc/rc.

That is, it is entirely possible  that the system is up and running, but
there is simply no way to communicate with it (if rc.conf wasn't set up,
the network probably isn't enabled either).

Boot in single user mode, check what is in /dev - if what's there doesn't
look correct (ordinary file for /dev/null or missing, no /dev/console or
not a char device, ...) then delete everything (except MAKEDEV if that is
in /dev on your version) and "cd /dev; sh MAKEDEV std" (or sh /etc/MAKEDEV
or wherever it is to be found).

If what is in /dev looks to be correct, check /etc/ttys next, but incorrect
config there is less likely to explain things.

kre

Re: toupper and warnings

[Greg A. Woods]

At Wed, 5 May 2021 20:33:30 - (UTC), chris...@astron.com (Christos Zoulas) 
wrote:
Subject: Re: toupper and warnings
>
> gcc hides warnings from system headers by default (my guess is because
> the Linux system headers have a concealed firearms license).
>
> Our bsd.sys.mk turns it on... Try gcc -Wall -Wsystem-headers

Does that really make the difference?

(I can't quickly test it at the moment as I've fixed my test system such
that I don't ever get these warnings from the ctype macros.  I.e. I went
the other way and chose to make my implementation's "undefined
behaviour" to be to behave as conservative as possible and allow the
caller to use these macros in the traditional naive way without fear and
without noisy warnings from picky compilers when char is signed.)

> I've been considering to make it the default for our native gcc,
> but then again I am against gratuitous user facing changes...

Note that -Wsystem-headers doesn't go well with -Wundef on NetBSD yet.

I find -Wundef to be quite helpful in writing more robust CPP
expressions -- it's saved me more than once from embarrassingly
non-portable ones, though I didn't start using it nearly soon enough.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpzulPfCalY4.pgp
Description: OpenPGP Digital Signature

Re: toupper and warnings

[Christos Zoulas]

In article ,
Greg Troxel   wrote:
>-=-=-=-=-=-
>
>
>We used to get warnings when toupper was called with char, because it is
>UB pe POSIX if the value is negative.
>
>I am not seeing this any more on NetBSD 9.
>
>I wonder if this is intended, and if the UB is safely avoided somhow, or
>if the warning is just missing, or ?
>
>example program that I think should get a UB warning; doesn't on
>netbsd-9.
>
>
>#include 
>#include 
>
>int
>main()
>{
>  char c, d;
>
>  c = getchar();
>
>  d = toupper(c);
>
>  if (d != c)
>return 1;
>  else
>return 0;
>}

gcc hides warnings from system headers by default (my guess is because
the Linux system headers have a concealed firearms license).

Our bsd.sys.mk turns it on... Try gcc -Wall -Wsystem-headers

I've been considering to make it the default for our native gcc,
but then again I am against gratuitous user facing changes...

christos

toupper and warnings

[Greg Troxel]

We used to get warnings when toupper was called with char, because it is
UB pe POSIX if the value is negative.

I am not seeing this any more on NetBSD 9.

I wonder if this is intended, and if the UB is safely avoided somhow, or
if the warning is just missing, or ?

example program that I think should get a UB warning; doesn't on
netbsd-9.


#include 
#include 

int
main()
{
  char c, d;

  c = getchar();

  d = toupper(c);

  if (d != c)
return 1;
  else
return 0;
}


signature.asc
Description: PGP signature

Re: reboot hangs at "uhid2 at uhidev9 report id 7 ..."

[Rhialto]

On Wed 05 May 2021 at 15:18:03 +0900, Henry wrote:
> I recently installed 9.1 on a HP 15-au123cl.  The install seemed to go
> fairly smoothly, and I was able to get the sets via ftp.
> 
> The system kept booting into single user mode, but searching around I
> finally figured out that I needed to edit /etc/rc.conf.  I thought I
> had successfully changed to rc_configured=YES.

The installer is also supposed to do that for you, so there must have
been something weird there.

> However, since then, whenever I try to boot the machine it hangs at:
> [   4.7432765] uhid2 at uhidev9 report id 7: input=0, output=0 feature=256
> (the numbers in brackets change; I have seen 7582388, 225.834047, 4.9366070).
> There seems to be nothing else to do other than to hold down the power
> button and shut the computer off.

The "[   4.7432765]" is a timestamp so it's not so strange that it
varies a bit.

"uhid" is a "human interface device", usually a mouse or keyboard. There
should be a line earlier in the output, starting with "uhidev9:" which
tells you what sort of device it is. For example, for my mouse:

uhidev0: Logitech (0x46d) USB Optical Mouse (0xc05a), rev 2.00/54.00, addr 1, 
iclass 3/1

> What can I do to get the computer to boot?  (Or, did the computer
> suddenly give out on me?)

Hopefully that will tell you which device it is, and you can try to
unplug it and then boot. Sometimes devices like iPhones present
themselves as multiple devices to the computer. The high number (9) may
be explained by something like that.

> Henry
-Olaf.
-- 
___ Q: "What's an anagram of Banach-Tarski?"  -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl


signature.asc
Description: PGP signature

Re: Some questions about build.sh, machine, -u and tools

[Valery Ushakov]

On Wed, May 05, 2021 at 12:57:21 +0200, Rocky Hotas wrote:

> On mag 03 16:42, Valery Ushakov wrote:
>
> > TL;DR: src/BUILDING explains most of these things.
> 
> It has the header of a Section 8 manpage, but it is not accessible as
> such (`man BUILDING', `man 8 BUILDING' or with lower keys). Is this
> normal?

Yes.  It's just formatted using mdoc, but is not installed as part of
system manual pages.


> > On Mon, May 03, 2021 at 12:18:54 +0200, Rocky Hotas wrote:
> 
> > Roughly speaking MACHINE determines with kernel, bootloader, etc the
> > system uses.  You can have multiple MACHINE_ARCH for the same MACHINE
> > when the machine can have different ABIs (e.g. old arm, earm) or run
> > in different endianness (big, little) or bitness (32, 64).
> 
> Ok! Even if two MACHINEs with different ABIs or endiannes have really
> few common features, maybe just the commercial brand and the
> partitioning scheme.  Sorry, this is extreme of course, but the common
> MACHINE idea still looks weird to me.

I think Martin explained it pretty well in another followup.


> > tooldir* is default TOOLDIR, a place where the cross tools are
> > installed, you can set it with -T option to build.sh.  tools is the
> > objdir for the src/tools, a place where tools are built.  The choice
> > to put tooldir inside objdir by default might be a bit confusing, IMO.
> > Personally, I just use explicit -T.
> 
> Ok! My previous guess was wrong, then. So, IIUC: src/tools are the cross
> tools. The directory tools is just an intermediate step in the building
> of the cross tools. Once they are built, their executables are finally
> placed in the TOOLDIR.

If by the "directory tools" you mean the one in the build directory
(it took me a while to realize that), then yes.  It's called an objdir
and is a standard make(1) feature.  Please check make(1).


> I was confused by the apparently different names that are present in
> tools and in tooldir.NetBSD-9.99.81-amd64. Instead, most of the names
> in tooldir.NetBSD-9.99.81-amd64 are just the names in tools, with `nb'
> prefix. Also, running from tooldir.NetBSD-9.99.81-amd64 a trivial (but
> effective, for a newbie)
> 
> diff nbsed ../../tools/sed/sed
> diff nbcat ../../tools/cat/cat
> 
> shows that the two files match. Correct me if I'm wrong.

Yes, we build our own make, sed, etc as part of the tools build and
install them in $TOOLDIR/bin.  We add nb- prefix to the installed
versions to avoid name clashes with the host programs.  E.g. GNU
programs (can) do the same, using g- prefix (and in some cases that g-
even fused into the name (gcc, gawk)).

-uwe

Re: Some questions about build.sh, machine, -u and tools

[Martin Husemann]

On Wed, May 05, 2021 at 12:57:21PM +0200, Rocky Hotas wrote:
> Ok! Even if two MACHINEs with different ABIs or endiannes have really
> few common features, maybe just the commercial brand and the
> partitioning scheme.  Sorry, this is extreme of course, but the common
> MACHINE idea still looks weird to me.

No, but you may have the choice wich kernel/userland you want to run
on the same physical hardware. An example is my cubietruck:
I run it big-endian as:

[~] martin@space-truckin > uname -p -m
evbarm earmv7hfeb

but most people use exactly the same hardware to run earmv7hf (little endian)
instead.

On this board the difference is a simple "set endianess" instruction early
in the kernel, but on some other machines it is a physical jumper on the board.

This is not a very typical case though.

The "compat" cases are more common: on arm machines you can execute
binaries for eabi (the default) and oabi. On aarch64 machines you could
run aarch64 (native 64bit), eabi (new 32bit abi) or oabi (old 32bit abi).

On mips it is o32, n32 or n64. Most popular case is amd64 kernels that also
can execute i386 userland.

But IMHO it is best to keep out this "compat" type of things when thinking
about native MACHINE and MACHINE_ARCH.


I guess now you see the complex spread sheet and understand why you have
been confused initally - hope it got better during this thread ;-)

Martin

Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas]

On mag 05 11:13, Martin Husemann wrote:

> A MACHINE is a concrete thing, it belongs to a broader group of similar
> (but not identical) other machines of the same MACHINE_ARCH.

Ok! So, the reference and the "glue" is not MACHINE (as I thought), but
MACHINE_ARCH. This also explains what Greg was writing before.

It seems that the distinction between MACHINE and MACHINE_ARCH is
created for this purpose. As far as a userland program meets the same
MARCHINE_ARCH, even across different MACHINEs, it should work.

> How wide the range of MACHINE_ARCH goes, depends on details, e.g. there are
> lots of very different MACHINE (mac68k, atari, amiga, sun3, next68k, 
> mvme68k...)
> for MACHINE_ARCH = m68k. This is because we made userland compatible.
> Similar for MACHINE_ARCH = powerpc.
[...] 
> So in short: MACHINE_ARCH may be shared with other MACHINEs. Userland
> programs (ignoring device specific ioctl helpers) do not care about
> MACHINE but only require the MACHINE_ARCH.

So that they are compatible with different MACHINEs if they have the
same MACHINE_ARCH.

Thank you!

Rocky

Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas]

On mag 05 10:57, Rocky Hotas wrote:

> There are two different kinds of tools:
> 
> 1.
> The ones in obj_dir/tools, which are the result of the building of
> /usr/src/tools.
[...]
> 2.
> The ones in obj_dir/tooldir.NetBSD-9.99.81-amd64, which are the actual
> toolchain.

Apparently, this is completely wrong. See my reply to Valery for an
update:

 

Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas]

On mag 03 16:42, Valery Ushakov wrote:
> TL;DR: src/BUILDING explains most of these things.

Thanks! I'm trying to read it and it clarifed some doubts, but not
all.
It has the header of a Section 8 manpage, but it is not accessible as
such (`man BUILDING', `man 8 BUILDING' or with lower keys). Is this
normal?

> On Mon, May 03, 2021 at 12:18:54 +0200, Rocky Hotas wrote:

> Roughly speaking MACHINE determines with kernel, bootloader, etc the
> system uses.  You can have multiple MACHINE_ARCH for the same MACHINE
> when the machine can have different ABIs (e.g. old arm, earm) or run
> in different endianness (big, little) or bitness (32, 64).

Ok! Even if two MACHINEs with different ABIs or endiannes have really
few common features, maybe just the commercial brand and the
partitioning scheme.  Sorry, this is extreme of course, but the common
MACHINE idea still looks weird to me.

> tooldir* is default TOOLDIR, a place where the cross tools are
> installed, you can set it with -T option to build.sh.  tools is the
> objdir for the src/tools, a place where tools are built.  The choice
> to put tooldir inside objdir by default might be a bit confusing, IMO.
> Personally, I just use explicit -T.

Ok! My previous guess was wrong, then. So, IIUC: src/tools are the cross
tools. The directory tools is just an intermediate step in the building
of the cross tools. Once they are built, their executables are finally
placed in the TOOLDIR.

I was confused by the apparently different names that are present in
tools and in tooldir.NetBSD-9.99.81-amd64. Instead, most of the names
in tooldir.NetBSD-9.99.81-amd64 are just the names in tools, with `nb'
prefix. Also, running from tooldir.NetBSD-9.99.81-amd64 a trivial (but
effective, for a newbie)

diff nbsed ../../tools/sed/sed
diff nbcat ../../tools/cat/cat

shows that the two files match. Correct me if I'm wrong.

> Yes, -u is an "update" build.  build.sh is not magic, it's just a
> wrapper for plain old make.  Roughly speaking, -u tells it to not nuke
> the existing objdir and destdir and just run make and let it do the
> make thing, figuring out which things are out of date.
> 
> If you have a tree you've already built.  You can hack on, say,
> src/games/trek and then just run $TOOLDIR/bin/nbmake-vax to compile
> your changes, where nbmake-vax is just a script that invokes nbmake
> host tool (i.e. good old make, compiled for the host you are on) with
> a bunch of variables pointing to the right places to find sources, the
> toolchain, etc.

Thank you so much!

Rocky

Re: Some questions about build.sh, machine, -u and tools

[Martin Husemann]

On Wed, May 05, 2021 at 10:57:56AM +0200, Rocky Hotas wrote:
> MACHINE is defined in the paper as a platform (par. 5.1).  Intuitively,
> yes, MACHINE seems related to a whole computer (so, a collection
> of hardware devices with its standards and conventions) and
> MACHINE_ARCH is somewhat more specific, being related to a specific
> CPU, but MACHINE is still a somewhat blurry element to me.

A MACHINE is a concrete thing, it belongs to a broader group of similar
(but not identical) other machines of the same MACHINE_ARCH.

How wide the range of MACHINE_ARCH goes, depends on details, e.g. there are
lots of very different MACHINE (mac68k, atari, amiga, sun3, next68k, mvme68k...)
for MACHINE_ARCH = m68k. This is because we made userland compatible.
Similar for MACHINE_ARCH = powerpc.

However, due to tiny but important instruction differences, we have
probably more earm* MACHINE_ARCH's than MACHINEs for MACHINE_ARCH=m68k.

So in short: MACHINE_ARCH may be shared with other MACHINEs. Userland
programs (ignoring device specific ioctl helpers) do not care about
MACHINE but only require the MACHINE_ARCH.

Martin

Re: Some questions about build.sh, machine, -u and tools

[Rocky Hotas]

According to the paper

 

let's use the terms `build host', `host' and `target'.

On mag 03  8:30, Greg Troxel wrote:

> I keep forgetting this and having to page it in, but a big concept is
> that you can share userland among systems built for the same CPU type
> but that are different kinds of computers.  Basically MACHINE describes
> the computer and MACHINE_ARCH the CPU.  It may be helpful to read
> build.sh.

I thought it was the opposite: a userland shared by several MACHINEs of
the same type but different CPUs...

MACHINE is defined in the paper as a platform (par. 5.1).  Intuitively,
yes, MACHINE seems related to a whole computer (so, a collection
of hardware devices with its standards and conventions) and
MACHINE_ARCH is somewhat more specific, being related to a specific
CPU, but MACHINE is still a somewhat blurry element to me.

I scrolled the whole build.sh searching for the string MACHINE, but
(at least at a first glance) I didn't find something new.

> The tooldir is a prefix that has bin/lib and so on, which has programs
> that run on the build host, and are cross for targets.
> 
> There is also an obj dir for building the cross tools, usually the tools
> subdir within the objdir.

This is the exact fact which confuses me. I tried to understand this as
follows (but I'm not sure it's right and the par. 5.5 in the paper did
not shed a light).

There are two different kinds of tools:

1.
The ones in obj_dir/tools, which are the result of the building of
/usr/src/tools.
These are the tools used by the `build host' to build the second type of
tools, the toolchain.

2.
The ones in obj_dir/tooldir.NetBSD-9.99.81-amd64, which are the actual
toolchain.
They are used by the `host' to build the sourcecode (kernel and/or
userland) for the `target' system.

> -u basically means "just run make, and don't clean first",
> operationally.  This only works if the makefile rules are correct and
> nothing has changed outside the scope of what make copes with.
> 
> If you have changed a few lines of code, -u almost always works.
> 
> If you did cvs update along netbsd-9, it is highly likely that -u will
> work.
> 
> If you updated along current, it often works.   The shorter the time
> period, the more likely.

Ok! This is straght and simple.

Thank you!

Rocky

reboot hangs at "uhid2 at uhidev9 report id 7 ..."

[Henry]

I recently installed 9.1 on a HP 15-au123cl.  The install seemed to go
fairly smoothly, and I was able to get the sets via ftp.

The system kept booting into single user mode, but searching around I
finally figured out that I needed to edit /etc/rc.conf.  I thought I
had successfully changed to rc_configured=YES.

However, since then, whenever I try to boot the machine it hangs at:
[   4.7432765] uhid2 at uhidev9 report id 7: input=0, output=0 feature=256
(the numbers in brackets change; I have seen 7582388, 225.834047, 4.9366070).
There seems to be nothing else to do other than to hold down the power
button and shut the computer off.

What can I do to get the computer to boot?  (Or, did the computer
suddenly give out on me?)

TIA

Henry