Alpha2 Trouble with AMD Sempron PC

[genki]

The system freezes a short time after boot. There is no KDL but doing a "ALT-Sysreq-D" and a "bt" command I get the following two errormessages:

​http://picasaweb.google.de/markerben/AMDSempronAlpha2Trouble#5467356932295151058

​http://picasaweb.google.de/markerben/AMDSempronAlpha2Trouble#5467356918104065570

system was running hrev36447 alpha2 gcc2hybrid

[bonefish]

The stack traces don't show any kind of error. This sounds like an app server deadlock. Please try a new revision and, if you can reproduce it again, provide the output of thread <id> with <id> replaced by the ID of the app server team (get it using the teams command). Possibly also interesting is the output of the running and ready commands (no parameters).

[axeld]

Also, the output of the "ints" KDL command would be helpful. If possible, attaching images is preferred over external services (it might take some time until a bug is being worked on).

[bonefish]

Sorry, I meant to write threads <id> (plural) -- to print the list of threads in the app server.

[bonefish]

OK, doesn't look like the app server deadlock I've seen before at least. All waiting threads seem to wait on different condition variables, probably belonging to their ports. Pretty normal behavior, I guess.

Axel, I suppose you had something in mind asking for the interrupts?

[axeld]

I had, but the output looks completely unsuspicious.

I guess booting in safe mode does not help either?

[axeld]

Also, have you tried turning off ACPI and similar things in the boot menu?

(you enter the boot menu by pressing space before the Haiku logo shows up; you may also keep the (left) shift key pressed to do that)

[genki]

It looks like if it helps to boot in safe mode. The system is now running for over seven minutes without freezing (new record!). And overall the system isn't so choppy anymore. GL-Teapot is now moving without any missing frames....

[axeld]

Okay, that's a start.

Can you then manually launch the media_server, and the net_server (in different sessions at first, both in /system/servers/), to see if that changes anything?

[genki]

Pictures five and six show a crash when the netserver was started manually. I will now try to start the mediaserver manually after rebooting into safe mode again. If I went into kdl again I will add new Photos immediately.

[axeld]

I see no crash, at least it says "keyboard requested halt" at the top - what do you mean by crash?

[genki]

Mouse can't be moved. GL-Teapot doesn't rotate anymore...

[axeld]

I would call that lock up or freeze. Anyway, so it looks like your network card is to blame for this (or rather, Haiku's driver for it). When you boot into safemode Haiku, can you get a syslog output, and attach it to this ticket? The file can be found under /var/log/syslog.

Also, the back trace of the network related threads would be interesting after having started the net_server. Finally, does a "unreal", and then "cont" in KDL let the system be usable again? What does "running" put out?

And thanks for all the debugging work you do! I hope we can nail down the issue.

[genki]

after the "cont" command the system doesn't get stable again. What do you mean with "back trace of the network related threads..."? I type "bt" and the id number of the networking server, right? I don't know which other threads are interesting for you. And how can i figure out their id? Sorry but I am only a dumb user with very little knowledge of the inner workings of the system. I hope I could help you with my new attached images otherwise feel free to give me some further instructions (that I can understand hopefully) to make some reasonable photos... :-) . I've got to go to bed now. See you, Mark.

[axeld]

A "threads | grep nf" should give you the threads I'm talking about (they all either have nforce or nfe in their names).

However, everything looks a bit strange; there are lots of ready threads, but as "unreal" didn't have any effect, this looks unrelated. Can you give the back trace of some of those ready threads, too? Eventually, they are in thread_yield() which would be interesting.

Also interesting is this app_server thread that waits on a mutex. The app_server threads are those that start with d:, a:, or w:. If you see a such a thread that says "mutex 0x......", its stack trace as well as the mutex output by "mutex 0x....." would be interesting, too.

I hope that gives us a better idea.

[genki]

added some new shots. Something that is still missing is a shot of the app_server threads. Axel you said they start with "d","a" or "w". Please tell me what I have to type when I am in Kernel Debug Land to figure out the IDs of those threads. When I have the missing IDs I then have to type "BT <ID-Number>" .. is this correct? I hope the new shots will help a little bit anyway. I will add new shots as soon as you give me the instructions.

Thanks, Mark aka Genki

[bonefish]

Replying to genki:

Please tell me what I have to type when I am in Kernel Debug Land to figure out the IDs of those threads.

You already did all that's needed to get the IDs. Confer attachment:4.JPG​. Though in that case none of the app server threads waits on a mutex.

When I have the missing IDs I then have to type "BT <ID-Number>" .. is this correct?

Yes.

[scottmc]

any changes on this one? Can you recheck it with a recent nightly? Let us know the results.

[scottmc]

moving to hrev1/beta1

[genki]

The problem still exists. I tried R41280 and the system freezes after the Live CD vs. Install prompt shows up. Take a look at the new attachments and please don't hesitate to give me further instructions what to type in kdl...

Sorry for the delay of my response, maybe you can change this ticket back to alpha3 Milestone?

[kvdman]

why don't you boot into safe mode, delete/move the nforce network driver, and boot normally, see if the problem persists.

[genki]

ok: without the network driver the system runs stable! And now?

[kvdman]

Well, I guess it confirms the network driver is the problem, and allows you to have a stable system (albeit without networking).

[anevilyak]

Could you please try this again with hrev41527 or later? (while leaving the network driver in place)

[genki]

Thank you guys! You can close this ticket. The system (including the network) runs without any problems. I tried R41539 gcc2 hybrid (with leaving the network driver in place).

[anevilyak]

Interrupt routing issue then, thanks for verifying!