Kai Henningsen wrote:
> No. GEM, I believe, originally came from CP/M. Most popular as the
> windowing system of the Atari ST; given that someone did a quick-hack MS-
> DOS clone to support it on the 68K, it seems fairly obvious that by that
> time, it had already been ported to MS-DOS. (GEM-DOS
Kai Henningsen wrote:
No. GEM, I believe, originally came from CP/M. Most popular as the
windowing system of the Atari ST; given that someone did a quick-hack MS-
DOS clone to support it on the 68K, it seems fairly obvious that by that
time, it had already been ported to MS-DOS. (GEM-DOS is
David Weinehall wrote:
> > We don't provide the binutils or gcc with the kernel either. The 6502
> > is a rather well known processor. Try plonking "6502 assembler" in
> > google and you'll have a lot of choice.
>
> Me likee, finally asm in the kernel I can grok.
Someone else who has trouble
Ryan Cumming wrote:
> When compiling the kernel under FreeBSD, __KERNEL__ is defined, but
> __linux__ is not. I think this is an error on the part of the header file,
> because on non-Linux build environments, which would otherwise compile the
> Linux kernel correctly, do not have __linux__
Ryan Cumming wrote:
When compiling the kernel under FreeBSD, __KERNEL__ is defined, but
__linux__ is not. I think this is an error on the part of the header file,
because on non-Linux build environments, which would otherwise compile the
Linux kernel correctly, do not have __linux__ defined.
David Weinehall wrote:
We don't provide the binutils or gcc with the kernel either. The 6502
is a rather well known processor. Try plonking 6502 assembler in
google and you'll have a lot of choice.
Me likee, finally asm in the kernel I can grok.
Someone else who has trouble with x86
Rik van Riel wrote:
>
> On Fri, 27 Apr 2001, LA Walsh wrote:
>
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile. If you're
> > going to be hit with swap penalties, it may be useful to not have to
> >
[EMAIL PROTECTED] wrote:
>
> <[EMAIL PROTECTED]> wrote:
> >is it going to become the default in future kernel releases?
> It's been that way in the -ac kernels for a while now, but Linus hasn't put it
> into his kernels yet. Perhaps he's waiting until work begins on 2.5, rather
> than break an
Rik van Riel wrote:
On Fri, 27 Apr 2001, LA Walsh wrote:
An interesting option (though with less-than-stellar performance
characteristics) would be a dynamically expanding swapfile. If you're
going to be hit with swap penalties, it may be useful to not have to
pre-reserve
[EMAIL PROTECTED] wrote:
>
> partition. The upgrade, though, will involve wiping the hard drive, allocating
> the whole drive to a single NTFS partition, and reinstalling Notes after
> installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I
> can't mount it read-only
[EMAIL PROTECTED] wrote:
partition. The upgrade, though, will involve wiping the hard drive, allocating
the whole drive to a single NTFS partition, and reinstalling Notes after
installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I
can't mount it read-only because
Alan Cox wrote:
>
> Looks ok to me but given the ability of the average kernel hacker to read
> help texts I;d rather it was a choice menu of say
OK, I guess I gave too much credit :)
This gives 4 options, 4K, 8K, 16K, and 32K.
4K is for the embedded guys, but they might want even less.
32K is
Alan Cox wrote:
>
> Since we expect to get errata docs very soon Im not that worried. As an
> implementation I'd rather a module option of 'ignore_blacklist' or similar
> so that it is runtime
This seamed to work here.
-Thomas
diff -u --new-file --recursive
Andrzej Krzysztofowicz wrote:
>
> IMO, it would be nice to add a test here whether the CONFIG_PRINTK_BUF_LEN
> value is really set as a power of two, eg.:
>
> #if (LOG_BUF_LEN & LOG_BUF_MASK)
> #error CONFIG_PRINTK_BUF_LEN must be a power of two
> #endif
I couldn't figure out how to do it in
Andrzej Krzysztofowicz wrote:
IMO, it would be nice to add a test here whether the CONFIG_PRINTK_BUF_LEN
value is really set as a power of two, eg.:
#if (LOG_BUF_LEN LOG_BUF_MASK)
#error CONFIG_PRINTK_BUF_LEN must be a power of two
#endif
I couldn't figure out how to do it in the
Alan Cox wrote:
Since we expect to get errata docs very soon Im not that worried. As an
implementation I'd rather a module option of 'ignore_blacklist' or similar
so that it is runtime
This seamed to work here.
-Thomas
diff -u --new-file --recursive
Alan Cox wrote:
Looks ok to me but given the ability of the average kernel hacker to read
help texts I;d rather it was a choice menu of say
OK, I guess I gave too much credit :)
This gives 4 options, 4K, 8K, 16K, and 32K.
4K is for the embedded guys, but they might want even less.
32K is
This should allow the printk buffer to be sized during config.
The default size is still 16K. It could use some checking to
insure power-of-2, but CML1 doesn't have a way to
do it that I see. All the architectures should be
covered, and all the default files also have it.
It gets added in the
David Brownell wrote:
> > please correct me if i'm wrong i only don't want to blacklist complete
> > chipset-series
>
> Then feel free to develop and submit a better fix. That'd
> be more practical if AMD's workaround were public. As I
> understand it, the bulk of the production chips have
Alan Cox wrote:
>
> > David Brownell recently added this check to the usb-ohci driver
> > since noone has gotten information from AMD for the workaround,
> > which is rumored to exist, for this bug.
> >
> > Do any of you have contacts within AMD who might be able to
> > get an explanation of the
Alan Cox wrote:
David Brownell recently added this check to the usb-ohci driver
since noone has gotten information from AMD for the workaround,
which is rumored to exist, for this bug.
Do any of you have contacts within AMD who might be able to
get an explanation of the workaround
David Brownell wrote:
please correct me if i'm wrong i only don't want to blacklist complete
chipset-series
Then feel free to develop and submit a better fix. That'd
be more practical if AMD's workaround were public. As I
understand it, the bulk of the production chips have this
This should allow the printk buffer to be sized during config.
The default size is still 16K. It could use some checking to
insure power-of-2, but CML1 doesn't have a way to
do it that I see. All the architectures should be
covered, and all the default files also have it.
It gets added in the
Peter Zaitcev wrote:
>
> > > 2.4.2-ac6
> > > o USB hub kmalloc wrong size corruption fix (Peter Zaitcev)
>
> > The first line of the oops is
> >
> >
> > kernel BUG at slab.c:1398!
> >
> > Any other ideas to try?
> > -Thomas
>
> I did not break it, honest! I will be looking in
Peter Zaitcev wrote:
2.4.2-ac6
o USB hub kmalloc wrong size corruption fix (Peter Zaitcev)
The first line of the oops is
kernel BUG at slab.c:1398!
Any other ideas to try?
-Thomas
I did not break it, honest! I will be looking in a USB mouse
problem
[EMAIL PROTECTED] wrote:
>
>
> which makes sense, I guess, because proc isn't a "real" filesystem. So how do I
> get binfmt_misc mounted?
mount it somewhere else, say, /dev/binfmt_mount instead of in /proc
until the proc entry is fixed. What should creat
/proc/sys/fs/binfmt_misc ?
[EMAIL PROTECTED] wrote:
which makes sense, I guess, because proc isn't a "real" filesystem. So how do I
get binfmt_misc mounted?
mount it somewhere else, say, /dev/binfmt_mount instead of in /proc
until the proc entry is fixed. What should creat
/proc/sys/fs/binfmt_misc ?
Wilfried Weissmann wrote:
>
> Jakob Østergaard wrote:
> > > So... am I just begging for pain if I try to install, say, a stock RH7
> > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing?
> > > If it requires this machine to always boot from a floppy because the driver
> > >
Wilfried Weissmann wrote:
Jakob stergaard wrote:
So... am I just begging for pain if I try to install, say, a stock RH7
on a machine with the FastTrak100 doing it's little RAID0/JBOD thing?
If it requires this machine to always boot from a floppy because the driver
cannot be linked
Andre Hedrick wrote:
> >From siliconvalley.com's GMSV column today:
>self-destruct if it's tampered with. The utility is enabled
>with 11 layers of security defenses, all of which must be
>successfully navigated to disable the system. These layers
>range from a series of forced
Andre Hedrick wrote:
From siliconvalley.com's GMSV column today:
self-destruct if it's tampered with. The utility is enabled
with 11 layers of security defenses, all of which must be
successfully navigated to disable the system. These layers
range from a series of forced
> On Thu, 1 Mar 2001, Hylke van der Schaaf wrote:
>
> > With kernet 2.2.18 DMA mode for my harddisks worked just fine,
> > getting IDE DMA working on an AMD7409 controller with kernel 2.4.2 is a problem.
> >
> > questions:
> > Why is DMA disabled on revision < C4?
> > How can I gat DMA working
On Thu, 1 Mar 2001, Hylke van der Schaaf wrote:
With kernet 2.2.18 DMA mode for my harddisks worked just fine,
getting IDE DMA working on an AMD7409 controller with kernel 2.4.2 is a problem.
questions:
Why is DMA disabled on revision C4?
How can I gat DMA working again?
in
2.4.2-ac3 was fine.
These are the only USB changes I see since then.
> 2.4.2-ac6
> o USB hub kmalloc wrong size corruption fix (Peter Zaitcev)
>
> 2.4.2-ac5
> o Fix busy loop in usb storage(Arjan van de Ven)
> o Fix USB thread wakeup scheduling
2.4.2-ac3 was fine.
These are the only USB changes I see since then.
2.4.2-ac6
o USB hub kmalloc wrong size corruption fix (Peter Zaitcev)
2.4.2-ac5
o Fix busy loop in usb storage(Arjan van de Ven)
o Fix USB thread wakeup scheduling
Mike Castle wrote:
> (libc does usually take care to be able to build against a later kernel
> version than you're running on, and determine at run time what features may
> or may not be there, so one could have a 2.4.2 kernel handy to build libc
> against while still running a 2.2.18 kernel.
Mike Castle wrote:
(libc does usually take care to be able to build against a later kernel
version than you're running on, and determine at run time what features may
or may not be there, so one could have a 2.4.2 kernel handy to build libc
against while still running a 2.2.18 kernel.
Thomas Dodd wrote:
>
> Robert Read wrote:
> >
> > Ok, here is a simple patch to add a config option, I'm compiling it
> > now, so it's not tested yet. One question: what is the best way to
> > force this option to be a power of 2?
>
> Why not just make t
Robert Read wrote:
>
> On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote:
> > Robert Read wrote:
> > >
> > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote:
> > > >
> > > > Has anyone tried 128K buffer size in kernel/pr
Robert Read wrote:
>
> On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote:
> >
> > Has anyone tried 128K buffer size in kernel/printk.c
> > and still have the kernel boot (without
> > hard to notice memory corruption problems and other subtle bugs)?
> > Any hints and tips will be
Robert Read wrote:
On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote:
Has anyone tried 128K buffer size in kernel/printk.c
and still have the kernel boot (without
hard to notice memory corruption problems and other subtle bugs)?
Any hints and tips will be appreciated.
I
Robert Read wrote:
On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote:
Robert Read wrote:
On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote:
Has anyone tried 128K buffer size in kernel/printk.c
and still have the kernel boot (without
hard to notice
Thomas Dodd wrote:
Robert Read wrote:
Ok, here is a simple patch to add a config option, I'm compiling it
now, so it's not tested yet. One question: what is the best way to
force this option to be a power of 2?
Why not just make the config option in Kbytes.
and do:
#define
2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
in IDE initialization. All 3 have ide.2.4.1-p8.all.01172001.patch
applied too. I'll try it without the ide patch today.
-Thomas
---kernel messages---
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system
2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
in IDE initialization. All 3 have ide.2.4.1-p8.all.01172001.patch
applied too. I'll try it without the ide patch today.
-Thomas
---kernel messages---
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system
Jasmeet Sidhu wrote:
>
> Hey guys,
>
> I am attaching my previous email for additional info. Now I am using
> kernel 2.4.1-ac12 and these problems have not gone away.
>
> Anybody else having these problems with a ide raid 5?
>
> The Raid 5 performance should also be questioned..here are some
Jasmeet Sidhu wrote:
Hey guys,
I am attaching my previous email for additional info. Now I am using
kernel 2.4.1-ac12 and these problems have not gone away.
Anybody else having these problems with a ide raid 5?
The Raid 5 performance should also be questioned..here are some number
Peter Samuelson wrote:
>
> [Jeremy M. Dolan]
> > Disk is spelled 'disk' except for Compact Disc and Digital Versatile
> > Disc. If it wasn't 3:30 in the morning, a patch would be attached.
>
> It wouldn't do any good. Many months ago, Ted Ts'o pleaded with
> Richard Gooch (devfs author, from
Peter Samuelson wrote:
[Jeremy M. Dolan]
Disk is spelled 'disk' except for Compact Disc and Digital Versatile
Disc. If it wasn't 3:30 in the morning, a patch would be attached.
It wouldn't do any good. Many months ago, Ted Ts'o pleaded with
Richard Gooch (devfs author, from Australia)
david wrote:
>
> hi i am moving from 2.2.18 to 2.4.0 i have a ide raid set but can not
> get it to run under 2.4.0
> i user mdadd / mdrun to config it. in raid-tools 0.42 but it dose not
> come up under 2.4.0 it just says unknow devices /dev/hda3 & /dev/hdc3
> but thay are thear and when i try
david wrote:
hi i am moving from 2.2.18 to 2.4.0 i have a ide raid set but can not
get it to run under 2.4.0
i user mdadd / mdrun to config it. in raid-tools 0.42 but it dose not
come up under 2.4.0 it just says unknow devices /dev/hda3 /dev/hdc3
but thay are thear and when i try to
Andrea Arcangeli wrote:
>
> On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> >
> > > x()
> > > {
> > >
> > > switch (1) {
> > > case 0:
> > > case 1:
> > > case 2:
> > > case 3:
> > > ;
> > > }
> > > }
>
Andrea Arcangeli wrote:
On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
x()
{
switch (1) {
case 0:
case 1:
case 2:
case 3:
;
}
}
Why am I required to put a `;' only
"Mike A. Harris" wrote:
>
> On Thu, 5 Oct 2000, Harald Welte wrote:
>
> >Some distributions already have the hdparm initscript.
>
> I'm not sure about that one for RH.. I use my own script, but
> there might be one now..
rc.sysinit looks at /etc/sysconfig/harddisks
in pinstripe and guinness.
"Mike A. Harris" wrote:
On Thu, 5 Oct 2000, Harald Welte wrote:
Some distributions already have the hdparm initscript.
I'm not sure about that one for RH.. I use my own script, but
there might be one now..
rc.sysinit looks at /etc/sysconfig/harddisks
in pinstripe and guinness.
55 matches
Mail list logo
