linux-2.4.0-test11-pre{3,4}/drivers/net/irda/toshoboe.c contains
a reference to the undefined symbol toshoboe_change_speed. I guess
this should be a reference to toshoboe_setbaud. Because I am not
positive, I am not sending this message directly to Linus, but I
am cc'ing it to linux-kernel. If I am right or if you have a better
patch, can you please send it to Linus? Thank you.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test11-pre4/drivers/net/irda/toshoboe.c Mon Nov 13 13:36:50 2000
+++ linux/drivers/net/irda/toshoboe.c Mon Nov 13 13:57:32 2000
@@ -275,7 +275,7 @@
if ((speed = irda_get_speed(skb)) != self->io.speed) {
/* Check for empty frame */
if (!skb->len) {
- toshoboe_change_speed(self, speed);
+ toshoboe_setbaud(self, speed);
return 0;
} else
self->new_speed = speed;
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
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.
general protection fault: ea3c
CPU: 0
EIP: 0050:[<00003319>]
EFLAGS: 00010046
eax: 0000ffff ebx: 00000001 ecx: 00000000 edx: 00000000
esi: 000000ff edi: ffff0014 ebp: c78b1ea4 esp: c78b1ea4
ds: 0058 es: 0000 ss: 0018
Process apmd (pid: 342, process nr: 10, stackpage=c78b1000)
Stack: 00000058 00ffffff 1eb80050 00000001 530a0000 00000016 00485c5f 00000000
c78b1f28 c01078f2 00000010 c78b1f28 ffffffff c64e0018 00000018 c01d8b51
000000ff ffffffff ffffffff 00000286 ffff0000 c64e0000 c0107ae6 0000530a
Call Trace: [apm_bios_call+58/120] [error_table+1009/9344] [apm_get_power_status+42/100] [apm_get_info+58/248] [proc_file_read+154/468] [sys_read+174/196] [system_call+52/56]
Code: <1>Unable to handle kernel paging request at virtual address 00003319
current->tss.cr3 = 05fe0000, %%cr3 = 05fe0000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[show_registers+653/704]
EFLAGS: 00010046
eax: 00000000 ebx: 00000000 ecx: 00003319 edx: c76ca000
esi: 0000002b edi: c78b2000 ebp: c8000000 esp: c78b1df4
ds: 0018 es: 0018 ss: 0018
Process apmd (pid: 342, process nr: 10, stackpage=c78b1000)
Stack: ffff0014 c78b1ea4 c02490c2 000000ff ffff0014 c78b1ea4 0000ffff 00000001
00000000 00000000 00003319 00010046 0000331a c8800000 c010a470 c78b1e68
c01d91a7 c01d927c 0000ea3c c78b1e68 c010a974 c01d927c c78b1e68 0000ea3c
Call Trace: [<c8800000>] [die+48/56] [error_table+2631/9344] [error_table+2844/9344] [do_general_protection+108/116] [error_table+2844/9344] [error_code+45/56]
[apm_bios_call+58/120] [error_table+1009/9344] [apm_get_power_status+42/100] [apm_get_info+58/248] [proc_file_read+154/468] [sys_read+174/196] [system_call+52/56]
Code: 8a 04 0b 89 44 24 38 50 68 9f 91 1d c0 e8 f5 9b 00 00 83 c4
Dax Kelson
>
> 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
> 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
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
> 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
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
> 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]
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]>
> 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
> > 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]
> 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
> > 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]
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]