Ghost Solution Suite

The Client is running on win 2003 and I am pulling an image from a Dell Optiplex 740 with onboard Broadcom 57xx and SATA drives only and a 64 bit processor (running in 32 bit mode). I installed the dos driver for the Broadcom 57xx, but I am running into a problem. I am receiving a "Device cannot be found error" which triggers "Driver cannot be loaded" and "Error 33: Unable to bind."

I noticed that the device is on IRQ 16, and I cannot change the setting. Niether the BIOS or Device driver allow me to change the setting.

As a result I cannot pull an image off of this machine.

Any help is greatly appreciated.

Just as an aside, which GSS version are you using currently?

> I am receiving a "Device cannot be found error" which triggers "Driver cannot be loaded" and "Error 33: Unable to bind."

Normally, I'd expect that this means that the PCI IDs for the NIC don't match one that the driver you're using is expecting (although there are some more exotic possibilities for devices on non-PCI buses); if you view the network adapter in the Windows Device Manager MMC snap-in, the "Details" tab of the device properties should by default display the "Device Instance Id" which is normally an encoding of the PCI-bus identifier used in the Windows registry, from which we can learn the exact identifier for the device and what kind of bus it is attached to. You can use control-C to copy this string out of that dialog to paste here.

> I noticed that the device is on IRQ 16, and I cannot change the setting. Niether the BIOS or Device driver allow me to change the setting.

Interesting, since that's outside the legacy PIC range. There's a tool we added in GSS2 (called irqcfg.exe) which we have in the standard templates and that queries the PCI bus and ACPI IRQ data to see what the available interrupt configurations are and try and resolve conflicts.

Most modern (i.e. ACPI-compliant) desktop systems run all the hardware IRQ lines through a mapping table which puts the entire business of the mapping onto the ACPI PICs and the legacy ISA-BUS PICs under software control; where hardwired restrictions on remapping do exist, such as with the Dell GX270 which has several IRQs physically hardwired together, this fact is at least discoverable by the software.

The irqcfg.exe tool can report on this and give us a text dump which we can look at to at least see what the 740 supports at the hardware level. If you don't have GSS2 yet, drop me a line at nigel dot bree at gmail dot com and I can send you the irqcfg tool so we can explore that.

I just had a discussion about this with Krish Jayaratne about this; we do have an Intel-based Dell 745 here, but the Intel version of this design just works fine out of the box. Krish has been in discussion with a GSS2 customer with a 740 and evidently the chipset in the 740 is different.

What we suspect might be going on is that the chipset for the Athlon has put the NIC on the other side of a non-PCI Bus; that's something that some AMD chipsets seem to do, such as the nVidia nForce4 NIC which is "hidden" behind a PCI-to-nVidia-proprietary bus bridge that hides it from old devices. If this is true of the chipset in the 740, the DOS drivers for normal 75xx NICs won't be able to discover the NIC - you'd need a customised DOS driver that are aware of how to enumerate the proprietary non-PCI bus.

However, it seems that the BIOS for this machine does have this, and if you enable PXE support you might be able to use the UNDI driver template in GSS. You may or may not need to also move the PXE boot option higher in the boot order, but it seems that the BIOS NIC driver for PXE purposes does know the special magic needed for this chipset and the UNDI driver can piggyback on that.