Hi Tony,
I've tried your suggestions and the one about using fbset resulted in a
breakthrough. 'fbset -depth' gave no results, but comparing the output of
'fbset -i' from a working kernel and a new one gave me something to try.
From 2.6.8 kernel (working framebuffer):
mode "1152x900-66"
# D
32-bit applications communicating with the kernel using standard calls
like ioctl() pass through a translation layer that converts the 32-bit
information into 64-bit counterparts, processes them, and converts them
back again before passing them back to userspace.
This is pretty common in sparc64,
I'm also going to read over those atyfb changes in the background and
see if I can figure anything out.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 15 February 2005 01:55, Frans Pop wrote:
> Hello Tony,
>
> Thanks for your reaction.
>
> On Monday 14 February 2005 17:59, Antonino A. Daplas wrote:
> > The above timings are screwed. This is 1024x768 at 85Hz INTERLACED.
> > The fb_find_mode() function picked up this mode when you speci
On Tue, 15 Feb 2005 00:18:08 +0100 (CET)
Michael Tautschnig <[EMAIL PROTECTED]> wrote:
> So the preferred behaviour would be: Add an interface-specification to
> l2tpns' config - or will the above "patch" ever be included in the
> official kernel?
I put the patch into my tree just now, I'll pus
[...]
So add "case TUNSETIFF" to the switch statement above.
You discovered the fix for your own bug, so why not implement
it and submit the resulting patch here? :-)
It might have been intentionally left out - but here we go:
--- linux-2.6.10/fs/compat_ioctl.c 2005-02-15 00:09:53.969591354 +0
On Mon, 14 Feb 2005 23:59:32 +0100 (CET)
Michael Tautschnig <[EMAIL PROTECTED]> wrote:
> switch (cmd) {
> case SIOCGIFFLAGS:
> case SIOCGIFMETRIC:
> case SIOCGIFMTU:
> case SIOCGIFMEM:
> case SIOCGIFHWADDR:
> case SIOCGIFINDEX:
> case SIOCGIFADDR:
> case
Take a look at the dev_ifsioc() function in ioctl32.c-- it does not
copy the data back to userspace except for SIOCSIFMAP, and judging
from the strict definition of TUNSETIFF it should not be required to
do so.
IMHO this isn't true -
switch (cmd) {
case SIOCGIFFLAGS:
case SIOCGIFMETRIC:
Take a look at the dev_ifsioc() function in ioctl32.c-- it does not
copy the data back to userspace except for SIOCSIFMAP, and judging
from the strict definition of TUNSETIFF it should not be required to
do so.
I think if this is functionality that is required (I see no TUNGETIFF,
but I don't play
On Mon, 2005-02-14 at 18:17, Keith M Wesolowski wrote:
> On Mon, Feb 14, 2005 at 06:08:12PM +, Pedro Ramalhais wrote:
>
> > You should be able to reduce that to the SILO limit (not sure what the
> > limit is), anyway i use an ugly SILO hack to make it load bigger images.
> > I'll send it to yo
Hello!
Thanks for the information regarding userland/kernelspace - I think I
understood ...
The reason of my question were problems using the tun/tap interface - I've
got an application (namely l2tpns) demanding the ifreq-structure being
copied back to userspace - which AFAIK doesn't happen in
Thanks, I got it to boot.
Kill these config options.
CONFIG_KALLSYMS=y
No way to kill this -- ???
Don't need either of these.
CONFIG_DUMMY_CONSOLE=y
Can't diable this.
These can be modules, right?
CONFIG_INPUT_MOUSEDEV=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_INPUT_MOUSE=y
No, they are static.
CONFIG_RAM
Here is a atch which forces the arch/sparc/boot directory being built
after all other arch/sparc/* directories. On my 2-way SS20 it makes
"make -j3 vmlinux" working in the first pass. Someone can test it on
machine with more CPUs. I post it here for judgement if it is a correct
way to force the
Do not forget about the patch for FPU context switching in SMP I posted
last month.
Without the patch, I am able to reproduce unexpected FP exceptions in
linker (ld) during the SMP compilation (make -j3 on 2-way SS20). With
the patch they are gone. I found it in the 2.4 kernel, but the buggy
On Mon, Feb 14, 2005 at 06:08:12PM +, Pedro Ramalhais wrote:
> You should be able to reduce that to the SILO limit (not sure what the
> limit is), anyway i use an ugly SILO hack to make it load bigger images.
> I'll send it to you if you're interested, however i'm not sure of the
> consequence
On Mon, 2005-02-14 at 10:53, Meelis Roos wrote:
> I'm trying to test the new framebuffer driver fixes on my SS5-170 (256M
> RAM). I have Debian unstable installed, running 2.6.8 kernel with
> initrd.
>
> I took the lastest 2.6 snapshot and built it. SILO 2.4.8 tells the
> kernel image is too bi
Hello Tony,
Thanks for your reaction.
On Monday 14 February 2005 17:59, Antonino A. Daplas wrote:
> The above timings are screwed. This is 1024x768 at 85Hz INTERLACED.
> The fb_find_mode() function picked up this mode when you specified
> [EMAIL PROTECTED], since there is no such mode in the mod
On Monday 14 February 2005 23:34, Frans Pop wrote:
> On Monday 14 February 2005 12:32, Ben Collins wrote:
> atyfb: Set Visible Mode to 1024x768-8
> atyfb: Virtual resolution 1024x2016, pixclock_in_ps 22349 (calculated
> 22349) atyfb: Dot clock: 44 MHz
> atyfb: Horizontal sync: 35
On Mon, 14 Feb 2005 17:32:07 +0100
"Jurzitza, Dieter" <[EMAIL PROTECTED]> wrote:
> nevertheless we may run into space issues because structures may grow on
> their way from userland to kernel-country, thereby kmalloc() calls are
> subject to earlier failures, as the maximum size of allocable mem
Hi folks,
nevertheless we may run into space issues because structures may grow on their
way from userland to kernel-country, thereby kmalloc() calls are subject to
earlier failures, as the maximum size of allocable memory for kmalloc() remains
the same.
See i. e. linux/include/linux/module.h,
See arch/sparc64/kernel/ioctl32.c, we translate all of the
structures on the way in and out of userspace when 64-bit
kernel runs 32-bit applications.
Hmm - I don't really get the point - would you mind explaining a little?
Is it the following lines or did I overlook anything:
#define COMPATIBLE_IOC
See arch/sparc64/kernel/ioctl32.c, we translate all of the
structures on the way in and out of userspace when 64-bit
kernel runs 32-bit applications.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
Hello!
Is there any generic way in situations, where (pointers
to) structs are transferred from user- to kernelspace and vice versa?
Any struct containing a long int or a pointer will have a different
size in kernel space! This usually happens when doing ioctls ...
I'm not sure, whether it caus
On Monday 14 February 2005 12:32, Ben Collins wrote:
> There's the problem right there. This is all wrong for sparc. Should be
> something like 1024x768, and atleast 70Hz refresh.
Hmm. Not sure if that's the whole problem. I tried booting with
video=atyfb:[EMAIL PROTECTED] (which I know is OK for
William Lee Irwin III wrote:
Between networking and serial it sounds as if this is a partial
explanation as to why I'm having trouble here.
The networking may be a red herring. I only mentioned it because it was
an easy option to remove to get the kernel size back down to a point
where silo woul
On Mon, Feb 14, 2005 at 06:23:09AM -0500, Ben Collins wrote:
> Kill these config options.
[...]
In all honesty the defconfig could use some pruning. I took a stab at
this but have been holding out until after 2.6.11.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe sparclinux"
On Sun, Feb 13, 2005 at 01:51:39AM -0600, Bob Breuer wrote:
> I've been poking at the sparc32 SMP code and I have it to the point
> where it will run a minimal userland. It is still far from being
> stable though.
> For reference, I started with the SMP patch [0] that wli sent to
> the list last J
> atyfb: atyfb_set_par
> atyfb: Set Visible Mode to 640x480-8
> atyfb: Virtual resolution 640x3225, pixclock_in_ps 39751 (calculated 39751)
> atyfb: Dot clock: 25 MHz
> atyfb: Horizontal sync: 31 kHz
> atyfb: Vertical refresh:59 Hz
There's the problem right there. This is al
Kill these config options.
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_EXTRA_PASS=y
Pretty sure you don't need all of these framebuffers, right?
> CONFIG_FB_CG3=y
> CONFIG_FB_CG6=y
> CONFIG_FB_TCX=y
Don't need either of these.
> CONFIG_PROM_CONSOLE=y
> CONFIG_DUMMY_CONSOLE=y
Kill the 12x22, it's hu
I'm trying to test the new framebuffer driver fixes on my SS5-170 (256M
RAM). I have Debian unstable installed, running 2.6.8 kernel with
initrd.
I took the lastest 2.6 snapshot and built it. SILO 2.4.8 tells the
kernel image is too big. Trimmed the config to minimal normal non-initrd
config (
30 matches
Mail list logo
