Re: Linux-2.6.13-rc7
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 acpi-hotkey.txt will face the wall first. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CD problems in 2.6.13rc6
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 to catch (some drives hang if you do it, > others do really *crazy* things). > > Would > > hdc: command not supported by drive > ide: failed opcode was: 0xec > > have been more helpful If it was clearly marked as "This is INFO, not a Warning". Most users I've met (myself included) are always expecting their hardware to crash and burn at the drop of a hat. Scary messages just confirm our anguish - especially when it's coming by way of the CD/HD system. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CD problems in 2.6.13rc6
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 the media error at hand made you
buy a new CD-RW. There is precedence for this (remember the blaming X and
other programs in the keyboard driver?) so perhaps the kernel people could
amend the error like:
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec
ide: Did you just run "hdparm -I" or do you use a nosy desktop?
Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CD problems in 2.6.13rc6
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.
root:sleipner:~# hdparm -I /dev/hdc
/dev/hdc:
ATAPI CD-ROM, with removable media
Model Number: TSSTcorpCD/DVDW TS-L532A
Serial Number: 254A204626
Firmware Revision: TI50
Standards:
Used: ATAPI for CD-ROMs, SFF-8020i, r2.5
Supported: CD-ROM ATAPI-2
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 2048.0kB
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*NOP cmd
*DEVICE RESET cmd
*PACKET command feature set
*Power Management feature set
*Mandatory FLUSH CACHE command
HW reset results:
CBLID- above Vih
Device num = 0 determined by CSEL
root:sleipner:~# hdparm -i /dev/hdc
/dev/hdc:
Model=TSSTcorpCD/DVDW TS-L532A, FwRev=TI50, SerialNo=254A204626
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=2048kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
Drive conforms to: Reserved:
* signifies the current active mode
root:sleipner:~# hdparm /dev/hdc
/dev/hdc:
IO_support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
HDIO_GETGEO failed: Invalid argument
root:sleipner:~# grep VIA /usr/src/testing/my-2.6.13-rc6-.config
[edited]
CONFIG_BLK_DEV_VIA82CXXX=y
root:sleipner:~# grep IDE /usr/src/testing/my-2.6.13-rc6-.config
[edited]
# CONFIG_PARIDE is not set
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
# Please see Documentation/ide.txt for help/info on IDE drives
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# IDE chipset support/bugfixes
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CD problems in 2.6.13rc6
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: failed opcode was: 0xec
"hdparm -i /dev/hdc" does not interfere (hdparm v6.1) and normal access like
copying,
burning, playing etc works without that message emerging. Though I have seen it
once...
During a session of quick mount/umount/play video file of several disks, there
it was.
I attributed it to bad media.
This is a VIA motherboard (AMD64 equipped) and I run without any desktop:
root:sleipner:~# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: PCI device 1106:0204 (VIA Technologies, Inc.) (rev 0).
Master Capable. Latency=8.
Prefetchable 32 bit memory at 0xd000 [0xdfff].
Bus 0, device 0, function 1:
Host bridge: PCI device 1106:1204 (VIA Technologies, Inc.) (rev 0).
Bus 0, device 0, function 2:
Host bridge: PCI device 1106:2204 (VIA Technologies, Inc.) (rev 0).
Bus 0, device 0, function 3:
Host bridge: VIA Technologies, Inc. K8M800 (rev 0).
Bus 0, device 0, function 4:
Host bridge: PCI device 1106:4204 (VIA Technologies, Inc.) (rev 0).
Bus 0, device 0, function 7:
Host bridge: VIA Technologies, Inc. K8M800 (rev 0).
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] (rev 0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 10, function 0:
Ethernet controller: Linksys, A Division of Cisco Systems [AirConn]
INPROCOMM IPN 2220 Wireless LAN Adapter (rev 01) (rev 0).
IRQ 10.
Master Capable. Latency=64. Min Gnt=32.Max Lat=32.
I/O at 0x1c00 [0x1c1f].
Non-prefetchable 32 bit memory at 0xc0006000 [0xc000601f].
Non-prefetchable 32 bit memory at 0xc0005000 [0xc00057ff].
Bus 0, device 11, function 0:
CardBus bridge: Texas Instruments PCI7420 CardBus Controller (rev 0).
IRQ 16.
Master Capable. Latency=64. Min Gnt=192.Max Lat=3.
Non-prefetchable 32 bit memory at 0x8802 [0x88020fff].
Bus 0, device 11, function 1:
CardBus bridge: Texas Instruments PCI7420 CardBus Controller (#2) (rev 0).
IRQ 17.
Master Capable. Latency=64. Min Gnt=192.Max Lat=3.
Non-prefetchable 32 bit memory at 0x88021000 [0x88021fff].
Bus 0, device 11, function 2:
FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port
PHY/Link-Layer Controller (rev 0).
IRQ 11.
Master Capable. Latency=64. Min Gnt=2.Max Lat=4.
Non-prefetchable 32 bit memory at 0xc0005800 [0xc0005fff].
Non-prefetchable 32 bit memory at 0xc000 [0xc0003fff].
Bus 0, device 12, function 0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet (rev 16).
IRQ 19.
Master Capable. Latency=64. Min Gnt=32.Max Lat=64.
I/O at 0x1000 [0x10ff].
Non-prefetchable 32 bit memory at 0xc0006400 [0xc00064ff].
Bus 0, device 16, function 0:
USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
(rev 128).
IRQ 18.
Master Capable. Latency=64.
I/O at 0x1c20 [0x1c3f].
Bus 0, device 16, function 1:
USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
(#2) (rev 128).
IRQ 18.
Master Capable. Latency=64.
I/O at 0x1c40 [0x1c5f].
Bus 0, device 16, function 2:
USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
(#3) (rev 128).
IRQ 18.
Master Capable. Latency=64.
I/O at 0x1c60 [0x1c7f].
Bus 0, device 16, function 3:
USB Controller: VIA Technologies, Inc. USB 2.0 (rev 130).
IRQ 18.
Master Capable. Latency=64.
Non-prefetchable 32 bit memory at 0xc0006800 [0xc00068ff].
Bus 0, device 17, function 0:
ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge (rev 0).
Bus 0, device 17, function 1:
IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C
PIPC Bus Master IDE (rev 6).
Master Capable. Latency=64.
I/O at 0x1c80 [0x1c8f].
Bus 0, device 17, function 5:
Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97
Audio Controller (rev 80).
IRQ 19.
I/O at 0x1400 [0x14ff].
Bus 0, device 17, function 6:
Communication controller: VIA Technologies, Inc. AC'97 Modem Controller
(rev 128).
IRQ 11.
I/O at 0x1800 [0x18ff].
Bus 0, device 24, function 0:
Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration (rev 0).
Bus 0, device 24, function 1:
Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
(rev 0).
Bus 0, device 24, function 2:
Host bridge: Advance
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 normal Athlon64 will likely have only > C0. Mobile chips can go up to C4, which is really deep sleep. You've probably already seen that /proc/acpi/processor/CPU1/power lists C1 only here. Ok, with your input regarding normal CPUs I'm inclined to believe ACPI is correct in my case. Still, I'll learn/read the code. Always have had a need to finish those long marches. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 ACPI-speak, read bios- and kernelcode. Then return, have no fear (even if just to admit that the BIOS is buggy). Speaking of bugs, I was directed, off-list, to the patch which mends your latest chip-away of C2/C3 for many systems: http://marc.theaimsgroup.com/?l=acpi4linux&m=112138186129178&w=2 It did however not fix my K8 system. >I.e. The whole concept of ACPI is that you shoulud _not_ need >a platform specific driver to accomplish this. Indeed. It's supposed to be some kind of neutral non-discrimatory standard... I suppose. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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: http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2 Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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, x86_64 kernel quirks or...? It seems crazy that a modern CPU like this should be so backwards as to not implement sleep states. It being in a notebook and all. I blame intel kernel hackers ;-) Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 it lasts with a light > > load and with a heavy load. > > No, I do not think so. Biggest difference should be on completely idle > machine where ACPI can utilize low power states. > > Can you check that C3 is utilized? Unloading usb modules may be > neccessary... I've been reading/checking up on this the last four hours since I had a nagging suspicion that the CPU indeed didn't enter a sleep state. With all the abbreviations in the ACPI field (S1, C1, P1 etc) it killed a fair amount of brain cells, but I'd still call faul on this: from /var/log/kernel [powernow-k8 module loads processor module which says] ACPI: CPU0 (power states: C1[C1]) and catting /proc/acpi/processor/CPU0/power gives active state: C1 max_cstate: C8 bus master activity: states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[02998796] /sys/module/processor/parameters/max_cstate says 8 /sys/module/processor/parameters/bm_history says 4294967295 So I'm a bit baffled that no C2/C3 turns up. I've done a test-compile with all of ACPI in kernel instead of as modules, but there was no difference. I'll unload the whole USB-module part and boot without loading them, but will it matter? Please provide more details about how to debug this (very confusing) field. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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, > not enough time, or simply it does not matter. > > That is, is it a best case or a worst case ? Those words swished above my head. I'd need serious hand-holding to conduct any further (meaningful) tests. > > > #!/bin/sh > > touch time-hz-start > > while (true) do > > touch time-hz-end > > sleep 1m > > done > > Why this ? > Why not simply nothing ? > A computer can be idle for more than 1 minute ;-) I had other things to do than sit with a stopwatch in my hand staring at a black screen :-) Also, 1 minute is a resonable comparison level. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
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 loading with a loop of md5sum /somedir, play a wav, fetch a couple of webpages etc. But since the talk has been that the powersave would come from CPU sleep between "ticks" (I know, I know, it's not ticks) not having to wake up so often, I decided against a load. > Would be more interresting to see how long it lasts with a light load > and with a heavy load. I won't do that unless heavily beaten ;-) The battery charge time is 2h10 minutes... Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Awful long timeouts for flash-file-system
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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Awful long timeouts for flash-file-system
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 except that it never happens on the hdb disk. On hdc there is a cdrw and hdd a dvd: loke:loke:~$ uname -r 2.6.11 loke:loke:~$ grep dma_timer_expiry /var/log/kernel Mar 3 18:03:01 loke kernel: hda: dma_timer_expiry: dma status == 0x61 Mar 4 19:54:47 loke kernel: hda: dma_timer_expiry: dma status == 0x61 Mar 13 18:52:13 loke kernel: hda: dma_timer_expiry: dma status == 0x61 Mar 15 13:35:10 loke kernel: hda: dma_timer_expiry: dma status == 0x61 Mar 15 19:38:47 loke kernel: hda: dma_timer_expiry: dma status == 0x61 loke:loke:~$ It began with kernel 2.6.11 and I reported it immediately: http://marc.theaimsgroup.com/?l=linux-kernel&m=110987450912711&w=2 Prior to that I was running 2.6.11-rc4 from Feb 13 to Feb 24 and -rc5 from Feb 24 to Mar 3 without these freezes. But perhaps that was too short periods to catch anything. Adding Bartlomiej Zolnierkiewicz to the CC list since it should be in his corner. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11 hda: dma_timer_expiry: dma status == 0x61
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 18:03:01 loke kernel: hda: dma_timer_expiry: dma status == 0x61
Mar 3 18:03:11 loke kernel: hda: DMA timeout error
Mar 3 18:03:11 loke kernel: hda: dma timeout error: status=0x58
{ DriveReady SeekComplete DataRequest }
Mar 3 18:03:11 loke kernel:
Mar 3 18:03:11 loke kernel: ide: failed opcode was: unknown
My drives have thir SMART regularly checked by
smartmontools(.sourceforge.net) and doing a manual run right after this
freeze showed everything to be OK.
Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5
>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 patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248 patch-2.6.11-rc5.gz23-Feb-2005 20:20 37 patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248 patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248 Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
