Debian Linux boot regression

[mark_k]

I downloaded the ready-made Debian HDF from http://aminet.net/package/misc/os/De...r8X11-21r5-hdf. The slightly-adjusted config I'm using is attached.

The HDF is configured for A4000 IDE hard disk. The config is using 68040 CPU.

Using WinUAE 2.4.0, it eventually shows an X login screen with no user input needed, other than pressing return a couple of times at the boot loader. The pic below shows the end result.

With later versions of WinUAE something goes wrong however...
WinUAE 2.4.1: hang at black screen after boot loader. The HD activity indicator does show activity however. So maybe it is actually doing something? I guess this is the "Debian Sarge blank screen" you mentioned in the 2.6.0b1 changelog? (I might try changing the HDF so it doesn't use a programmed mode, maybe that can help narrow down where the regression occurred.)

With WinUAE 2.6.0b3 I get dumped at a text-mode login prompt, see pics. With 68030 CPU I also get that prompt, but entering a username just causes the prompt to be printed again.

Updates: Adding a video=pal-lace argument to the amiboot command line in s/startup-sequence makes Linux use a standard PAL mode, so no blank display problem.
With that change the HDF boots fine with WinUAE 2.4.1 It works with 2.5.0b15, broken with 2.5.0b18.

With 2.5.0b18, the boot process hangs, with this printed over and over:
kmod: failed to exec /sbin/modprobe -s -k binfmt-4c46, errno = 8

WinUAE 2.5.0b16 and 2.5.0b17 both boot fine, so some change between 2.5.0b17 and 2.5.0b18 is responsible. The only thing in the 2.5.0b18 changelog which looks like it might be relevant is: "Few (rare) variants of MOVES didn't increase PC correctly."

[mark_k]

I also tried booting the Debian HDF with emulated A3000/030 and A3000/040 in WinUAE 2.6.0b3. The HDF connected to the A3000 built-in SCSI controller. To do that you need to edit the root= argument, change from root=/dev/hda2 to root=/dev/sda2. [Of course I'm not certain how that particular HDF would boot on real A3000 hardware, but figured I'd mention this anyway.]

With A3000/040, booting hangs with this line repeating over and over in WinUAE log:
040 BUS ERROR: fc=1 w=0 logical=10001000 ssw=0121 PC=c0002074

In the Linux console output, notice the sending SDTR and blank fields for Vendor, Model and Rev. Maybe some 33C93 emulation problem there? Also notice Linux thinks it's a WD33C93B chip. Did any real A3000's have that, as opposed to the original WD33C93 or maybe WD33C93A?

With A3000/030 the Linux console output is similar to the 68040 case. The WinUAE log output doesn't have the bus error line repeating, instead just these five lines:
MMU: page fault (logical addr=800083AC SSW=0301 read=0 size=4 fc=1 pc=0003f2ba)
MMU: page fault (logical addr=C00120D8 SSW=0301 read=0 size=4 fc=1 pc=0003f2ba)
MMU: page fault (logical addr=C0001C68 SSW=5062 read=1 size=2 fc=2 pc=c0001c68)
MMU: page fault (logical addr=C0011AB8 SSW=0341 read=1 size=4 fc=1 pc=c0001d5c)
MMU: page fault (logical addr=C0002074 SSW=5062 read=1 size=2 fc=2 pc=c0002074)

[Toni Wilen]

b18 fix is correct, it looks like this bug and another bug made it work accidentally in this situation...

68040 + Debian works again but unfortunately this fix had no effect on NetBSD.

[mark_k]

Testing with the 2013-01-22 19:18 winuae.exe, while it gets a lot further in the boot process than 2.6.0b3, it doesn't boot into X like 2.5.0b17 did. At the point X is about to start, this text is shown:

Checking for valid XFree86 server configuration...Your random numbers are not th
at random.
error in configuration file.
Not starting X display manager.

[Toni Wilen]

68030 + Debian seems to work now (MMU page table cache flushing was unreliable causing invalid pages to remain invalid even if they were fixed by bus error handler)

not random..

I guess it is better to check sources first for explanation...

[mark_k]

I can now boot to X with the 2013-01-22 21:04 winuae.exe and 68030 CPU.

With 68040 there is an error quite early in the boot sequence (see pic), and consequently many other things later on in the boot sequence show error messages too. I can attach a log if you want but it might not be much help.

Also with that version of winuae.exe, booting an installed NetBSD 6.0.1 HDF with A3000/040 config, WinUAE reports this in the log several times:
040 MMU_SSW_LK!

[Toni Wilen]

What is this version of netbsd? Your screen shot says "NetBSD 6.0.1 (GENERIC)" but I only remember seeing "NetBSD 6.0.1 (INSTALL)" which only hangs before keyboard selection if 68040+.

[mark_k]

I used an HDF with an already-installed NetBSD 6.0.1, installed using an emulated A3000/030. Hang on a few mins and I'll upload it...

It's about 84MB, get it from http://www..com/file/kfNmf5cG...nstall_A3.html.

[Toni Wilen]

File seems to be broken (downloaded twice).

twilen@mint ~/d $ tar xvJf NetBSD_4GB_HD_after_install_A3000_zeroed_ADOS_partition.tar.xz
NetBSD_4GB_HD.bin
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

(btw, please, don't use sparse tars, at least 7zip does not support it)

[mark_k]

That error message (I assume you're extracting using GNU tar?) is bogus, the file probably did extract properly. The extracted file should be 4000000000 bytes long, MD5 checksum 2abf2aa583b6f672744326ca9385fd27

(I create the tar archives sparsely because it's massively faster to compress and decompress/unpack, in cases like this where most of the file data is zero bytes.)

[Toni Wilen]

Right, file was fine after all.. For some weird reason all your previous 4G xz tars did unpack without errors.

I didn't notice any major time differences when unpacking 7zip, only compression took long time..

[mark_k]

Yeah, the reason for the error message is a bug in GNU tar; it chokes on certain tar-compliant archives which contain sparse files created by some other tar archivers. (I think I used GNU tar to create the other archives, hence no error message with those.)

Regarding unpacking, the speed benefit would depend on how much RAM you have and how fast your hard disk is. Unpacking a sparse archive to a USB 2.0 hard disk takes a lot less time than unpacking the equivalent non-sparse ~4GB file. In the latter case 4GB of actual data would need to be written to disk which would probably take over 2.5 minutes.

[Toni Wilen]

Forgot to reply..

Originally Posted by mark_k

In the Linux console output, notice the sending SDTR and blank fields for Vendor, Model and Rev. Maybe some 33C93 emulation problem there? Also notice Linux thinks it's a WD33C93B chip. Did any real A3000's have that, as opposed to the original WD33C93 or maybe WD33C93A?

Initial SCSI detection code seems to use different code than "real" SCSI access that expects correct 33C93 states but because current emulation skips all "useless" SCSI disconnect/reconnect stuff it gets confused and refuses to read the returned inquiry data

33C93 emulation does not support any advanced features (A and later) but I decided to return 33C93A+ status because some programs may assume 33C93 is too buggy..

Regarding unpacking, the speed benefit would depend on how much RAM you have and how fast your hard disk is. Unpacking a sparse archive to a USB 2.0 hard disk takes a lot less time than unpacking the equivalent non-sparse ~4GB file. In the latter case 4GB of actual data would need to be written to disk which would probably take over 2.5 minutes.

I guess SSD + 16G of RAM helps then

[Toni Wilen]

Blank vendor, models, revision fields fixed. It was incorrect handling of wd phase 0x45, it can be used to "start" data phase.

[Toni Wilen]

Originally Posted by mark_k

Also notice Linux thinks it's a WD33C93B chip

This is also fixed, now it returns correct WD33C93A.

[mark_k]

I noticed that wth the default DblPAL-like AGA screen mode, the righthand edge of the Debian X desktop is blank (testing with 2.6.0b4 and the Aminet Debian HDF). Edit to add: The right edge is not cut off using WinUAE 2.3.3. The 2nd pic shows what it looks like with WinUAE 2.3.3.

And also, booting with A4000/030 config with today's (2013-01-28) winuae.exe hangs early in the boot sequence. 2.6.0b4 works fine.

Originally Posted by Toni Wilen

I guess SSD + 16G of RAM helps then

Writing files sparsely is good for SSDs too, since ~3.5GB less data is written to the SSD each time you unpack one of the sparse image files.