Re: IBM Workpad z50 dmesg collection

On Tue, 18 May 2021 at 00:56, Alexander Bochmann <[email protected]> wrote:
>
> ...on Mon, May 17, 2021 at 06:49:14PM +0100, David Brownlee wrote:
>
>  > Excellent - thanks (and sorry for reply latency on this)
>
> No worries, I've been sitting on this thing for years :)
>
>  > - Does the latest
>  > http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/latest/hpcmips/ kernel
>  > boot? In the unlikely event of the pcmcia issue being fixed since 9.x
>  > its probably worth checking
>
> I didn't try HEAD yet, but I did a quick boot of the NetBSD 9.2
> release kernel.
>
> Unfortunately no dmesg again, as I'm still out of a serial cable,
> and neither network nor storage are operable - it looks ok in the
> dmesg at first (ne0 is detected, as is wd0), but then it ends up
> with a "wd0: IDENTIFY failed", and when using the installer kernel,
> it sais no usable network device has been found.
>
> I took a photo of the bottom of the dmesg on screen, currently
> available here:
> https://cloud.gxis.eu/index.php/s/N3bw45GfDqSLAXg

HEAD is radically different to any of the 9 kernels - once a release
is branched only a relatively small percentage of changes are pulled
up (and its been a _long_ time since the original 9 branch :), so it's
probably worth a kernel test boot

>  > - For the 8.x boots, I wonder if it could be floating point or shared
>  > library related. There are static linked binaries in /rescue,
>  > including 'sleep', 'expr' & 'ps' which can use floating point. It may
>  > be worth a small amount of testing to see if an error can be triggered
>  > with a /bin/ vs /rescue/ binary
>
> I can try that tomorrow. As far as I have seen while building
> several NetBSD/hpcmips releases, the userland doesn't use -msoft-float
> in general (while most of the kernel does, except for some locore stuff),
> so I assume the system depends on some floating point emulation directly
> in the kernel?

Historically the practice was to avoid any in-kernel FPU use for all
platforms, (though that has changed in some cases for crypto code)

> From NetBSD 8 on, ld throws a warning when linking the kernel,
> because -msoft-float and -mhard-float bits are being mixed - but
> seems it's the same in earlier versions, except that it doesn't
> create a warning during the build.
>
> (The linker warning has been mentioned on the list a couple of
> years ago, and the answer was that it's expected to occur.)
>
>  > - What would you require as a minimum for testing - just a built
>  > kernel? (Thinking about bisecting the device issue between 8 & 9)
>
> Yes, a hpcmips GENERIC kernel will do. I can also do builds
> myself, but I'm afraid I haven't really understood the workflow
> around selecting commits and git bisect up to now (sorry, I haven't
> really been using git beyond the occasional fetch / checkout).

The notes I scribbled into the other thread should be a reasonable
base, I'll try to clean them up a little...

1) Clone the github NetBSD mirror
git clone https://github.com/NetBSD/src.git && cd src

2) update to current around the time of the working netbsd-8 release
git checkout $(git rev-list -1 --before="2018-07-17" trunk)

3) Build the system tools and a GENERIC kernel to test boot
./build.sh -U -m hpcmips tools kernel=GENERIC

4) Based on the initial test result
a) kernel good: Run "git bisect good", git checkout about a year or so
later & retry build
b) kernel bad: Run "git bisect bad", git checkout about a year or so
earlier & retry build
c) Build failed: Git checkout forward or back a day or so and retry build

5) Repeat 3 & 4 until you get one "good" and one "bad" result, at
which point git bisect will take over and start a binary search for
the problem commit, with you needing to run git bisect good, bad or
skip after the result of each test