for the sysctl binary interface
only leaving sysctl /proc support.
At least the sysctl tables were placed at the end of
the list so user space did not see this mistake.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Looks good, thanks Eric.
Acked-by: Paul Mundt [EMAIL PROTECTED]
-
To unsubscribe
>
Looks good, thanks David.
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
-
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/
.
Acked-by: Paul Mundt [EMAIL PROTECTED]
-
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/
in to account.
The following patch attempts to catch the bogus values and round it up to
at least 0-order.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
mm/page_alloc.c |4
1 file changed, 4 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8c1a116..4a9a83f
in to account.
The following patch attempts to catch the bogus values and round it up to
at least 0-order.
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
mm/page_alloc.c |4
1 file changed, 4 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8c1a116..4a9a83f 100644
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
> I have the source code for a vendor written driver that is targeted at
> 2.6.9. It includes this and then proceeds to manipulate files from the
> driver.
>
> asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
>
On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote:
> > > regarding alignment that don't allow clear_page() to be used
> > > copy_page() in the memcpy() case), but it's going to need a lot of
>
> Maybe these optimalisations should be in the coding style docs?
>
For what purpose?
On Mon, Jan 01, 2007 at 02:59:32AM +0100, Folkert van Heusden wrote:
regarding alignment that don't allow clear_page() to be used
copy_page() in the memcpy() case), but it's going to need a lot of
Maybe these optimalisations should be in the coding style docs?
For what purpose?
On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
I have the source code for a vendor written driver that is targeted at
2.6.9. It includes this and then proceeds to manipulate files from the
driver.
asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
asmlinkage
On Sat, Dec 30, 2006 at 06:04:14PM -0500, Robert P. J. Day wrote:
> fair enough. *technically*, not every call of the form
> "memset(ptr,0,PAGE_SIZE)" necessarily represents an address that's on
> a page boundary. but, *realistically*, i'm guessing most of them do.
> just grabbing a random
On Sat, Dec 30, 2006 at 06:04:14PM -0500, Robert P. J. Day wrote:
fair enough. *technically*, not every call of the form
memset(ptr,0,PAGE_SIZE) necessarily represents an address that's on
a page boundary. but, *realistically*, i'm guessing most of them do.
just grabbing a random example
On Thu, Dec 28, 2006 at 03:03:02PM -0200, Marcelo Tosatti wrote:
> The following patch adds a config option to get rid of the DMA zone on i386.
>
> Architectures with devices that have no addressing limitations (eg. PPC)
> already work this way.
>
> This is useful for custom kernel builds where
On Thu, Dec 28, 2006 at 03:03:02PM -0200, Marcelo Tosatti wrote:
The following patch adds a config option to get rid of the DMA zone on i386.
Architectures with devices that have no addressing limitations (eg. PPC)
already work this way.
This is useful for custom kernel builds where the
On Tue, Dec 26, 2006 at 03:42:57PM +0800, Fengguang Wu wrote:
> On Tue, Dec 26, 2006 at 03:16:52PM +0900, Paul Mundt wrote:
> > pidhash_shift = max(4, fls(megabytes * 4));
> > pidhash_shift = min(12, pidhash_shift);
> > pidhash_size = 1 << pidhas
On Tue, Dec 26, 2006 at 03:42:57PM +0800, Fengguang Wu wrote:
On Tue, Dec 26, 2006 at 03:16:52PM +0900, Paul Mundt wrote:
pidhash_shift = max(4, fls(megabytes * 4));
pidhash_shift = min(12, pidhash_shift);
pidhash_size = 1 pidhash_shift;
+ size = pidhash_size * sizeof
in to account.
The following patch attempts to catch the bogus values and round it up to
at least 0-order (or down, in the PID hash case).
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
kernel/pid.c| 17 +
mm/page_alloc.c |4
2 files changed, 17 insertions
in to account.
The following patch attempts to catch the bogus values and round it up to
at least 0-order (or down, in the PID hash case).
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
kernel/pid.c| 17 +
mm/page_alloc.c |4
2 files changed, 17 insertions(+), 4
: alarm support.
Paul Mundt (18):
sh: Reworked swap cache entry encoding for SH-X2 MMU.
sh: Shut up csum_ipv6_magic() warnings.
sh: push-switch fixups for work_struct API damage.
sh: Add uImage and S-rec generation support.
sh: landisk board build fixes.
sh: Split
: alarm support.
Paul Mundt (18):
sh: Reworked swap cache entry encoding for SH-X2 MMU.
sh: Shut up csum_ipv6_magic() warnings.
sh: push-switch fixups for work_struct API damage.
sh: Add uImage and S-rec generation support.
sh: landisk board build fixes.
sh: Split
This looks like a result of too many auto-merges. The
CONFIG_ARCH_VERSATILE case was handled a total of 6 times.
This kills 5 of them.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
drivers/net/smc91x.h | 90 ---
1 file changed, 90 del
This looks like a result of too many auto-merges. The
CONFIG_ARCH_VERSATILE case was handled a total of 6 times.
This kills 5 of them.
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
--
drivers/net/smc91x.h | 90 ---
1 file changed, 90 deletions
On Sat, Dec 09, 2006 at 07:11:21AM -0500, Robert P. J. Day wrote:
> i'm far more interested in at least knowing what happens to patches
> once they enter the system, so i can plan on what kind of cleanup i
> can work on next.
>
Trivial patches tend not to be a priority for most people, especially
On Sat, Dec 09, 2006 at 07:11:21AM -0500, Robert P. J. Day wrote:
i'm far more interested in at least knowing what happens to patches
once they enter the system, so i can plan on what kind of cleanup i
can work on next.
Trivial patches tend not to be a priority for most people, especially
The changes in 365970a1ea76d81cb1ad2f652acb605f06dae256 result in
cmpxchg() being invoked with bogus sizes with gcc-4.1 on SH, particularly
when kernel/workqueue.c:set_wq_data() is left inlined:
LD .tmp_vmlinux1
kernel/built-in.o: In function `__cmpxchg':
The changes in 365970a1ea76d81cb1ad2f652acb605f06dae256 result in
cmpxchg() being invoked with bogus sizes with gcc-4.1 on SH, particularly
when kernel/workqueue.c:set_wq_data() is left inlined:
LD .tmp_vmlinux1
kernel/built-in.o: In function `__cmpxchg':
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Jamie Lenehan (1):
sh: sh775x/titan fixes for irq header changes.
Mark Glaisher (1):
sh: dma-api channel capability extensions.
Paul Mundt (29):
sh: SE7206 build fixes
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Jamie Lenehan (1):
sh: sh775x/titan fixes for irq header changes.
Mark Glaisher (1):
sh: dma-api channel capability extensions.
Paul Mundt (29):
sh: SE7206 build fixes
On Fri, Dec 01, 2006 at 04:50:50PM +0900, Paul Mundt wrote:
> While working on SH kprobes, I noticed that avr32 got the preemption
> handling wrong in the no probe case. The idea is that upon entry of
> kprobe_handler() preemption is disabled outright across the life of the
> kprobe, o
While working on SH kprobes, I noticed that avr32 got the preemption
handling wrong in the no probe case. The idea is that upon entry of
kprobe_handler() preemption is disabled outright across the life of the
kprobe, only to be re-enabled in post_kprobe_handler().
However, in the event that the
On Thu, Nov 30, 2006 at 10:11:53PM -0500, Mathieu Desnoyers wrote:
> --- a/include/asm-generic/atomic.h
> +++ b/include/asm-generic/atomic.h
[snip]
> +#if 0
> +/* Atomic add unless is only effective on atomic_t on powerpc (at least) */
> +static inline long atomic_long_add_unless(atomic_long_t *l,
On Thu, Nov 30, 2006 at 04:10:08PM -0800, Paul Jackson wrote:
> The call to bitmap_find_free_region(), in arch/sh/kernel/cpu/sh4/sq.c
> looks bogus:
>
> page = bitmap_find_free_region(sq_bitmap, 0x0400,
>get_order(map->size));
>
> It says the
On Thu, Nov 30, 2006 at 04:10:08PM -0800, Paul Jackson wrote:
The call to bitmap_find_free_region(), in arch/sh/kernel/cpu/sh4/sq.c
looks bogus:
page = bitmap_find_free_region(sq_bitmap, 0x0400,
get_order(map-size));
It says the bitmap
On Thu, Nov 30, 2006 at 10:11:53PM -0500, Mathieu Desnoyers wrote:
--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
[snip]
+#if 0
+/* Atomic add unless is only effective on atomic_t on powerpc (at least) */
+static inline long atomic_long_add_unless(atomic_long_t *l, long
While working on SH kprobes, I noticed that avr32 got the preemption
handling wrong in the no probe case. The idea is that upon entry of
kprobe_handler() preemption is disabled outright across the life of the
kprobe, only to be re-enabled in post_kprobe_handler().
However, in the event that the
On Fri, Dec 01, 2006 at 04:50:50PM +0900, Paul Mundt wrote:
While working on SH kprobes, I noticed that avr32 got the preemption
handling wrong in the no probe case. The idea is that upon entry of
kprobe_handler() preemption is disabled outright across the life of the
kprobe, only to be re
rent patch instead
> of the old one. I really should write this text from scratch instead
> of copying it :)
>
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
>
sh and sh64 bits look fine, thanks.
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
pgpPSx6aOkQR3.pgp
Description: PGP signature
write this text from scratch instead
of copying it :)
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
sh and sh64 bits look fine, thanks.
Acked-by: Paul Mundt [EMAIL PROTECTED]
pgpPSx6aOkQR3.pgp
Description: PGP signature
/kernel/syscalls.S |5 +
> include/asm-sh64/unistd.h |7 ++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
Both look good, thanks.
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
pgpMPGgrepOy4.pgp
Description: PGP signature
changed, 11 insertions(+), 1 deletion(-)
Both look good, thanks.
Acked-by: Paul Mundt [EMAIL PROTECTED]
pgpMPGgrepOy4.pgp
Description: PGP signature
On Wed, Aug 10, 2005 at 10:00:57AM +0200, Christoph Hellwig wrote:
> Some architectures have a too different ptrace so we have to exclude
> them: alpha, ia64, m32r, parisc, sparc, sparc64. They continue to
> keep their implementations. For sh64 I had to add a sh64_ptrace wrapper
> because it
On Wed, Aug 10, 2005 at 10:00:57AM +0200, Christoph Hellwig wrote:
Some architectures have a too different ptrace so we have to exclude
them: alpha, ia64, m32r, parisc, sparc, sparc64. They continue to
keep their implementations. For sh64 I had to add a sh64_ptrace wrapper
because it does
On Sun, Aug 07, 2005 at 11:58:03PM +0200, Adrian Bunk wrote:
> The LOG_BUF_SHIFT from lib/Kconfig.debug is sufficient.
>
Yes, looks good, thanks.
pgpnWELFEEFdt.pgp
Description: PGP signature
On Sun, Aug 07, 2005 at 11:58:03PM +0200, Adrian Bunk wrote:
The LOG_BUF_SHIFT from lib/Kconfig.debug is sufficient.
Yes, looks good, thanks.
pgpnWELFEEFdt.pgp
Description: PGP signature
On Thu, Jul 21, 2005 at 11:47:32AM +0200, Jiri Slaby wrote:
> drivers/char/scan_keyb.c
> drivers/char/scan_keyb.h
These still work, but are meant to be used by other drivers and not
standalone. There's a few users of this that haven't been merged yet
anyways.
pgpyJnEZ3e1or.pgp
Description: PGP
On Thu, Jul 21, 2005 at 11:47:32AM +0200, Jiri Slaby wrote:
drivers/char/scan_keyb.c
drivers/char/scan_keyb.h
These still work, but are meant to be used by other drivers and not
standalone. There's a few users of this that haven't been merged yet
anyways.
pgpyJnEZ3e1or.pgp
Description: PGP
On Wed, Jul 20, 2005 at 03:01:56PM +0200, Jan Dittmer wrote:
> Still, for basic compile testing and testing patches on other
> architectures it would be nice, when the patch writer can test his/her
> patch with a simple defconfig, without knowing a common platform for
> this target arch.
This is
On Wed, Jul 20, 2005 at 07:02:53PM +0900, Miles Bader wrote:
> Some archs seem to provide defconfigs for various different platforms,
> which seems nice, and there seems to be some sort of framework for
> doing this, but ...
>
For most of the architectures aimed at embedded systems, having an
On Wed, Jul 20, 2005 at 07:02:53PM +0900, Miles Bader wrote:
Some archs seem to provide defconfigs for various different platforms,
which seems nice, and there seems to be some sort of framework for
doing this, but ...
For most of the architectures aimed at embedded systems, having an
On Wed, Jul 20, 2005 at 03:01:56PM +0200, Jan Dittmer wrote:
Still, for basic compile testing and testing patches on other
architectures it would be nice, when the patch writer can test his/her
patch with a simple defconfig, without knowing a common platform for
this target arch.
This is what
t use a different value (at least for the ones
using generic hardirqs, ia64 seems to be the only one?).
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
include/asm-sh/thread_info.h: needs update
include/asm-sh
to be the only one?).
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
include/asm-sh/thread_info.h: needs update
include/asm-sh64/thread_info.h: needs update
Index: include/asm-sh/thread_info.h
On Fri, Mar 25, 2005 at 09:03:57PM +, Russell King wrote:
> > It would be trivial to treat them both as foobar0 and have the
> > registration succeed for whoever gets it first, but I could see that this
> > would be problematic in the serial8250 case. On the other hand, this is
> > then
On Fri, Mar 25, 2005 at 08:25:08PM +, Russell King wrote:
> Eh? How do you end up with "/sys/devices/platform/foobar0.0" for the
> former case? It has an ID of "-1", and not zero. Your idea doesn't
> make any sense.
>
Yes, I missed the -1 part, so Kyle is correct.
It would be trivial to
On Fri, Mar 25, 2005 at 02:38:22PM -0500, Kyle Moffett wrote:
> So how would you tell the difference between the following?
> device = "foobar0"
> id = -1
> path = "/sys/devices/platform/foobar0"
> versus
> device = "foobar"
> id = 0
> path =
On Fri, Mar 25, 2005 at 10:10:14AM -0800, Greg KH wrote:
> > This might make sense for devices that end in numbers, but does it really
> > make sense for devices that don't?
>
> Then fix those drivers to not put the number in there if they don't have
> one :)
>
But they do have non -1 ids, the
On Wed, Mar 09, 2005 at 04:34:39PM -0800, Greg KH wrote:
> [PATCH] driver core: Separate platform device name from platform device number
>
> Separate platform device name from platform device number such that
> names ending with numbers aren't confusing.
>
This might make sense for devices that
On Wed, Mar 09, 2005 at 04:34:39PM -0800, Greg KH wrote:
[PATCH] driver core: Separate platform device name from platform device number
Separate platform device name from platform device number such that
names ending with numbers aren't confusing.
This might make sense for devices that end
On Fri, Mar 25, 2005 at 10:10:14AM -0800, Greg KH wrote:
This might make sense for devices that end in numbers, but does it really
make sense for devices that don't?
Then fix those drivers to not put the number in there if they don't have
one :)
But they do have non -1 ids, the device
On Fri, Mar 25, 2005 at 02:38:22PM -0500, Kyle Moffett wrote:
So how would you tell the difference between the following?
device = foobar0
id = -1
path = /sys/devices/platform/foobar0
versus
device = foobar
id = 0
path = /sys/devices/platform/foobar0
On Fri, Mar 25, 2005 at 08:25:08PM +, Russell King wrote:
Eh? How do you end up with /sys/devices/platform/foobar0.0 for the
former case? It has an ID of -1, and not zero. Your idea doesn't
make any sense.
Yes, I missed the -1 part, so Kyle is correct.
It would be trivial to treat
On Fri, Mar 25, 2005 at 09:03:57PM +, Russell King wrote:
It would be trivial to treat them both as foobar0 and have the
registration succeed for whoever gets it first, but I could see that this
would be problematic in the serial8250 case. On the other hand, this is
then serial8250's
em_ptr'
drivers/built-in.o(.text+0x628): In function `write_kmem':
mem.c: undefined reference to `xlate_dev_kmem_ptr'
make: *** [.tmp_vmlinux1] Error 1
include/asm-sh/io.h | 11 +++
include/asm-sh64/io.h | 11 +++
2 files changed, 22 insertions(+)
Signed-off-by: Paul Mundt &
/built-in.o(.text+0x628): In function `write_kmem':
mem.c: undefined reference to `xlate_dev_kmem_ptr'
make: *** [.tmp_vmlinux1] Error 1
include/asm-sh/io.h | 11 +++
include/asm-sh64/io.h | 11 +++
2 files changed, 22 insertions(+)
Signed-off-by: Paul Mundt [EMAIL PROTECTED
With the BUG_ON() use in linux/list.h I get this:
CC init/initramfs.o
In file included from include/linux/wait.h:23,
from include/linux/fs.h:205,
from init/initramfs.c:2:
include/linux/list.h: In function `list_del':
include/linux/list.h:164: warning:
With the BUG_ON() use in linux/list.h I get this:
CC init/initramfs.o
In file included from include/linux/wait.h:23,
from include/linux/fs.h:205,
from init/initramfs.c:2:
include/linux/list.h: In function `list_del':
include/linux/list.h:164: warning:
On Tue, Mar 01, 2005 at 03:41:18AM +0100, Adrian Bunk wrote:
> Do modular framebuffers really make sense?
>
Yes, at least these are quite common with embedded systems, quite often
without fbcon. It makes little sense to keep the driver constantly loaded
if the device is not being used as a
On Tue, Mar 01, 2005 at 03:41:18AM +0100, Adrian Bunk wrote:
Do modular framebuffers really make sense?
Yes, at least these are quite common with embedded systems, quite often
without fbcon. It makes little sense to keep the driver constantly loaded
if the device is not being used as a console
cc-option can presently not be used for checking as flags. It seems like
MIPS ran into this already and added their own as-option (which at this
point seems to be completely unused on MIPS, so perhaps it's worth
removing entirely from there).
This patch moves the definition to the top-level
cc-option can presently not be used for checking as flags. It seems like
MIPS ran into this already and added their own as-option (which at this
point seems to be completely unused on MIPS, so perhaps it's worth
removing entirely from there).
This patch moves the definition to the top-level
On Tue, Feb 01, 2005 at 02:05:52PM -0800, Greg KH wrote:
> On Wed, Jan 12, 2005 at 02:48:36PM +0200, Paul Mundt wrote:
> > Yes, it would seem that way. Here we go again:
> >
> > drivers/sh/Makefile |6
> > drivers/sh/superhyway/Makefile
On Tue, Feb 01, 2005 at 02:30:08PM -0800, Greg KH wrote:
> On Tue, Feb 01, 2005 at 11:23:27PM +0100, Sam Ravnborg wrote:
> > On Tue, Feb 01, 2005 at 02:05:52PM -0800, Greg KH wrote:
> > > > drivers/sh/Makefile |6
> > > > drivers/sh/superhyway/Makefile |7 +
On Tue, Feb 01, 2005 at 02:30:08PM -0800, Greg KH wrote:
On Tue, Feb 01, 2005 at 11:23:27PM +0100, Sam Ravnborg wrote:
On Tue, Feb 01, 2005 at 02:05:52PM -0800, Greg KH wrote:
drivers/sh/Makefile |6
drivers/sh/superhyway/Makefile |7 +
On Tue, Feb 01, 2005 at 02:05:52PM -0800, Greg KH wrote:
On Wed, Jan 12, 2005 at 02:48:36PM +0200, Paul Mundt wrote:
Yes, it would seem that way. Here we go again:
drivers/sh/Makefile |6
drivers/sh/superhyway/Makefile |7 +
drivers/sh
On Tue, Jan 11, 2005 at 10:36:52PM +, Russell King wrote:
> However, since it's been rather a long time, I will need to go
> back and redo this patch, along with all the other patches which
> get ARMv6 VIPT aliasing caches working, and then confirm that this
> does indeed end up with something
On Tue, Jan 11, 2005 at 10:36:52PM +, Russell King wrote:
However, since it's been rather a long time, I will need to go
back and redo this patch, along with all the other patches which
get ARMv6 VIPT aliasing caches working, and then confirm that this
does indeed end up with something
On Wed, Jan 12, 2005 at 02:48:36PM +0200, Paul Mundt wrote:
> > Did you forget a .h file with these function prototypes?
> >
> Yes, it would seem that way. Here we go again:
>
I haven't heard anything else from you about this since the last update,
do you have any more iss
On Sat, Jan 22, 2005 at 01:21:02PM +0100, Christoph Hellwig wrote:
> (forgot to mention that I'd like to thank Tom Rini for testing the
> patch on his Hitachi SE7750 and correcting two stupid little bugs)
>
Looks good, I'll apply it, thanks.
pgp6iGuyeaWYx.pgp
Description: PGP signature
On Sat, Jan 22, 2005 at 01:21:02PM +0100, Christoph Hellwig wrote:
(forgot to mention that I'd like to thank Tom Rini for testing the
patch on his Hitachi SE7750 and correcting two stupid little bugs)
Looks good, I'll apply it, thanks.
pgp6iGuyeaWYx.pgp
Description: PGP signature
On Wed, Jan 12, 2005 at 02:48:36PM +0200, Paul Mundt wrote:
Did you forget a .h file with these function prototypes?
Yes, it would seem that way. Here we go again:
I haven't heard anything else from you about this since the last update,
do you have any more issues with this code
m to recall Gates
starting up a foundation for such things, and donating money to charity.
While I may not like alot of the things that MS does, or care for how Gates
does business, I'm still not going to try and blame the worlds problems on
him simply because he does some things I don't like.
Also, say for some reason you are "forced" into working temporarily for such
a company to pay the bills.. nothing is stopping you from looking for alternate
means of employment.
Seems to me you just want the quick and easy way out, and refuse to admit the
possibility that there are other options
ieve that I have been "damaged" by M$.
>
Oh please, next you'll be blaming world hunger on MS because third world
countries can't afford licenses of win2k.
Regards,
--
Paul Mundt <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
be blaming world hunger on MS because third world
countries can't afford licenses of win2k.
Regards,
--
Paul Mundt [EMAIL PROTECTED]
-
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
for alternate
means of employment.
Seems to me you just want the quick and easy way out, and refuse to admit the
possibility that there are other options. Just because you haven't taken the
time to look at them, doesn't mean they don't exist.
Regards,
--
Paul Mundt [EMAIL PROTECTED
, and donating money to charity.
While I may not like alot of the things that MS does, or care for how Gates
does business, I'm still not going to try and blame the worlds problems on
him simply because he does some things I don't like.
Regards,
--
Paul Mundt [EMAIL PROTECTED]
-
To unsubscribe from
On Mon, Jun 18, 2001 at 02:58:17PM -0700, James Simmons wrote:
> > Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis".
>
> Agh!!! That needs to be fixed.
>
I've already fixed it in ruby..
Regards,
--
Paul Mundt <[EMAIL PROTECTED]&g
(). Take a look at drivers/video/sis/sis_main.h,
specifically sisbios_mode[] for a list of supported modes.
Something like:
video=sisfb:mode:640x480x32
should do the job.
Regards,
--
Paul Mundt <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
:
video=sisfb:mode:640x480x32
should do the job.
Regards,
--
Paul Mundt [EMAIL PROTECTED]
-
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
On Mon, Jun 18, 2001 at 02:58:17PM -0700, James Simmons wrote:
Yep, in fbmem.c the name entry is sisfb as opposed to just sis.
Agh!!! That needs to be fixed.
I've already fixed it in ruby..
Regards,
--
Paul Mundt [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
801 - 889 of 889 matches
Mail list logo
