LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Robert Hancock <email@example.com> To: "Altobelli, David" <firstname.lastname@example.org> Cc: Nobin Mathew <email@example.com>, Jiri Slaby <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Grant Grundler <firstname.lastname@example.org> Subject: Re: sharing interrupt between PCI device Date: Tue, 11 Nov 2008 12:49:03 -0600 [thread overview] Message-ID: <4919D39F.email@example.com> (raw) In-Reply-To: <92D64232F2316045B18937D5C9996B152252BB941B@GVW1144EXB.americas.hpqcorp.net> Altobelli, David wrote: >>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <firstname.lastname@example.org> wrote: >>>> Yes USB Virtual Controller has input devices like keyboard and mouse >>>> (routed through hpilo card (remote console)), so those things stops >>>> working when we remove hpilo driver. >>>> > > That is not quite correct. Nothing is routed through hpilo. > > The problem is that there is a shared hardware resource in iLO function 2 (hpilo), > and it is used by iLO function 4 (uhci_hcd kdb/mouse). When hpilo is unloaded, > the pci_device_disable() call removes the ability for this function to act as a > busmaster, which stops the uhci_hcd from functioning correctly. > > Reloading hpilo will enable the remote console again. > > Removing the pci_disable_device() "fixes" the problem, but doing that worries me. I suspect that removing the pci_disable_device in that driver is probably the best solution. It's not really mandatory to disable the device in all cases, we have other devices that have similar issues and so can't be disabled. As long as it can't generate interrupts or otherwise affect the system after the module is unloaded (but it sounds like it doesn't use interrupts anyway). It's not really a good hardware design (mucking with one PCI function on the device shouldn't disable functionality on other functions), but what can you do..
next prev parent reply other threads:[~2008-11-11 18:49 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <fa.h7+lofM1lpbRM5V4/ti5d7RwXuM@ifi.uio.no> 2008-11-05 0:28 ` sharing interrupt between PCI device Robert Hancock 2008-11-05 7:49 ` Nobin Mathew 2008-11-05 8:36 ` Jiri Slaby 2008-11-05 9:20 ` Nobin Mathew 2008-11-06 6:11 ` Nobin Mathew 2008-11-06 7:44 ` Nobin Mathew 2008-11-06 21:24 ` Jiri Slaby 2008-11-07 5:46 ` Nobin Mathew 2008-11-08 7:57 ` Grant Grundler 2008-11-08 9:49 ` Jiri Slaby 2008-11-08 11:53 ` Nobin Mathew 2008-11-08 11:57 ` Jiri Slaby 2008-11-08 17:27 ` Grant Grundler 2008-11-08 19:10 ` Jiri Slaby 2008-11-08 19:15 ` Grant Grundler 2008-11-10 6:35 ` Nobin Mathew 2008-11-10 6:39 ` Nobin Mathew 2008-11-10 6:47 ` Nobin Mathew 2008-11-10 7:51 ` Grant Grundler 2008-11-10 7:58 ` Ingo Molnar 2008-11-10 10:31 ` Nobin Mathew 2008-11-10 15:42 ` Nobin Mathew 2008-11-10 20:34 ` Grant Grundler 2008-11-11 4:57 ` Nobin Mathew 2008-11-11 16:24 ` Altobelli, David 2008-11-11 18:49 ` Robert Hancock [this message] 2008-11-10 20:33 ` Grant Grundler 2008-11-03 13:32 Nobin Mathew 2008-11-03 14:44 ` Jiri Slaby
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=4919D39F.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).