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:	Wed, 17 Jan 2007 12:08:48 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Benjamin Romer <benjamin.romer@...sys.com>
Cc:	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>
Subject: Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)

Benjamin Romer <benjamin.romer@...sys.com> writes:

> On the Unisys ES7000/ONE system, we encountered a problem where
> performing a kexec reboot or dump on any cell other than cell 0 causes
> the system timer to stop working, resulting in a hang during timer
> calibration in the new kernel. 
>
> We traced the problem to one line of code in disable_IO_APIC(), which
> needs to restore the timer's IO-APIC configuration before rebooting. The
> code is currently using the 4-bit physical destination field, rather
> than using the 8-bit logical destination field, and it cuts off the
> upper 4 bits of the timer's APIC ID. If we change this to use the
> logical destination field, the timer works and we can kexec on the upper
> cells. This was tested on two different cells (0 and 2) in an ES7000/ONE
> system.
>
> For reference, the relevant Intel xAPIC spec is kept at
> ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
> specifically on page 334.

Looks like good bug hunting.  I will have to look but it might
make more sense to simply fix: struct IO_APIC_route_entry,
or use whatever technique we normally use to generate the io_apic
vectors.

I don't recall enough off of the top of my head to recall what
the discrimination rule between logical and physical is but
I think setting the system in physical mode is a good clue :)

Eric
-
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