Re: How to check if a spin lock has been freed or released?

Yeah, I can vouch for this too (ignoring obsolete hardware after they claim
they shall support it). For instance, in XPSP2 and Win2003SP1, Microsoft
introduced a nice little gem of a regression in the fact that they removed
the check in update.sys which verified that the processor was actually a P6
class or above before touching the microcode update MSRs.

This caused a 200MHz Pentium MMX I had running Win2003 to bluescreen on boot
after I installed SP1 (and this machine is actually in spec according to
Microsoft! - 133MHz minimum. I don't know of any 133MHz machines that are
P6 class...).

Because this box was at a remote location, I ended up having to talk someone
through hooking up a kernel debugger and using .kdfiles to load the SP0
version of update.sys via phone, then disabling the Microcode Update driver
permanently in the registry so it would boot without a kd attached. Not fun
at all.

"Maxim S. Shatskih" <maxim@xxxxxxxxxxxxxxxx> wrote in message
news:OTz30tLJGHA.3936@xxxxxxxxxxxxxxxxxxxxxxx
> For FreeBSD, one of the solutions would be to implement the exact clone
> of
> Windows KSPIN_LOCK (in addition to a normal FreeBSD's spinlocks) and use
> it for
> NDIS spinlocks. This would require, though, the mapping of Window's notion
> of
> IRQL to some FreeBSD's entity.
>
> About AML. Many motherboards have just buggy ACPI support, this is
> hardly a
> blame addressed to Microsoft.
>
> Older MS OSes like w2k were very permitting in terms of buggy ACPI
> support
> in BIOS. 2003 Server is no more. I have the mobo running fine on 2000 and
> XP,
> but the front panel power button just does not work at all on 2003 :-)
>
> The only issue is that BIOS authors immediately abused this
> permittivity by
> MS, and from now on the other OS makers must be "this permissive" too,
> with the
> very vague notion of "this" - the degree of how w2k is permissive to AML
> bugs
> is not documented anywhere (surely).
>
> Maybe MS should issue some analog of Driver Verifier for ACPI BIOSes
> and at
> least withdraw the mobos not passing the tests from their HCL, but I don't
> think this is already done (maybe due to lack of real-world motivation to
> lessen the number of hardware able to run Windows).
>
> Also note - MS ignores the obsolete hardware. 100% ignores it. They
> will
> never even accept any claims about Server 2003 running badly on particular
> Pentium-III 800MHz machine of 2000 vintage. For Linux and FreeBSD, this
> can be
> not so - lots of people are running these OSes on very, very obsolete
> hardware.
>
> This means that, if newer MS OS will be lesser permittive in AML bugs,
> and
> some mobo will be broken - MS will be able to declare it "obsolete" and
> ignore
> it.
>
>> bugs like NdisFreeSpinLock() misuse would show up immediately during
>> testing on the 95/98/ME platforms (assuming they, like CE, have an
>> NdisFreeSpinLock() that's also not a no-op).
>
> 95/8/Me are uniprocessor by design, I expect them to have the whole
> spinlock
> implementation as no-op. Well, it can be restricted to the analog on
> KeRaise/LowerIrql, as it is done in uniprocessor NT kernels, but the
> spinlock
> object will not be used by _any_ spinlock APIs, not only NdisFreeSpinLock.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@xxxxxxxxxxxxxxxx
> http://www.storagecraft.com
>


.

Loading