Navigation
« 

Anonymous




Register
Login
« 
« 

Amiga Future

« 

Community

« 

Knowledge

« 

Last Magazine

The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
More informations

« 

Service

« 

Search




Advanced search

Unanswered topics
Active topics
« 

Social Media

Twitter Amigafuture Facebook Amigafuture RSS-Feed [german] Amigafuture RSS-Feed [english] Instagram YouTube Patreon
« 

Advertisement

Amazon

Patreon

« 

Partnerlinks

MorphOS freezes with roadshow and Marvel II ethernet on Peg2

Support Roadshow

Moderators: AndreasM, olsen

Post Reply
Dragster
Newbie
Newbie
Posts: 5
Joined: 14.03.2013 - 18:39
Location: Mexico City

MorphOS freezes with roadshow and Marvel II ethernet on Peg2

Post by Dragster »

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
Dragster
Newbie
Newbie
Posts: 5
Joined: 14.03.2013 - 18:39
Location: Mexico City

Post by Dragster »

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? :-?

Thank you,

Dragster
olsen
CygnusEd Developer
Posts: 167
Joined: 06.06.2006 - 16:27

Post by olsen »

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? :-?
First thing, thank you for looking into the matter and digging up some supporting evidence as to what's wrong!

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.
Dragster
Newbie
Newbie
Posts: 5
Joined: 14.03.2013 - 18:39
Location: Mexico City

Post by Dragster »

Hi Olsen, thanks for your reply!
olsen wrote:
First thing, thank you for looking into the matter and digging up some supporting evidence as to what's wrong!
You're welcome :)
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.
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.
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.
That's perfectly understandable...
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.
Yes, perhaps roadshow needs some sort of workaround as it was made with the MorphOSs' drivers initialization problem reported by me some time ago...
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?
No, I haven't noticed any signs of memory corruption.
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.
Sure, I'll post the output of the command in a moment...

Cheers,

Dragster
Dragster
Newbie
Newbie
Posts: 5
Joined: 14.03.2013 - 18:39
Location: Mexico City

Post by 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
olsen
CygnusEd Developer
Posts: 167
Joined: 06.06.2006 - 16:27

Post by olsen »

Dragster wrote:Here it is:

BTW, the comment is shownetstatus <nic_name> right?
Yes (me and my bad memory...).
Transfer statistics (in/out) = DMA:0/0 Byte:4252/1522 Word:-/0
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.

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?
Notice the connection speed (100 mbps)... thisis suposed to be a Gbps NIC.
Yes, but this is exactly what the driver reports when asked :-)
Dragster
Newbie
Newbie
Posts: 5
Joined: 14.03.2013 - 18:39
Location: Mexico City

Post by Dragster »



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?
Thanks for your answer Olsen...how can I change that?

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
olsen
CygnusEd Developer
Posts: 167
Joined: 06.06.2006 - 16:27

Post by olsen »

Dragster wrote:


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?
Thanks for your answer Olsen...how can I change that?

I can't find any parameter with those names or those values using roadshowcontrol...
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.

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
Note that this is the default setup, i.e. if you did not override the "iprequests" or "writerequests" entries (which are commented out above), then you will get 32 each.

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) 
In this example it appears that incoming traffic kept up to 24 requests busy at a time, and the remaining 1006 never saw much use. Outgoing traffic kept up to 15 requests busy at a time, and the remaining 497 didn't contribute much either ;-)

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