Re: APM oops with Dell 5000e laptop
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 > getting harder and harder to find cpus for the original 5000 series. And > this new model's been sitting on my desk for couple of weeks now > collecting dust. Disable apm and be done with that! I do not see why this is a problem. Just add comment to apm.c, there are more comments about b0rken machines in there. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 getting harder and harder to find cpus for the original 5000 series. And this new model's been sitting on my desk for couple of weeks now collecting dust. Disable apm and be done with that! I do not see why this is a problem. Just add comment to apm.c, there are more comments about b0rken machines in there. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> > 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 id the compal bios. The DMI tables > can include more useful BIOS info but rarely do (you might want to dump all the > DMI tables in your box and see if you have a BIOS vendor/version) The BIOS revisions seem to match up, but there are already multiple versions of the BIOS for this machine already, so I initially discounted that method. It also means a bit of upkeep, too. I was really hoping for a "set it and forget it" approach, but that doesn't seem possible. Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> 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 id the compal bios. The DMI tables can include more useful BIOS info but rarely do (you might want to dump all the DMI tables in your box and see if you have a BIOS vendor/version) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 id the compal bios. The DMI tables can include more useful BIOS info but rarely do (you might want to dump all the DMI tables in your box and see if you have a BIOS vendor/version) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 id the compal bios. The DMI tables can include more useful BIOS info but rarely do (you might want to dump all the DMI tables in your box and see if you have a BIOS vendor/version) The BIOS revisions seem to match up, but there are already multiple versions of the BIOS for this machine already, so I initially discounted that method. It also means a bit of upkeep, too. I was really hoping for a "set it and forget it" approach, but that doesn't seem possible. Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> > 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 I know to get > > o Cache sizes on older machines > o The type of monitoring device (lm78 etc) attached > o slot information You cannot base this on the Type 1: System Information as a method of identifying the system. I have in front of me a Dell 5000e and a Compal N30W2, which are the exact same machines. A SMBIOS dump shows different identification information for both machines. In the System Information struct, one says Compal Electronics and the other says Dell Computer Corporation for the manufacturer. The Product Names are also (obviously) different as well. So far, I have been unable to find anything in the dump that identifies the two machines as the same. 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? Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> 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 I know to get o Cache sizes on older machines o The type of monitoring device (lm78 etc) attached o slot information I have user space code to walk these tables so I have a basis to attack this in 2.2.19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> 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 broken > features of otherwise working hardware with black lists. There will be > many *many* of these laptops sold. Unlike other BIOS, this cannot be fixed up and I don't believe there is an easy way to identify every single "version" of this machine (Stephen Rothwell, can you comment here?). That broken call is a major part of the Linux APM system. The simplest (and arguably, best) solution is to just not compile it into the kernel or add "apm=off" to lilo.conf until the problem is fixed. > Is there a way to uniquely identify the affected BIOSes at boot time and > turn off APM? According to Brad Douglas, the 32-bit Get Power Status > (0AH) call is broken. 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). > Supposedly there will be a BIOS update in the "future" to correct this > problem. This is what we have been led to believe. I have no ETA at this time. Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 them back. 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 companies aren't going to see too many requests unless anyone who's even considering buying a new laptop complain about this. Compal provides no communication channel for the consumers, so we have to go through the big companies like dell. When I e-mailed dell's tech support I got a response from a guy who had *no* idea what linux is. > > 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 getting harder and harder to find cpus for the original 5000 series. And this new model's been sitting on my desk for couple of weeks now collecting dust. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > John Kim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> 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 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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 broken features of otherwise working hardware with black lists. There will be many *many* of these laptops sold. Is there a way to uniquely identify the affected BIOSes at boot time and turn off APM? According to Brad Douglas, the 32-bit Get Power Status (0AH) call is broken. Supposedly there will be a BIOS update in the "future" to correct this problem. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> 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 kernels. There are no fixes. Return the faulty equipment to the vendor and suggest they get a QA department. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 kernels. There are no fixes. Return the faulty equipment to the vendor and suggest they get a QA department. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 broken features of otherwise working hardware with black lists. There will be many *many* of these laptops sold. Is there a way to uniquely identify the affected BIOSes at boot time and turn off APM? According to Brad Douglas, the 32-bit Get Power Status (0AH) call is broken. Supposedly there will be a BIOS update in the "future" to correct this problem. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 them back. 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 companies aren't going to see too many requests unless anyone who's even considering buying a new laptop complain about this. Compal provides no communication channel for the consumers, so we have to go through the big companies like dell. When I e-mailed dell's tech support I got a response from a guy who had *no* idea what linux is. 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 getting harder and harder to find cpus for the original 5000 series. And this new model's been sitting on my desk for couple of weeks now collecting dust. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ John Kim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 broken features of otherwise working hardware with black lists. There will be many *many* of these laptops sold. Unlike other BIOS, this cannot be fixed up and I don't believe there is an easy way to identify every single "version" of this machine (Stephen Rothwell, can you comment here?). That broken call is a major part of the Linux APM system. The simplest (and arguably, best) solution is to just not compile it into the kernel or add "apm=off" to lilo.conf until the problem is fixed. Is there a way to uniquely identify the affected BIOSes at boot time and turn off APM? According to Brad Douglas, the 32-bit Get Power Status (0AH) call is broken. 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). Supposedly there will be a BIOS update in the "future" to correct this problem. This is what we have been led to believe. I have no ETA at this time. Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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. -Barry K. Nathan [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 I know to get o Cache sizes on older machines o The type of monitoring device (lm78 etc) attached o slot information I have user space code to walk these tables so I have a basis to attack this in 2.2.19 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
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 I know to get o Cache sizes on older machines o The type of monitoring device (lm78 etc) attached o slot information You cannot base this on the Type 1: System Information as a method of identifying the system. I have in front of me a Dell 5000e and a Compal N30W2, which are the exact same machines. A SMBIOS dump shows different identification information for both machines. In the System Information struct, one says Compal Electronics and the other says Dell Computer Corporation for the manufacturer. The Product Names are also (obviously) different as well. So far, I have been unable to find anything in the dump that identifies the two machines as the same. 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? Brad Douglas [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM oops with Dell 5000e laptop
> > 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 with no > response. > > http://linuxcare.com.au/cgi-bin/apm/incoming?id=90 > http://linuxcare.com.au/cgi-bin/apm/incoming?id=91 We have an open ticket with Compal (the manufacturer) about the problem. The 32-bit Get Power Status (0AH) call is broken. Brad Douglas [EMAIL PROTECTED] http://www.tuxtops.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
