#3802 closed bug (not reproducible)
KDL at boot (buffer underrun message in serial output)
| Reported by: | stpere | Owned by: | mmlr |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Drivers/Disk | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
I'm running (or rather trying to run :) hrev30316 on real hardware. I get a KDL at boot at the fourth icon, and I get a PANIC message saying that it didn't find any boot partition.
I'm using the new ATA bus_manager, because the legacy one didn't work on my hardware when I first tried a few days ago.
It was working a few revisions ago (I could binary search if needed) on the same hardware, with the ATA bus_manager.
I wired myself a NULL modem to get serial output, I attached the result.
I spotted "buffer underrun" messages which seems significant. There seems to be something wrong with DMA in that situation, but I won't try to diagnosis any further :)
Attachments (2)
Change History (12)
comment:1 by , 16 years ago
| Component: | - General → Drivers/Disk |
|---|---|
| Owner: | changed from to |
by , 16 years ago
| Attachment: | serial output added |
|---|
follow-up: 3 comment:2 by , 16 years ago
| Status: | new → assigned |
|---|
comment:3 by , 16 years ago
Replying to mmlr:
It seems that the output is a bit garbled, is it possible that you are running this on a SMP machine? The text is cut at some places and intermixed with different text at others.
I take that back, after reloading the attachment it looks all fine now - strange, sorry for the noise.
comment:4 by , 16 years ago
Sorry for the garbled output file, my serial port was set to read 115200 7N1, it was wrong, of course. DeadYak noticed it was clipped and I did a new one and did hope to update it before you noticed, but it was a "race condition" :)
Ok, I commented out the continue at the line you specified. It didn't boot more, but the serial output is a few lines longer. Can I do something else?
comment:5 by , 16 years ago
Can you please use the "ints" command after the panic and attach that as well? What you are seeing is an interrupt gone missing. It's exactly the symptom if interrupts never arrive, which can have a few different reasons. The ints output should tell if it's possibly a shared interrupt problem.
comment:6 by , 14 years ago
Can you recheck this with a recent Haiku build? It may have been fixed recently.
comment:7 by , 14 years ago
Hi, unfortunately I don't have access to that machine anymore, so can't confirm nor deny! Should it be closed?
comment:8 by , 14 years ago
| Blocking: | 7665 added |
|---|
comment:9 by , 6 years ago
| Resolution: | → not reproducible |
|---|---|
| Status: | in-progress → closed |
comment:10 by , 6 years ago
| Blocking: | 7665 removed |
|---|
Replying to stpere:
It was hrev30286. If it worked before that it means the diagnostic code is one more thing we can't trust...
It seems that the output is a bit garbled, is it possible that you are running this on a SMP machine? The text is cut at some places and intermixed with different text at others. If you see something like this, try running with SMP disabled so the output gets cleaner.
Nah, that's just because a DMA transfer that was already set up was aborted due to an error when sending the request itself. The real question would be why it fails to send the request. It's possible that the device is in an inconsistent state because an earlier command timed out apparently. It's possible that the timeout happened because of a race condition in the current interrupt handling in the ide_adapter. Fixing that requires breaking the old IDE bus_manager though, so we can only do it after switching to ATA.
Can you please remove the "continue" at line 348 in "src/add-ons/kernel/bus_managers/ata/ATAChannel.cpp" and see if this gets it working again? Please also try to then capture a new serial output (preferrable without missing parts).