Bug#463487: Kernel 2.6.22 hangs at boot (hardware-software prob.)
Package: linux-image-2.6.22
Version: 2.6.22-3-486
After I installed a used suspect hard-drive which has a bad history, I
booted from another drive. It hung just after the line:
checking if image is initramfs... it is
It hung at the same place when I tried to boot from the suspect drive.
It did the same when I removed the suspect hard drive and tried
booting from the good drive. But after waiting for about an hour, it
booted OK under these same conditions. Before this it booted OK from
a floppy and a memory test (couldn't test all of it) showed all OK.
Now the suspect hard-drive was removed from my PC about a month ago to
fix a problem of the PC (an old Pentium I) shutting down by itself
once in a while (every several hours, etc.). This problem started
after I replaced the power supply with a "better" used one. Thus the
suspect HD may draw too much current, etc. and cause lower voltages as
well as trip the overload protection built into the power supply.
However, it's likely not just a hardware problem since others on the
Internet have reported a hang at the same place in the boot sequence.
See Ubuntu bug #155278. I think it's a race condition that happens if
the hardware is somewhat degraded in some way. Also, I've noticed a
long pause of a few seconds after this initramfs... message and think
that something wrong is going on at this point.
David Lawyer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365266: Kernel 2.6.15 probes ide0 after being told there is no ide0
Package: linux-image-2.6.15-1-486 Version: 2.6.15-8_i386 While booting version 2.6.15 on a Pentium 1, there is a long pause while the kernel probes ide0. There is no such pause in version 2.6.12. The kernel command line has: hda=none, hdb=none and ide0=none so it should know there is no ide0 (mine failed after I plugged in the HD cable reversed by mistake). Also, from the resume message it seems to have crashed while probing. Here's an excerpt from dmesg with my comments after **: Linux version 2.6.15-1-486 (Debian 2.6.15-8) ([EMAIL PROTECTED]) (gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)) #2 Mon Mar 6 15:19:16 UTC 2006 [snip] Kernel command line: auto BOOT_IMAGE=Linux-2.6.15 ro root=1602 plip=timid root=/dev/hdc2 ide0=none hda=none hdb=none [snip] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIXa: IDE controller at PCI slot :00:07.0 ** This device is actually the PCI-ISA bridge as is shown by lspci -v **:00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] **(rev 02) ** Flags: bus master, medium devsel, latency 0 ** **:00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE **[Triton I] (rev 02) (prog-if 80 [Master]) ** Flags: bus master, medium devsel, latency 64 ** I/O ports at ffa0 ** PIIXa: chipset revision 2 PIIXa: bad irq (0): will probe later PIIXa: neither IDE port enabled (BIOS) PIIXb: IDE controller at PCI slot :00:07.1 PIIXb: chipset revision 2 PIIXb: not 100% native mode: will probe irqs later ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio ** My BIOS is old and doesn't know about DMA Probing IDE interface ide1... **Why doesn't it probe ide0 first? It may know that there's no ide0 **so it starts by probing ide1 hdc: QUANTUM FIREBALL EX3.2A, ATA DISK drive hdd: Maxtor 90340D2, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 hdc: max request size: 128KiB hdc: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, (U)DMA hdc: cache flushes not supported hdc: hdc1 hdc2 hdc3 hdd: max request size: 128KiB hdd: 6640704 sectors (3400 MB) w/512KiB Cache, CHS=6588/16/63, (U)DMA hdd: cache flushes not supported hdd: hdd1 hdd2 hdd3 **this is where it pauses for a long time Attempting manual resume [snip] --- Strange. The message about probing ide0 is now missing. But from the logs I found this and similar messages, differing only in time: Apr 19 08:03:51 davespc kernel: hdd: hdd1 hdd2 hdd3 Apr 19 08:03:51 davespc kernel: Probing IDE interface ide0... Apr 19 08:03:51 davespc kernel: Attempting manual resume Also, in the past, I didn't see the "Probing ... ide0" displayed on the screen while booting but found it in dmesg. What does "Attempting manual resume" mean? Did the program crash trying to probe ide0? Now here's what happens with 2.6.12. It works OK with no long pause. --- Linux version 2.6.12-1-386 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:41:08 JST 2005 [snip] Kernel command line: BOOT_IMAGE=Linux-2.6.12 ro root=1602 plip=timid root=/dev/hdc2 ide0=none hda=none hdb=none [snip] Freeing unused kernel memory: 236k freed ide_setup: ide0=none -- BAD OPTION ide_setup: hda=none ide_setup: hdb=none **Good. ide_setup gets the command-line options Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 **Same Revision as for bad 2.6.15 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NET: Registered protocol family 1 Capability LSM initialized PIIXa: IDE controller at PCI slot :00:07.0 **Same mistaken identity of this PCI function PIIXa: chipset revision 2 PIIXa: bad irq (0): will probe later PIIXa: neither IDE port enabled (BIOS) PIIXb: IDE controller at PCI slot :00:07.1 PIIXb: chipset revision 2 PIIXb: not 100% native mode: will probe irqs later ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide1... hdc: QUANTUM FIREBALL EX3.2A, ATA DISK drive hdd: Maxtor 90340D2, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide0... ide2: I/O resource 0x3EE-0x3EE not free. ide2: ports already in use, skipping probe Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hdc: max request size: 128KiB hdc: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, (U)DMA hdc: cache flushes not supported /dev/ide/host1/bus1/target0/lun0: p1 p2 p3 hdd: max request size: 128KiB hdd: 6640704 sectors (3400 MB) w/512KiB Cache, CHS=6588/16/63, (U)DMA hdd: cache flushes not supported /dev/ide/host1/bus1/target1/lun0: p1 p2 p3 [snip] **Note there is no probing for ide0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409011: When booting: 38 sec. delay at "Attempting manual resume"
Package: linux-image-2.6.17-2-486 Version: 2.6.17-9_i386 Please merge my bug report 365266 into this as they are at least partially the same bug. When I submitted the 365266 bug report I thought that the delay in booting was due to probing ide0 which is broken on my PC. But now it doesn't seem to probe ide0 anymore but the delay still exists. Here's from dmesg at the point of delay. Note that I've put "debug" and "time" on the kernel command line (using lilo). [ 46.324557] hdd: cache flushes not supported [ 46.325131] hdd: hdd1 hdd2 hdd3 [ 84.007425] Attempting manual resume [ 84.353163] kjournald starting. Commit interval 5 seconds What is going on? "resume" must mean resume from a suspend, but there is no suspend in dmesg. The "Attempting manual resume" message is found in /linux-2.6.x/kernel/power/disk.c in the function resume_store(). I don't have source code on my PC but found it on the Internet at: http://www.gelato.unsw.edu.au/lxr/source/kernel/power/disk.c#L12 According to this site, the function name that issues this message (resume_store) only appears in the definition of this function, In other words the function is defined but never used (if this site indexing is correct). cat /sys/power/resume results in 22:67 which is hdd3, the swap partition on my "backup" drive. Apparently the image being restored comes from there and it happens just after hdd3 prints in the dmesg output. Yet I don't see S1SUSPEND on hdd3 which is the SWSUSP_SIG (sinature). There is a document, swsusp, in the power directory of the kernel documentation and it says that it's not good to use suspend if the ide driver is a module (as it is with this package). But is suspend being used at all? David Lawyer --- Here's the output of dmesg for my Pentium I PC. There are several other places where there is excessive delay but those will be the subject of future bug reports. Linux version 2.6.17-2-486 (Debian 2.6.17-9) ([EMAIL PROTECTED]) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 Wed Sep 13 15:56:30 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0010 - 0300 (usable) BIOS-e820: fffc - 0001 (reserved) 48MB LOWMEM available. On node 0 totalpages: 12288 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 8192 pages, LIFO batch:1 DMI not present or invalid. ACPI: Unable to locate RSDP Allocating PCI resources starting at 1000 (gap: 0300:fcfc) Built 1 zonelists Kernel command line: auto BOOT_IMAGE=Linux2.6.17hdc ro plip=timid root=/dev/hdc2 ide0=noprobe hda=none hdb=none acpi=none debug time [17179569.184000] No local APIC present or hardware disabled [17179569.184000] mapped APIC to d000 (01061000) [17179569.184000] Initializing CPU#0 [17179569.184000] PID hash table entries: 256 (order: 8, 1024 bytes) [0.00] Detected 99.730 MHz processor. [ 26.819180] Using tsc for high-res timesource [ 26.820993] Console: colour VGA+ 80x25 [ 26.823420] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 26.824536] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 26.850290] Memory: 41704k/49152k available (1456k kernel code, 7040k reserved, 566k data, 252k init, 0k highmem) [ 26.850547] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 26.930830] Calibrating delay using timer specific routine.. 200.13 BogoMIPS (lpj=400265) [ 26.931668] Security Framework v1.0.0 initialized [ 26.931853] SELinux: Disabled at boot. [ 26.931999] Capability LSM initialized [ 26.932366] Mount-cache hash table entries: 512 [ 26.934600] CPU: After generic identify, caps: 01bf [ 26.935222] CPU: After vendor identify, caps: 01bf [ 26.935758] Intel Pentium with F0 0F bug - workaround enabled. [ 26.935894] [ 26.935994] CPU: After all inits, caps: 01bf [ 26.936690] CPU: Intel Pentium 75 - 200 stepping 06 [ 26.936960] Checking 'hlt' instruction... OK. [ 26.951054] SMP alternatives: switching to UP code [ 26.951195] Freeing SMP alternatives: 0k freed [ 26.954201] checking if image is initramfs... it is [ 37.801654] Freeing initrd memory: 4070k freed [ 37.807719] NET: Registered protocol family 16 [ 37.808617] EISA bus registered [ 37.814229] PCI: PCI BIOS revision 2.10 entry at 0xfd121, last bus=0 [ 37.814379] Setting up standard PCI resources [ 37.830991] ACPI: Subsystem revision 20060127 [ 37.831135] ACPI: Interpreter disabled. [ 37.831264] Linux Plug and Play Support v0.97 (c) Adam Belay [ 37.831695] pnp: PnP ACPI:
Bug#296687: Parallel port too fast for old printer
Package: kernel-image-2.6.8-1-386_2.6.8-3.1_i386.deb Version: NA I'm using a 23-year-old NEC 3530 Spinwriter printer with a parallel port interface (most of them were serial, which work OK with Linux). It works fine with kernel version 2.2.20. For kernel 2.4.26, if I type: cat "This is a test" > /dev/lp0, it prints "his is a testt". In other words the first strobe somehow misses the 1st byte but gets the second byte. For my 2.6 kernel version, at first I couldn't get it to print at all. But then I gave the option dma=none, etc. to the parport_pc module and then it would erratically print about half of what cat sent to the printer. Sometimes it would do no more than a linefeed. What I think is happening is that the parport_pc driver is sending too fast for the printer. The driver may not be doing handshaking right. My PC parallel port is a fast ECP one, but the printer parallel port it connects to is just a 23-year-old Centronics: SPP. So the driver should wait for ACK after each byte before sending the next byte. Does it? My printer manual shows the protocol and timings expected. It shows about 10 us between the start of adjacent bytes. Since the printer takes 20,000 us to print a character (50 chars/sec.) the 10 us spacing is 2,000 times faster than needed. My timing diagram show the next byte being sent to the printer about 1us after the end of the ACK pulse. The timing diagram also shows that BUSY is not asserted until the 512 bytes printer buffer is almost full. It doen't get asserted when recieving a byte as was claimed by someone on the Internet. There was no problem with using an old NEC serial printer since one just sets the serial speed for 600 baud. But I can't use it anymore since it broke. Since the serial driver works OK for old serial ports, shouldn't the parallel port driver do likewise? David Lawyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296687: More info on Parallel Port bug
I looked at:
URL: http://www.ibiblio.org/peanut/Kernel-2.6.10/parport.txt
Then in 2.6 I checked up on my parallel port in
/proc/sys/dev/parport/parport0 and looked at the "modes" file per the
above. It shows: PCSPP,TRISTATE,COMPAT,ECP. It doesn't show DMA since
I've disabled it by dma=none as an option to the parport_pc module.
According to the document at ibiblio, this means that all these mode are
being used. Before disabling DMA, it was being used to. Also dmesg
shows that FIFO is apparently being used too.
This is definitely wrong. Since my ECP port is connected by a cable to
a 25-year-old legacy parallel port on my printer, the ECP port must
operate in the old SPP mode and not in any of the other advanced modes.
This may be the cause of the problem. The original mode requires that the
driver do the handshaking, but in the ECP mode the hardware does it and
the cable control lines are used for different purposes (the pinout
changes). So I now suspect that the problem is that the wrong modes are
used on the port.
Now if both ends of the parallel cable were connected to ECP ports, all
would work OK. So Linux needs to detect what kind of port is on the
other end of the cable. Note that my printer is not on at boot-time so
there's no way to probe it then. Perhaps a module option is needed to
tell the driver what the capabilities are of the other parallel port.
David Lawyer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296687: Problem Fixed
I fixed the problem by setting the parallel port in the BIOS from ECP to SPP. Then the driver does software handshaking and my old printer works OK. So this is a problem with documentation. I just emailed the authors of the kernel docs on the parallel port and told them about this fix. So you could close this bug if you want to, although it would be nice if somehow the software configured it all. David Lawyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296687: Problem Fixed
On Tue, Mar 01, 2005 at 11:55:42AM +0900, Horms wrote: > On Fri, Feb 25, 2005 at 12:07:20AM -0800, David Lawyer wrote: > > I fixed the problem by setting the parallel port in the BIOS from ECP to > > SPP. Then the driver does software handshaking and my old printer works > > OK. So this is a problem with documentation. I just emailed the > > authors of the kernel docs on the parallel port and told them about this > > fix. So you could close this bug if you want to, although it would be > > nice if somehow the software configured it all. > > Hi David, > > are you suggesting that there should be a kernel option > to restrict the modes that the parallel port driver will > operate in - so that if you have older hardware it will only > use modes supported by the other end. Or are you suggesting > that the driver should autodetect this somehow. My knowledge > of the relevant specs are weak (non-existant), but the latter > sounds like it might not be possible. I think the latter may be possible if one has a modern (not over 20 years old) parrallel port on their PC (like I do). There's a spec for negotiation between the two ports over the parallel cable. In my case, there would be no response from my printer and it would then be assumed by my PC that the printer port doesn't meet IEEE 1284 specs and thus use the old Centronics protocol known as SPP. But I don't know how the port tells that to Linux. The old protocol requires driver handshaking for every byte sent. I think that the BIOS allows setting SPP for cases where the software doesn't know about ECP. Since Linux knows about ECP and since ECP can fallback to SPP mode, it should have worked in ECP mode. So I now think it's a bug and needs to be fixed even though I found a work around to get my printer printing. > In any case, have you considered reporting this to LKML and > the maintainers? How do I do this? > -- > Horms > David Lawyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#257542: Kernel panics when cdrom mounted
Package: kernel-image-2.6.6-1-386
Version: -1
When I try to mount my old cdrom, it hesitates for a while and then
Linux crashes with the following message on the bottom of the screen:
Kernel panic: Fatal exception in interrupt In interrupt handler - not
syncing
This is repeatable. But it doesn't happen in kernel-image-2.4-586tsc.
There are also a lot of other message lines above the panic message such
as cdrom_start ... but I didn't copy them down. In fact, many of them had
scrolled off the screen.
Here's the data on my cdrom using hdparm -I :
/dev/hdc:
ATAPI CD-ROM, with removable media
Model Number: FX600S
Serial Number:
Firmware Revision: P01
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: <=10ms with INTRQ
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 256.0kB
DMA: *sdma0 *sdma1 *sdma2 *mdma0 *mdma1 (?)
Cycle time: min=150ns recommended=230ns
PIO: pio0 pio1 pio2 pio3
Cycle time: no flow control=230ns IORDY flow control=180ns
I think there are two problems here. One is that I don't think the
kernel should crash due to cdrom driver problems. The second is the
problem with the cdrom driver itself.
If I run "dcd" for playing a CD recording, it works OK even though there
are some error messages. Here are boot-time messages for kernel 2.4:
Jul 2 15:05:20 davespc1 kernel: hdc: FX600S, ATAPI CD/DVD-ROM drive
Jul 2 15:05:20 davespc1 kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jul 2 15:05:20 davespc1 kernel: hdc: attached ide-cdrom driver.
Jul 2 15:05:20 davespc1 kernel: hdc: ATAPI 6X CD-ROM drive, 256kB Cache, DMA
Jul 2 15:05:20 davespc1 kernel: Uniform CD-ROM driver Revision: 3.12
Jul 2 15:05:20 davespc1 kernel: hdc: DMA interrupt recovery
Jul 2 15:05:20 davespc1 kernel: hdc: cdrom_decode_status: status=0xd0 { Busy }
Jul 2 15:05:20 davespc1 kernel: hdc: cdrom_decode_status:
error=0xd0LastFailedSense 0x0d
Jul 2 15:05:20 davespc1 kernel: hdc: DMA disabled
--
Note that DMA was disabled by the above, enabling the cdrom to work OK.
DMA here really means bus mastering DMA and not the obsolete mdma
(Multi-Word DMA) or sdma (Single-Word DMA) supported by the physical
cdrom. Also note the CD driver is 3.12 (3.20 is used for kernel 2.6).
Here's selected messages from dmesg, also for 2.4. It shows about the
same as above.
Linux version 2.4.26-1-586tsc ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian
20040401)) #1 Sat May 1 16:46:38 EST 2004
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide: late registration of driver.
PIIX4: IDE controller at PCI slot 00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hdc: FX600S, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: attached ide-cdrom driver.
hdc: ATAPI 6X CD-ROM drive, 256kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command
hdc: DMA interrupt recovery
hdc: lost interrupt
hdc: cdrom_decode_status: status=0xd0 { Busy }
hdc: cdrom_decode_status: error=0xd0LastFailedSense 0x0d
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command
Here's a couple of messages for 2.6, but I think it happened when I
tried to mount the cdrom as I didn't find it in dmesg:
Jul 2 14:33:49 davespc1 kernel: hdc: ATAPI 6X CD-ROM drive, 256kB Cache, DMA
Jul 2 14:33:49 davespc1 kernel: Uniform CD-ROM driver Revision: 3.20
Note that the driver is 3.20 while the driver I use in kernel 2.4 is
3.12. Perhaps this difference account for the different behavior. Is
there a way to capture the kernel messages just prior to the kernel
panic message?
David Lawyer
Bug#434571: Module snd-sb16 set interrupts wrong
Package: linux-image Version: 2.6.21-2 I have the Sound Blaster 16 OEM card CT1790 which I have mainly used to play CDs thru. It has jumpers to set IRQs and it's set at irq2. I seem to only be able to get it to work OK at irq5 which is the default for the card. Except that my Modem is on irq 5. That's why I set the jumper to irq2. Now the card, while not PnP, can have it's interrupts set by software (by Linux software ?). Well, yes, because when I load the snd-sb16 module for it and specify irq=2 I find from /proc/interrupts that it's been set to irq 5 and the sound card works OK (at least with .wav files). So the linux software must have changed the irq 2 (that I jumpered) to irq 5. This happens when I haven't used my modem yet and irq 5 is still available. But now I can't use my modem. If I remove the module, irq 5 is available (per /proc/int*) and the modem will grab irq 5 and try to dial. But I get all sorts of errors due the the shorting out of the irq 5 line by the sound card since irq 5 is still set in the sound card even though the sound card module has been removed and irq 5 has been released by the kernel. My sound card is working right since it's sending 0 volts (a grounded line --actually low impedance) on the irq 5 line to indicate that it isn't sending any interrupts. So the kernel needs to have a list of resources that exist in hardware but are not currently supported by any loaded module, or the like. Once the interrupt has been changed to 5, the only way I know to get it back to 2 is to power-down (turn off the power) and then boot again. This is not a power-on reboot. Now, if when loading the snd-sb16 module after I start the modem so that irq 5 is in use with irq=2 on the command line, /proc/int* does show that irq 9 is for SoundBlaster (since irq 2 and 9 are really the same irq). OK so far but irq 9 is never sent by the sound-card when I try to use it, although the module is apparently listening for it. Nor is irq 5 sent either as may be checked by starting the modem and checking the number of interrupts sent per /proc/int* after trying to play a .wav file. Playing a .wav file only plays the first couple of words since apparently no interrupts are sent. So it seems to me that the snd-sb16 module may not be able to change the interrupts except perhaps to reset the card so that the default irq 5 is set it the card, overriding what may be set by jumpers. If the driver has such limitations, they need to be either fixed or documented. David Lawyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365266: Kernel 2.6.15 probes ide0 after being told there is no ide0
On Fri, Dec 26, 2008 at 11:31:50AM +0100, Moritz Muehlenhoff wrote: > On Fri, Apr 28, 2006 at 02:39:02PM -0700, David Lawyer wrote: > > Package: linux-image-2.6.15-1-486 > > Version: 2.6.15-8_i386 > > > > While booting version 2.6.15 on a Pentium 1, there is a long pause > > while the kernel probes ide0. There is no such pause in version > > 2.6.12. The kernel command line has: hda=none, hdb=none and ide0=none > > so it should know there is no ide0 (mine failed after I plugged in the > > HD cable reversed by mistake). Also, from the resume message it seems > > to have crashed while probing. Here's an excerpt from dmesg with my > > comments after **: > > Does this error still occur with more recent kernel versions? No. I think it's been fixed for about a year now. > > Cheers, > Moritz > David Lawyer -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599373: Installing kernel changes hard drive hda to sda, etc.
Package: linux-image Version: 2.6.32-5-486 Installing this updated kernel (my old one was 2.6.30) changed my hard drive designations in /dev from hdxx to sdxx. For example hda2 became sda2. There was no warning that this was happening. Now sda2 is supposed to be a SATA drive and mine are ATA (non-serial) drives. I guess they now still work OK but I should have gotten some notice or explanation of the name change. Do I need to put the sd notation in lilo.conf? The installation recommended that I should use the UUID designation for harddrives. I responded OK and now my /etc/fstab table is nearly impossible to read since the UUID device numbers are so long that they take up almost an entire line on the screen, so other data on the line wraps over to the next line. Can they be replaced with sd.. ? I manually modify the /etc/fstab table from time to time and need to keep it simple like it was before it was messed up with long UUIDs. David Lawyer -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006235557.ga2...@davespc
Bug#855003: ATA HD race conditions at boot-time
Package: linux-image-686-pae
Version: 4.9.0-1
When I booted my PC it hung at one point for 30 seconds and then resumed
booting. Here's part of the dmesg for it. Note that it happened 17 seconds
into the boot.
:
[0.00] Linux version 4.9.0-1-686-pae (debian-kernel@lists.debian.org)
(gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2
(2017-01-12)
http://www.smythies.com/~doug/network/hd_race/";>Linux ata hard disk
access race condition. WWW.Smythies.com
This error doesn't repeat so I think it's a race condition. The SATA
drive is one I installed about a couple of months ago and may have booted the PC
with it perhaps 60 times with no delay like this. However, I upgraded the
kernel to -pae perhaps a couple of weeks ago. There are now 2 HD's on my
PC, one SATA (ata30) and the other a slower PATA with a ribbon cable.
David Lawyer
