On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> On 8/14/06, Giuseppe Bilotta <[email protected]> wrote:
>> On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:
>>
>>> On many laptops (including mine) polling battery takes a loooong time
>>> and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
>>> etc. It is pretty common problem. I think I have my ACPI client
>>> refreshing every 3 minutes.
>>
>> BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
>> and all keypresses and mouse movements (and I think even network
>> IRQs?) are totally *dead* while polling.
>>
>> However, The Other OS(tm) *seems* to do it right enough to have no
>> noticeable keypress losses, even when updating the battery status. Is
>> it using different system calls, or what?
>>
>
> I am not sure, but there are many things that may affect it:
>
> 1. Battry attributes are divided into 2 groups - static (i think they
> go into /proc/acpi/battery/<name>/info and dynamic
> (/proc/acpi/batetry/state). Static attributes take really long time to
> pull and they do not change so it may wery well be they are polled one
> at startup. Dynamic attributes are cheaper to poll and even then OS
> may cache access or limit rate.
Well, this would explain why Linux freezes while polling only if Linux
polls for the slow, static ones just as much as it does for the
dynamic ones ...
> 2. Quite often there are OEM drivers that are tweaked to a specific
> hardware and involve hardware-specific hacks.
If I remember correctly (damn, I can't find a way to do a search on
the LKML archives ...) there was someone working on Dell stuff, at
least as far as fans and thermal sensors were concerned (based on the
code from Massimo Dal Zotto) to integrate them with the kernel sensors
framework. However, some of those patches where NACKed by someone from
Dell because they were sort of "guessy" about the addresses to poke
around to get the information, instead of using the data provided by
the BIOS on where to look for them ... however, there hasn't been any
news about that that stuff since ...
--
Giuseppe "Oblomov" Bilotta
"Da grande lotter? per la pace"
"A me me la compra il mio babbo"
(Altan)
("When I grow up, I will fight for peace"
"I'll have my daddy buy it for me")
On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
>
> > 2. Quite often there are OEM drivers that are tweaked to a specific
> > hardware and involve hardware-specific hacks.
>
> If I remember correctly (damn, I can't find a way to do a search on
> the LKML archives ...) there was someone working on Dell stuff, at
> least as far as fans and thermal sensors were concerned (based on the
> code from Massimo Dal Zotto) to integrate them with the kernel sensors
> framework. However, some of those patches where NACKed by someone from
> Dell because they were sort of "guessy" about the addresses to poke
> around to get the information, instead of using the data provided by
> the BIOS on where to look for them ... however, there hasn't been any
> news about that that stuff since ...
>
As far as I remember that person from Dell was not ready to disclose
details of their SMBIOS :( so it naturally went nowhere.
--
Dmitry
On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> >
> > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > hardware and involve hardware-specific hacks.
> >
> > If I remember correctly (damn, I can't find a way to do a search on
> > the LKML archives ...) there was someone working on Dell stuff, at
> > least as far as fans and thermal sensors were concerned (based on the
> > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > framework. However, some of those patches where NACKed by someone from
> > Dell because they were sort of "guessy" about the addresses to poke
> > around to get the information, instead of using the data provided by
> > the BIOS on where to look for them ... however, there hasn't been any
> > news about that that stuff since ...
> >
>
> As far as I remember that person from Dell was not ready to disclose
> details of their SMBIOS :( so it naturally went nowhere.
actually Dell did document their smbios ...
http://linux.dell.com/libsmbios/main/index.html
there was also a posting from Dell with details, but I assume that's
included in their libsmbios...
>
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On 8/19/06, Arjan van de Ven <[email protected]> wrote:
> On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> > On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> > >
> > > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > > hardware and involve hardware-specific hacks.
> > >
> > > If I remember correctly (damn, I can't find a way to do a search on
> > > the LKML archives ...) there was someone working on Dell stuff, at
> > > least as far as fans and thermal sensors were concerned (based on the
> > > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > > framework. However, some of those patches where NACKed by someone from
> > > Dell because they were sort of "guessy" about the addresses to poke
> > > around to get the information, instead of using the data provided by
> > > the BIOS on where to look for them ... however, there hasn't been any
> > > news about that that stuff since ...
> > >
> >
> > As far as I remember that person from Dell was not ready to disclose
> > details of their SMBIOS :( so it naturally went nowhere.
>
> actually Dell did document their smbios ...
>
> http://linux.dell.com/libsmbios/main/index.html
>
> there was also a posting from Dell with details, but I assume that's
> included in their libsmbios...
>
I could not find any fan control or temperature monitoring references
there. Maybe I missed them.
--
Dmitry
On Mon, 2006-08-21 at 08:34 -0400, Dmitry Torokhov wrote:
> On 8/19/06, Arjan van de Ven <[email protected]> wrote:
> > On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> > > On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > > > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> > > >
> > > > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > > > hardware and involve hardware-specific hacks.
> > > >
> > > > If I remember correctly (damn, I can't find a way to do a search on
> > > > the LKML archives ...) there was someone working on Dell stuff, at
> > > > least as far as fans and thermal sensors were concerned (based on the
> > > > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > > > framework. However, some of those patches where NACKed by someone from
> > > > Dell because they were sort of "guessy" about the addresses to poke
> > > > around to get the information, instead of using the data provided by
> > > > the BIOS on where to look for them ... however, there hasn't been any
> > > > news about that that stuff since ...
> > > >
> > >
> > > As far as I remember that person from Dell was not ready to disclose
> > > details of their SMBIOS :( so it naturally went nowhere.
> >
> > actually Dell did document their smbios ...
> >
> > http://linux.dell.com/libsmbios/main/index.html
> >
> > there was also a posting from Dell with details, but I assume that's
> > included in their libsmbios...
> >
>
> I could not find any fan control or temperature monitoring references
> there. Maybe I missed them.
there was an lkml posting from a Dell guy with a full table, just that
my google skills seem to be not successful at locating it right now.
On Wed 16-08-06 09:31:48, Giuseppe Bilotta wrote:
> On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
>
> > On 8/14/06, Giuseppe Bilotta <[email protected]> wrote:
> >> On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:
> >>
> >>> On many laptops (including mine) polling battery takes a loooong time
> >>> and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
> >>> etc. It is pretty common problem. I think I have my ACPI client
> >>> refreshing every 3 minutes.
> >>
> >> BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
> >> and all keypresses and mouse movements (and I think even network
> >> IRQs?) are totally *dead* while polling.
> >>
> >> However, The Other OS(tm) *seems* to do it right enough to have no
> >> noticeable keypress losses, even when updating the battery status. Is
> >> it using different system calls, or what?
> >>
> >
> > I am not sure, but there are many things that may affect it:
> >
> > 1. Battry attributes are divided into 2 groups - static (i think they
> > go into /proc/acpi/battery/<name>/info and dynamic
> > (/proc/acpi/batetry/state). Static attributes take really long time to
> > pull and they do not change so it may wery well be they are polled one
> > at startup. Dynamic attributes are cheaper to poll and even then OS
> > may cache access or limit rate.
>
> Well, this would explain why Linux freezes while polling only if Linux
> polls for the slow, static ones just as much as it does for the
> dynamic ones ...
I guess patch caching battery/*/state would be welcome.
--
Thanks for all the (sleeping) penguins.