ubuntu crashes often now while watching video

"Paul" wrote in message
...
Paul wrote:
Adam wrote:


So, do I still load "asus_atk0110" module?
Or, am I suppose to load "asus_atk0100" module (if any) instead?


I can't promise anything, but take a look with

dmesg | grep -i acpi

and see if any ATK related stuff is in there. Do that
soon after boot, as the dmesg uses a circular buffer and
later events can overwrite the stuff from T=0.

I booted my Mint USB stick on the new computer (Asus),
and it uses a regular SuperIO hardware monitor. On there,
adding a sudo modprobe nct6775 got me a bunch of hardware
monitor stuff. So that machine will be useless for debugging
this problem.

I think the machine I'm typing on, may have ATK, so
I'll have to reboot this machine and have a look.

Paul

Using Mint, my current motherboard (Core2 based), the sensors-detect
find "coretemp" and "some Winbond chip". Which is normal

However, when the sensors program is used, instead of
reading out from the Winbond, it reads from ATK0110
instead.

And I don't find the detection of that listed in dmesg.

So somehow it knows to check ATK0110.

*******

The article here, goes into how the OS parses the ACPI
tables. Using the Intel tool, they disassemble the table.

./iasl -dc dsdt.bin

That's an Intel tool. And it may be commonly used by
Linux people, who are checking for ACPI errors or problems
with their computer design.

This is one of the reasons there was an interest in doing
a "Linux BIOS", so there would be a way to bypass errors
in the tables, and make a computer work with Linux.

That's getting out of my comfort range, in terms of
debugging. When you run the sensors command, it doesn't
seem to be using ATK0110. The ATK0100 could be for
turning LEDs on and off, turning off the backlight,
and other general purpose I/O things. Rather than
giving access to hardware monitor registers.

So if someone from lm-sensors was working on it,
they'd probably want you to disassemble some stuff,
to figure out why it isn't working.

Your information is consistent with you not having
a SuperI/O chip on that computer (sensors-detect doesn't
find one on the bus, and ATK0110 is not leaping to the
rescue when sensors command is used). Intel has been
contriving to eliminate SuperI/O, but lots of
computers still include half of one or a whole one.
For example, just the other day I discover my
computer has a serial port, which would be an interface
on a SuperI/O. Only problem is, there's no connector
on the back of the computer. I have to buy an adapter plate
with ribbon cable, if I want to use it.

Paul

Uhm, the mobo manual (E8042) shows Super I/O under
Motherboard Layout section (p. 1-6). On the physical board,
it may be the ITE IT8721F chip?

Adam wrote:
"Paul" wrote in message
...
Paul wrote:
Adam wrote:

So, do I still load "asus_atk0110" module?
Or, am I suppose to load "asus_atk0100" module (if any) instead?

I can't promise anything, but take a look with

dmesg | grep -i acpi

and see if any ATK related stuff is in there. Do that
soon after boot, as the dmesg uses a circular buffer and
later events can overwrite the stuff from T=0.

I booted my Mint USB stick on the new computer (Asus),
and it uses a regular SuperIO hardware monitor. On there,
adding a sudo modprobe nct6775 got me a bunch of hardware
monitor stuff. So that machine will be useless for debugging
this problem.

I think the machine I'm typing on, may have ATK, so
I'll have to reboot this machine and have a look.

Paul
Using Mint, my current motherboard (Core2 based), the sensors-detect
find "coretemp" and "some Winbond chip". Which is normal

However, when the sensors program is used, instead of
reading out from the Winbond, it reads from ATK0110
instead.

And I don't find the detection of that listed in dmesg.

So somehow it knows to check ATK0110.

*******

The article here, goes into how the OS parses the ACPI
tables. Using the Intel tool, they disassemble the table.

./iasl -dc dsdt.bin

That's an Intel tool. And it may be commonly used by
Linux people, who are checking for ACPI errors or problems
with their computer design.

This is one of the reasons there was an interest in doing
a "Linux BIOS", so there would be a way to bypass errors
in the tables, and make a computer work with Linux.

That's getting out of my comfort range, in terms of
debugging. When you run the sensors command, it doesn't
seem to be using ATK0110. The ATK0100 could be for
turning LEDs on and off, turning off the backlight,
and other general purpose I/O things. Rather than
giving access to hardware monitor registers.

So if someone from lm-sensors was working on it,
they'd probably want you to disassemble some stuff,
to figure out why it isn't working.

Your information is consistent with you not having
a SuperI/O chip on that computer (sensors-detect doesn't
find one on the bus, and ATK0110 is not leaping to the
rescue when sensors command is used). Intel has been
contriving to eliminate SuperI/O, but lots of
computers still include half of one or a whole one.
For example, just the other day I discover my
computer has a serial port, which would be an interface
on a SuperI/O. Only problem is, there's no connector
on the back of the computer. I have to buy an adapter plate
with ribbon cable, if I want to use it.

Paul

Uhm, the mobo manual (E8042) shows Super I/O under
Motherboard Layout section (p. 1-6). On the physical board,
it may be the ITE IT8721F chip?

The issue is, there are two ways to access the chip.
Have the BIOS access it, as an ACPI object of some sort.
Or probe the bus directly. The software in this case,
upon spotting the ACPI object, is using that ACPI interface.
And apparently not seeing everything it should see.
Even though sensors-detect appears to go right to the
bus and look for them.

"sensors" program - ACPI object via BIOS call
"sensors-detect" program - direct bus access

This would be a jolly good design if...
the BIOS had a feature to disable the ACPI
table entry, so hardware buses could be used
for everything. Like the good old days.

Paul

"Adam" wrote in message
...

"Paul" wrote in message
...
Paul wrote:
Adam wrote:


So, do I still load "asus_atk0110" module?
Or, am I suppose to load "asus_atk0100" module (if any) instead?


I can't promise anything, but take a look with

dmesg | grep -i acpi

and see if any ATK related stuff is in there. Do that
soon after boot, as the dmesg uses a circular buffer and
later events can overwrite the stuff from T=0.

I booted my Mint USB stick on the new computer (Asus),
and it uses a regular SuperIO hardware monitor. On there,
adding a sudo modprobe nct6775 got me a bunch of hardware
monitor stuff. So that machine will be useless for debugging
this problem.

I think the machine I'm typing on, may have ATK, so
I'll have to reboot this machine and have a look.

Paul

Using Mint, my current motherboard (Core2 based), the sensors-detect
find "coretemp" and "some Winbond chip". Which is normal

However, when the sensors program is used, instead of
reading out from the Winbond, it reads from ATK0110
instead.

And I don't find the detection of that listed in dmesg.

So somehow it knows to check ATK0110.

*******

The article here, goes into how the OS parses the ACPI
tables. Using the Intel tool, they disassemble the table.

./iasl -dc dsdt.bin

That's an Intel tool. And it may be commonly used by
Linux people, who are checking for ACPI errors or problems
with their computer design.

This is one of the reasons there was an interest in doing
a "Linux BIOS", so there would be a way to bypass errors
in the tables, and make a computer work with Linux.

That's getting out of my comfort range, in terms of
debugging. When you run the sensors command, it doesn't
seem to be using ATK0110. The ATK0100 could be for
turning LEDs on and off, turning off the backlight,
and other general purpose I/O things. Rather than
giving access to hardware monitor registers.

So if someone from lm-sensors was working on it,
they'd probably want you to disassemble some stuff,
to figure out why it isn't working.

Your information is consistent with you not having
a SuperI/O chip on that computer (sensors-detect doesn't
find one on the bus, and ATK0110 is not leaping to the
rescue when sensors command is used). Intel has been
contriving to eliminate SuperI/O, but lots of
computers still include half of one or a whole one.
For example, just the other day I discover my
computer has a serial port, which would be an interface
on a SuperI/O. Only problem is, there's no connector
on the back of the computer. I have to buy an adapter plate
with ribbon cable, if I want to use it.

Paul

Uhm, the mobo manual (E8042) shows Super I/O under
Motherboard Layout section (p. 1-6). On the physical board,
it may be the ITE IT8721F chip?


Sorry, my bad, getting myself confused. I was looking at
the new desktop build when posting. So, ignore this post.
This thread is for the laptop, which I don't know has Super I/O or not.