From: ebiederm@xmission.com (Eric W. Biederman)
To: "Christian Schaubschläger" <christian.schaubschlaeger@gmx.at>
Cc: kexec@lists.infradead.org
Subject: Re: Problem with kexec on i386, linux-3.5
Date: Mon, 13 Aug 2012 20:31:59 -0700 [thread overview]
Message-ID: <87sjbqjgi8.fsf@xmission.com> (raw)
In-Reply-To: <500EE046.2000705@gmx.at> ("Christian \=\?utf-8\?Q\?Schaubschl\?\= \=\?utf-8\?Q\?\=C3\=A4ger\=22's\?\= message of "Tue, 24 Jul 2012 19:49:58 +0200")
Christian Schaubschläger <christian.schaubschlaeger@gmx.at> writes:
> Hello list,
>
> I'm not sure if this is the correct place to post this; if it's not,
> I'd like to apologize.
>
> Here's a short description of my problem:
>
> I have a tiny protected-/real mode program, which I start using kexec
> (kexec-tools 2.0.3 released 05 April 2012). At some point this program
> makes a call to extended-int13 to read data from the disk. Now
> starting with linux-3.5-rc1 (and at least up to linux-3.5) this
> extended int13 call does not work any more. Apparently the call
> returns with error code 0x80, which means "timeout (not ready)".
>
> I have two machines here, both with Intel chipsets (one CougarPoint,
> one older ICH7-M), and I see the same behaviour on both machines.
>
> When I use older kernels (starting from 2.6.something up to 3.4.6),
> everything works fine.
>
> Now I'm not sure if this is a kernel issue, or a kexec issue, or a
> mistake by myself. Maybe someone has a hint for me...
>
> If required, of course, I can provide more detailed information about
> my hardware, kernel config, etc. (since I'm not sure if this is the
> correct place, I wanted to keep this message short for now).
That is a tricky issue. Sometimes the slightest things can set
something like this off.
Somewhere someone changed something in one of the drivers that made it
so that the hardware winds up in a state the int 13 disk driver does not
like it after kexec.
If you want to track this down I would recommend a bisect between 3.4
and 3.5-rc1 to see which change breaks your setup.
Once we know what kernel change caused this we can start to think about
how fixable your failure is.
Ideally we fix these kinds of things, in practice many times things are
just too hard to track down and things like this break.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-08-14 3:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 17:49 Problem with kexec on i386, linux-3.5 Christian Schaubschläger
2012-08-14 3:31 ` Eric W. Biederman [this message]
2012-08-16 12:41 ` Christian Schaubschläger
2012-08-16 19:22 ` Eric W. Biederman
2012-08-17 6:58 ` Christian Schaubschläger
2012-09-07 15:16 ` Khalid Aziz
2012-09-07 20:29 ` Khalid Aziz
2012-09-10 6:00 ` Christian Schaubschläger
2012-09-10 16:29 ` Khalid Aziz
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=87sjbqjgi8.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=christian.schaubschlaeger@gmx.at \
--cc=kexec@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox