linux-kernel - Re: 2.6.25-rc6 regression

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:	Sun, 13 Apr 2008 23:33:10 +0200
From:	Pavel Machek <pavel@....cz>
To:	Soeren Sonnenburg <kernel@....de>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: 2.6.25-rc6 regression - hang on resume

Hi!

> > /sys/bus/pci/devices/0000:00:1b.0/irq
> > 
> > contains 21 in one case and 22 in another... as do other
> > interrupts. Is that expected? Can you post /proc/interrupts for both
> > versions?
> 
> It might be that configs are slightly different - if you think this
> gives a clue I will post them, but your discovery below looks
> promising:

Yep... any chance to do git bisect to see where it broke?

> > Error: something went wrong performing real mode call
> > open("/sys/class/graphics",
> > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -1 ENOENT (No
> > such file or directory)
> > open("/dev/tty", O_RDWR|O_LARGEFILE)    = 6
> > ioctl(6, KDGKBTYPE, 0xbfae8887)         = 0
> > 
> > ...can you perhaps add printf-s to s2ram to find out what changed?
> 
> OK, I searched for ???"something went wrong performing real mode call" in
> the s2ram source and found this function:
> 
> int do_real_post(unsigned pci_device)
> {
>     int error = 0;
>     struct LRMI_regs r;
>     memset(&r, 0, sizeof(r));
> 
>     /* Several machines seem to want the device that they're POSTing in
>        here */
>     r.eax = pci_device;
> 
>     /* 0xc000 is the video option ROM.  The init code for each
>        option ROM is at 0x0003 - so jump to c000:0003 and start running
> */
>     r.cs = 0xc000;
>     r.ip = 0x0003;
> 
>     /* This is all heavily cargo culted but seems to work */
>     r.edx = 0x80;
>     r.ds = 0x0040;
> 
>     if (!LRMI_call(&r)) {
>         fprintf(stderr,
>             "Error: something went wrong performing real mode call\n");
>         error = 1;

Sweet, so the problem is inside X86EMU_exec(), right? ...and that's
bytecode interpretter. You could add printfs() all over it, to see
where the execution differs.

> so either the graphics adapter is somehow not ready yet or a wrong
> address is used for posting?

Or something goes wrong in the interpretter...

> Do you already now have an idea? Or which things should I print out?

It starts to look like git bisect is the easier way to get some
results...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/