KO: Katana+Odachi

I had little problem merging Katana (Linux box) and Odachi (Windows box) together. I now have a fully function Linux-Windows hybrid computer. I normally boot from Linux. And if I want to boot with Windows, either physically or from a virtual machine, I can.

Making Windows XP capable of booting from the physical BIOS and VMWare was slightly tricky. I remember trying to do so before and failed. I kept getting a blue screen when starting up Windows from within VMWare, with the error 0x7B INACCESSIBLE_BOOT_DEVICE. The solution was simply to boot physically in Windows, create a copy of the current hardware profile, and change the driver of the 3rd-party IDE controller to the generic one. I renamed the profile copy to “Physical” and the one I modified to “Virtual”. Now, it works like a charm!

For the sound in Linux, I had a little bit difficulty making ALSA work for non-ALSA software, including VMWare. (My friend NoMez has the same problem.) But I’ve found something that fixes that. All I needed to do what to create the file ~/.asoundrc with the following:

pcm.!dsp {
  type plug
  slave.pcm "dmixer"
}

Although, that seems to have made another problem. With that, I seem to be unable to record any audio, so Skype and my home-made VCR script don’t work as expected. (I can hear friends in Skype, but people can’t hear me. And video recorded by my script has no audio.)

To each solution, there’s a problem,” I always say.

However, I did manage to still use my SB Live! sound card instead of the crappy on-board sound. The motherboard I have now is the worst I’ve ever used with its weak audio output and non-working Ethernet port. I now have the following in my five PCI slots:

  • Sound Blaster Live! sound card
  • D-Link wireless card
  • Realtek chipset Ethernet card
  • 3-port FireWire card
  • ATI TV Wonder (BT878 chipset) TV tuner and capture card

I also have a good nVidia video card in the AGP slot, and I found a great RPM repository at www.livna.org with wonderful kernel modules and X drivers for the card. The 3D acceleration is always fun to have, even if I’m not a hardcore gamer.

Compiling my favourite SNES emulator, ZSNES, was also a problem. But that’s because there was actually a bug in the source code. A fixed version is linked in a ZSNES forum page. (Direct download.)

I decided to rename my computer to K.O.(Katana+Odachi), since it’s like the initials of a good friend of mine…

Comments

0x0000007B INACCESSABLE_BOOT_DEVICE

Oh the good ol’ days. Doesn’t this bring back memories?

It does sound a bit strange. Doesn’t windows need to read the boot device to get to the point when it crashes because it can not read the boot device?

Here is what really happens: Loader is the program that presents the the boot menu. Loader also loads a bunch of stuff into memory, including the kernel and boot time drivers. Some of the boot time drvers are in the “boot path,” meaing I/O to/from the boot device must traverse though the drivers. If any of those drivers fail to properly start then you get bugcheck 0x7B.

Okay, so if Loader needs to load the drivers for the boot device from the boot device, how does it talk to the boot device? Good question. Loader contains in it a small, read only NTFS driver. (This driver only support 8.3 formatted file names, hence the limitations of the names of the Windows directory and all files that get loaded by Loader.) That is how Loader can traverse the file system. Loader then uses BIOS routines to access the disk. This is the same way that DOS would talk to hard disks. It has not changed much since that time.

So, after Loader is done loading it hands off to NTOSKRNL.EXE. Once the kernel (and executive) has initialized itself it starts the boot drivers. After the driver stack for the boot device is initialized the OS uses only the driver stack to access the device. If any of the drivers in the stack fail to start properly, you get bugcheck 0x7B.

Your fix makes sense. Get the faulting driver out of the driver stack for the boot device and you don’t get the 0x7B anymore.

mike

I'll go to bed less stupid tonight!

I was trying to make sense out of this since I resolved the problem. If Windows can boot, why does it complain about an "inaccessible boot device". So, thanks, Mike. Now, it's all clear.

I just thought of something else...

Always use the stock Windows IDE driver unless the stock Windows IDE driver does not work with your specific hardware (in that case I say get new IDE hardware). Think about it, the IDE driver is the gateway to all your most precious data. If there is a bug in that driver, you loose the data on your HD. Now, the stock Windows IDE driver is running on millions of machines of all types all over the world. Pretty good test bed.

Great, let’s think about the third party driver. (1) Do the dev’s know how to write a kernel mode Windows component (not trivial)? (2) What is the testing on this driver? (3) How many other people are running this to flush out the bugs?

You make the call, I am running the stock IDE driver. My data is safe.

(Written by someone who spend a week restoring a corrupted HD due to a bug in nVidia’s IDE driver.)

Enjoy!

mike

No problem...

…glad I can help.

Background image