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.

[Toni Wilen]

WinPcap is installed (not necessarily 100% working) because at least some packets arrive.

[Mad-Matt]

I dont know if the oddaty i noticed is same thing but here goes .. If i use tcp by amiga, I make use of uaenet.device. Ive noticed recently and im sure it hasnt always been like this as ive setup feature since it was first implmented - that recieving is real slow borderline anciant modem speed.

problem is i dont know if its amitcp fault or winuae or winpcap or windows thats the issue ! quite possable that a windows update broke it all.

I do like to make use of this feature to quickly (well used to be) transfer files between Real Amiga and Winuae via NetFS.

[ahhyes]

Originally Posted by luca_m96

@ahhyes:

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

A2065 emulation requires that.

it is installed, the latest version I have tested Winuae in a virtualbox session, Under Wine (Linux) and also booted into a natively running Windows install, I have the same problem under all 3.

[ahhyes]

Originally Posted by 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.

Did you try installing distribution sets via FTP? Surely I cant be the only one with the issue. The MTU of le0 is 1500. 1514 is going to cause fragmentation which is where I believe the issue may be.

If anyone else is reading this, and has the time to help out, would you mind downloading the compressed hard disk image and seeing if you can reproduce the issue also?

The install instructions are here:

ftp://ftp.netbsd.org/pub/NetBSD/NetB...kernel%20boots

Hard disk image is here:

http://ahhyes.net/ambsd.rar

Toni, I am forced to use FTP to install the distribution sets because I have no way to make netbsd see a CD-ROM drive or fake CD-ROM drive with an ISO image, otherwise I'd be installing the distribution sets that way, the install notes state:

To install NetBSD from a CD-ROM drive, make sure it is a SCSI CD-ROM on a SCSI bus currently supported by NetBSD (refer to the supported hardware list) or an ATAPI CD-ROM connected to the A1200 or A4000 internal IDE connector. If it is a SCSI CD-ROM on a non-supported SCSI bus like Blizzard-3 SCSI or Apollo SCSI you must first copy the distribution sets to an AmigaDOS partition as described above.

but even if I could do this and get the OS fully installed, I'd still have the network interface issue as soon as elevated levels of traffic hit. There isn't much else I can try, but I am more than happy to help with testing any fixes/suggestions people may have.

[Toni Wilen]

Originally Posted by ahhyes

Did you try installing distribution sets via FTP?

Yeah, it did work (minus some checksum errors when unpacking)

The MTU of le0 is 1500. 1514 is going to cause fragmentation which is where I believe the issue may be.

1500 and 1514 are the same thing. 1500 is max payload MTU, 1514 is payload + ethernet headers included. 1500 means, I can send max 1500 bytes of user data, you don't need to know that internally I also need 14 extra bytes

(I did the same mistake when I mistook 1500 for full ethernet mtu..)

[ahhyes]

Originally Posted by Toni Wilen

Yeah, it did work (minus some checksum errors when unpacking)

That suggests a corrupted download. Error correction in TCP is meant to prevent this. So you're suggesting there is still a problem?

What do you suggest I do? (besides give up)

[Toni Wilen]

Checksum error stuff is not important now

Do you have FTP server and WinUAE running on same physical PC? (even if you use two NICs) This can cause issues if NIC have hardware checksum offloading capabilities. (IPv4 Checksum OffLoad or Large Send Offload)

FTP server sends something, OS TCP/IP stack creates IPv4 packet without setting checksum field because it expects NIC to fix it (TCP/IP checksum offloading) but because winpcap gets the data before it reaches the physical NIC, WinUAE gets IPv4 packet with incorrect checksum, emulated OS drops it..

[ahhyes]

Originally Posted by Toni Wilen

Checksum error stuff is not important now

Do you have FTP server and WinUAE running on same physical PC? (even if you use two NICs) This can cause issues if NIC have hardware checksum offloading capabilities. (IPv4 Checksum OffLoad or Large Send Offload)

The FTP server is running on another machine within my LAN (linux server).

I do have WinUAE setup within VirtualBox on linux, so there is a Virtual Ethernet that Windows is using provided by VirtualBox and also the physical NIC on the machine. To rule this arrangement out as being an issue, I did test by rebooting natively into windows and running WinUAE, I still had the same issue.

[ahhyes]

Did some reading up on this network interface:

http://netbsd.gw.com/cgi-bin/man-cgi?le++NetBSD-5.0

Nothing on what the "timeout" message means in the diagnostics...

[Toni Wilen]

Timeout is probably non-driver specific kernel check.

Most likely would be transmit done interrupt not arriving. I'll check the sources but it may not help much if it is generic "shouldn't happen, buggy driver or hardware" debug message.

[ahhyes]

Originally Posted by Toni Wilen

Timeout is probably non-driver specific kernel check.

Most likely would be transmit done interrupt not arriving. I'll check the sources but it may not help much if it is generic "shouldn't happen, buggy driver or hardware" debug message.

whatever change you made in the beta (test) version you got me to download, you are on the right track. With the current public download, if i try to send a file via ftp, it hangs after 64KB. The beta version you gave me allows the file to send (slowly, with timeouts, but it at least finishes)

[ahhyes]

Out of desperation, I created a new IDe hard disk in winuae, formatted it in workbench, copied all the distfiles from the netbsd cd over. netbsd is able to mount the amiga filesystem. I seem to have no luck as it reports that numerous archives are damaged. I have checked the md5sums of my files on the ftp server and they are correct, archives also check out ok.

as a test, i verified the etc.tgz file on my ftp server. downloaded it via ftp in netbsd (took nearly 5 mins to get a 380KB file!), archive is corrupt when i try a "tar tzf" to list the contents. I ftp'd the file back to the server and ran md5sum on it, the md5sum had changed..

I am totally stumped. There must be some memory corruption or something totally bizarre going on.

The problem could very well be netbsd itself and not WinUAE, or it could be a combination of bugs on both sides. I am really stumped. Need more people to test and see what they can come up with.

From what I can tell, ftp in both directions (with the beta version) is working, but *extremely* slowly. probably caused by the timeouts and device resetting itself after every few KB it transfers. I suspect there is also some data corruption going on with this issue at the same time, making it impossible to install the distribution sets over ftp or via a mounted amigados partition.

if netbsd has been confirmed as working, I'd really like to speak to whoever it was that got it working, I'm certainly not having as much luck as they did

[Toni Wilen]

I can't find anything wrong with A2065 emulation (anymore), perhaps problem is somewhere else (lost interrupts?), also random screen jitter probably shouldn't happen..

Perhaps 4.x NetBSD works better? (It was used for MMU compatibility testing)

[ahhyes]

Originally Posted by Toni Wilen

I can't find anything wrong with A2065 emulation (anymore), perhaps problem is somewhere else (lost interrupts?), also random screen jitter probably shouldn't happen..

Perhaps 4.x NetBSD works better? (It was used for MMU compatibility testing)

I can try NetBSD 4, I'll let you know how it goes. I did notice the screen jittering as well.

I'd really hoped NetBSD 5 would work. Perhaps I should wake up the netbsd devs and challenge them to get NetBSD 5 to work on WinUAE and see what they come up with. I cant imagine that the amiga port of netbsd gets a lot of testing..

edit: I've subscribed to their mailing list. wish me luck :P

[prowler]

Originally Posted by ahhyes

I'd really hoped NetBSD 5 would work. Perhaps I should wake up the netbsd devs and challenge them to get NetBSD 5 to work on WinUAE and see what they come up with. I cant imagine that the amiga port of netbsd gets a lot of testing..

edit: I've subscribed to their mailing list. wish me luck :P

Good thinking.

In trying to get the developers to accept your challenge to use WinUAE to troubleshoot NetBSD 5, be sure to make them aware of this thread. There is a good chance that the ability to write clear bug reports you have demonstrated will help persuade them it will be worthwhile.

Oh, and good luck of course!

[Toni Wilen]

Problem can't be too serious (and worth debugging) if version 4 is first confirmed working.

[ahhyes]

Originally Posted by Toni Wilen

Problem can't be too serious (and worth debugging) if version 4 is first confirmed working.

No go with NetBSD 4.0.1, same issues with le0: timeouts

Here is my config:

http://ahhyes.net/alex3.uae



edit: Also had no luck raising the netbsd devs, tried to subscribe to their mailing list but it requires manual approval before you can post, heard nothing back yet.

[ahhyes]

Toni,

http://netbsd.gw.com/cgi-bin/man-cgi...NetBSD-current

The qn interface provides access to the 10 Mb/s Ethernet network via the Fujitsu MB86950 Ethernet chip set. Each of the host's network addresses is specified at boot time with an SIOCSIFADDR .

The qn interface supports the following Zorro II expansion cards:
QuickNet: Resource Management Force's Ethernet card, manufacturer 2011, product 2

The "qn" interface (under certain conditions) gets detected sometimes (like in first screenshot) and it locks up winuae, this usually gets detected if bsdsocket.lib/uaenet.dev are turned on, however several times I have witnessed "qn" getting ldetected by netbsd despite only A2065 support being enabled.

Could you check that whatever bus ID/product is making bsd detect the qn device gets physically disconnected from the bus if only A2065 support is enabled. I think that may be a good starting point in getting netbsd to play nice. Only the "le" interface should be getting detected since the A2065 is based on the AMD chipset, not fujitsu.

I think I am going to give up. I have spent days and days and days on this. if anyone else would like to give it ago, everything you need is in this thread.

[Toni Wilen]

2011/2 is same as "fake" UAE filesystem autoconfig device. (2011 = non-assigned autoconfig manufacturer for test devices etc.. which is bad idea for "real" products)

Amiga Linux seems to have extra checks to confirm the device type but NetBSD only checks manufacturer/product ids.

Workaround: disable all UAE controller harddrives. (they aren't usable in non-AmigaOS environments anyway)

[Toni Wilen]

Uhmm.. Timeout really was a bug in A2065 emulation after all..

I forgot that transmit happens in separate thread and if transmit interrupt is set when main thread is reading or writing NIC chip registers: interrupt bit may not get set.. (main thread copied interrupt register to temp variable, did some operations with it and put it back to original variable)

Should be really really fixed now.. (multithreading bugs + modern multicore CPUs = fun, different logging options = really random behavior)

Same url, make sure date says 9.10.2010 (or newer)