2.5.62-mm3 boots up fine, but won't run X. Something goes
wrong switching to graphics so my monitor says "no signal"
Using radeonfb:
Switching to the framebuffer console almost works, but
the video mode is messed up so parts of the text appear
all over the screen. Switching back to X again shows
X in a very messed up video mode, some sort
of resolution mismatch.
Using plain vga console:
Nothing happens on the screen after I get "no signal",
console switching has no effect. Sync&Reboot via
sysrq works though.
The kernel uses UP, preempt, no module support, devfs configured
but not used.
Hardware:
2.4GHz P4, 512M
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP
Helge Hafting
On Mon, Feb 24, 2003 at 01:26:53PM +0100, Helge Hafting wrote:
> 2.5.62-mm3 boots up fine, but won't run X. Something goes
> wrong switching to graphics so my monitor says "no signal"
>
> Using radeonfb:
> Switching to the framebuffer console almost works, but
> the video mode is messed up so parts of the text appear
> all over the screen. Switching back to X again shows
> X in a very messed up video mode, some sort
> of resolution mismatch.
>
> Using plain vga console:
> Nothing happens on the screen after I get "no signal",
> console switching has no effect. Sync&Reboot via
> sysrq works though.
>
> The kernel uses UP, preempt, no module support, devfs configured
> but not used.
>
> Hardware:
> 2.4GHz P4, 512M
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY
> 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP
Same is here. Radeon too, only it is Radeon M7 LY 8)
>
> Helge Hafting
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Helge Hafting <[email protected]> wrote:
>
> 2.5.62-mm3 boots up fine, but won't run X. Something goes
> wrong switching to graphics so my monitor says "no signal"
>
Does 2.5.63 do the same thing?
On Mon, Feb 24, 2003 at 12:16:01PM -0800, Andrew Morton wrote:
> Helge Hafting <[email protected]> wrote:
> >
> > 2.5.62-mm3 boots up fine, but won't run X. Something goes
> > wrong switching to graphics so my monitor says "no signal"
> >
>
This is the boot messages and decoded ksymoops which happens when I try
to log off and login as a different user in KDE3.1 (debian/unstable).
> Does 2.5.63 do the same thing?
I haven't tried this yet.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Zilvinas Valinskas <[email protected]> wrote:
>
> On Mon, Feb 24, 2003 at 12:16:01PM -0800, Andrew Morton wrote:
> > Helge Hafting <[email protected]> wrote:
> > >
> > > 2.5.62-mm3 boots up fine, but won't run X. Something goes
> > > wrong switching to graphics so my monitor says "no signal"
> > >
> >
> This is the boot messages and decoded ksymoops which happens when I try
> to log off and login as a different user in KDE3.1 (debian/unstable).
>
Ah, thank you.
kernel BUG at mm/rmap.c:248!
The fickle finger of fate points McCrackenwards.
> > Does 2.5.63 do the same thing?
> I haven't tried this yet.
2.5.63 should be OK.
--On Tuesday, February 25, 2003 01:55:37 -0800 Andrew Morton
<[email protected]> wrote:
> Ah, thank you.
>
> kernel BUG at mm/rmap.c:248!
>
> The fickle finger of fate points McCrackenwards.
Yep. He tripped over my sanity check that pages not marked anon actually
have a real mapping pointer. Apparently X allocates a page that should be
marked anon but isn't.
My main reason for adding the anon flag was to prove to myself that the
mapping pointer can be trusted. Apparently it can, generally, but it looks
like I haven't successfully tracked down all the places that should set it.
It looks like anon pages can come from random sources, so it might be an
impossible task to find them all.
I know you said you like the idea of having the flag, but I think the
cleanest fix would be to change the check from
if (PageAnon(page))
to
if (page->mapping && !PageSwapCache(page))
Or I could set the anon flag based on that test. I know page flags are
getting scarce, so I'm leaning toward removing the flag entirely.
What would you recommend?
Dave McCracken
Dave McCracken <[email protected]> wrote:
>
>
> --On Tuesday, February 25, 2003 01:55:37 -0800 Andrew Morton
> <[email protected]> wrote:
>
> > Ah, thank you.
> >
> > kernel BUG at mm/rmap.c:248!
> >
> > The fickle finger of fate points McCrackenwards.
>
> Yep. He tripped over my sanity check that pages not marked anon actually
> have a real mapping pointer. Apparently X allocates a page that should be
> marked anon but isn't.
Wonder where that came from?
> My main reason for adding the anon flag was to prove to myself that the
> mapping pointer can be trusted. Apparently it can, generally, but it looks
> like I haven't successfully tracked down all the places that should set it.
> It looks like anon pages can come from random sources, so it might be an
> impossible task to find them all.
Yes, the debug check is important at this time.
> I know you said you like the idea of having the flag, but I think the
> cleanest fix would be to change the check from
>
> if (PageAnon(page))
> to
> if (page->mapping && !PageSwapCache(page))
Well I'm not particularly overjoyed by the flag. What I liked was that we
have a place where we can implement anonymous page counting, so we get
another interesting number in /proc/meminfo. Minor point.
> Or I could set the anon flag based on that test. I know page flags are
> getting scarce, so I'm leaning toward removing the flag entirely.
>
> What would you recommend?
Keep the flag for now, find the escaped page under X, remove the flag later?
--On Tuesday, February 25, 2003 13:27:55 -0800 Andrew Morton
<[email protected]> wrote:
>> Or I could set the anon flag based on that test. I know page flags are
>> getting scarce, so I'm leaning toward removing the flag entirely.
>>
>> What would you recommend?
>
> Keep the flag for now, find the escaped page under X, remove the flag
> later?
It occurred to me I'm already using (abusing?) the flag for nonlinear
pages, so I have to keep it. I'll chase solutions for X.
Dave McCracken
--On Tuesday, February 25, 2003 15:46:26 -0600 Dave McCracken
<[email protected]> wrote:
>> Keep the flag for now, find the escaped page under X, remove the flag
>> later?
>
> It occurred to me I'm already using (abusing?) the flag for nonlinear
> pages, so I have to keep it. I'll chase solutions for X.
Ok, the vm_ops->nopage function is set in drivers like drm and agp. I
don't think it's reasonable to require all of them to set PageAnon. So
here's a patch that tests the page on do_no_page and sets the flag
appropriately.
Dave McCracken
>>> Keep the flag for now, find the escaped page under X, remove the flag
>>> later?
>>
>> It occurred to me I'm already using (abusing?) the flag for nonlinear
>> pages, so I have to keep it. I'll chase solutions for X.
>
> Ok, the vm_ops->nopage function is set in drivers like drm and agp. I
> don't think it's reasonable to require all of them to set PageAnon. So
> here's a patch that tests the page on do_no_page and sets the flag
> appropriately.
Well, it runs fine, but I get truly freaky performance results. My machine
might have gone wacko on me or something - the patch seems perfectly simple
to me. Kernbench is all over the map - user and elapsed way up, system is
down. Ummm .. probably all too strange to be true, and I've made a mistake,
but if some more sane person than I could run a quick test, would help.
Thanks,
M.
Kernbench-2: (make -j N vmlinux, where N = 2 x num_cpus)
Elapsed User System CPU
2.5.62-mjb3 43.92 557.65 94.12 1483.50
test 68.61 923.78 90.19 1477.33
Kernbench-16: (make -j N vmlinux, where N = 16 x num_cpus)
Elapsed User System CPU
2.5.62-mjb3 45.21 560.46 114.58 1492.67
test 69.04 927.20 100.56 1488.17
DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.
Results are shown as percentages of the first set displayed
SDET 1 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 3.1%
test 83.9% 1.7%
SDET 2 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 4.0%
test 87.0% 3.8%
SDET 4 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 2.0%
test 90.3% 2.1%
SDET 8 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 4.6%
test 95.6% 6.3%
SDET 16 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 2.7%
test 103.0% 3.4%
SDET 32 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 0.9%
test 96.6% 1.0%
SDET 64 (see disclaimer)
Throughput Std. Dev
2.5.62-mjb3 100.0% 1.1%
test 94.8% 0.6%
>>> It occurred to me I'm already using (abusing?) the flag for nonlinear
>>> pages, so I have to keep it. I'll chase solutions for X.
>>
>> Ok, the vm_ops->nopage function is set in drivers like drm and agp. I
>> don't think it's reasonable to require all of them to set PageAnon. So
>> here's a patch that tests the page on do_no_page and sets the flag
>> appropriately.
>
> Well, it runs fine, but I get truly freaky performance results. My machine
> might have gone wacko on me or something - the patch seems perfectly
> simple to me. Kernbench is all over the map - user and elapsed way up,
> system is down. Ummm .. probably all too strange to be true, and I've
> made a mistake, but if some more sane person than I could run a quick
> test, would help.
Pah. Debian stealth-upgraded me to gcc 3.2 ... no wonder it's slow as a
dog. So your patch is stable, and works just fine. Sorry,
M.
On Wednesday 26 February 2003 18:52, Martin J. Bligh wrote:
Hi Martin,
> Pah. Debian stealth-upgraded me to gcc 3.2 ... no wonder it's slow as a
> dog. So your patch is stable, and works just fine. Sorry,
hmm, you mean gcc 3.2 compilations are slow as dog? gcc 2.95.x is better?
ciao, Marc
>> Pah. Debian stealth-upgraded me to gcc 3.2 ... no wonder it's slow as a
>> dog. So your patch is stable, and works just fine. Sorry,
> hmm, you mean gcc 3.2 compilations are slow as dog? gcc 2.95.x is better?
Yeah, about 1.5x difference. See the whole thread on that where I posted
more numbers a week or two ago (though that bit was right down at the end
of the first email, IIRC).
M.
> Pah. Debian stealth-upgraded me to gcc 3.2 ... no wonder it's slow as a
> dog. So your patch is stable, and works just fine. Sorry,
Yep, gcc-2.95 -> gcc-3.2 dropped SDET results by about 10% on my ppc64
boxes :(
Anton