Bug 140065 - "atkbd.c: Spurious ACK on isa0060/seri0..." infinitely repeated on boot
Summary: "atkbd.c: Spurious ACK on isa0060/seri0..." infinitely repeated on boot
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-19 16:12 UTC by Daniel Walsh
Modified: 2015-01-04 22:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-03 19:11:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Daniel Walsh 2004-11-19 16:12:00 UTC
Description of problem:
I am getting the following error repeated infinitely on boot
Spurious ACK on isa0060/serio0. Some Program, like XFree86, might be
trying to access hardware directly

The machine works fine with original FC3 kernel.

Version-Release number of selected component (if applicable):
2.6.9-1.678_FC3

How reproducible:


Steps to Reproduce:
1.  Boot the machine
2.
3.
  
Actual results:

Infinite loop, never finishes.
Expected results:
Boot

Additional info:

Comment 1 Rob Hughes 2004-11-21 18:55:01 UTC
Happening to me as well on all three FC3 (installed, 678, 681) kernels
I've tried. Unplugging all USB devices doesn't seem to make any
difference. I'm using a NForce2 chipset board from ASUS.

Comment 2 Matthew Miller 2004-11-23 16:53:33 UTC
We're seeing this in FC2 on an Asus P4S533-MX system *without* SATA. 

We get

  VFS: Mounted root (ext2 filesystem).
  VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
  Please append a correct "root=" boot option
  Kernel panic - not syncing : VFS: Unable to mount root fs on
    unknown-block(0,0)

followed by an infinite number of 

  atkbd.c: Spurious ACK on isa0060/seri0. Some program, like XFree86, 
    might be trying access hardware directly.

The machine isn't SMP, but oddly, if we boot the SMP kernel, we get
the panic message but _not_ the atkbd.c errors.

Also very disturbing: this happens with the newest
kernel-2.6.9-1.6_FC2, but kernel-2.6.9-1.3_FC2 works _fine_.

Comment 3 Matthew Miller 2004-11-23 18:41:02 UTC
Hmmm. "root=/dev/hda2" instead of "root=LABEL=/" solves the problem
here -- not only does the system boot, but there's no "atkbd.c:
Spurious ACK" messages. Is this also the case on the FC3 systems, or
is this totally unrelated?

Comment 4 Rob Hughes 2004-11-23 19:10:47 UTC
I have "root=/dev/sda3" in my grub.conf. I'll try hde3 and see if 
that makes a difference.

Comment 5 Reinier Balt 2004-11-24 19:45:29 UTC
I have the same problem. Dell Inspiron 3800 (no SMP, celeron 500, no SATA).
2.6.9-1.3 works fine, but 2.6.9-1.6 panics with the spurious ACK error.

When booting with root=/dev/hda1 the problem goes away.

Comment 6 Rob Hughes 2004-11-25 14:35:34 UTC
I've tried this with root=/dev/sda3 and root=/dev/hde3. Neither worked for me.
This may, however, be related to bug 140367, which seems to be causing my drive
to fail to initilize.

Comment 7 Rob Hughes 2004-11-29 23:52:27 UTC
Over the weekend, I booted the rescue cd, removed all kernel packages,
then rebooted again to the cd, chose install and had it install the
kernel and write a new grub config/MBR. Since then, the problem has
gone away and it boots fine, even with the 681 kernel.

Comment 8 Daniel Walsh 2004-12-03 19:11:03 UTC
kernel-2.6.9-1.681_FC3 is working for me now.

Comment 9 Matthew Miller 2004-12-03 19:20:21 UTC
Daniel -- shall I open a separate bug for the "root=LABEL=/" problem?
To my knowledge, the latest kernel doesn't resolve that.

Comment 10 Daniel Walsh 2004-12-03 19:29:55 UTC
Might be a good idea, since your bug is probably getting lost in the
noise.

Dan

Comment 11 Matthew Miller 2004-12-03 20:01:18 UTC
Okay. Issue in comment #2 filed as bug #141791.


Note You need to log in before you can comment on or make changes to this bug.