root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device
Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.
When the revolution comes, the author of
root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device
Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.
When the revolution comes, the author of
On Mon, 15 Aug 2005 01:37:08 +0100 Alan Cox wrote:
>
> We certainly could interpret 0x51, 0x04 specifically. Its not an "error"
> in the usual spew at the user case generally speaking but a "do this"
> "no" sequence. Its useful to log because sending unknown commands to an
> IDE device is
On 2005-08-14 20:10:49 Nick Warne wrote:
>Note the last sentence:
>
>' This variation is designed for use with "libraries" of drive
>identification information, and can also be used on ATAPI drives which may
>give media errors with the standard mechanism.
My jaw just clonked on the
The "hdparm -I /dev/hdc"
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04 { AbortedCommand }
de: failed opcode was: 0xec
Is present on all kernels that I have locally (oldest 2.6.11.11)
so it is not related to the threadstarters problems, it seems.
Doing a "hdparm -I /dev/hdc" (without a disk/with a ISO disk/[u]mounted/music
CD):
Aug 14 19:14:33 sleipner kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Aug 14 19:14:33 sleipner kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Aug 14 19:14:33 sleipner kernel: ide:
Doing a hdparm -I /dev/hdc (without a disk/with a ISO disk/[u]mounted/music
CD):
Aug 14 19:14:33 sleipner kernel: hdc: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Aug 14 19:14:33 sleipner kernel: hdc: drive_cmd: error=0x04 { AbortedCommand }
Aug 14 19:14:33 sleipner kernel: ide:
The hdparm -I /dev/hdc
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04 { AbortedCommand }
de: failed opcode was: 0xec
Is present on all kernels that I have locally (oldest 2.6.11.11)
so it is not related to the threadstarters problems, it seems.
On 2005-08-14 20:10:49 Nick Warne wrote:
Note the last sentence:
' This variation is designed for use with libraries of drive
identification information, and can also be used on ATAPI drives which may
give media errors with the standard mechanism.
My jaw just clonked on the table. And
On Mon, 15 Aug 2005 01:37:08 +0100 Alan Cox wrote:
We certainly could interpret 0x51, 0x04 specifically. Its not an error
in the usual spew at the user case generally speaking but a do this
no sequence. Its useful to log because sending unknown commands to an
IDE device is something we want
On Tue, 26 Jul 2005 15:14:39 +0200 Vojtech Pavlik wrote:
> This almost looks like a regular Athlon 64, not even the mobile
> version. I wouldn't expect very big deep sleep capabilities on that
> one. You can check the
>
> /proc/acpi/processor/CPU1/power
>
> file for the list of C states.
On 2005-07-26 5:23:08 Len Brown wrote:
>than C1 and the generic ACPI code doesn't support it,
>then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)
The issue has made me fume enough to contemplating installing windos for
the first time in some 10 years. But I'll persevere. Will
On 2005-07-26 5:23:08 Len Brown wrote:
than C1 and the generic ACPI code doesn't support it,
then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)
The issue has made me fume enough to contemplating installing windos for
the first time in some 10 years. But I'll persevere. Will learn
On Tue, 26 Jul 2005 15:14:39 +0200 Vojtech Pavlik wrote:
This almost looks like a regular Athlon 64, not even the mobile
version. I wouldn't expect very big deep sleep capabilities on that
one. You can check the
/proc/acpi/processor/CPU1/power
file for the list of C states. A
On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
> will not help. It seems like your machine is simply not able to do
> reasonable powersaving.
Digging up this patch from last month regarding C2 on a AMD K7 implies
that the whole blame can be put on kernel acpi:
On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
> Okay, if you have no C2/C3 like the dump above shows, unloading usb
> will not help. It seems like your machine is simply not able to do
> reasonable powersaving.
Because of the CPU, ACPI implementation or because of kernel acpi
quality,
On Fri, 22 Jul 2005 16:48:55 +0200 Pavel Machek wrote:
[...]
...Jesper Juhl wrote
> > Ok, so with an idle machine, different HZ makes no noticeable
> > difference, but I'd suspect things would be different if the machine
> > was actually doing some work.
> > Would be more interresting to see
On Fri, 22 Jul 2005 16:48:55 +0200 Pavel Machek wrote:
[...]
...Jesper Juhl wrote
Ok, so with an idle machine, different HZ makes no noticeable
difference, but I'd suspect things would be different if the machine
was actually doing some work.
Would be more interresting to see how long
On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
Okay, if you have no C2/C3 like the dump above shows, unloading usb
will not help. It seems like your machine is simply not able to do
reasonable powersaving.
Because of the CPU, ACPI implementation or because of kernel acpi
quality,
On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote:
will not help. It seems like your machine is simply not able to do
reasonable powersaving.
Digging up this patch from last month regarding C2 on a AMD K7 implies
that the whole blame can be put on kernel acpi:
On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote:
> 2005/7/21, Voluspa <[EMAIL PROTECTED]>:
> >
> > 2h48m at 100 HZ
> > 2h48m at 250 HZ
> > 2h47m at 1000 HZ
>
> Now, what would be interesting is to see if the lack of differences
> comes f
On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote:
> On 7/21/05, Voluspa <[EMAIL PROTECTED]> wrote:
[...]
> >
> Ok, so with an idle machine, different HZ makes no noticeable
> difference, but I'd suspect things would be different if the machine
> was actually doing som
On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote:
On 7/21/05, Voluspa [EMAIL PROTECTED] wrote:
[...]
Ok, so with an idle machine, different HZ makes no noticeable
difference, but I'd suspect things would be different if the machine
was actually doing some work.
I first thought about
On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote:
2005/7/21, Voluspa [EMAIL PROTECTED]:
2h48m at 100 HZ
2h48m at 250 HZ
2h47m at 1000 HZ
Now, what would be interesting is to see if the lack of differences
comes from the fact that the processor has enough time to sleep
On Thu, 17 Mar 2005 05:06:23 +0100 Voluspa wrote:
Went back to 2.6.10 and just got one of those dma_timer_expiry freezes.
Seems the disk is on the blink then. Sorry about the noise.
Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Thu, 17 Mar 2005 05:06:23 +0100 Voluspa wrote:
some junk
Went back to 2.6.10 and just got one of those dma_timer_expiry freezes.
Seems the disk is on the blink then. Sorry about the noise.
Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
At 2005-03-15 0:28:59 linux-os wrote:
> But when it is on a system that is booting from a real drive, I get
> the following errors, each one taking 15 seconds to time-out.
I'm getting these freezes (timeouts) sporadicly on a normal IDE system
during normal runtime. Ext2 file system, no pattern
At 2005-03-15 0:28:59 linux-os wrote:
But when it is on a system that is booting from a real drive, I get
the following errors, each one taking 15 seconds to time-out.
I'm getting these freezes (timeouts) sporadicly on a normal IDE system
during normal runtime. Ext2 file system, no pattern
Out of the blue came a screen freeze. Opera browser froze, window
manager froze (not X or mouse) but gkrellm system monitor was alive and
showing no irregular activity. The freeze lasted less than a minute.
It resembled nothing I've ever seen before. Kernel log has the following
entry:
Mar 3
Out of the blue came a screen freeze. Opera browser froze, window
manager froze (not X or mouse) but gkrellm system monitor was alive and
showing no irregular activity. The freeze lasted less than a minute.
It resembled nothing I've ever seen before. Kernel log has the following
entry:
Mar 3
>This time it's really supposed to be a quickie, so people who can,
>please check it out, and we'll make the real 2.6.11 asap.
Out of diskspace on kernel.org?
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
[...]
patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
This time it's really supposed to be a quickie, so people who can,
please check it out, and we'll make the real 2.6.11 asap.
Out of diskspace on kernel.org?
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
[...]
patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
32 matches
Mail list logo
