linux-kernel - Re: 2.6.21-rc6-mm1 USB related boot hang

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]

Message-ID: <461E9F69.6020808@acm.org>
Date:	Thu, 12 Apr 2007 16:06:49 -0500
From:	Corey Minyard <minyard@....org>
To:	Jiri Kosina <jikos@...os.cz>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Helge Hafting <helgehaf@...el.hist.no>,
	linux-kernel@...r.kernel.org,
	linux-usb-devel@...ts.sourceforge.net, Greg KH <greg@...ah.com>,
	Mike Galbraith <efault@....de>, Adrian Bunk <bunk@...sta.de>
Subject: Re: 2.6.21-rc6-mm1 USB related boot hang

Jiri Kosina wrote:
> On Thu, 12 Apr 2007, Jiri Kosina wrote:
>
>   
>> CONFIG_IPMI_SI=y
>> hangs upon boot on the already mentioned printk from ipmi_si. With
>> CONFIG_IPMI_SI=m
>> the boot succeeds. When manually trying to modprobe ipmi_si after that, 
>> the modprobe itself hangs, but the machine remains usable otherwise.
>>     
>
> Actually, after approximately 6 minutes 30 seconds, the modprobe finishes 
> with -ENODEV and the following is spitted into dmesg:
>
> ipmi_si: There appears to be no BMC at this location
> ACPI: PCI interrupt for device 0000:02:00.4 disabled
> ipmi_si: Unable to find any System Interface(s)
>
> Anyway I just checked that I get precisely the same behavior with plain 
> 2.6.21-rc6, so we can rule out -mm with this issue.
>
> It's possible that this system has some broken KCS. I will try to narrow 
> this down.
>   
My guess is that this system spaces out its KCS registers, but there 
appears to be no way to specify register spacing or offsets with PCI.  
That would mean that the configuration register appears operational to 
the driver, but the data register is returning bogus data.  Thus it 
appears "sort of" working to the driver, and it takes a long time to 
time out.

I'm pretty sure it's possible to test to figure out where the registers 
are really located.  However, I have no way to test this change.  All 
the other configuration methods have a way to discover this information.

Jiri, we should probably take this offline if you want to continue to 
work on it.

Thanks,

-corey
-
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/