WinUAE 2.3.0 + NetBSD 5.0.2 No go.

[ahhyes]

Hi guys,


Thought I'd give NetBSD a go since I now hear that there is MMU support. I've transferred the miniroot.fs over to the swap partition, however the NetBSD kernel seems to hang while starting up, see picture below:



And thats as far as it will go. I did some googling around and didnt find much except a post from someone else stating they had the same issue, and they were advised to make sure that they were not using the 'uae' controller for the hard disk, well, that doesnt apply to me since I have chosen IDE in WinUAE.

Any ideas on how to fix/troubleshoot?

Thanks!

[ahhyes]

If anyone wants to troubleshoot it:

here is a link to my hard disk image compressed with WinRAR - approx 2.5MB compressed, uncompresses to about 2GB.

http://ahhyes.net/ambsd.rar

It's installed in WinUAE as a IDE RDB image.

[Toni Wilen]

Works for me.

Make sure all "fake" devices are disabled (uaescsi, uaenet etc..), A2065 Z2 emulation should be enabled (if you want network)

[ahhyes]

Hi toni,

I've narrowed it down to network. if any network support is enabled then the qn0 device gets loaded by the netbsd kernel, then it hangs.

That includes A2065 Z2 - I had this enabled and I got past the hang once only, by some sheer act by god (only the le0 device got loaded on that occasion which doesn't cause any hang). On a subsequent reboot with the same settings (only A2065 Z2 enabled), it tried to load the "qn" (quicknet) device again after loading le0 and hung.

Any ideas?

[ahhyes]

sorry i edited my second post for clarity

[Toni Wilen]

I can't duplicate.

Make sure you have proper A4000 configuration (chipset panel chipset extra: A4000) Attach your winuaelog.txt if it still isn't working.

[ahhyes]

Hi Toni,

There seems to be problems with for me with A2065 Z2 (which netbsd detects as an le0: device) I experience timeouts as soon as the inetrface encounters some elevated levels of traffic. eg: When installing NetBSD and using FTP as the method to install the base operating system files, this is when the problems start:



This sort of behavior happens if interrupts are not being serviced quick enough or there are some other issues with the net adaptor (buffering issues).

Since A2065 Z2 isnt a workable option for me, I was hoping maybe the other networking options within WinUAE may be of help.

using uaenet.device/bsdsocket results in a hang during kernel init (when the "quicknet" (qn) device gets loaded)

Are you able to reproduce the issue of uaenet.device and bsd sockets not working?

[Toni Wilen]

uaenet or bsdsocket simply can't work, they are virtual Amiga device drivers that require working AmigaOS environment. (bsdsocket is library level, uaenet is device level, A2065 is hardware level)

"Alien" operating systems require supported hardware device and A2065 was chosen because it is the most supported Amiga NIC and hardware is quite simple.

A2065 is 100% confirmed working on Debian Linux, no timeouts. It is never tested on any other OS. (except AmigaOS of course)

Probable reason is feature that is either missing or emulated incorrectly that is only used by netbsd.

Check winuaelog.txt for possible warnings or errors.

Do you have separate physical NIC for emulation use? Windows and WinUAE sharing same physical NIC will cause issues, sooner or later.

[Toni Wilen]

A2065 bug found, near-brown paper bag quality again..

WinPCap transmit size limit was set to 1500 bytes internally. Normal ethernet frame max size is 1514 bytes (payload + headers), not 1500 (max payload only)

-> all big packets were silently dropped..

Debian MTU is also 1500 but for some reason it does work.. (and Amiga TCP/IP stacks by default probably use smaller dial-up friendly MTU)

Workaround: setting MTU to 1486 or smaller should fix it (but I only got "ifconfig: SIOCSIFMTU: Invalid argument" error)

Fix coming later..

[ahhyes]

Hi Toni,

That makes sense since the issue only crops up elevated levels of traffic hit the interface. So, you mean I should change the MTU from within NetBSD as a workaround for the time being?

Thank you for your help so far, greatly appreciated.

[Toni Wilen]

Originally Posted by ahhyes

o, you mean I should change the MTU from within NetBSD as a workaround for the time being?

It should work but either it is not supported or I did something wrong (ifconfig le0 mtu 1400 -> SIOCSIFMTU)

I also found some minor interrupt related problems that can also cause random timeouts in some situations but they will recover automatically.

[Toni Wilen]

Does http://www.winuae.net/files/b/winuae.zip fix A2065 emulation timeout issue?

At least my netbsd ftp freeze problems vanished. Started installer in update mode, pressed CTRL+Z, enabled interface (ifconfig le0 <ip> <mask> up) and then used plain included ftp command and ftp server in same LAN.

If you still have problems, use -a2065log (probably good idea to -log too) command line parameter to enable logging of source and destination mac addresses and frame size and type. (command is not supported in previous winuae versions)

[ahhyes]

Thanks Toni. I'll give it a go tonight after work.

Cheers.

[ahhyes]

No Go for me Toni, I also cant change the MTU from within NetBSD for that interface, same error as you.

Some logging info:

A2065<-DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065->DST:00.0E.0C.DA.27.A1 SRC:00.80.10.90.DC.D2 E=0800 S=66
A2065*>DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065<!DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065->DST:00.0E.0C.DA.27.A1 SRC:00.80.10.90.DC.D2 E=0800 S=66
A2065*>DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065<!DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065->DST:00.0E.0C.DA.27.A1 SRC:00.80.10.90.DC.D2 E=0800 S=66
A2065*>DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065<!DST:00.0E.0C.DA.27.A1 SRC:08.00.27.90.DC.D2 E=0800 S=66
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0E.0C.DA.27.A1 E=0800 S=1514
A2065: STOP.
A2065: INIT.
A2065: Initialization block:
.00.00.00.80.10.90.DC.D2.00.10.88.00.00.00.40.00.20.80.00.80.A0.80.00.40
A2065: 008000 0 16 4 008020 0080A0 00:80:10:90C2
uaenet_win32 thread 544 killed
uaenet_win32 closed

While normal ftp directory listing/logon was occuring, the framesizes were obviously smaller and there were no timeouts. once I started a transfer, it was trying larger frames and timing out

Also saw some of this when I alt-tabbed out of winuae:

A2065<-DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065: RECEIVE BUFFER ERROR
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065: RECEIVE BUFFER ERROR
A2065<!DST:00.0F.24.7E.51.93 SRC:08.00.27.90.DC.D2 E=0800 S=54
A2065: short frame 68148532 bytes
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=1434
A2065: RECEIVE BUFFER ERROR
A2065<!DST:00.0F.24.7E.51.93 SRC:08.00.27.90.DC.D2 E=0800 S=54
A2065: short frame 68148532 bytes
A2065<!DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=968
A2065<-DST:08.00.27.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=968
A2065<*DST:00.80.10.90.DC.D2 SRC:00.0F.24.7E.51.93 E=0800 S=968
A2065: RECEIVE BUFFER ERROR
A2065<!DST:00.0F.24.7E.51.93 SRC:08.00.27.90.DC.D2 E=0800 S=54
A2065: short frame 68148532 bytes

[Toni Wilen]

I think your problem is receiving of 1514 byte frames and I only fixed sending of 1501+ byte frames

How can I test ftp receiving easily using netbsd without installing it? Default filesystem is mounted read-only so I only tested sending..

Do you have pause emulation when minimized/not active setting set? Network receive/transmit thread is still running, receive buffer errors are normal in this situation (it means no space for received frame because no one is emptying buffers)

[ahhyes]

I have to run the install each time to reproduce the issue.

using the disk image in the thread:

Boot into the install, giving wd0b as the root partition, dump device as none.

During the install, when asked if you want to mount any additional filesystems, enter wd0d then hit enter, assign /usr as the mount point, you'll be also asked if you want to use wd0b as a swap, answer 'yes'. eventually new filesytems will be created.

you will get to the point where you will be asked how you would like to install the distribution sets, select 'f' for ftp.

use the following server: ftp.netbsd.org, login anonymous, server path: pub/NetBSD/NetBSD-5.0.2/amiga/binary/sets/

add base.tgz and select 'n' to stop adding distribution files. The ftp transfer will start. You should be able to observe the timeouts.

I have copied the distribution sets locally to an ftp server on my LAN, for speed reasons.

[ahhyes]

edit: If you need a better set of steps to get through the installer (the installer is not very user friendly at all) let me know and i will write something up for you.

[ahhyes]

Originally Posted by Toni Wilen

Do you have pause emulation when minimized/not active setting set? Network receive/transmit thread is still running, receive buffer errors are normal in this situation (it means no space for received frame because no one is emptying buffers)

I do have pause enabled. So that would explain it

[Toni Wilen]

"Works for me"

Installation seemed to work fine (but some extraction errors appeared in console, can't be A2065 emulation problem because upper networking layers should detect errors and retry automatically), also didn't notice any hangs or A2065 STOP/INIT/START re-initializations.

Log shows 1514 byte received frames.

40-085 [9704 113x450]: A2065->DST:00.1E.AB.00.6E.8C SRC:00.80.10.4D.5B.61 E=0800 S=66
40-085 [9704 113x450]: A2065*>DST:00.1E.AB.00.6E.8C SRC:00.24.8C.4D.5B.61 E=0800 S=66
40-108 [9705 113x450]: A2065<-DST:00.24.8C.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-108 [9705 113x450]: A2065<*DST:00.80.10.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-129 [9707 113x450]: A2065<-DST:00.24.8C.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-129 [9707 113x450]: A2065<*DST:00.80.10.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-131 [9707 113x450]: A2065<-DST:00.24.8C.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-131 [9707 113x450]: A2065<*DST:00.80.10.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-137 [9708 000x000]: A2065<-DST:00.24.8C.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-138 [9708 114x022]: A2065<*DST:00.80.10.4D.5B.61 SRC:00.1E.AB.00.6E.8C E=0800 S=1514
40-138 [9708 114x022]: A2065->DST:00.1E.AB.00.6E.8C SRC:00.80.10.4D.5B.61 E=0800 S=66
40-138 [9708 114x022]: A2065*>DST:00.1E.AB.00.6E.8C SRC:00.24.8C.4D.5B.61 E=0800 S=66

00.1E.AB.00.6E.8C is ADSL router LAN MAC (Didn't bother with installation file mirroring..)

@ahhyes:

Are you sure you have WinPCap (http://www.winpcap.org/install/default.htm ) properly installed ?

A2065 emulation requires that.