# Can't boot into Gentoo

## Gear.0

I posted in the section because I am certain that the problem lies in my kernel configuration.

After compiling for the first time and attempting to boot it just stops.

The last message I see displayed on the screen is:

```
HDA Intel 0000:00:1b:0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
```

I did some searching and found many people having sound issues with this... I still don't see why it would prevent me from booting, but one person claimed to solve it by removing SND_HND_INTEL from the kernel.

So I recompiled my kernel without that option and tried booting again. This time I got a different message before it stopped doing anything:

```
CCID:Activated CCID 3 (TCP-Friendly Rate Control)
```

I tried searching for this message again but it doesn't seem to be associated with any problems...

I'm starting to think that neither of those two messages has anything to do with my problem. That being the case I have no clue how to proceed from here because I don't even know what the error is.

Can anyone give me advice on what to do next? Is there maybe a log file that will tell me the real error?

I would be happy to upload or provide any files or information that anyone requests of me.

Thank you.

----------

## The Doctor

What type of kernel are you using?

if it is a custom kernel, you probably missed some hardware.

if it is genkernel, you probably still missed some hardware.

what I would do is use the system rescue CD, found here so you can use a GUI and read the instructions in on the same box.

To install one of Pappy's kernel seeds and follow the directions below on how to do it. these instructions are good even if you use the default config.

Pappy's kernel seeds are very good and the web site has exelent instructions on how to configure a kernel.

Pappy's kernel seeds here

if you don't want to try that, then post you kernel config and the output of lspci.

----------

## Gear.0

Sorry I didn't specify.

The kernel is 2.6.36-gentoo-r5

and I customized the .config myself using Pappy's Kernel seeds guide already.

I read through the whole thing and followed it to a T.

----------

## The Doctor

Ok

my last idea is to run

```
lspci -v
```

and copy down the modules that are being used by your hardware and enable them.

you can get a much more user friendly list by running

```
sudo lspci -v | grep Kernel
```

----------

## Gear.0

The line:

```
lspci -v | grep Kernel
```

only gave me this:

```
Kernel modules: i2c-i801
```

and that's it..

I did build that driver into the kernel as a module, and I just tried building it directly into the kernel neither worked.

So I guess I will try and go through the output of:

```
lspci -v
```

But I am not really sure how to interpret any of that into information about what goes into the kernel...

do you have any other advice for me?

Thanks for your help so far.

----------

## The Doctor

Well the idea of lspci -v | grep Kernel should give you a list of modules that the environment you are in is using for the hardware.

if you run it in a non-chroot environment, it should give you what the CD is using so you can match you kernel.

lspci -v will just give you more output (useful to see what is NOT being supported). grep filters output and displays only the lines with the word 'Kernel' in it, in case you where curious.

The way I use the lspci is to search for the proper module on the net an in the kernel config.

One of the most helpful tricks I have found is googling you computer name with gentoo to see if a wiki has been put up with you hardware.

It might be helpful if you posted the output of lspci.

from what you posted, I suspect that you need to enable a driver for you hardrive, as i2c-i801 is related to you mother board (I think...).

----------

## NeddySeagoon

Gear.0,

Make a post here I'm sure Pappy will be glad to hear from you.

----------

## Gear.0

Ok will do.

I suppose I should also just go ahead and provide the necessary information as well.

lspci -n (non-chroot)

```
00:00.0 0600: 8086:3405 (rev 12)

00:01.0 0604: 8086:3408 (rev 12)

00:03.0 0604: 8086:340a (rev 12)

00:07.0 0604: 8086:340e (rev 12)

00:10.0 0800: 8086:3425 (rev 12)

00:10.1 0800: 8086:3426 (rev 12)

00:14.0 0800: 8086:342e (rev 12)

00:14.1 0800: 8086:3422 (rev 12)

00:14.2 0800: 8086:3423 (rev 12)

00:14.3 0800: 8086:3438 (rev 12)

00:1a.0 0c03: 8086:3a37

00:1a.1 0c03: 8086:3a38

00:1a.2 0c03: 8086:3a39

00:1a.7 0c03: 8086:3a3c

00:1b.0 0403: 8086:3a3e

00:1c.0 0604: 8086:3a40

00:1c.2 0604: 8086:3a44

00:1c.3 0604: 8086:3a46

00:1c.4 0604: 8086:3a48

00:1d.0 0c03: 8086:3a34

00:1d.1 0c03: 8086:3a35

00:1d.2 0c03: 8086:3a36

00:1d.7 0c03: 8086:3a3a

00:1e.0 0604: 8086:244e (rev 90)

00:1f.0 0601: 8086:3a16

00:1f.2 0101: 8086:3a20

00:1f.3 0c05: 8086:3a30

00:1f.5 0101: 8086:3a26

02:00.0 0604: 10de:05b8 (rev a3)

03:00.0 0604: 10de:05b8 (rev a3)

03:02.0 0604: 10de:05b8 (rev a3)

04:00.0 0302: 10de:05e0 (rev a1)

05:00.0 0300: 10de:05e0 (rev a1)

07:00.0 0106: 197b:2363 (rev 03)

07:00.1 0101: 197b:2363 (rev 03)

08:00.0 0c00: 1106:3403

09:00.0 0200: 10ec:8168 (rev 02)
```

cat /proc/cpuinfo (non-chroot)

```
processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 0

cpu cores   : 4

apicid      : 0

initial apicid   : 0

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.81

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 1

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 1

cpu cores   : 4

apicid      : 2

initial apicid   : 2

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.37

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 2

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 2

cpu cores   : 4

apicid      : 4

initial apicid   : 4

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.26

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 3

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 3

cpu cores   : 4

apicid      : 6

initial apicid   : 6

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.47

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 4

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 0

cpu cores   : 4

apicid      : 1

initial apicid   : 1

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.37

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 5

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 1

cpu cores   : 4

apicid      : 3

initial apicid   : 3

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.26

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 6

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 2

cpu cores   : 4

apicid      : 5

initial apicid   : 5

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5417.63

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 7

vendor_id   : GenuineIntel

cpu family   : 6

model      : 26

model name   : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

stepping   : 5

cpu MHz      : 2672.905

cache size   : 8192 KB

physical id   : 0

siblings   : 8

core id      : 3

cpu cores   : 4

apicid      : 7

initial apicid   : 7

fpu      : yes

fpu_exception   : yes

cpuid level   : 11

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid

bogomips   : 5345.37

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:
```

cat /etc/fstab (chroot)

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

#

# 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 / tail freely.

#

# The root filesystem should have a pass number of either 0 or 1.

# All other filesystems should have a pass number of 0 or greater than 1.

#

# See the manpage fstab(5) for more information.

#

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

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

/dev/sda3      /boot      ext2      defaults,noatime   1 2

/dev/sda6      /      ext4      noatime      0 1

/dev/sda5      none      swap      sw      0 0

/dev/cdrom      /mnt/cdrom   auto      noauto,user   0 0

#/dev/fd0      /mnt/floppy   auto      noauto      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)

shm         /dev/shm   tmpfs      nodev,nosuid,noexec   0 0
```

and my kernel .config

http://paste.pocoo.org/show/339333/

If it gets removed from the pastebin I will gladly upload it again.

----------

## pappy_mcfae

As a general rule, ALSA sound drivers are set as modules. If compiled into the kernel, it can cause issues with the way Gentoo uses ALSA. While I know some who would debate this, I go by what Gentoo says works...and Gentoo recommends setting ALSA drivers as modules...and so do I. 

I went through your .config and you actually did a really good job, for the most part. Some areas I would have set as modules, so I did. This .config should work unless there is a hardware issue with the mobo, or a BIOS issue...we'll know all that soon enough.

Click here for your new .config. Compile as is.

Please do the following:

1. Move your current .config file out of your kernel source directory (/usr/src/linux-2.6.36-gentoo-r5  ).

2. Issue the command make mrproper. This is a destructive step. It returns the source to pristine condition. Unmoved .config files will be deleted!

3, Copy my .config into your source directory.

4. Delete /lib64/modules/2.6.36-gentoo-r5/. The next step will recreate that directory and its contents.

5. Issue the command make && make modules_install.

6. Install the kernel as you normally would, and reboot.

7. Once it boots, please post /var/log/dmesg so I can see how things loaded.

Beyond that, consult the Gentoo ALSA Guide for more complete information on setting up ALSA under Gentoo.

Cheers,

Pappy

----------

## Gear.0

I am sorry that it took me so long to respond.

I am also sorry to report that I followed your steps exactly but still am unable to boot.

It no longer displays the same message so it appears that that has been fixed.. or just changed..

What I now see is this:

 *Quote:*   

> [    1.069485] CCID: Activated CCID 2 (TCP-like)
> 
> [    1.069585] CCID: Activated CCID 3 (TCP-Friendly Rate Control)

 

and it just stops there, similar to before.

Now that I am thinking back I actually recall having a similar problem before, basically because I am using ext4 I had to enable in the kernel "Enable the block layer-> [*]Support for large block devices and files"

Once I enabled that I could boot. However, I don't know if that is related at all because I don't even see the option in my menuconfig. It appears that with 64bit the option goes away.

Just brainstorming... I really don't know what to try next. Advice is appreciated.

----------

## NeddySeagoon

Gear.0,

Screen messages are asynchronous with what the kernel is actually doing, so they are not a good indicator of what actually went went wrong.

In the 64 bit kernel  [*]Support for large block devices and files is always on and you are not permitted to turn it off. The CPU works in 64 bits anywhere, so the special treatment to deal with numbers bigger than 32 bits need not be an option.

I'm beginning to suspect a hardware issue.  As its a boot time issue, we can rule out overheating as the sysem would have enough thermal inertia to get you booted before it got hot enough to fail.  The next most popular hardware error is the RAM subsystem.

Please attempt to run memtest from a liveCD. Its provided as a boot option on the Gentoo CDs and on System Rescue CD. Failures do not always mean dead RAM. It can mean a dead motherboard or CPU.  Post back with your results.

Long shot ... Pappys kernel .config has CONFIG_HZ_1000=y set.  On some systems this was known to prevent booting.  Its worth trying another option.

In Europe, 250Hz is good to match the TV frame rate, in the USA 300HZ is good for the same reason.  Use make menuconfig to make the change.

Current kernels may well have fixed this issue now - I'm not sure

----------

## pappy_mcfae

Before you do anything else, switch to ANYTHING but ext4! Reiserfs-3 is highly recommended, ext3 next...in that order. Reiserfs-4 is NOT recommended, even though I hear a lot less trouble from it. 

I have had all kinds of issues with all kinds of people running ext4. I am not sure of what it takes to make it work successfully. I sometimes wonder if anyone has ever really been able to do anything with ext4 but troubleshoot it for messing everything else up completely. 

Considering the numbers of problems I'm seeing with ext4, I am seriously thinking of no longer supporting .configs from people who insist on running it. If things remain as problematic with reiserfs, then we can troubleshoot from that point. Don't forget to compile reiserfs into the kernel image. Setting it as a module will insure boot failure.

Cheers,

Pappy

----------

## roarinelk

build a kernel without the following set:

- CONFIG_DMAR=y

- CONFIG_CPU_FREQ=y

and add "clocksource=tsc" to the kernel commandline.

DMAR is a source of all kinds of problems (due to crappy BIOS tables),

cpufreq sometimes causes timer problems,

Report whether it helped...

----------

## Gear.0

Ok I thought ext4 was a sort of standard nowadays for Linux. I have it working perfectly with no ill effects on my laptop with Gentoo. But I trust your word pappy  :Smile: 

So, if I were to switch to Reiserfs-3 I would assume everything would get overwritten right? There isn't a way to switch over while keeping my files is there?

If I get no response to this by today I'll just go ahead and start over with reiserfs-3 (or something else, I'll do some research) tomorrow.

----------

## NeddySeagoon

Gear.0,

To switch filesystems you have to destroy what you have then remake the filesystems. You can back up your install, do the switch then restore the install.

If you want to do that google stage4.

However from my dmesg [    2.496102] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)  thats 2.5 seconds until the first SATA link is up. Root is not yet mounted. This is a AMD Phenom II at 3200MHz.  Your last sign of life is at [ 1.069485] CCID: Activated CCID 2 (TCP-like).

From that, I conclude your root is not mounted yet, so your problem is unlikely to be filesystem related.

Before you do something that takes a long time, try the other options you have been offered. Kernel rebuilds will be much faster.

----------

## pappy_mcfae

There is no file system "standard". I use reiser3 because it works. I don't use ext3 because I think it's too slow. I don't use XFS because it's far too delicate, or so the reports go. Reiserfs4 is unproved, and only shows up in zen sources, or other specialized kernels.

As for the problems with ext4, I have dealt with a few people recently whose problems wound up being related to ext4. That is why I recommend using something else. The kernel I made for you should be completely bootable. The fact that it isn't leads me to believe that the most likely problem is ext4. 

The only other thing could be BIOS issues...and you really don't want that to be the case...as that means it might take longer to get your system supported properly via Linux. 

Considering the time it takes to set up a basic Gentoo system, IMO, reformatting and trying with a more stable and time-tested file system is a lot better than futzing around only to find the file system IS the actual issue. Fix the most obvious problem first, then move from there.

Cheers,

Pappy

----------

## Jaglover

 *Quote:*   

> As for the problems with ext4, I have dealt with a few people recently whose problems wound up being related to ext4. That is why I recommend using something else.

 

Considered the authority you have here you'd be more careful with your words.

The whole filesystem choice controversy is very rarely addressed properly. There are a few tests that at least try to be objective and those show Ext3 is no slower than Reiser3 while being more robust. Ext4 is default for Ubuntu and probably many other distros. To draw meaningful conclusions one should consider the userbase. Say, 1,000 users with Reiser3 had 3 problems, 100,000 Ext4 users had 20 problems. Does it mean Ext4 is more problematic?

1. I had terrible experience with X filesystem, now I'm using Y only. 

2. I switched to Z filesystem, my computer is so fast now.

Statements like this mean absolutely nothing because they are isolated cases. In case 1 user maybe had a power break that caused corruption, second case is begging for question: How did you measure this?

When talking about filesystems we often can see nothing but wishful thinking, prejudice, in some cases even fanaticism. 

For instance I believe ExtX filesystems have always been a good choice for generic purpose. Those with special needs may consider XFS, Reiser, JFS, whatever. One should keep in mind UPS has always been a good idea and is even more so with contemporary filesystems. System is loaded into RAM anyway which means even if there are minor differences in filesystem performance it does not affect directly "the speed" of your PC, there is no good reason to use some exotic filesystem for your / partition. And, if using unstable branch one can have problems with anything, not just filesystems.

----------

## gerard27

Jaglover ++

I couldn't believe what I read concerning ext4.

I have /boot ext2, the rest ext4 for ~2 years.

Never any problem/data loss.

Gerard.

----------

## pappy_mcfae

First of all, with the experience I have working with the kernels of others, my words and opinions do carry some weight. How many kernels have ANY of you SUCCESSFULLY got running for others? One...maybe two. When you have the success I've had in the numbers I've had it, then I'll listen to your THEORIES.

Secondly, if calling ext4 bad is so wrong, why is it that so many people who have used it have had so many problems? This file system IS problematic, no matter how many adherents it has. I didn't make the news, I'm just reporting what I've seen working with HUNDREDS...nay, almost thousands of kernels.

Third, I don't much care if others have had other-worldly success with ext4, some people cannot get it to work. If you wish to crow about its "greatness" start a thread and do so. Stop polluting this thread with theory and conjecture about a file system I have noted to be, at least, unstable. Considering what I've seen recently with people having issues with ext4, it is you who have to show that ext4 issues are beyond the pale...cannot POSSIBLY be the issue. 

Further, if you *do* have a suggestion, could you WAIT until mine is tried first before you enter into these lame debates in a place where they ARE NOT welcome? Is that too much to ask?

Fourth, I am NOT here to debate file system issues. I will not enter into that argument! Once again, if you wish to debate the relative merits of file system A vs. file system B, START ANOTHER THREAD! I don't see that Gentoo.org is going to be running out of hard drive space any time in the near future.

The Original Poster of this post asked *me* via email to help him get his computer going. Did he call on any of you others? No! He didn't. This thread was set up by the OP, at MY suggestion, so that my kernel seeds thread didn't get overloaded with others having me help them. It was not set up to have others who have NO experience setting up hundreds of FUNCTIONAL kernel .configs come by to muddy the waters.

If any of you kibitzers want to continue to debate OFF TOPIC ISSUES, take it elsewhere. I am TRYING to help this guy get his machine going; something for which I am VERY well known. Having you grouse about this silly debate is HAMPERING my attempt to get the user's machine operational.

Once again, if you are here to turn this into a debate about file systems, PLEASE GO AWAY! This thread is about getting another's machine going, not about your theories, or telling me how wrong I am, absent proof. 

When you have as many notches in your belts when it comes to working on kernels and getting others' machines to run, then I'll care about what you have to say. For the moment, PLEASE stop the crap so the OP and I can communicate.

Forgive what may appear as arrogance, but if you're not helping, you're not helping...and clearly, those here to second guess me, or debate file systems ARE NOT HELPING! Get it?

Cheers,

Pappy

----------

## Gear.0

I can now boot into my system!

Thank you to everyone who helped.

After switching to reiserFS I noticed no change at all to the output when my booting process would freeze.

So then trying the four other suggestions that I noticed posted in this thread:

changing the CONFIG_HZ to 300 instead of 1000

CONFIG_DMAR=n

CONFIG_CPU_FREQ=n

and adding the kernel line "clocksource=tsc"

Somewhere within those 4 changes allowed my system to boot. I then tried turning them off one by one and have deduced that the single change that was necessary to make my system boot was NeddySeagoon's suggestion of changing CONFIG_HZ_1000=y to 300Hz.

So what side effects will I notice due to having this option at 300 instead of 1000? I do have a nice video card and do want to be able to play some games under Linux, such as DOOM3, QuakeLive, and others under WINE. Will this affect that at all?

----------

## NeddySeagoon

Gear.0,

You won't notice anything.  The timer raises an IRQ at the frequency you set.

The service routine looks round for something to do and queues the task(s) if any.

At 1000Hz, it does this 1000 time a second, at 300Hz, its 300 times a second.

Most times there will be nothing to do, so the IRQ processing time is wasted CPU time.

It has no effect on your video card at all. Its only recently that frequencies other than 100Hz have become available.

----------

## pappy_mcfae

Nice to see that's figured out. I'll have to keep that in mind if I run into a similar situation with another machine like yours.

And yes, I was wrong, but such is life. Given the same circumstances and what I've seen in the past, I'd make the same diagnosis. Now that I have better info, I can make a better determination.

It's just curious that I've been running all my machines at 1500 Hz since it became an option in zen sources, and I've not had one single problem. I never had a problem at 1000Hz. :shrug:

Cheers,

Pappy

----------

## gerard27

Maybe you're wrong about ext4 too?

Gerard.

----------

## roarinelk

 *pappy_mcfae wrote:*   

> 
> 
> It's just curious that I've been running all my machines at 1500 Hz since it became an option in zen sources, and I've not had one single problem. I never had a problem at 1000Hz.
> 
> 

 

depending on the clocksource, such high HZ values may have shorter cycletimes than

the clocksource can provide, leading to these kinds of hangs.  You've been lucky

so far in you choice of hardware I guess.

However I strongly doubt going higher than 1000 is beneficial unless you do low-latency

audio mixing or somesuch...

EDIT: ext4 isn't as bad as you describe it.  It is as forgiving of unclean unmounts/suddon shutdowns

as reiser3.  I've never lost a file on my ext4 partitions, and I have git kernels panic on me

a few times a day!

----------

## pappy_mcfae

Gerard,

Whether or not I am wrong on ext4 is not the point. The point is/was that being snarky about attempts to get another person's machine running, and posting snarky little comments while others are attempting to help is NOT helpful in the least. If I had been right, would you admit to it as freely as I admitted to my wrong?

I doubt it.

But that's all in the past, and there it should remain. The OP's machine is running, and that was my entire purpose for posting any words in this thread in the first place. Anything else was, to me, an irritation...specifically when the snark machine came out to play.

Cheers,

Pappy

----------

## pappy_mcfae

roarinelk,

I have never seen this as an issue before now...and as I've said, I've made hundreds of kernels for people. When I see P-III's and other dinosaurs that can handle 1000 Hz without even a snivel, what is one to think of an I7 that can't?

Yes, it is an option that doesn't even come to the mind. If a slow machine can handle fast timing, why can't a fast machine do the same? To my mind, that is something completely out of the realm of possibility. That it did prove to be the issue gives me serious pause. 

FYI, having things cranked tends to make the whole machine run snappier, at least to my observations. There are benefits to having a snappy kernel beyond working with sound.

Cheers,

Pappy

----------

