[CORE-13988] booting hangs if SATA operation mode is set to AHCI Created: 2017-11-09  Updated: 2017-12-25  Resolved: 2017-12-25

Status: Resolved
Project: Core ReactOS
Component/s: None
Fix Version/s: 0.4.8

Type: Bug Priority: Major
Reporter: Michael Arthur Long Assignee: alter-1
Resolution: Fixed Votes: 2
Labels: None

Attachments: PNG File 230UNIATA1.png     PNG File 230UNIATA2.png     PNG File 230UNIATA3.png     PNG File 230UNIATA4.png     Text File 230_AHCI.log     Text File 230_ATA.log     Text File ReactOS 0.4.7 RC1 UniATA 46e4.log     Text File debug.log and backtrace.log     Text File debug.log with UniATAdbg.txt     File uniata_46e4-46e5.patch    
Issue Links:
is blocked by CORE-14117 Update UniATA to Version 0.46e5 Resolved
relates to CORE-7020 ReactOS doesn`t boot in virtualbox wi... Open


I tested this issue with the live CDs of 0.4.6 r75965 +new usb from vgal and with 0.4.7 RC1 on real hardware. In the BIOS there is an option called "SATA operation" where I can toggle between "ATA" and "AHCI". If I select "ATA" then ReactOS boots fine. If I select "AHCI" then ReactOS hangs while loading UNIATA.sys:

So I used the debug to screen booting mode to gather the debug log:

and the backtrace:

Is there anything else I can do to help?

Comment by Michael Arthur Long [ 2017-11-19 ]

I attached a debug log and the backtrace which I could receive via RS-232. But it looks a little bit different than the screen debug output.

Comment by alter-1 [ 2017-12-11 ]

Please install debug build of UniATA to get detailed log via rs232

Comment by Michael Arthur Long [ 2017-12-15 ]

I used the ReactOS version 0.4.6 r75965 +new usb from vgal. Then I replaced the ReactOS file usbehci.sys with the one from Windows so I got mouse and keyboard working. Then I installed UniATA debug version 46e3. Then I set the SATA operation to "ATA", booted to desktop and received the debug log 230_ATA.log. Then I set the SATA operation to "AHCI" and booted but ReactOS crashed again. I also receiver the debug.log 230_AHCI.log . When ReactOS crashed I couldn't enter "bt" anymore. I tryed it twice. Putty didn't even show the letters.

Comment by Javier Fernandez [ 2017-12-15 ]

please attach pictures, better than posting links. (links will die)

Comment by Michael Arthur Long [ 2017-12-15 ]

I just attached the 2 log files. The links are old and exist because JIRA does not allow the upload of big pictures.

Comment by Michael Arthur Long [ 2017-12-15 ]

Here you go, I replaced the old links with lower resolution in-JIRA-pictures.

Comment by Stas'M [ 2017-12-15 ]

Sorry for being offtop, but does these photos are taken using scanner? 

Also why you just don't save them in JPG format? They will be much smaller.

Comment by ThFabba [ 2017-12-15 ]

Tip for the future: if your screenshots are so big that Jira won't accept them, they're probably bigger than necessary. You could still size down the current ones to 35% and they'd be perfectly legible. There are no hidden barcodes or anything encoded in the on-screen logs so as long as the text is readable, they're fine

Edit: that also implies that if you attached the log as a text file, there will be no further information in a screenshot, so we won't need those.

Comment by ThFabba [ 2017-12-15 ]

As for the actual bug: the backtrace is what contains the useful information here. In order to make sense of the parts that aren't in ntoskrnl.exe (in this case, uniata.sys and scsiport.sys) we either need you to resolve these addresses by using log2lines/raddr2line (https://www.reactos.org/wiki/Debugging#Translating_Addresses) or we need the exact binaries you used. That means if you use an unofficial ISO such as vgal's, we need a link to it please. Thanks!

Comment by Michael Arthur Long [ 2017-12-16 ]

Stas'M Kind of. I placed the monitor on a photocopier and made a copy. Then I put the copy on my scanner. The quality is already very low and the text is barely readable so I didn't want to reduce the quality even further.

ThFabba The screenshots were made at a time when I had no working host pc to receive anything over RS-232. The link is here: http://vgal.ru.com/reactos-75965-new-usb/ and here is the direct link http://vgal.ru.com/downloads/bootcd-ReactOS-75965-vgal.7z

I will retry with the ReactOS usbehci.sys so I might be able to enter "bt". But somehow I have the feeling that the debug version of UniATA did no difference at all.

Comment by Michael Arthur Long [ 2017-12-16 ]

I am sorry, no luck with the ReactOS usbehci.sys. I couldn't enter "bt" with it either.

Comment by ThFabba [ 2017-12-16 ]

The resolved backtrace already tells pretty much the whole the story.

*** Fatal System Error: 0x000000c2

Entered debugger on embedded INT3 at 0x0008:0x80945ea4.
kdb:> bt
<NTOSKRNL.EXE:145ea5 (:0 (RtlpBreakWithStatusInstruction))>
<NTOSKRNL.EXE:8295d (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf))>
<NTOSKRNL.EXE:82f34 (ntoskrnl/ke/bug.c:1456 (KeBugCheckEx))>
<NTOSKRNL.EXE:9faf9 (ntoskrnl/mm/ARM3/expool.c:421 (ExAllocatePoolWithTag))>
<NTOSKRNL.EXE:9de99 (ntoskrnl/mm/ARM3/contmem.c:408 (MiAllocateContiguousMemory))>
<NTOSKRNL.EXE:9e36c (ntoskrnl/mm/ARM3/contmem.c:640 (MmAllocateContiguousMemory))>
<uniata.sys:e96c (drivers/storage/ide/uniata/id_dma.cpp:155 (AtapiDmaAlloc))>
<uniata.sys:21f84 (drivers/storage/ide/uniata/id_sata.cpp:839 (UniataAhciInit))>
<uniata.sys:15e4d (drivers/storage/ide/uniata/id_init.cpp:1926 (AtapiChipInit))>
<uniata.sys:850c (drivers/storage/ide/uniata/id_ata.cpp:3312 (AtapiHwInitialize))>
<NTOSKRNL.EXE:125bbd (ntoskrnl/ke/i386/irqobj.c:599 (KeSynchronizeExecution))>
<scsiport.sys:6343 (drivers/storage/scsiport/scsiport.c:1615 (ScsiPortInitialize))>
<uniata.sys:e127 (drivers/storage/ide/uniata/id_ata.cpp:10947 (DriverEntry))>
<NTOSKRNL.EXE:5bd85 (ntoskrnl/io/iomgr/driver.c:1572 (IopCreateDriver))>
<NTOSKRNL.EXE:5c015 (ntoskrnl/io/iomgr/driver.c:521 (IopInitializeDriverModule))>
<NTOSKRNL.EXE:17658e (ntoskrnl/io/iomgr/driver.c:892 (IopInitializeBuiltinDriver))>
<NTOSKRNL.EXE:17693d (ntoskrnl/io/iomgr/driver.c:1106 (IopInitializeBootDrivers))>
<NTOSKRNL.EXE:177611 (ntoskrnl/io/iomgr/iomgr.c:547 (IoInitSystem))>

This is a BAD_POOL_CALLER bugcheck indicating that a pool allocation was attempted at an IRQL that was too high. MiAllocateContiguousMemory attempted to allocate 0x800 bytes of NonPagedPoolCacheAligned memory; it was called at IRQL 0xD (DIRQL).
uniata is making its call to MmAllocateContiguousMemory from inside its HwStorInitialize routine, which is documented to run at DIRQL:
However this function is only allowed at DISPATCH_LEVEL or below:

That's a clear violation of the contract in the uniata driver, and may be fixed by queuing a DPC or performing this allocation in another function, such as HwStorPassiveInitializeRoutine.
I see no relation to USB, so testing with vgal's isos or messing with usbehci seems unnecessary.

The problem should be clear from just this, but a log with UniATA debugging may yield additional information useful to alter-1. To obtain one, remove the # from line 8 (#add_definitions(-D_DEBUG)) and build the driver/iso that way.


Comment by Michael Arthur Long [ 2017-12-16 ]

ThFabba Thank you. Yes, I get "BAD_POOL_CALLER" on the blue screeen. I used vgals version so I could use a mouse and a keyboard to install the driver (but that didn't seem to happen anyway). But I can use a keyboard with PS/2 if I don't need a mouse.

Comment by Michael Arthur Long [ 2017-12-16 ]

debug.log with UniATAdbg.txt I attached a debug.log with UniATA version 46e3 debug. Backtrace is also included. ReactOS version 0.4.7 RC1.

Comment by alter-1 [ 2017-12-17 ]

MiAllocateContiguousMemory should not be called in this case at all. Please, try this uniata_46e4-46e5.patch patch

Comment by Michael Arthur Long [ 2017-12-17 ]

If you like, then I will retry with 46e4 instead of 46e3 as before. But I cannot compile cpp files easily.

Comment by Michael Arthur Long [ 2017-12-17 ]

ReactOS 0.4.7 RC1 UniATA 46e4.log I just copyed "uniata.sys" into ReactOS\system32\drivers\ and replaced the existing file. I hope that this kind of "installation" is correct. Your patch was not applied. It's version 46e4.

Comment by alter-1 [ 2017-12-17 ]

46e5 contains fix exactly for this bug. New code prevents multiple execution of memory init. So, it must be applied fo further tests.

Comment by Michael Arthur Long [ 2017-12-17 ]

As I said, I can not compile C++ files easily. Could you provide the new version in a compiled form? Thanks.

Comment by alter-1 [ 2017-12-17 ]


Comment by Michael Arthur Long [ 2017-12-17 ]

alter-1: Thank you. You have fixed the bug.

Comment by Jedi-to-be [ 2017-12-17 ]

alter-1 Please update your site accordingly

Comment by alter-1 [ 2017-12-20 ]

Site version is updated

Comment by Michael Arthur Long [ 2017-12-25 ]

The new version has been commited in a76fdbd8cb5ea6a28b1e18213544988d767887e2. I did a retest with this version and now ReactOS has no problems anymore on the test machine when the SATA operation mode is set to AHCI. This means this issue is fixed. Thanks to all contributors.

Comment by Javier Fernandez [ 2017-12-25 ]

Michael Arthur Long close report then

Comment by Michael Arthur Long [ 2017-12-25 ]

@Javier Fernandez: Sorry, I thought my JIRA account has not the rights to do this. But the function was just hidden. Thank you.

Generated at Tue Feb 19 18:53:40 UTC 2019 using Jira 7.12.3#712004-sha1:5ef91d760d7124da5ebec5c16a948a4a807698df.