Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#9139 closed bug (duplicate)

net_server always crashes booting the A4 ISO loading the ipro1000 driver

Reported by: Stephan Aßmus Owned by: Nobody
Priority: normal Milestone: R1
Component: Drivers/Network/ipro1000 Version: R1/alpha4
Keywords: Cc:
Blocked By: #8684 Blocking:
Has a Patch: no Platform: All


Hardware is a Lenovo T60. I've burned the ISO image in Ubuntu, and let the validation after burning run. On the same laptop, I run a pretty outdated revision of Haiku with no problems.

Booting the alpha4 ISO, two out of two times, the net_server crashed. I took a picture of the KDL output. From the stack trace, it looks as though net_server configures initial devices (NetServer::_ConfigureDevices()) which eventually opens the ipro1000 driver. During driver setup, it tries to figure out the MSI count (pci_msi_count()) which enters the PCI bus manager and crashes in FindDevice(). Sounds a bit as though the code that would add a device re-enters itself and FindDevice() crashes since the device that was going to be added in the first place is looking itself up in some list. But that is just gut feeling from looking at the stack crawl only, not actually at the code.

Attachments (3)

IMAG0181.jpg (1.9 MB) - added by Stephan Aßmus 5 years ago.
Picture of the KDL output after the crash
kdl.png (320.4 KB) - added by jackburton 5 years ago.
SYSLOG00.TXT (85.5 KB) - added by diver 5 years ago.
debug syslog

Change History (15)

Changed 5 years ago by Stephan Aßmus

Attachment: IMAG0181.jpg added

Picture of the KDL output after the crash

comment:1 Changed 5 years ago by diver

I think this is because of a new ACPI version which has been committed to A4 branch in hrevr1alpha4-44682. confirmed to work ok.

comment:2 Changed 5 years ago by Fredrik Holmqvist

I'm sorry, but please don't always blame ACPI. It seems to always be the scapegoat until investigation show the reason. I think there are a lot more plausible explanations.

comment:3 Changed 5 years ago by diver

Disabling local apic workarounds the problem.

comment:4 in reply to:  1 Changed 5 years ago by Stephan Aßmus

Hm, I thought I did test the release candidate. I tested the download from the link that Matt sent me. I didn't see any commits to the alpha branch in this regard. (?)

comment:5 Changed 5 years ago by Rene Gollent

Possibly related to #9128 ?

comment:6 in reply to:  5 Changed 5 years ago by Stephan Aßmus

Replying to anevilyak:

Possibly related to #9128 ?

I wouldn't see how. Here is crashes before app_server even loads. It's not a hang and crashes to KDL with the same sc everytime.

comment:7 Changed 5 years ago by jackburton

Happens under XenServer too, with the A4 ISO. XenServer emulates a RealTek rtl8139 (a revision/model supported by our rtl81xx driver).

Changed 5 years ago by jackburton

Attachment: kdl.png added

comment:8 Changed 5 years ago by luroh

Yep, seeing the same on my marvell_yukon machine and the A4 iso.

comment:9 Changed 5 years ago by Urias McCullough

Unfortunately, I'm also seeing it with my RTL8111/8168B NIC here. I tried both ISO and Anyboot images burned to CD, with the same result.

Going to build my own image to double-check and test a few other things to see if I can narrow down a cause.

Changed 5 years ago by diver

Attachment: SYSLOG00.TXT added

debug syslog

comment:10 Changed 5 years ago by Michael Lotz

Blocked By: 8684 added
Resolution: duplicate
Status: newclosed

This is really the same as #8684 which has an explanation for why it's happening. So noone actually tested a CD boot before the release?

comment:11 Changed 5 years ago by diver

That's weird, because one user tested haiku-hrevr1alpha4-44678-releasecandidate-cd.tar.xz and it didn't crash.

comment:12 Changed 5 years ago by Stephan Aßmus

Maybe there is a driver that's used when booting from CD which releases the PCI device manager handle one time too many? And this driver is only used on some systems when booting from CD? Like SATA versus ATA?

Note: See TracTickets for help on using tickets.