LinuxLists.cc - 2.6.1-mm1

[permalink] [raw]

Subject: 2.6.1-mm1: sound/pci/cmipci.c compile error

On Fri, Jan 09, 2004 at 01:40:03AM -0800, Andrew Morton wrote:
>...
> - A big ALSA update.
>...
> Changes since 2.6.1-rc2-mm1:
>...
> +alsa-101.patch
>
> ALSA update
>...

I got the following compile error when trying to compile
sound/pci/cmipci.c statically into the kernel:

<-- snip -->

...
CC sound/pci/cmipci.o
sound/pci/cmipci.c: In function `alsa_card_cmipci_setup':
sound/pci/cmipci.c:3300: error: `joystick' undeclared (first use in this function)
sound/pci/cmipci.c:3300: error: (Each undeclared identifier is reported only once
sound/pci/cmipci.c:3300: error: for each function it appears in.)
make[2]: *** [sound/pci/cmipci.o] Error 1

<-- snip -->

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-01-09 21:19:37

[permalink] [raw]

Subject: Re: 2.6.1-mm1

"Prakash K. Cheemplavam" <[email protected]> wrote:
>
> Hi,
>
> could it be that you took out /or forgot to insterst the work-around for
> nforce2+apic? At least I did a test with cpu disconnect on and booted
> kernel and it hang. (I also couldn't find the work-around in the
> sources.) I remember an earlier mm kernel had that workaround inside.
>

I discussed it with Bart and he felt that it was not a good way of fixing
the problem. I'm not sure if he has a better fix in the works though..

2004-01-09 21:24:16

by Prakash K. Cheemplavam

[permalink] [raw]

Subject: Re: 2.6.1-mm1

Andrew Morton wrote:
> "Prakash K. Cheemplavam" <[email protected]> wrote:
>>could it be that you took out /or forgot to insterst the work-around for
>>nforce2+apic? At least I did a test with cpu disconnect on and booted
>
> I discussed it with Bart and he felt that it was not a good way of fixing
> the problem. I'm not sure if he has a better fix in the works though..
>
Yes, it is no good fix, but at least better than nothing...don't you agree?

Prakash

2004-01-09 22:42:23

[permalink] [raw]

Subject: Re: 2.6.1-mm1: sound/pci/cmipci.c compile error

Adrian Bunk <[email protected]> wrote:
>
> I got the following compile error when trying to compile
> sound/pci/cmipci.c statically into the kernel:
>
> <-- snip -->
>
> ...
> CC sound/pci/cmipci.o
> sound/pci/cmipci.c: In function `alsa_card_cmipci_setup':
> sound/pci/cmipci.c:3300: error: `joystick' undeclared (first use in this function)
> sound/pci/cmipci.c:3300: error: (Each undeclared identifier is reported only once
> sound/pci/cmipci.c:3300: error: for each function it appears in.)

Like this, methinks

diff -puN sound/pci/cmipci.c~cmipci-joystick-fix sound/pci/cmipci.c
--- 25/sound/pci/cmipci.c~cmipci-joystick-fix Fri Jan 9 14:41:51 2004
+++ 25-akpm/sound/pci/cmipci.c Fri Jan 9 14:41:59 2004
@@ -3297,7 +3297,7 @@ static int __init alsa_card_cmipci_setup
&& get_option(&str,&soft_ac3[nr_dev]) == 2
#endif
#ifdef SUPPORT_JOYSTICK
- && get_option(&str,&joystick[nr_dev]) == 2
+ && get_option(&str,&joystick_port[nr_dev]) == 2
#endif
);
nr_dev++;

_

2004-01-09 23:05:09

by cheuche+lkml

[permalink] [raw]

Subject: Re: 2.6.1-mm1 - nforce2 timer patch sum up

On Fri, Jan 09, 2004 at 01:20:38PM -0800, Andrew Morton wrote:
> "Prakash K. Cheemplavam" <[email protected]> wrote:
> >
> > Hi,
> >
> > could it be that you took out /or forgot to insterst the work-around for
> > nforce2+apic? At least I did a test with cpu disconnect on and booted
> > kernel and it hang. (I also couldn't find the work-around in the
> > sources.) I remember an earlier mm kernel had that workaround inside.
> >
>
> I discussed it with Bart and he felt that it was not a good way of fixing
> the problem. I'm not sure if he has a better fix in the works though..

One of the fixes was about getting timer interrupts on apic. It was a
quick hack from me and definitely wrong. Furthermore, it does
unfortunately nothing against these hangs.

I will try to summarize this problem.

Back in the 2.5 series, timer configuration was :

..TIMER: vector=0x31 pin1=2 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found pin 0) ...works.

and interrupt 0 in /proc/interrupts was IO-APIC-edge.

A fix in mp_override_legacy_irq() in arch/i386/kernel/mpparse.c changes
this behavior to :

..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... works.

and interrupt 0 went to XT-PIC mode, and spurious interrupts on IRQ7
appeared !

It seems that there is no timer connected to pin 2 on the nforce2 apic
when linux tries to find it (MP-BIOS bug with pin1=2). Maybe it is not
connected at all on (all ?) nforce2 motherboards.
However, this configuration information (pin1=2) comes from :

ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

that is, from the BIOS. This is confusing because if the timer is not
connected to this pin, why the bios tells it is ? OK, this won't be the
first broken bios out there.

After some experimentation, I came across with an interesting result
when I change the INT_SRC_OVR's global_irq to 0 (timer connecter to
pin 0, not 2), all I have is :

..TIMER: vector=0x31 pin1=0 pin2=-1

and everything is working great, no spurious or streams of IRQ7, not
even a small drift I noticed with other configurations between LOC count
and IRQ0 count in /proc/interrupts. nmi_watchdog=1 doesn't work however
(well it never worked anyway). Others on lkml achieved more or less the
same result with force-setting the timer on pin 0 with
io_apic_set_pci_routing() and nmi_watchdog=1 works this way.

To sum up about the problem :

- timer is not on pin 2 (or something needs to be done ?)
- bios lies about it in its INT_SRC_OVR (or expect something to be
done ?)
- timer works well on pin 0, through the 8259A or via a hacked
INT_SRC_OVR or a io_apic_set_pci_routing()
- timer on ExtINT or timer in lapic+noapic mode leads to spurious IRQ7

But I cannot see a proper fix. Maybe nvidia or motherboard makers could
tell us why there is an INT_SRC_OVR for the timer telling the kernel to
find it on pin 2 where there is nothing. Intel apic documentation says
this is the correct pin to connect the timer but it does not work on
nforce2 apic. Note that if motherboard makers release a bios with
timer's INT_SRC_OVR on pin 0, this problem magically goes away...
But that would not removes the spurious IRQ7 with local apic but noapic,
since the acpi override would not be looked at, so there might be
another problem.

And this is just the timer problem, the cpu disconnect one is still an
other story. Maybe they are related but the connection is far from
being obvious.

I hope this sum up about one of these two nforce patches helps.

Mathieu

2004-01-09 23:37:26

[permalink] [raw]

Subject: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Fri, Jan 09, 2004 at 01:40:03AM -0800, Andrew Morton wrote:
>...
> All 393 patches
>...
> use-soft-float.patch
> Use -msoft-float
>...

FYI:

This causes the following link error:

<-- snip -->

...
LD .tmp_vmlinux1
drivers/built-in.o(.text+0x55814f): In function `sisfb_do_set_var':
: undefined reference to `__floatsidf'
drivers/built-in.o(.text+0x55816d): In function `sisfb_do_set_var':
: undefined reference to `__divdf3'
drivers/built-in.o(.text+0x55817a): In function `sisfb_do_set_var':
: undefined reference to `__floatsidf'
drivers/built-in.o(.text+0x558196): In function `sisfb_do_set_var':
: undefined reference to `__divdf3'
drivers/built-in.o(.text+0x5581a9): In function `sisfb_do_set_var':
: undefined reference to `__floatsidf'
drivers/built-in.o(.text+0x5581bf): In function `sisfb_do_set_var':
: undefined reference to `__divdf3'
drivers/built-in.o(.text+0x5581cb): In function `sisfb_do_set_var':
: undefined reference to `__adddf3'
drivers/built-in.o(.text+0x5581e0): In function `sisfb_do_set_var':
: undefined reference to `__adddf3'
drivers/built-in.o(.text+0x5581ea): In function `sisfb_do_set_var':
: undefined reference to `__fixunsdfsi'
drivers/built-in.o(.text+0x5584fa): In function `sisfb_do_set_var':
: undefined reference to `__adddf3'
drivers/built-in.o(.text+0x558514): In function `sisfb_do_set_var':
: undefined reference to `__adddf3'
drivers/built-in.o(.text+0x55852e): In function `sisfb_do_set_var':
: undefined reference to `__adddf3'
drivers/built-in.o(.init.text+0x5cde2): In function `sisfb_init':
: undefined reference to `__floatsidf'
drivers/built-in.o(.init.text+0x5cdf5): In function `sisfb_init':
: undefined reference to `__divdf3'
drivers/built-in.o(.init.text+0x5cdff): In function `sisfb_init':
: undefined reference to `__fixunsdfsi'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-01-10 04:06:07

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Adrian Bunk wrote:

> On Fri, Jan 09, 2004 at 01:40:03AM -0800, Andrew Morton wrote:
>
>> ...
>> All 393 patches
>> ...
>> use-soft-float.patch
>> Use -msoft-float
>> ...
>
>

I know. The version of sisfb in 2.6 vanilla is from stone-age. This is
has been fixed a long time ago in my current development version (and
will be in 2.4 as soon as Marcelo applies my patch which I sent him
about a week ago). For 2.6, using my current version requires James
Simmons's fbdev-patch because of low-level fbdev-interface changes (like
sysfs usage, etc).

The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)

Thomas

--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org

2004-01-12 03:25:22

by Linus Torvalds

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Sat, 10 Jan 2004, Thomas Winischhofer wrote:
>
> The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)

Note that the fb stuff is ancient because it's basically not maintained as
far as I'm concerned.

I occasionally get huge drops from James, and they invariably break stuff.
Which means that I often decide (espcially when trying to stabilize
things) that I just can't _afford_ to apply the fr*gging patches. Because
by past experience applying one of the big "everything changes" patches
tends to break more things that it fixes.

I'm sorry, but this i show it is. The fbcon people have been changing
interfaces faster than they have been fixing bugs in the code. Together
with the fact that most of the development seems to happen in outside
trees, and nobody ever sends me fixes relative to the released tree, this
makes for a pretty bad situation.

I really think that development should happen in the regular tree, or at
least be synched up in reasonable chunks THAT DO NOT BREAK everything.

I realize that some fb developers seem to disagree with me, but the fact
is, the way things are done now, fb will _always_ be broken. Most people
for whom the standard kernel works will never test the fb development
trees, so those trees will never get any amount of reasonable testing. As
a result, they WILL be buggy, and synching with them WILL be painful as
hell.

There is a d*mn good reason for why development should happen
incrementally, and in the standard trees, and not in some outside tree.
For one: testing. For another: figuring out when things break in a timely
manner.

Linus

2004-01-12 04:53:51

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Sunday 11 January 2004 21:58, Linus Torvalds wrote:
>On Sat, 10 Jan 2004, Thomas Winischhofer wrote:
>> The whole framebuffer stuff in 2.6 is ancient. (Look at the file
>> dates.)
>
>Note that the fb stuff is ancient because it's basically not
> maintained as far as I'm concerned.
>
>I occasionally get huge drops from James, and they invariably break
> stuff. Which means that I often decide (espcially when trying to
> stabilize things) that I just can't _afford_ to apply the fr*gging
> patches. Because by past experience applying one of the big
> "everything changes" patches tends to break more things that it
> fixes.
>
>I'm sorry, but this i show it is. The fbcon people have been
> changing interfaces faster than they have been fixing bugs in the
> code. Together with the fact that most of the development seems to
> happen in outside trees, and nobody ever sends me fixes relative to
> the released tree, this makes for a pretty bad situation.
>
>I really think that development should happen in the regular tree,
> or at least be synched up in reasonable chunks THAT DO NOT BREAK
> everything.
>
>I realize that some fb developers seem to disagree with me, but the
> fact is, the way things are done now, fb will _always_ be broken.
> Most people for whom the standard kernel works will never test the
> fb development trees, so those trees will never get any amount of
> reasonable testing. As a result, they WILL be buggy, and synching
> with them WILL be painful as hell.
>
>There is a d*mn good reason for why development should happen
>incrementally, and in the standard trees, and not in some outside
> tree. For one: testing. For another: figuring out when things break
> in a timely manner.
>
> Linus
>-

I can well see your reticence in view of the situation, I think I'd be
gun-shy too. Its called prudence.

However, since I've been running 2.6.1-mm1 here, using the rivafb with
an elderly gforce2-mx2 32 megger, I've noted that when running
kde-3.1.1a with 8 windows, and a couple of them have multimegabyte
backdrops, the biggest one being that famous deep space shot from
hubble of about 4 or 5 months back. In any other kernel, switching
to that window took about 12 seconds for the backdrop to be converted
to 1600x1200x32 and drawn the first time and about 8 seconds for the
next time. But with this 2.6.1-mm1 kernel, that repeat window switch
is so close to instant that I cannot see it being drawn.

So as far as I'm concerned, this particular set of fb patches to
rivafb *need* to stay in mainline. I'd sure appreciate it, a bunch.

This ones a winner I think.
>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/

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 05:43:54

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Gene Heskett <[email protected]> wrote:
>
> However, since I've been running 2.6.1-mm1 here, using the rivafb with
> an elderly gforce2-mx2 32 megger, I've noted that when running
> kde-3.1.1a with 8 windows, and a couple of them have multimegabyte
> backdrops, the biggest one being that famous deep space shot from
> hubble of about 4 or 5 months back. In any other kernel, switching
> to that window took about 12 seconds for the backdrop to be converted
> to 1600x1200x32 and drawn the first time and about 8 seconds for the
> next time. But with this 2.6.1-mm1 kernel, that repeat window switch
> is so close to instant that I cannot see it being drawn.
>
> So as far as I'm concerned, this particular set of fb patches to
> rivafb *need* to stay in mainline. I'd sure appreciate it, a bunch.

There are no significant fbdev patches in 2.6.1-mm1. There is a DRM
update.

2004-01-12 06:11:31

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Sun, 11 Jan 2004 21:42:59 PST, Andrew Morton said:
> Gene Heskett <[email protected]> wrote:
> > hubble of about 4 or 5 months back. In any other kernel, switching
> > to that window took about 12 seconds for the backdrop to be converted
> > to 1600x1200x32 and drawn the first time and about 8 seconds for the
> > next time. But with this 2.6.1-mm1 kernel, that repeat window switch
> > is so close to instant that I cannot see it being drawn.

> There are no significant fbdev patches in 2.6.1-mm1. There is a DRM
> update.

The 12 seconds coming and 8 seconds going, versus instant, sounds an *awful*
lot like the virtual memory manager making better choices in -mm kernels, so
the pages of pixmap are staying in memory rather than paging out.

Other guess is that o21-sched.patch is DTRT, while the stock scheduler DTWT
for his particular config.

Gene: Can you tell what exactly your system is doing for the 12/8 seconds? Is it
CPU bound, or beating on the disk while paging in/out, or just sitting idle? Leaving
a 'vmstat 1' running while you change backdrops should tell us something.

Attachments:

(No filename) (226.00 B)

2004-01-12 06:21:19

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 00:42, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> However, since I've been running 2.6.1-mm1 here, using the rivafb
>> with an elderly gforce2-mx2 32 megger, I've noted that when
>> running kde-3.1.1a with 8 windows, and a couple of them have
>> multimegabyte backdrops, the biggest one being that famous deep
>> space shot from hubble of about 4 or 5 months back. In any other
>> kernel, switching to that window took about 12 seconds for the
>> backdrop to be converted to 1600x1200x32 and drawn the first time
>> and about 8 seconds for the next time. But with this 2.6.1-mm1
>> kernel, that repeat window switch is so close to instant that I
>> cannot see it being drawn.
>>
>> So as far as I'm concerned, this particular set of fb patches to
>> rivafb *need* to stay in mainline. I'd sure appreciate it, a
>> bunch.
>
>There are no significant fbdev patches in 2.6.1-mm1. There is a DRM
>update.

Whatever it is, its pure speed on this system here, Andrew. DRM?
lemme see if thats even turned on. Nope "# CONFIG_DRM is not set"
Doing a make xconfig, I see that if I turn it on, there is not a
driver for my gforce2/nvidia, so I naturally turned it back off.

I do have VIA and agpgart enabled just above it, and over in the
framebuffer menu, support for framebuffer and nvidia/riva are both
checked.

Anyway, something has made a huge difference in window switching
speeds here, someplace between 2.6.0-mm2 and 2.6.1-mm1. I like it.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 06:34:53

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Gene Heskett <[email protected]> wrote:
>
> >There are no significant fbdev patches in 2.6.1-mm1. There is a DRM
> >update.
>
> Whatever it is, its pure speed on this system here, Andrew. DRM?
> lemme see if thats even turned on. Nope "# CONFIG_DRM is not set"
> Doing a make xconfig, I see that if I turn it on, there is not a
> driver for my gforce2/nvidia, so I naturally turned it back off.
>
> I do have VIA and agpgart enabled just above it, and over in the
> framebuffer menu, support for framebuffer and nvidia/riva are both
> checked.
>
> Anyway, something has made a huge difference in window switching
> speeds here, someplace between 2.6.0-mm2 and 2.6.1-mm1. I like it.

Beats me. Doing that vmstat measurement which Vladis suggests would be
interesting.

2004-01-12 06:47:43

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 01:11, [email protected] wrote:
>On Sun, 11 Jan 2004 21:42:59 PST, Andrew Morton said:
>> Gene Heskett <[email protected]> wrote:
>> > hubble of about 4 or 5 months back. In any other kernel,
>> > switching to that window took about 12 seconds for the backdrop
>> > to be converted to 1600x1200x32 and drawn the first time and
>> > about 8 seconds for the next time. But with this 2.6.1-mm1
>> > kernel, that repeat window switch is so close to instant that I
>> > cannot see it being drawn.
>>
>> There are no significant fbdev patches in 2.6.1-mm1. There is a
>> DRM update.
>
>The 12 seconds coming and 8 seconds going, versus instant, sounds an
> *awful* lot like the virtual memory manager making better choices
> in -mm kernels, so the pages of pixmap are staying in memory rather
> than paging out.
>
>Other guess is that o21-sched.patch is DTRT, while the stock
> scheduler DTWT for his particular config.
>
>Gene: Can you tell what exactly your system is doing for the 12/8
> seconds? Is it CPU bound, or beating on the disk while paging
> in/out, or just sitting idle? Leaving a 'vmstat 1' running while
> you change backdrops should tell us something.

I can try that with the 2 kernels, but it will have to be after amanda
is done with her nightly tour, which will take another 2.5 hours. By
then I expect to be sleeping, or hope to be, its 1:30am here now.

Or maybe not, what do I do when "vmstat 1" prints its column headers and segfaults?:
---
[root@coyote linux-2.6]# vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
Segmentation fault
[root@coyote linux-2.6]#
---
cd'ing to /proc/1, and trying to "cat mem" gets me this:
---
[root@coyote 1]# cat mem
cat: mem: No such process
[root@coyote 1]#
---
Some of the other names there have content, but 'mem' seems to be
a truely empty filename, marked:
-rw------- 1 root root 0 Jan 12 01:32 mem
but apparently inacessable.

This actually sounds pretty serious, and I did have a hard lockup
in the night last night, had to use the reset button, but I think
that was a cpu overheat, I'd run the heat up cause the missus was
squawking about being cold.

I've rearranged things airwise and got the cpu down to below 70C.
These AMD DX-1600 thoroughbreds really are genuine coffee boilers.
I really should replace it with the cheapest barton cored one, but
this ones been running that hot for 30 months now. Running seti 24/7
of course doesn't help. :)

Do I need YANP42.6 (Yet Another New Program 4 2.6)?
Sorry, couldn't resist creating a new acronym. :)

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 07:03:37

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 01:34, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> >There are no significant fbdev patches in 2.6.1-mm1. There is a
>> > DRM
>> >
>> >update.
>>
>> Whatever it is, its pure speed on this system here, Andrew. DRM?
>> lemme see if thats even turned on. Nope "# CONFIG_DRM is not
>> set" Doing a make xconfig, I see that if I turn it on, there is
>> not a driver for my gforce2/nvidia, so I naturally turned it back
>> off.
>>
>> I do have VIA and agpgart enabled just above it, and over in the
>> framebuffer menu, support for framebuffer and nvidia/riva are
>> both checked.
>>
>> Anyway, something has made a huge difference in window switching
>> speeds here, someplace between 2.6.0-mm2 and 2.6.1-mm1. I like
>> it.
>
>Beats me. Doing that vmstat measurement which Vladis suggests would
> be interesting.
I just found that the old standby, top, is apparently showing sane
memory values.
---
Mem: 514720K av, 511360K used, 3360K free, 0K shrd,
11468K buff
Swap: 3857104K av, 42292K used, 3814812K free
317328K cached
---
So at least one program knows howto get at the data.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 06:58:12

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 01:34, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> >There are no significant fbdev patches in 2.6.1-mm1. There is a
>> > DRM
>> >
>> >update.
>>
>> Whatever it is, its pure speed on this system here, Andrew. DRM?
>> lemme see if thats even turned on. Nope "# CONFIG_DRM is not
>> set" Doing a make xconfig, I see that if I turn it on, there is
>> not a driver for my gforce2/nvidia, so I naturally turned it back
>> off.
>>
>> I do have VIA and agpgart enabled just above it, and over in the
>> framebuffer menu, support for framebuffer and nvidia/riva are
>> both checked.
>>
>> Anyway, something has made a huge difference in window switching
>> speeds here, someplace between 2.6.0-mm2 and 2.6.1-mm1. I like
>> it.
>
>Beats me. Doing that vmstat measurement which Vladis suggests would
> be interesting.

See my reply to Vladis of 30 seconds ago, it gets even curiouser!
vmstat 1 segfaults, /proc/1/mem isn't readable.
Interesting indeed. And I cannot get at the stats with ksysguard,
"cannot connect to FQDN" I didn't have that enabled in gkrellm, and
when I do its just a blank header, so its not getting anything
either.

Yup, curiouser and curiouser...

Whats interesting in /sys in this area?

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 07:05:35

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Gene Heskett <[email protected]> wrote:
>
> Or maybe not, what do I do when "vmstat 1" prints its column headers and segfaults?:

You probably need a new vmstat. There were quite a few buggy ones around.
Make sure you have a current procps.

2004-01-12 07:20:54

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 02:05, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> Or maybe not, what do I do when "vmstat 1" prints its column
>> headers and segfaults?:
>
>You probably need a new vmstat. There were quite a few buggy ones
> around. Make sure you have a current procps.

And where are they available? I'm not allergic to ripping out the
rpms if need be. Do you have a list of compatible pairings showing
version numbers to get?

Gah, bedtime..

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 09:00:17

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Linus Torvalds wrote:
>
> On Sat, 10 Jan 2004, Thomas Winischhofer wrote:
>
>>The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)
>
>
> Note that the fb stuff is ancient because it's basically not maintained as
> far as I'm concerned.

Erm, well, _I_ know. But I assume you meant this message mainly for the
public.

> I'm sorry, but this i show it is. The fbcon people have been changing
> interfaces faster than they have been fixing bugs in the code. Together

You tell me. I actually stopped adapting sisfb for a couple of months
during the 2.5 development cycle - I could not keep up with the speed of
substantial changes either.

> with the fact that most of the development seems to happen in outside
> trees, and nobody ever sends me fixes relative to the released tree, this
> makes for a pretty bad situation.
>
> I really think that development should happen in the regular tree, or at
> least be synched up in reasonable chunks THAT DO NOT BREAK everything.
>
> I realize that some fb developers seem to disagree with me, but the fact
> is, the way things are done now, fb will _always_ be broken. Most people
> for whom the standard kernel works will never test the fb development
> trees, so those trees will never get any amount of reasonable testing. As
> a result, they WILL be buggy, and synching with them WILL be painful as
> hell.

Isn't a large part of the fbcon/dev stuff in current 2.6 broken anyway?
Could it become worse by merging James' current changes? But I guess
this question - as well as the rest of your message - is for James to
answer.

If the lastest and greatest of the fbdev stuff isn't merged with 2.6.2,
I will revert the interface changes in sisfb and send a patch which
works with the then-current vanilla kernel.

Thomas

--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net/
twini AT xfree86 DOT org

2004-01-12 10:36:51

by Andrew Walrond

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 Jan 2004 2:58 am, Linus Torvalds wrote:
>
> I occasionally get huge drops from James, and they invariably break stuff.
> Which means that I often decide (espcially when trying to stabilize
> things) that I just can't _afford_ to apply the fr*gging patches. Because
> by past experience applying one of the big "everything changes" patches
> tends to break more things that it fixes.
>

I want the new fb stuff very badly.

My particular application is a game which has it's own software 3D renderer,
so it just needs to be able to blast the frames into video ram. A good fbdev
would mean not needing X, which would be nice.

Please consider this for inclusion in very early 2.7. And I urge James to work
with Linus on this. Perhaps when it's stable in 2.7, we can back-port to
2.6 :)

Andrew Walrond

2004-01-12 12:38:13

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 >Gene Heskett <[email protected]> wrote:
what do I do when "vmstat 1" prints its column
There were quite a few buggy ones
have a current procps.
in 3.15.something.
started x, open a shell and ran vmstat 1
really big backdrop window, 8 or 9
Switched back to window 1, instant,
Back to 1 & kill vmstat.
for that time period.
---swap-- -----io---- --system-- ----cpu----
bi bo in cs us sy id wa
0 0 715 134 1084 2191 59 10 21 10
0 0 0 0 1273 4856 96 4 0 0
0 0 0 376 1303 4726 96 4 0 0
0 0 0 36 1311 3546 98 2 0 0
0 0 0 0 1071 2414 99 1 0 0
0 0 600 24 1077 2770 97 3 0 0
0 0 1152 0 1076 2477 97 3 0 0
0 0 1152 12 1059 2466 95 5 0 0
0 0 1152 16 1063 2332 94 6 0 0
0 0 1000 0 1060 2335 96 4 0 0
0 0 0 0 1064 2416 98 2 0 0
0 0 0 12 1052 2363 99 1 0 0
0 0 0 12 1050 2371 100 0 0 0
0 0 0 16 1050 13575 83 17 0 0
0 0 0 0 1128 2649 99 1 0 0
0 0 0 0 1083 2470 98 2 0 0
0 0 28 0 1062 2793 98 2 0 0
0 0 0 16 1052 2306 99 1 0 0
0 0 0 16 1122 2524 99 1 0 0
0 0 0 0 1096 2526 99 1 0 0
0 0 0 0 1056 3281 99 1 0 0
0 0 0 0 1050 2335 100 0 0 0
0 0 0 136 1080 2295 99 1 0 0
0 0 0 16 1057 2315 99 1 0 0
0 0 0 0 1063 3037 99 1 0 0
0 0 0 0 1164 2709 95 5 0 0
0 0 0 0 1061 2785 99 1 0 0
0 0 0 112 1362 2862 90 10 0 0
0 0 0 16 1227 2612 94 6 0 0
was there before I noticed it. Now I'll try another
the oldest currently in my grub.conf
---swap-- -----io---- --system-- ----cpu----
bi bo in cs us sy id wa
0 0 866 158 1098 2424 54 12 23 12
0 0 0 36 1204 2788 99 1 0 0
0 0 0 12 1060 2697 99 1 0 0
0 0 0 0 1050 2379 99 1 0 0
0 0 0 0 1049 2365 99 1 0 0
0 0 0 304 1199 3357 98 2 0 0
0 0 0 16 1136 3077 99 1 0 0
0 0 544 36 1101 2856 95 5 0 0
0 0 1152 0 1076 2375 95 5 0 0
0 0 1280 0 1060 3062 96 4 0 0
0 0 1152 788 1201 2370 96 4 0 0
0 0 928 220 1065 2423 96 4 0 0
0 0 0 0 1048 2411 97 3 0 0
0 0 0 0 1051 2399 99 1 0 0
0 0 0 0 1050 2425 99 1 0 0
0 0 0 4 1050 13626 83 17 0 0
0 0 0 0 1052 2362 100 0 0 0
0 0 0 16 1131 2608 95 5 0 0
0 0 0 0 1051 2362 100 0 0 0
0 0 0 0 1050 2346 99 1 0 0
0 0 28 12 1064 2824 99 1 0 0
0 0 0 0 1200 2728 96 4 0 0
0 0 0 16 1056 2704 99 1 0 0
0 0 0 0 1052 2358 100 0 0 0
0 0 0 16 1058 2567 99 1 0 0
0 0 0 0 1061 2422 99 1 0 0
0 0 0 0 1176 2697 99 1 0 0
0 0 0 16 1050 3050 98 2 0 0
0 0 0 0 1051 2382 100 0 0 0
0 0 0 0 1064 2830 98 2 0 0
0 0 0 12 1174 2708 99 1 0 0
0 0 0 0 1053 2590 99 1 0 0
---swap-- -----io---- --system-- ----cpu----
bi bo in cs us sy id wa
0 0 0 16 1098 2513 98 2 0 0
0 0 0 0 1112 2876 98 2 0 0
0 0 0 0 1227 2881 97 3 0 0
0 0 0 0 1054 2434 99 1 0 0
0 0 0 12 1086 2463 99 1 0 0
was done, was done even that early. Anyway, back to
But I have to build it first, brb :)
"vmstat 1" now shows:
---swap-- -----io---- --system-- ----cpu----
bi bo in cs us sy id wa
0 0 869 160 1099 2513 53 12 24 11
0 0 0 0 1358 5053 96 4 0 0
0 0 0 0 1135 2651 99 1 0 0
0 0 856 0 1083 2726 97 3 0 0
0 0 1280 36 1093 2775 95 5 0 0
0 0 1152 304 1128 2450 96 4 0 0
0 0 1160 0 1068 2406 96 4 0 0
0 0 608 0 1054 2374 95 5 0 0
0 0 0 0 1048 2357 99 1 0 0
0 0 0 16 1098 2414 99 1 0 0
0 0 0 876 1178 3047 98 2 0 0
0 0 0 12 1096 13784 85 15 0 0
0 0 0 0 1132 2601 99 1 0 0
0 0 28 0 1145 2995 99 1 0 0
0 0 0 16 1121 2636 99 1 0 0
0 0 0 16 1169 2640 98 2 0 0
0 0 0 0 1109 2982 99 1 0 0
0 0 0 0 1215 2797 100 0 0 0
And that covers the range of whats still
I hope all this noise is usefull data, but I
the old man wasn't paying sufficient attention.
During the build, I noticed that the advansis
Its working here just fine and probably
to be used in defense of liberty: soap,
Please use in that order."
not too shabby for a WV hillbilly
note, additions to this message
Eugene Heskett, all rights reserved.

2004-01-12 15:00:27

by Moritz Muehlenhoff

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Thomas Winischhofer wrote:
> Isn't a large part of the fbcon/dev stuff in current 2.6 broken anyway?
> Could it become worse by merging James' current changes?

Well, yes. The current version of sisfb works very well on my SIS630 notebook
and the current radeonfb works in most circumstances, while applying James'
code drops over the last months has always lead to visual corruptions of
radeonfb, that make it almost unusable.
It would be very good if the fbdev patches would be available as separate
patches.

2004-01-12 16:35:34

by Dave Jones

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Mon, Jan 12, 2004 at 01:21:12AM -0500, Gene Heskett wrote:

> DRM? lemme see if thats even turned on. Nope "# CONFIG_DRM is not set"
> Doing a make xconfig, I see that if I turn it on, there is not a
> driver for my gforce2/nvidia, so I naturally turned it back off.
>
> I do have VIA and agpgart enabled just above it

With CONFIG_DRM off, the AGP options may as well be turned off too,
as they do nothing[1] on a system without 3d acceleration.

Dave

[1] Well, unless you have an Intel i8xx chipset where you need it for
the horrid framebuffer needs memory through GART hack.
And in your case, you don't have one of these.

2004-01-12 17:05:52

by Dave Jones

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Mon, Jan 12, 2004 at 12:00:19PM -0500, Gene Heskett wrote:

> Are you saying I should turn it on, but just not select a specific
> makers chip-boardset? Or that I should go get a different card?

Might as well turn it off completely. You have an Nvidia card, and
that isn't supported by DRI. (AGPGART is just a soft-dependancy for AGP
based cards that DRI supports)

> But, I'm thinking of building another, and certainly open for video
> card suggestions within the 'utility' price range.

Apart from the integrated chipsets from Intel/VIA etc sadly, there's really
not much in the graphics world that has 100% opensource drivers any more.
Basically, forget it for the high performance end of the market.
(And these days, even most of the commodity stuff (NVIDIA, ATI etc) falls
into that bracket)

Dave

2004-01-12 17:00:32

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Monday 12 January 2004 11:33, Dave Jones wrote:
>On Mon, Jan 12, 2004 at 01:21:12AM -0500, Gene Heskett wrote:
> > DRM? lemme see if thats even turned on. Nope "# CONFIG_DRM is
> > not set" Doing a make xconfig, I see that if I turn it on, there
> > is not a driver for my gforce2/nvidia, so I naturally turned it
> > back off.
> >
> > I do have VIA and agpgart enabled just above it
>
>With CONFIG_DRM off, the AGP options may as well be turned off too,
>as they do nothing[1] on a system without 3d acceleration.
>
> Dave
>
>[1] Well, unless you have an Intel i8xx chipset where you need it
> for the horrid framebuffer needs memory through GART hack.
> And in your case, you don't have one of these.

Are you saying I should turn it on, but just not select a specific
makers chip-boardset? Or that I should go get a different card?

In which case I'd have about an 80 dollar limit as I'm not a game
player that needs a 500 dollar video card. OTOH, as long as I stay
the hell away from nvidias own drivers, this card has been quite
bulletproof. The only thing thats missing is the GLX extensions.

The last time I brought an ATI card home, the box carried no
indication that it was anything but what it said it was. But it
couldn't be made to work, new vendor/product code return. I called
ATI on my quarter and was told rather snippishly that it worked fine
with their windows drivers that were on the cd, and that if I wanted
support, I had to be running windows. So I bought a driver from
xorg, didn't work, same problem, except no refund was available. I
got snotty, and they did too. Screw both of 'em, and the camels that
rode in on them, That left nvidia as the other major player, so
thats what I bought with my refund. It worked right out of the box.

tvtime, even running full screen, runs just fine here on this old
card, as does the vlc stuff, but thats the extent of my requirements
for full motion video.

But, I'm thinking of building another, and certainly open for video
card suggestions within the 'utility' price range.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2004-01-12 17:54:47

by Jesse Allen

[permalink] [raw]

Subject: Re: 2.6.1-mm1

Andrew Morton wrote:
> "Prakash K. Cheemplavam" <[email protected]> wrote:
> >
> > Hi,
> >
> > could it be that you took out /or forgot to insterst the work-around for
> > nforce2+apic? At least I did a test with cpu disconnect on and booted
> > kernel and it hang. (I also couldn't find the work-around in the
> > sources.) I remember an earlier mm kernel had that workaround inside.
> >
>
> I discussed it with Bart and he felt that it was not a good way of fixing
> the problem. I'm not sure if he has a better fix in the works though..

I didn't think these patches would make it into a kernel tree, except experimental ones. For one, I don't think we know what's wrong with the nforce2's apic timer. And second, I don't need the disconnect patch, because I have verfied a BIOS update has fixed C1 disconnect completely for my board. (works on and off)

If anyone needs stability, they should try the C1 disconnect off patch, use athcool, or set it off in the bios (whatever works). As for me, I'd rather have it not default off because my board now works with it on and keeps my system cooler.

2004-01-12 18:38:07

by Prakash K. Cheemplavam

[permalink] [raw]

Subject: Re: 2.6.1-mm1

Jesse Allen wrote:
> I didn't think these patches would make it into a kernel tree, except experimental ones. For one, I don't think we know what's wrong with the nforce2's apic timer. And second, I don't need the disconnect patch, because I have verfied a BIOS update has fixed C1 disconnect completely for my board. (works on and off)

Isn't is possbile to find out which registers were altered with the new
bios? Ie. read out registers with out bios and then with new bios adn
then compare? Then we (well someone smarter than me :)) could make a
real fix for the nforce2-apic issue.

Prakash

2004-01-13 19:04:57

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Sat, Jan 10, 2004 at 05:04:53AM +0100, Thomas Winischhofer wrote:
> Adrian Bunk wrote:
>
> > On Fri, Jan 09, 2004 at 01:40:03AM -0800, Andrew Morton wrote:
> >
> >> ...
> >> All 393 patches
> >> ...
> >> use-soft-float.patch
> >> Use -msoft-float
> >> ...
> >
> >
>
> I know. The version of sisfb in 2.6 vanilla is from stone-age. This is
> has been fixed a long time ago in my current development version (and
> will be in 2.4 as soon as Marcelo applies my patch which I sent him
> about a week ago). For 2.6, using my current version requires James
> Simmons's fbdev-patch because of low-level fbdev-interface changes (like
> sysfs usage, etc).
>
> The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)

Until the framebuffer stuff in 2.6 gets updated, I'm suggesting the
patch below to mark FB_SIS as BROKEN.

> Thomas

cu
Adrian

--- linux-2.6.1-mm2/drivers/video/Kconfig.old 2004-01-13 20:02:28.000000000 +0100
+++ linux-2.6.1-mm2/drivers/video/Kconfig 2004-01-13 20:02:55.000000000 +0100
@@ -696,7 +696,7 @@

config FB_SIS
tristate "SIS acceleration"
- depends on FB && PCI
+ depends on FB && PCI && BROKEN
help
This is the frame buffer device driver for the SiS 630 and 640 Super
Socket 7 UMA cards. Specs available at <http://www.sis.com.tw/>.

2004-01-14 00:36:12

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

Adrian Bunk wrote:
> On Sat, Jan 10, 2004 at 05:04:53AM +0100, Thomas Winischhofer wrote:
>
>>Adrian Bunk wrote:
>>
>>
>>>On Fri, Jan 09, 2004 at 01:40:03AM -0800, Andrew Morton wrote:
>>>
>>>
>>>>...
>>>>All 393 patches
>>>>...
>>>>use-soft-float.patch
>>>> Use -msoft-float
>>>>...
>>>
>>>
>>I know. The version of sisfb in 2.6 vanilla is from stone-age. This is
>>has been fixed a long time ago in my current development version (and
>>will be in 2.4 as soon as Marcelo applies my patch which I sent him
>>about a week ago). For 2.6, using my current version requires James
>>Simmons's fbdev-patch because of low-level fbdev-interface changes (like
>>sysfs usage, etc).
>>
>>The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)
>
>
> Until the framebuffer stuff in 2.6 gets updated, I'm suggesting the
> patch below to mark FB_SIS as BROKEN.

I think that's a bit harsh. It basically works, it just illegally uses
some FP operations (as it still does in 2.4 until Marcelo finally
applies the patch I have sent him for three times now - hint, hint)

Thomas

--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org

2004-01-15 11:33:11

[permalink] [raw]

Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error

On Wed, Jan 14, 2004 at 01:35:00AM +0100, Thomas Winischhofer wrote:
> >
> >Until the framebuffer stuff in 2.6 gets updated, I'm suggesting the
> >patch below to mark FB_SIS as BROKEN.
>
> I think that's a bit harsh. It basically works, it just illegally uses
> some FP operations (as it still does in 2.4 until Marcelo finally
> applies the patch I have sent him for three times now - hint, hint)

Now that -mm uses -msoft-float, this means that FB_SIS does no longer
compile...

> Thomas

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-01-15 11:44:22