hCOkS1D[\4f_>Zm^CT1A^BL@[ng`]oWbiRbFjgIn9M`dGV]f7V2?>4ATA=k   
   From: "Lars Erdmann"    
      
   Forget about this hardware detection thing.   
   What it effectively does is forcing RESOURCE.SYS to run all the snoopers   
   that are listed in the SNOOP.LST file and nothing else.   
   The only thing the snoopers do is "add resources"   
   (IRQs, memmapped regs, I/O mapped regs, DMA channels)   
   to some internal resource tree that you can subsequently view with    
   rmview.exe.   
   By the way: you can always enable full HW detection in the Hardware Manager.   
   That is then equivalent to hitting F5 on bootup.   
      
   Why do you need a new RESOURCE.SYS for new ACPI.PSD ?   
   Because ACPI.PSD supports IRQs > 15 and the old RESOURCE.SYS would not   
   allow to register IRQs > 15.   
   You certainly don't want your driver load to fail only because   
   the shitty resource manager is not happy with your IRQ number ...   
      
   That said I very much doubt that RESOURCE.SYS is the cause for the hangs.   
   It's just the last driver that had been loaded when the hang occured.   
      
   Lars   
      
      
   "Dariusz Piatkowski"  schrieb im Newsbeitrag    
   news:Qg5I6Bo2seGy-pn2-NJTtzPf3tIC3@neurobox...   
   > Hi Dave!   
   >   
   > On Sun, 22 Jan 2012 03:18:04 UTC, Dave Yeo  wrote:   
   >   
   >> Dariusz Piatkowski wrote:   
   >> > Hi Trevor!   
   >> >   
   >> > On Sat, 21 Jan 2012 20:40:03 UTC, "Trevor Hemsley"   
   >> >   wrote:   
   >> >   
   >> >> On Sat, 21 Jan 2012 17:03:14 UTC in comp.os.os2.misc, "Dariusz    
   >> >> Piatkowski"   
   >> >>   wrote:   
   >> >>   
   >> >>> I am able to run my 14.105 SMP based stuff in a 4-core configuration    
   >> >>> on my new   
   >> >>> MSI board...however attempting to even boot when the full 6-core    
   >> >>> setup is   
   >> >>> enabled in BIOS causes the machine to hand HARD in RESOURCE.SYS, even    
   >> >>> though I   
   >> >>> am still attempting to boot with just a 4-core enabled OS2    
   >> >>> configuration through   
   >> >>> OS2APCI.PSD driver. Subsequently my machine currently has the 2 of    
   >> >>> the 6 cores   
   >> >>> physically disabled in BIOS.   
   >> >>>   
   >> >>> So...I'm thinking the driver is running into some problems. I have    
   >> >>> never seen   
   >> >>> this before, and just about every mention of this problem I'm finding    
   >> >>> on the net   
   >> >>> is dealing with eCS ACPI boots...which I'm not certain I can relate    
   >> >>> to in any   
   >> >>> way.   
   >> >>>   
   >> >>> Any hints as to what may be at play here? What/where to look for the    
   >> >>> issue?   
   >> >>   
   >> >> The ECS acpi stuff requires that you install their version of    
   >> >> resource.sys. No   
   >> >> idea why that is as they do not say. Perhaps it is related to your    
   >> >> issue,   
   >> >> perhaps it has nothing to do with it.   
   >> >   
   >> >   
   >> > I'm not running any eCS SMP stuff on my machine however. It's all IBM    
   >> > stuff, and   
   >> > the 4-core SMP configuration is courtesy of OS2APIC.PSD driver.   
   >> >   
   >> > All I can tell is that I get a HARD hang when the boot logo displays   
   >> > ..RESOURCE.SYS...at the bottom of the screen (using ALT-F2 during boot    
   >> > start).   
   >> > Both (main and maintenance) my partitions hang, that means 14.104&    
   >> > 14.105. I   
   >> > suppose that might mean the driver which JUST loaded prior to    
   >> > RESOURCE.SYS hung   
   >> > the system...however, I'm not sure of how to determine that.   
   >>   
   >> Have you got hardware detection turned on? You could try removing   
   >> everything from snoop.lst except ibmkbd.snp and pcibus.snp in that order.   
   >> Also the IBM supplied ibmkbd.sys is buggy when it comes to SMP,   
   >> unluckily you have to purchase eCS to get the updated one.   
   >> You could also experiment with underclocking your system, at least that   
   >> shouldn't fry anything.   
   >   
   >   
   > I tried several different approaches:   
   >   
   > 1) the maintenance partition is a bare-bones configuration, snoop.lst    
   > doesn't   
   > even exist there, yet I see the same hang...so I'm thinking it may be    
   > something   
   > outside of snoop.lst, not quite sure what though   
   >   
   > 2) I did try a bare-bones snoop.lst in my regular partition, that did not    
   > have   
   > any effects on the hang   
   >   
   > 3) I tried FULL hardware detection as well, no difference   
   >   
   > 4) finally, I under-clocked the machine, in several stages, down to a 2Gig   
   > setting from a default of 3.4, no difference there   
   >   
   > Relying on some of the other system tools I see that 'dmidecode' fails to   
   > produce output, what I get is:   
   >   
   > === START ===   
   > [G:\test\dmidecode]dmidecode   
   > # dmidecode 2.10   
   > SMBIOS 2.5 present.   
   > 54 structures occupying 1934 bytes.   
   > Table at 0x0009F800.   
   >   
   > Invalid entry length (0). DMI table is broken! Stop.   
   > === STOP ===   
   >   
   > In comparison, the previous MSI board showed the following result:   
   >   
   > === START ===   
   > # dmidecode 2.10   
   > SMBIOS 2.6 present.   
   > 53 structures occupying 2033 bytes.   
   > Table at 0x000FCEB0.   
   >   
   > ...details of the dump....   
   >   
   > === STOP ===   
   >   
   > So at the very least, the NEW board is using an older version of    
   > SMBIOS...and it   
   > appears to be incorrect...I can always try to revert back to an older    
   > version of   
   > BIOS itself and see if that fixes the issue.   
   >   
   > PCI scan produces a good result however, no IRQ conflicts, etc.   
   >    
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)