# Boot up oddity with ACPI - Part SOLVED

## MrSums

Recently I've had to soft-reboot my desktop every time I start it in the morning in order for it to recognise the keyboard & mouse - it seems to boot fine into gdm, but neither kb nor mouse are recognised. Hit the soft reboot button and next time everything is fine.

Investigating the /var/log/everything/current log file, I find that on initial boot, I get the following:

 *Quote:*   

> Jul 15 08:17:31 [kernel] via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
> 
> Jul 15 08:17:31 [kernel] eth0: VIA Rhine II at 0x1b000, 00:0c:6e:d2:91:ce, IRQ 11.
> 
> Jul 15 08:17:31 [kernel] eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
> ...

 

but on reboot, these lines are:

 *Quote:*   

> Jul 15 08:18:30 [kernel] via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
> 
> Jul 15 08:18:30 [kernel] ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> 
> Jul 15 08:18:30 [kernel] ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> IRQ 11
> ...

 

I thought it might be something to do with parallel startup of the rc scripts, so I turned that off, but made no difference. 

Any clues please?

Thanks

----------

## VinzC

The log indicates things that happen while the kernel is initializing. So it has nothing to do with parallel startup as it takes place long before the init scripts are run. GSI stands for Global System Interrupts and I think it's just ACPI that's indicating an interrupt was assigned somewhere, nothing to die for  :Wink:  .

As to why it happened on the next reboot only... Doesn't really matter I think. That's probably because the kernel initializes the hardware in threads and not sequentially (like it did before, IIRC). So you might see things scrambled in the kernel log. For instance you might see ACPI lines appear in the middle of [what you think is] IDE or Ethernet device initialization...

I've got no better explanation.

EDIT: Here's a link to an article that deals with interrupt routing.

----------

## MrSums

Found out WHAT I had done, but not necessarily WHY it is happening. I read an article on speeding up the boot process which suggested putting xdm into the boot run-level, rather than default. 

Clearly I didn't properly follow this, but removing it from boot and putting back into default sorted the problem.

----------

## VinzC

I just don't understand why it should be a problem -- but I'm no hardware specialist, you know. Was the IRQ that of your video card? If yes, what was the problem exactly?

----------

## MrSums

lspci gives:

 *Quote:*   

> 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
> 
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
> 
> 00:0b.0 SCSI storage controller: Adaptec AIC-7850 (rev 01)
> ...

 

and  cat /var/log/everything/current | grep IRQ gives:

 *Quote:*   

> 
> 
> Jul 20 09:38:27 [kernel] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
> 
> Jul 20 09:38:27 [kernel] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12)
> ...

 

This suggests to me that the ethernet card (00:12.0) is originally given IRQ11, but then this is also then assigned to the video card on 01:00.0.

The problem was that on first boot, neither the keyboard nor mouse were recognised so although I had a login screen, I couldn't input anything. However, if I then soft-rebooted the keyboard and mouse both worked fine.

I am guessing that by putting the xdm init script into the boot runlevel, it was initialising prior to keyboard/mouse, but for the lift of me I don't understand why it would then work on a soft reboot. Whether this is an ACPI problem? I am not convinced that the above detail helps a great deal.

----------

## VinzC

I see. I would rather believe your DSDT needs fixing. This is an ACPI problem, IMHO.

----------

