WinUAE 2.3.0 + NetBSD 5.0.2 No go.

[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)