Hi there,
Recently I've experienced problems with roadshow on my Pegasos II using the Marvell Discovery II (gigabit)ethernet... it works well but I'm having random system lock ups...it happens while browsing the web with OWB and even accessing my PC in my LAN with VNC...however netstack works just perfect, I don't have such behavior with it... I even installed MorphOS 3.1 from scratch in a different partition and then installed roadshow.. same hting... so it doesn't seem to be anything causing conflicts -software wise- with it nor hardware issue but a problem in roadshow itself (probably with Gbps NICS?)...
Does anyone have such a setup who can confirm the issue?
Thank you,
Dragster
Navigation
«
«
«
Amiga Future
«
Community
«
Knowledge
«
Last Magazine
«
Service
«
Search
«
Social Media
«
Advertisement
«
Partnerlinks
MorphOS freezes with roadshow and Marvel II ethernet on Peg2
Support Roadshow
First thing, thank you for looking into the matter and digging up some supporting evidence as to what's wrong!Dragster wrote:OK, I was able to reproduce the problem in another Pegasos II, so it's not hardware... As stated before, the problem does not happen with netstack... it's gotta be something in roadshow..
Olsen, any comments?
I'm puzzled as to what's going on. Roadshow in its current form has been in use on AmigaOS4 for quite a while now, and I would have expected that major issues such as the one you reported should have appeared and would have been fixed earlier.
Clearly, something is not right. First the stability problems reported for the X-Surf, and now for the Marvell Discovery II NIC. I don't have any explanation for the behaviour yet, and I'm still not sure how to get a grip on the problem.
From what you write, it might be the NIC's driver which crashes during I/O operations. This is not to say that the driver is at fault, it's just that whatever happens during the Roadshow<->driver interaction may be the problem. If the system just locks up, it could be that the driver hangs during interrupt processing. If the system does not lock up, did you see any signs that memory contents may have been corrupted, e.g. programs or file systems crashing?
While Roadshow still runs smoothly, could you check what "ShowNetInterface interface <insert>" says? I would be interested in the statistics information printed, particularly if and how many times DMA was used.
Hi Olsen, thanks for your reply!
Cheers,
Dragster
You're welcomeolsen wrote:
First thing, thank you for looking into the matter and digging up some supporting evidence as to what's wrong!
Yes, but.. in the case of the Pegasos II there's no OS4 driver for the Marvell Discovery II, they only support the via_rhine NIC which roadshow handles well in MorphOS. Though roadshow and the MorphOS network screenbar both report this NIC connects at 10mbps, when in fact it connects at 100 mbps as I've ftp'ed some files within my LAN at nearly 8 megabytes / second. I guess roadshow queries the driver itself for the connection speed and both the via_rhine and the marvell discovery II report wrong values.olsen wrote: I'm puzzled as to what's going on. Roadshow in its current form has been in use on AmigaOS4 for quite a while now, and I would have expected that major issues such as the one you reported should have appeared and would have been fixed earlier.
That's perfectly understandable...Clearly, something is not right. First the stability problems reported for the X-Surf, and now for the Marvell Discovery II NIC. I don't have any explanation for the behaviour yet, and I'm still not sure how to get a grip on the problem.
Yes, perhaps roadshow needs some sort of workaround as it was made with the MorphOSs' drivers initialization problem reported by me some time ago...From what you write, it might be the NIC's driver which crashes during I/O operations. This is not to say that the driver is at fault, it's just that whatever happens during the Roadshow<->driver interaction may be the problem.
No, I haven't noticed any signs of memory corruption.If the system just locks up, it could be that the driver hangs during interrupt processing. If the system does not lock up, did you see any signs that memory contents may have been corrupted, e.g. programs or file systems crashing?
Sure, I'll post the output of the command in a moment...While Roadshow still runs smoothly, could you check what "ShowNetInterface interface <insert>" says? I would be interested in the statistics information printed, particularly if and how many times DMA was used.
Cheers,
Dragster
Here it is:
BTW, the comment is shownetstatus <nic_name> right?
2.MorphOS 3.1:C> shownetstatus discovery-ii
Interface "discovery-ii"
Device name = mv6436x_eth.device
Device unit number = 0
Hardware address = XX:XX:XX:XX:XX:XX
Maximum transmission unit = 1500 Bytes
Transmission speed = 100000000 Bits/Second
Hardware type = Ethernet
Packets sent = 1522
Packets received = 4252
Packets dropped = 0 (in = 0, out = 0)
Buffer overruns = 0
Unknown packets = 0
Address = 192.168.1.83
Network mask = 255.255.255.0
Number of read I/O requests = 1030 (maximum of 24 used at a time, 516 are still pending)
Number of write I/O requests = 512 (maximum of 15 used at a time, 0 are still pending)
Number of bytes received = 5,263,105
Number of bytes sent = 233,444
Transfer statistics (in/out) = DMA:0/0 Byte:4252/1522 Word:-/0
Address binding = Dynamic
Address lease expires = 03/31/2013 10:08 am
Link status = Up
Notice the connection speed (100 mbps)... thisis suposed to be a Gbps NIC.
Thank you,
Dragster
BTW, the comment is shownetstatus <nic_name> right?
2.MorphOS 3.1:C> shownetstatus discovery-ii
Interface "discovery-ii"
Device name = mv6436x_eth.device
Device unit number = 0
Hardware address = XX:XX:XX:XX:XX:XX
Maximum transmission unit = 1500 Bytes
Transmission speed = 100000000 Bits/Second
Hardware type = Ethernet
Packets sent = 1522
Packets received = 4252
Packets dropped = 0 (in = 0, out = 0)
Buffer overruns = 0
Unknown packets = 0
Address = 192.168.1.83
Network mask = 255.255.255.0
Number of read I/O requests = 1030 (maximum of 24 used at a time, 516 are still pending)
Number of write I/O requests = 512 (maximum of 15 used at a time, 0 are still pending)
Number of bytes received = 5,263,105
Number of bytes sent = 233,444
Transfer statistics (in/out) = DMA:0/0 Byte:4252/1522 Word:-/0
Address binding = Dynamic
Address lease expires = 03/31/2013 10:08 am
Link status = Up
Notice the connection speed (100 mbps)... thisis suposed to be a Gbps NIC.
Thank you,
Dragster
Yes (me and my bad memory...).Dragster wrote:Here it is:
BTW, the comment is shownetstatus <nic_name> right?
Thank you, this is the portion I wanted to be sure about. The data is not being moved through the DMA transport method, which eliminates one possible error cause.Transfer statistics (in/out) = DMA:0/0 Byte:4252/1522 Word:-/0
I noticed that the number of I/O requests reserved for read/write operations is very high (1030 for reading, 512 for writing). Does stability of the system change in any way if you reduce both numbers?
Yes, but this is exactly what the driver reports when askedNotice the connection speed (100 mbps)... thisis suposed to be a Gbps NIC.
Thanks for your answer Olsen...how can I change that?
I noticed that the number of I/O requests reserved for read/write operations is very high (1030 for reading, 512 for writing). Does stability of the system change in any way if you reduce both numbers?
I can't find any parameter with those names or those values using roadshowcontrol...
2.Downloads:T2/MorphOS> roadshowcontrol
bpf.bufsize = 4096
icmp.maskrepl = 0
icmp.processecho = 0
icmp.procesststamp = 0
ip.defttl = 64
ip.forwarding = 0
ip.sendredirects = 1
ip.subnetsarelocal = 0
tcp.do_rfc1323 = 1
tcp.do_timestamps = 1
tcp.do_win_scale = 1
tcp.mssdflt = 1500
tcp.recvspace = 65536
tcp.rttdflt = 3
tcp.sendspace = 65536
tcp.use_mssdflt_for_remote = 0
udp.cksum = 1
udp.recvspace = 41600
udp.sendspace = 9216
task.controller.priority = 0
Thanks,
Dragster
These parameters are set as part of the network interface configuration. You can either set them through the tool types of the repective configuration file icon, or you may edit the configuration file itself.Dragster wrote:Thanks for your answer Olsen...how can I change that?
I noticed that the number of I/O requests reserved for read/write operations is very high (1030 for reading, 512 for writing). Does stability of the system change in any way if you reduce both numbers?
I can't find any parameter with those names or those values using roadshowcontrol...
Here is how the relevant section (of "DEVS:NetInterfaces/Discovery-II") could look like:
Code: Select all
# You can choose how much memory will be used when handling
# incoming and outgoing network traffic for this device.
# The default is to reserve 32 buffers of 1500 byte each, both
# inbound and outbound traffic. Larger values may provide
# better performance.
#iprequests=32
#writerequests=32
The number of I/O requests available determines the limits for data throughput, and you should choose the numbers according to what ShowNetStatus tells you:
Code: Select all
Number of read I/O requests = 1030 (maximum of 24 used at a time, 516 are still pending)
Number of write I/O requests = 512 (maximum of 15 used at a time, 0 are still pending)
Roadshow eventually uses all available I/O requests over time as it cycles through them. You'd want to have at least as many requests ready as there is traffic using them. I'd recommend to check how the high water mark for requests in use is and then reserve at least double that number.
I don't know how long you could use your system before strange things happened :-/ But if the 24 read requests were what Roadshow would use during a long session, 48 or more would be a good setting for the "iprequests" line.
Higher numbers do not necessarily translate into higher transmission speeds, though.
The defaults (32 requests for input and output) work well for 10 MBit/s Ethernet, and should be higher for 100 MBit/s Ethernet. I have no idea how they should look like for 1 GBit/s Ethernet. Your CPU load will probably limit throughput before you get much higher than 200 MBit/s.
I am wondering if lower numbers are going to have an effect on your system. In the case of the X-Surf crashes, this was not the case, so I am suspecting something else might be at work here.
Can you run a memory test on your system? Is your system generally very stable or do you have other stability issues as well?
Post Reply
8 posts
• Page 1 of 1
Jump to
- Amiga Future
- ↳ Internes
- ↳ Termine
- Computer
- ↳ Amiga und Kompatible Allgemein
- ↳ Amiga und Kompatible Spiele
- ↳ Amiga und Kompatible Hardware
- ↳ Amiga Programmieren
- ↳ Amiga Emulation
- ↳ Amiga General Chat english
- ↳ Andere Systeme
- Sonstiges
- ↳ Kleinanzeigen - Classifieds
- ↳ OffTopic
- APC&TCP
- ↳ APC&TCP-News
- ↳ APC&TCP-Support
- ↳ CygnusEd Support
- ↳ DigiBooster Support
- ↳ Roadshow Support