lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 16 Feb 2008 11:46:42 -0500
From:	Andrew Buehler <abuehler.kernel@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Oliver Pinter <oliver.pntr@...il.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, linux-scsi@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: USB regression (and other failures) in 2.6.2[45]*

(Note: I consider it blatantly incorrect to send a reply both to a
mailing list and directly to the address of someone who is subscribed to
that list unless you have reason to believe that that someone will not
see the message otherwise, but in this case I am doing so anyway because
I see no way to avoid it and still make sure all relevant people receive
the message.)

On 2/16/2008 10:20 AM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Oliver Pinter wrote:
> 
>> On 2/15/08, Andrew Buehler <abuehler.kernel@...il.com> wrote:
>>> In my workplace, I use a customized version of Novell's ZENworks
>>> imaging boot CD, which is based off of Linux. I have one
>>> particular model of laptop - the IBM/Lenovo R61 - on which three
>>> different things fail completely in current kernels (tested with
>>> 2.6.24.2 and 2.6.25-rc1): USB, AHCI (and thus access to the SATA
>>> drive), and networking. As a consequence of all three failing in
>>> parallel, I have no practical way to get logs and other
>>> information off of the machine to help with tracking down the
>>> bugs.
> 
> ...
> 
> To make a long story short, the USB symptoms you describe indicate a
> problem with interrupt routing.  This could well explain the other
> difficulties too.  There are various kernel parameters you can try
> putting on the boot command line to work around it:  acpi=noirq or
> acpi=off or pci=noacpi or a few others.

I have now tried all three of these, with no apparent effect; the USB
drive is still not detected when plugged in after boot. A naive search
on Google provides no indication of other possible parameters to try;
the only list I have found of ACPI-related kernel parameters includes no
others which seem likely to be helpful without more knowledge of the
specifics of the situation (and the subsystem) than I have.

What would the next step be?

-- 
    Andrew Buehler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ