kdl: last transaction still open

[ttcoder]

Occurs for dsuden, see below for bt. Not sure whether to file under "BFS" or something else.

Couldn't fine a way to make this reproducible on any of my computers here.

[waddlesplash]

Please get the following:

1. A syslog from this machine just after boot.
2. The output of the listdev and listimage commands (once whatever operation usually triggers this has been started)
3. A picture of the output of syslog | tail 15 run at the KDL prompt.

[ttcoder]

Forwarding/Cc'ing this to Dane, thanks

EDIT: forgot to mention -- got word a few days ago that waddlesplash and Dane are working on this off-ticket, trying to find a way to diagnose/fix this

[waddlesplash]

Ping -- any update on getting those 3 things?

[ttcoder]

@dane I remember being Cc'ed on your discussing sending a reproducible case in snail mail.. Is your offer to send a USB stick with CC6 to waddlesplash still valid? Might be a way to spare you the chore of getting the nitty-gritty under-the-hood stuff :-)

[waddlesplash]

Except, ttcoder, you were unable to reproduce this, yes? IIRC quite literally nobody but Dane has seen this one. So I don't know why sending me a drive would help here...

[ttcoder]

All my "test lab" here consists of ten-year old computers.

All our problems (this KDL and others) started with hardware from recent years. Not sure what Dane is (was) using last for assembling station rigs, possibly still Asus/AMD combos as before.

[waddlesplash]

So, probonopd ran into this booting off USB (the second person ever to do so?) and ran the syslog+tail command and discovered that there were a ton of failing writes on the part of usb_disk. So I highly suspect the same is true here; that BFS is failing to write back the journal and this is its way of notifying you :)

Once again, the syslog information will confirm this. But if it's the case it will be much easier to find a solution. So this is not a problem in our block cache after all.

[ttcoder]

Well it would be ironic if this ticket was fixed in a roundabout way, thanks to data provided by another user! (just to be clear & make sure I understand, we are talking of a bug that is not specific only to USB? Dane's KDLs occur with AHCI, maybe set to IDE legacy mode, no USB mass storage involved I think). I'm trying to get ahold of Dane to test some other stuff, should converse with him about this too once in touch.

[waddlesplash]

Presumably it would occur whenever the journal hits an error writing back to disk.

Uh ... why are you using "IDE legacy mode"? That is not that reliable in BIOSes these days, and Haiku's AHCI support is more than stable.

[ttcoder]

I've just reverted my own test 'puter to AHCI. Uses 52000 from last august so the old boot problems should be gone, I'm seeing no regression so far. (ten years ago we had problems where Haiku would be "stuck" at boot in 10 or 20% of boot-ups, and that problem would be gone in IDE emulation mode).

In touch with Dane, will tell him to do the same -- I can see how this could make a big difference, if it ever turns out that our BFS corruptions problems are even remotely related to buggy IDE emulation. That and get a cheap PS/2 keyboard on ebay to enter the tail/syslog command in KDL.

-EDIT-: done, will keep the ticket posted if I hear back from Dane.

-EDIT2-: waddlesplash and Dane did some tweaking of the AMD setup, of IDE/AHCI, of haiku hrev, of HDA, and CC6 has been running for 3 days without a KDL, first time ever it lasts more than 24 hours! Knocking on wood..

[ttcoder]

No new instance of this ever since we went AHCI native, so it was a BIOS configuration problem indeed, closing.