All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report
Date: Thu, 20 Nov 2003 00:33:20 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106928857021781@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106863619315583@msgid-missing>

On Wednesday 19 November 2003 6:08 am, Yu, Luming wrote:

Thanks for doing this work and posting the results.

> 1. USB mouse doesn't work. ( I need to verify config file)

The driver seems to know about the device:

	Product: USB Wheel Mouse
	host/usb-uhci.c: interrupt, status 3, frame# 1415
	input: USB HID v1.00 Mouse [04fc:0003] on usb1:2.0

although it looks unhappy about it.  The "interrupt, status 3" message
seems to be a warning about an interrupt when the driver didn't expect
it.  I wonder whether this can be reproduced on an x86 box?

You could also try the CONFIG_USB_UHCI_ALT driver instead of the
CONFIG_USB_UHCI one you seem to be using, and see whether that
makes a difference.

> 2.PCI: no interrupt route for 00:00:03 pin B

You say this is a known issue for 2.6, but I can't find any details
or discussion about it.  It looks to me like a firmware problem.
The function at 00:00:03.3 (2.6 nicely tells us which function)
claims it's using INTB, but ACPI isn't telling us which GSI that
corresponds to.  Can you ask your BIOS guys about this?

> 3.alloc 0x0-0xcf7 from PCI IO for PCI Bus 00:00 failed   (Known issue)

I poked at this again.  The reason this fails is because the
VGA console driver starts up very early and allocates ports
0x3c0-0x3df.  It would be nice if we could figure out a way
to allocate those ports later, after the PCI bridge has been
discovered, so we get the ioport resources correct, but I
don't know a reasonable way to do that.

> 4.> 1. After login, the dmesg return below message. 	(Known issue)
> > ifup-post(864): <sc1236(0,1008,0,20000000000d5b20)>

I just added a patch to remove these messages, so this should
be fixed.

>  <<conf.TXT>>  <<dmesg.24.ZIP>>  <<lspci.24.ZIP>> 

The conf.TXT attachment was empty.

Bjorn


  parent reply	other threads:[~2003-11-20  0:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-12 11:22 Latest 2.4 IA64 Baseline (Bjorn) + Latest ACPI testing report Yu, Luming
2003-11-19 13:08 ` Yu, Luming
2003-11-20  0:33 ` Bjorn Helgaas [this message]
2003-11-20  3:28 ` Matthew Wilcox
2003-11-20 17:09 ` Bjorn Helgaas
2003-11-20 17:29 ` Luck, Tony
2003-12-10 10:29 ` Yu, Luming
2003-12-11  0:34 ` Bjorn Helgaas
2003-12-11 19:32 ` Bjorn Helgaas
2003-12-16  9:37 ` Yu, Luming
2003-12-16 12:17 ` Matthew Wilcox
2003-12-16 16:23 ` Bjorn Helgaas
2003-12-17  2:54 ` Yu, Luming
2003-12-17  3:07 ` Yu, Luming
2003-12-17 12:23 ` Matthew Wilcox
2003-12-18  2:42 ` Yu, Luming
2003-12-18 12:14 ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-106928857021781@msgid-missing \
    --to=bjorn.helgaas@hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.