# UDEV and DMA problems on boot.

## vfox

Hi,

I've got two issues that I need some assistance with. I've browsed through the forums for the last 4 hours and have found nothing that's been able to help me solve them.

On boot i get the following (if i remove the quiet option from my grub.conf):

```

hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78171894, sector=78171894

ide: failed opcode was: unknown

hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78171894, sector=78171894

ide: failed opcode was: unknown

hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=781718794, sector=78171894

ide: failed opcode was: unknown

hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78171894, sector=78171894

ide: failed opcode was: unknown

ide0: reset: success

hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78171894, sector=78171894

ide: failed opcode was: unknown

end_request: I/O error, dev hda, sector 78171894

Adding 506036k swap on /dev/hdb2.  Priority:-1 extents:1

parport: PnPBIOS parport detected.

parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]

eth0: DSPCFG accepted after 0 usec.

eth0: link up.

eth0: Setting full-duplex based on negotiated link capability.

fbsplash: console 0 using theme 'default'

fbsplash: switched splash state to 'on' on console 0

fbsplash: console 1 using theme 'default'

fbsplash: switched splash state to 'on' on console 1

fbsplash: console 2 using theme 'default'

fbsplash: switched splash state to 'on' on console 2

fbsplash: console 3 using theme 'default'

fbsplash: switched splash state to 'on' on console 3

fbsplash: console 4 using theme 'default'

fbsplash: switched splash state to 'on' on console 4

fbsplash: console 5 using theme 'default'

fbsplash: switched splash state to 'on' on console 5

fbsplash: console 6 using theme 'default'

fbsplash: switched splash state to 'on' on console 6

fbsplash: console 7 using theme 'default'

fbsplash: switched splash state to 'on' on console 7

fbsplash: console 8 using theme 'default'

fbsplash: switched splash state to 'on' on console 8

fbsplash: console 9 using theme 'default'

fbsplash: switched splash state to 'on' on console 9

fbsplash: console 10 using theme 'default'

fbsplash: switched splash state to 'on' on console 10

eth0: no IPv6 routers present
```

That's the output of #cat dmesg

My hdb looks like this.

```

/hda1-  XP (NTFS)

/hdb1 - NTFS (extra storage for xp)

/hdb2 - linux swap

/hdb3 - Boot partition (reiserfs)

/hdb4 - Root partition (reiserfs)

```

So now I'm wondering why something is trying to access my winxp drive.

My grub.conf looks like this:

```

timeout 3

# By default, boot the first entry.

default 2

# Fallback to the second entry.

fallback 1

splashimage=(hd1,2)/grub/splash.xpm.gz

# For booting GNU/Linux

title Gentoo-2.6.12-r9

root (hd1,2)

kernel (hd1,2)/vmlinuz quiet ro root=/dev/hdb4 

#splash=verbose,fadein,theme:livecd-2005.1 quiet CONSOLE=/dev/tty1

#initrd (hd1,2)/fbsplash-livecd-2005.1-1280x1024

title Gentoo-2.6.12-r9.old

root (hd1,2)

kernel (hd1,2)/vmlinuz.old quiet ro root=/dev/hdb4

title WinXp

root (hd0,0)

chainloader +1

```

Secondly, I've been attempting to enable DMA on boot but that's not happening. I still get the Warning: DMA is not turned on...blah blah blah. 

I have built in support for my Intel chipset in the kernel as I've seen on other threads. But I'm still lost on to why it's not "enabling."

Any help would be greatly appreciated. Thanks   :Very Happy: 

----------

## NeddySeagoon

vfox,

The system is probing /dev/hda to see whats there. Thats nothing to worry about.

The error messages are a bit alarming. Is it trying to read off the end of the disk ?

Keep your backups up to date. 

What IDE chuip set do you have ?

lspci will show you.

----------

## vfox

This is my lspci output.

```

0000:00:00.0 Host bridge: Intel Corporation 82850 850 (Tehama) Chipset Host Bridge (MCH) (rev 02)

0000:00:01.0 PCI bridge: Intel Corporation 82850 850 (Tehama) Chipset AGP Bridge (rev 02)

0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 04)

0000:00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 04)

0000:00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 04)

0000:00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 04)

0000:00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 04)

0000:00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 04)

0000:01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1)

0000:02:08.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller

0000:02:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)

0000:02:0a.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)

```

I've selected the Intel PIIXN.... as built-in.  Could i be using the wrong one?

----------

## widan

```
hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78171894, sector=78171894

ide: failed opcode was: unknown
```

Does your disk have a host protected area (computers from IBM, Dell, ... often have one for rescue programs ...) ? The kernel will normally detect it, like this:

```
hda: Host Protected Area detected.

current capacity is 71754738 sectors (36738 MB)

native capacity is 78140160 sectors (40007 MB)

hda: Host Protected Area disabled.

hda: 78140160 sectors (40007 MB) w/1740KiB Cache, CHS=65535/16/63, UDMA(100)
```

If you have one, and the error LBA is between the "current" and the "native" capacities, then the kernel likely got confused about the HPA.

 *vfox wrote:*   

> I've selected the Intel PIIXN.... as built-in

 

Normally it's ok for all Intel chipsets.

You should have some lines like this in dmesg (but obviously, with PIIXn at the start):

```
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller

    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA

    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
```

Do they indicate DMA or PIO modes ? If you have DMA there, your chipset is properly configured.

In that case, your problem with DMA can also be caused by the errors on hda. From your dmesg, the kernel gets back some IDE errors, then issues a bus reset on ide0 (in case repeated errors were caused by a confused controller). Usually those bus resets cause the controller to drop DMA on that channel (ide0 = hda and hdb). Could you try booting with hda disconnected from the IDE, and see if the DMA problem still exists ?

----------

## vfox

Booting without /hda wouldn't be an option. Firstly, I know it's worked in the past week. I recently installed gentoo using a stage3 tarball and the genkernel. I found that was a bit too much for my use so I went with a stage 1 tarball and customized the kernel myself. Secondly, I'm too lazy to open the box and install grub on hdb.  :Smile: 

As for this 

 *Quote:*   

> NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
> 
>     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> 
>     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA

 

I have no such line present in the dmesg file. The snippit I put up previously contained the whole file. I just cut out the repeated errors.

 *Quote:*   

> 
> 
> Does your disk have a host protected area (computers from IBM, Dell, ... often have one for rescue programs ...) ? The kernel will normally detect it, like this:
> 
> Code:
> ...

 

I do run on a Dell but I've killed/formatted/maimed my original HD multiple times. I'm pretty sure there's no protected areas on the drive. If there were, how would I find out?

----------

## widan

 *vfox wrote:*   

> I have no such line present in the dmesg file. The snippit I put up previously contained the whole file. I just cut out the repeated errors.

 

The errors are causing the kernel log buffer to overflow, and it drops the old messages. You can change the log buffer size there:

```
Kernel hacking  --->

  [*] Kernel debugging

  (18)  Kernel log buffer size (16 => 64KB, 17 => 128KB)
```

Increase the number, it will double the log buffer size for each step. That way you will be able to get the beginning of the kernel output, where the IDE detection messages are.

 *vfox wrote:*   

> I do run on a Dell but I've killed/formatted/maimed my original HD multiple times. I'm pretty sure there's no protected areas on the drive. If there were, how would I find out?

 

HPAs can survive multiple formats. They are called Host Protected Areas for some reason (they hide part of the disk to the OS, but normally Linux disables those when it finds them), especially when they are put in "secure" mode (where only the BIOS and approved utilities can access the HPA).

You'll know if you have one if you can get the beginning of the kernel messages. When you have a complete dmesg output, look for the lines I posted above. If you have something close to that, you have a HPA.

----------

## vfox

Ok considering the length of my dmesg output now, I've uploaded it so you can have a look at it.

www.impaxt.com/dmesg.txt

Looking through it I found this tidbit of info.

```
ReiserFS: hdb4: found reiserfs format "3.6" with standard journal

ReiserFS: hdb4: using ordered data mode

ReiserFS: hdb4: journal params: device hdb4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30

ReiserFS: hdb4: checking transaction log (hdb4)

ReiserFS: hdb4: Using r5 hash to sort names

VFS: Mounted root (reiserfs filesystem) readonly.

Freeing unused kernel memory: 180k freed

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78172095, sector=78172095

ide: failed opcode was: unknown

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78172095, sector=78172095

ide: failed opcode was: unknown

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78172095, sector=78172095

ide: failed opcode was: unknown

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78172095, sector=78172095

ide: failed opcode was: unknown

hda: DMA disabled

hdb: DMA disabled

ide0: reset: success
```

Once I'm in the system I can re-enable dma on my linux drive but it's still a bit annoying. Does this help?

----------

## widan

```
hda: max request size: 128KiB

hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)

hda: cache flushes not supported

 hda: hda1

...

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hda: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78172095, sector=78172095

ide: failed opcode was: unknown
```

It is trying to read past the end of the disk (you only have 78165360 sectors, but it's trying to access sector #78172095. Since the kernel receives many errors, it is (wrongly) assuming the problem is caused by the controller, and resets the IDE bus, and also disables DMA. Since your hdb is on the same IDE bus, it's DMA gets disabled too.

Now the problem is to find out why some program is trying to read off-disk. Since it is not easy to do from userland, it's likely a filesystem probe from a mount attempt (those are done from the kernel, and don't have as much sanity checking as the userland interface). Those lines seem to indicate that mounting hda was attempted (as vfat, then as NTFS, both failing):

```
FAT: bogus number of FAT structure

VFS: Can't find a valid FAT filesystem on dev hda.

...

NTFS-fs error (device hda): read_ntfs_boot_sector(): Primary boot sector is invalid.

NTFS-fs error (device hda): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.

NTFS-fs error (device hda): ntfs_fill_super(): Not an NTFS volume.
```

Do you have an fstab entry for hda, to have it mounted at boot ?

----------

## vfox

Nope.

```
# /etc/fstab: static file system information.

# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.14 2003/10/13 20:03:38 azarah Exp $

#

# noatime turns off atimes for increased performance (atimes normally aren't

# needed; notail increases performance of ReiserFS (at the expense of storage

# efficiency). It's safe to drop the noatime options if you want and to

# switch between notail and tail freely.

# <fs> <mountpoint> <type> <opts> <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.

/dev/hdb3 /boot reiserfs noauto,notail 1 1

/dev/hdb4 / reiserfs notail 0 1

/dev/hdb2 none swap sw 0 0

/dev/cdrw /mnt/cdrw iso9660 user,noauto,ro,exec 0 0

/dev/dvdrw /mnt/dvdrw iso9660 user,noauto,ro,exec 0 0

#/dev/fd0 /mnt/floppy auto noauto 0 0

# NOTE: The next line is critical for boot!

none /proc proc defaults 0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for

# POSIX shared memory (shm_open, shm_unlink).

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will

# use almost no memory if not populated with files)

# Adding the following line to /etc/fstab should take care of this:

none /dev/shm tmpfs nodev,nosuid 0 0

```

When the Kernel boots up, there's a message early in the game that says. Configuring UDEV to your system, then right after that I get about 10 of these, and they match the off-disk sectors I believe. 

Buffer I/O error on hda...

Could this have something to do with the way udev is configured?

Here's the udev.conf file.

```
# /etc/udev/udev.conf:  main config file for udev

# $Header: /var/cvsroot/gentoo-x86/sys-fs/udev/files/udev.conf.post_059,v 1.1 2005/07/03 07:11:11 gregkh Exp $

#

# This file can be used to override some of udev's default values

# for where it looks for files, and where it places device nodes.

# udev_root - where in the filesystem to place the device nodes

udev_root="/dev/"

# udev_db - The name and location of the udev database.

#           NOTE: this should be somewhere that is writable before

#                 / is mounted rw, like /dev ...

udev_db="/dev/.udevdb"

# udev_rules - The name and location of the udev rules file

udev_rules="/etc/udev/rules.d/"

# udev_log - set to "yes" if you want logging

udev_log="no"

```

By the way, thanks widan for taking the time to help me.   :Cool: 

----------

## widan

Do you have LVM installed (even if you don't actually use it, it will still do probes) ? Look for a /sbin/lvm file.

----------

## vfox

I'll be at work til about 5:30P Est or so, so I won't be able to check til then. What would LVM have to do with it? Just curious.

----------

## vfox

Ok, I was able to remote into my pc and startup a reiserfs detection software on winxp. I have no LVM file in my SBIN directory.

----------

## widan

 *vfox wrote:*   

> What would LVM have to do with it? Just curious.

 

LVM probes the disks to find volume groups, and it happens to run just after udev is started. Near that time dmsetup can also be run if it's installed (but I think it's installed with LVM - if you want to check, the file is /sbin/dmsetup). Udev itself does not probe the disks.

Things that can cause disk probes I know of are LVM (and dmsetup), the md driver (software RAID), and filesystem mounts. If you want to know the process that is touching the disk, you can try this: edit the file /usr/src/linux/mm/page-writeback.c. In there find those lines:

```
/*

 * Flag that makes the machine dump writes/reads and block dirtyings.

 */

int block_dump;
```

And change the last one to read:

```
int block_dump = 1;
```

This will enable block layer logging at boot (you can do it through /proc/sys once booted, but your problem probably happens too early for that, so this forces it enabled by default). Recompile your kernel, install it, and reboot. Then look at the dmesg output, and find the errors. Around them you should find lines like this:

```
bash(29697): READ block 639632 on hda1
```

The first item is the name of the process that touched the block.

Once it's booted, you should stop the block layer logging, as it can slow down a machine a lot (syslog will always be busy writing all those logs to the disks, and that generates even more logging):

```
echo 0 > /proc/sys/vm/block_dump
```

----------

## tHATdUD3

Hello,

I think that i may be having the same exact problem that is listed here.  As there does not seem to be a solution to the problem, I'm wondering if maybe someone can help.

I have 2 Promise controllers.  Running kernel 2.6.11-hardened-r15.  I'm using device mapper to create the raid volumes.

Error Message

```

PDC202XX: Secondary channel reset.

ide5: reset: success

hdk: task_in_intr: status=0x51 { DriveReady SeekComplete Error }

hdk: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=976783734, high=58, low=3705206, sector=976783734

ide: failed opcode was: unknown

...

```

I then found out the following

```

cat /proc/ide/hdk/capacity

488397168

```

If it's trying to read 976783734 > 488397168

lspci Output

```

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge

0000:00:08.0 RAID bus controller: Promise Technology, Inc. PDC20271 (FastTrak TX2000) (rev 02)

0000:00:09.0 RAID bus controller: Promise Technology, Inc. PDC20271 (FastTrak TX2000) (rev 02)

0000:00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)

0000:00:0c.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15)

0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge

0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

```

Any suggestions/help is greatly appreciated.

----------

## tHATdUD3

It's becoming obvious to me, that i'm probably not seeing something:

```

dmsetup status

raid1: 0 976794336 striped 

raid0: 0 976794336 striped 

raid1p2: 0 908411490 linear 

raid0p1: 0 976784067 linear 

raid1p1: 0 68372577 linear 

```

----------

## widan

 *tHATdUD3 wrote:*   

> If it's trying to read 976783734 > 488397168

 

If this disk is part of a RAID0, and is the one that holds the sector containing the array's partition table, then this partition table refers to sector counts that are ok for the whole array, but not for this disk alone (and the fact that it tries to access about twice the max sector for one disk seems to confirm that). So that's not that strange.

It looks like you are trying to access (mount, ...) the "raw" devices directly. Nothing should access those devices directly if they are part of an array. dmraid should give you some special devices under /dev/mapper that represent the array and the partitions on it. Those devices are the only ones you should use.

----------

## tHATdUD3

I tried dmsetup remove_all (thinking that it would solve the problem), I'm still getting the errors though.  This is getting frustrating, could it be related to hardware?  smartmontools passes on everything, reiserfsck passes.  I'm running out of ideas.

----------

## tHATdUD3

 *widan wrote:*   

> It looks like you are trying to access (mount, ...) the "raw" devices directly. Nothing should access those devices directly if they are part of an array. dmraid should give you some special devices under /dev/mapper that represent the array and the partitions on it. Those devices are the only ones you should use.

 

These errors come after boot, surprisingly (before i did dmsetup remove_all) all of the /dev/mapper mounts mounted fine.

```

vol_id(939): READ block 976783874 on hdi1

vol_id(939): READ block 976783875 on hdi1

vol_id(939): READ block 976783876 on hdi1

vol_id(939): READ block 976783877 on hdi1

vol_id(939): READ block 976783878 on hdi1

vol_id(939): READ block 976783879 on hdi1

hdi: dma_intr: status=0x51 { DriveReady SeekComplete Error }

hdi: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=976783935, high=58, low=3705407, sector=976783935

ide: failed opcode was: unknown

```

----------

## soviet/funk

I have pretty much the same problem. I received two harddisks from a broken Lacie Big Disk Extreme, which stripes the two drives together in a RAID0 array, and have to try to rescue the data from the drives. I put them into my case and connected them to an IDE controller exactly as they were in the Lacie case. Booted 2.6.11-gentoo-r7 (x86_64 on AMD Athlon 64) just fine. My two existing drives are SATA, sda and sdb with three parts each. The two IDE drives are marked as hda and hdb. Fdisk sees no partitions on them. Deal with that later, i know little about RAID in practice. 

Then started a dance back and forth with umpteen kernel builds and udev guide/forum threads reading. I decided to upgrade to 2.6.12-gentoo-r10 while also completing udev transition and adding RAID0 support to my kernel. I removed devfs from the kernel, as it was deemed obsolete. I emerged the most up-to-date, "stable" udev (068). Reboot. Now:

*2.6.11-r7 still boots OK

*2.6.12-r10 with pure udev : right after udev starts, i get the same messages as above regarding hda: task_in_intr: status 0x59 {DriveReady SeekComplete DataRequest Error} and so on. Don't have the full messages, but reading above i trust they are the same, trying to read beyond hda's actual geometry. These messages pour out with slightly different numbers for drive sectors for a few minutes. In between all the error messages re hda, i see complaints from an other process that something is hogging I/O or logs (went to fast for me). Then boot stops because the root (usually /dev/sda3) can't be found. No device or file. I'm dropped to Ctrl+D or root password which puts me in a read-only environment. When i do ls and cd around, i find that i'm actually in /dev/sda3... but the device is not mapped. I find /dev/disk/by-id and by-path, which seem to say that the only drive detected and mapped is hda, with *strange* six partitions (that's the total of my two SATA disks... is this a hint?). fdisk -l finds only /dev/hda. 

*2.6.12-r10 with raid support removed does nothing different. 

*2.6.12 with devfs and forced devfs at boot boots OK, but complains about lacking udev support. Natch. 

*grub can't find Windows XP anymore. It should be in /dev/sdb1, but the old grub.conf entry doesn't find it. Any combination of (hdX,Y) has been tried, no luck. Writing grub to MBR doesn't work with (hd0,0) anymore, (hd2,0) seems to find the right drive but corrupts the screen at boot. Giving grub a manual device.map lets me put grub in (hd0,0) again, but has no effect on WinXP booting or the problem above. 

I've been through lots of forum threads but can't find my lunch. It has something to do with udev, i'm sure. The devices are probably not mapped out right, but i don't know what to do in /etc/udev/rules.d. Looks OK to me. 

I could presumably get a clean boot by removing the hda and hdb drives, but then i can't fix them.. 

Next step is to disable the hardware RAID in my motherboard (MSI nvidia) and see if that fixes something. (Makes a little sense in that hda and hdb are striped together and some process tries to read beyond hda. Which it "could" if the array was good.  RAID BIOS messages gave me hope, though, saying that the array is healthy. But I'll try software RAID instead, if I can get my new kernel to boot cleanly..

Let me know what i should post of configs, I'll just put in my fstab for now. 

```

# /etc/fstab: static file system information.

# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.14 2003/10/13 20:03:38 azarah Exp $

#

# noatime turns off atimes for increased performance (atimes normally aren't

# needed; notail increases performance of ReiserFS (at the expense of storage

# efficiency).  It's safe to drop the noatime options if you want and to

# switch between notail and tail freely.

# <fs>                  <mountpoint>    <type>          <opts>                  <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.

/dev/sda1               /boot           reiserfs        noauto,notail           1 1

/dev/sda3               /               reiserfs        notail                  0 1

/dev/sda2               none            swap            sw                      0 0

/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         user,noauto,ro,exec     0 0

/dev/fd0                /mnt/floppy     auto            noauto                  0 0

/dev/sdb1               /mnt/winxp      ntfs            defaults,rw,umask=000   0 0

/dev/sdb2               /mnt/kevin      vfat            defaults,umask=000      0 0

/dev/sdb3               /mnt/liv        vfat            defaults,umask=000      0 0

#/dev/hda               /mnt/lacie_a    hfsplus         noauto,notail     0 0

#/dev/hdb               /mnt/lacie_b    hfsplus         noauto,notail     0 0

# removable devices

/dev/sdc                /mnt/ht202      auto            user,noauto,umask=000   0 0

/dev/sdd                /mnt/ht202_sdd  auto            user,noauto,umask=000   0 0

/dev/sdd1               /mnt/sdd1       hfsplus,vfat            user,noauto,umask=000   0 0

/dev/sdc1               /mnt/edisk      ntfs,hfsplus,vfat               user,noauto,umask=000   0 0

# NOTE: The next line is critical for boot!

none                    /proc           proc            defaults                0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for

# POSIX shared memory (shm_open, shm_unlink).

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will

#  use almost no memory if not populated with files)

# Adding the following line to /etc/fstab should take care of this:

none                    /dev/shm        tmpfs           nodev,nosuid            0 0

```

----------

## soviet/funk

I can now nullify that the onboard RAID of my motherboard had anything to do with booting problems. I disabled RAID in BIOS, rebooted, built 2.6.12 again without devfs, twice, once without and once with kernel RAID/device mapper. No dough on any count. Back in good old 2.6.11 again. 

I can add that the message inbetween hda errors states that something is "hogging interrupts". I can only assume, and thus assume that the hda process is so consuming that the rest of the disk mapping fails, leaving me with devices only for hda and none for sda/sdb/hdb. Next thing I will do is to pull the power on the two IDE drives and boot up and see what that does. If successful, i may try to set RC_DEVICE_TARBALL to yes for the time being, hoping that boots will go clean until I've sorted the problems out. 

crossing fingers. 

kevin

----------

## soviet/funk

yes indeed, removing power from hda/hdb gave me a clean boot. (except for wholly unrelated errors with snd-modules)

Does someone have an idea what is the problem with the drives? I'd format them and see but that would bork the whole rescue operation. They are not mounted auto in fstab, so i don't see why they should be forcibly checked. Can i turn off DMA? I can't follow the hints above to find the culprit process before sometime monday.  Will do then, unless someone has a good idea over the weekend. 

now the weekend..

kevin

----------

