Hi!
> > > Is there a way to uniquely identify the affected BIOSes at boot time and
>
> > Im looking at one with some pointers from Dell. It won't be in 2.2.18 so its
> > quite likely a fixed BIOS will be out first anyway.
>
> Wherever the fix comes from, I sure hope it comes soon, because it's
> > I don't believe doing this just to make a Dell detect properly is the right way to
>go (regardless of my bias). I think the best we can do build a list of the systems
>that are the same, but it's certainly not a preferred way.
> >
> > Any suggestions?
>
> The ideal approach is to ident an
> I don't believe doing this just to make a Dell detect properly is the right way to
>go (regardless of my bias). I think the best we can do build a list of the systems
>that are the same, but it's certainly not a preferred way.
>
> Any suggestions?
The ideal approach is to ident and version
> > I do not believe so. I tend to think that detecting these broken models is a
>waste of kernel code (especially, if there's an effort to correct the problem).
>
> One idea the Dell folks suggested is walking the SMBIOS data table. That happens
> to be something I want to do as its the only g
> I do not believe so. I tend to think that detecting these broken models is a waste
>of kernel code (especially, if there's an effort to correct the problem).
One idea the Dell folks suggested is walking the SMBIOS data table. That happens
to be something I want to do as its the only good way
John D. Kim wrote:
> Well, there will be a great number of these laptops sold, not just through
> dell, but other brands that buy from compal. But most of them will be
> running Windows, and Windows seem to work fine with it. So these
[snip]
FWIW, Windows uses ACPI on these machines, not APM.
> Alan Cox said once upon a time (Thu, 16 Nov 2000):
>
> > > I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
> > > Red Hat 7.0 on it, and got an APM related oops at boot.
> >
> > Yep. This is not a Linux problem
>
> The kernel works around/ignores/disables other broken h
On Thu, 16 Nov 2000, Alan Cox wrote:
> > The kernel works around/ignores/disables other broken hardware or broken
> > features of otherwise working hardware with black lists. There will be
> > many *many* of these laptops sold.
> And I hope many many of these people demand BIOS upgrades or send
> The kernel works around/ignores/disables other broken hardware or broken
> features of otherwise working hardware with black lists. There will be
> many *many* of these laptops sold.
And I hope many many of these people demand BIOS upgrades or send them back.
> Is there a way to uniquely iden
Alan Cox said once upon a time (Thu, 16 Nov 2000):
> > I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
> > Red Hat 7.0 on it, and got an APM related oops at boot.
>
> Yep. This is not a Linux problem
The kernel works around/ignores/disables other broken hardware or broke
> I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
> Red Hat 7.0 on it, and got an APM related oops at boot.
Yep. This is not a Linux problem
> Here is what got in /var/log/messages, I'm willing to try suggested fixes,
> etc. The problem also happens with the 2.4 test ke
>
> I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
> Red Hat 7.0 on it, and got an APM related oops at boot.
>
> I found that this was reported on l-k in late September with a couple
> responses, but no resolution.
>
> Here are a couple detailed bug reports on this sam
I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
Red Hat 7.0 on it, and got an APM related oops at boot.
I found that this was reported on l-k in late September with a couple
responses, but no resolution.
Here are a couple detailed bug reports on this same problem, again
13 matches
Mail list logo
