Opened 9 years ago

Closed 8 years ago

#5902 closed bug (fixed)

Alpha2 Trouble with AMD Sempron PC

Reported by: genki Owned by: mmlr
Priority: normal Milestone:
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (22)

0.jpg (203.5 KB ) - added by genki 9 years ago.
1.jpg (249.1 KB ) - added by genki 9 years ago.
2.jpg (258.8 KB ) - added by genki 9 years ago.
3.jpg (265.5 KB ) - added by genki 9 years ago.
4.JPG (157.4 KB ) - added by genki 9 years ago.
5.jpg (418.5 KB ) - added by genki 9 years ago.
6.jpg (273.8 KB ) - added by genki 9 years ago.
syslog (421.6 KB ) - added by genki 9 years ago.
DSCF1497.JPG (182.3 KB ) - added by genki 9 years ago.
DSCF1498.JPG (468.7 KB ) - added by genki 9 years ago.
DSCF1499.JPG (405.7 KB ) - added by genki 9 years ago.
DSCF1500.JPG (94.2 KB ) - added by genki 9 years ago.
DSCF1501.JPG (215.0 KB ) - added by genki 9 years ago.
DSCF1502.JPG (76.7 KB ) - added by genki 9 years ago.
DSCF1503.JPG (237.1 KB ) - added by genki 9 years ago.
DSCF1504.JPG (181.0 KB ) - added by genki 9 years ago.
DSCF1505.JPG (186.2 KB ) - added by genki 9 years ago.
DSCF1506.JPG (190.8 KB ) - added by genki 9 years ago.
DSCF1875.JPG (480.7 KB ) - added by genki 8 years ago.
DSCF1876.JPG (130.2 KB ) - added by genki 8 years ago.
DSCF1877.JPG (858.3 KB ) - added by genki 8 years ago.
DSCF1878.JPG (469.5 KB ) - added by genki 8 years ago.

Change History (48)

comment:1 by bonefish, 9 years ago

Component: - GeneralServers/app_server
Milestone: R1R1/alpha2
Owner: changed from nobody to axeld
Version: R1/alpha1R1/Development

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

comment:2 by axeld, 9 years ago

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

by genki, 9 years ago

Attachment: 0.jpg added

by genki, 9 years ago

Attachment: 1.jpg added

by genki, 9 years ago

Attachment: 2.jpg added

by genki, 9 years ago

Attachment: 3.jpg added

comment:3 by bonefish, 9 years ago

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

by genki, 9 years ago

Attachment: 4.JPG added

comment:4 by bonefish, 9 years ago

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?

comment:5 by axeld, 9 years ago

I had, but the output looks completely unsuspicious.

I guess booting in safe mode does not help either?

comment:6 by axeld, 9 years ago

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)

comment:7 by genki, 9 years ago

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....

comment:8 by axeld, 9 years ago

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?

by genki, 9 years ago

Attachment: 5.jpg added

by genki, 9 years ago

Attachment: 6.jpg added

comment:9 by genki, 9 years ago

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.

comment:10 by axeld, 9 years ago

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

comment:11 by genki, 9 years ago

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

comment:12 by axeld, 9 years ago

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.

by genki, 9 years ago

Attachment: syslog added

by genki, 9 years ago

Attachment: DSCF1497.JPG added

by genki, 9 years ago

Attachment: DSCF1498.JPG added

by genki, 9 years ago

Attachment: DSCF1499.JPG added

by genki, 9 years ago

Attachment: DSCF1500.JPG added

by genki, 9 years ago

Attachment: DSCF1501.JPG added

comment:13 by genki, 9 years ago

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.

comment:14 by axeld, 9 years ago

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.

by genki, 9 years ago

Attachment: DSCF1502.JPG added

by genki, 9 years ago

Attachment: DSCF1503.JPG added

by genki, 9 years ago

Attachment: DSCF1504.JPG added

by genki, 9 years ago

Attachment: DSCF1505.JPG added

by genki, 9 years ago

Attachment: DSCF1506.JPG added

comment:15 by genki, 9 years ago

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

in reply to:  15 comment:16 by bonefish, 9 years ago

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.

comment:17 by scottmc, 8 years ago

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

comment:18 by scottmc, 8 years ago

Milestone: R1/alpha3

moving to hrev1/beta1

by genki, 8 years ago

Attachment: DSCF1875.JPG added

by genki, 8 years ago

Attachment: DSCF1876.JPG added

by genki, 8 years ago

Attachment: DSCF1877.JPG added

by genki, 8 years ago

Attachment: DSCF1878.JPG added

comment:19 by genki, 8 years ago

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?

comment:20 by kvdman, 8 years ago

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

comment:21 by genki, 8 years ago

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

comment:22 by kvdman, 8 years ago

Well, I guess it confirms the network driver is the problem, and allows you to have a stable system (since everything but networking is working).

Last edited 8 years ago by kvdman (previous) (diff)

comment:23 by anevilyak, 8 years ago

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

Last edited 8 years ago by anevilyak (previous) (diff)

comment:24 by genki, 8 years ago

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

comment:25 by anevilyak, 8 years ago

Component: Servers/app_serverSystem/Kernel
Owner: changed from axeld to mmlr
Status: newassigned

comment:26 by anevilyak, 8 years ago

Resolution: fixed
Status: assignedclosed

Interrupt routing issue then, thanks for verifying!

Note: See TracTickets for help on using tickets.