On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > What happens if you create a buffer cache entry? Does that
> > invalidate the page cache one? Or do you just allow invalidates one
> > way, and not the other? And why=
>
> I just figured on one way invalidates, because that seems cheap and
> eas
Hi everyone,
Mark, I got your point about the dma/udma stuffs. My hdparm setting is UDMA w/
MultiSector 16..
I had recompiled my kernel and disabled the FB option but my linux box still hanged
(another completely freeze) yesterday... Oh well..
I have been tracking this thread for a few days a
I am doing the following:
malloc some memory is user space
pass its pointer to some kernel module
in the kernel module...do a pci_alloc_consistent so that i get a memory
region for PCI DMA operations
now the problem is that i want to remap the address range pointed by the
user space
On Tue, 15 May 2001, Richard Gooch wrote:
> > What happens if you create a buffer cache entry? Does that
> > invalidate the page cache one? Or do you just allow invalidates one
> > way, and not the other? And why=
>
> I just figured on one way invalidates, because that seems cheap and
> easy a
Hi,
The following patches to irq.c were made to deal with potential errors in
creating /proc entries for irqs on bootup. The code add checks to ensure
that the entries were created succesfully. In case of error, it attempts to
cleanup after itself. The patch was made against v2.4.4 of the kernel
Linus Torvalds writes:
>
> On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > However, what about simply invalidating an entry in the buffer cache
> > when you do a write from the page cache?
>
> And how do you do the invalidate the other way, pray tell?
>
> What happens if you create a buffer
On Mon, 14 May 2001, Rik van Riel wrote:
> On Mon, 14 May 2001, Daniel Phillips wrote:
> >
> > How about:
> >
> > > + if (PageActive(page))
> > > + SetPageReferenced(page);
> > > + else
> > > + activate_page(page);
>
> Fine with me ...
Now, please explain to me why it's not j
On Tue, 15 May 2001, Neil Brown wrote:
>
> I want to create a new block device - it is a different interface to
> the software-raid code that allows the arrays to be partitioned using
> normal partition tables.
See the other posts about creating a "disk" layer. Think of it as just a
simple "lvm
Hi,
The following is a patch to the pcmcia code in which a kmalloc failure could
cause the code to crash since the pointer is dereferenced. I've instead
allocated the fixed sized array on the stack. The patch was made against
v2.4.4 of the kernel and result from some errors found during checker r
I have a problem in kernel 2.4.4
I use readw to access memory below 1MB , report "Segmentation fault"
and stall in memory
simple code below (this will get paraller port)
==
int init_module(void){
unsigned int *BIOS_Data=(unsigned int *)0x400;
u32 test;
test = re
On Tue, 15 May 2001, Richard Gooch wrote:
>
> However, what about simply invalidating an entry in the buffer cache
> when you do a write from the page cache?
And how do you do the invalidate the other way, pray tell?
What happens if you create a buffer cache entry? Does that invalidate the
pag
Hi Linus,
There is no reason why bdflush should call page_launder().
Its pretty obvious that bdflush's job is to only write out _buffers_.
Under my tests this patch makes things faster.
Guess why? Because bdflush is writing out buffers when it should instead
blocking inside try_to_free_page
Linus Torvalds writes:
> You could choose to do "partial coherency", ie be coherent only one
> way, for example. That would make the coherency overhead much less,
> but would also make the caches basically act very unpredictably -
> you might have somebody write through the page cache yet on a rea
On Mon, May 14, 2001 at 11:49:16PM -0400, God wrote:
> > Packets are dropped when a device queue
> > fills, and when one sender is much faster than the other the faster sender
> > often wins the race, while the packets of the slower one get dropped.
>
> [.]
>
> Speaking of queues on routers
Linus Torvalds writes:
>
> On Mon, 14 May 2001, Richard Gooch wrote:
> >
> > Is there some fundamental reason why a buffer cache can't ever be
> > fast?
>
> Yes.
>
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page cac
Hi folks. I've never posted a kernel patch before, so I don't know if I
got it right. I followed the instructions in the FAQ... I'm not
subscribed, so if you could follow up to [EMAIL PROTECTED], I would
appreciate it.
This patch adds support for my sound card, which was an OEM version of
the
Oliver Neukum wrote:
> >
> > That's not the issue. LILO takes whatever you pass to root= and converts
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> And happily passes a "root=" arg
On Tuesday, 15. May 2001 00:54, H. Peter Anvin wrote:
> Alexander Viro wrote:
> > On Mon, 14 May 2001, Alan Cox wrote:
> > > > > Except that Linus wont hand out major numbers, which means I can't
> > > > > even boot simply off such a device. I bet the vendors in question
> > > > > dont think the s
Hi all
Thanks for the replies regarding inodes. From the replies I
understood that inode numbers are assigned at the time of accessing in the
case of msdos and nfs files. And it may change during running if it is not
being accessed.
Now the question is who is re
On Mon, 14 May 2001, Linus Torvalds wrote:
>
> How hard is it to generate a new "disk driver framework", and let people
> register themselves, kind of like the "misc" drivers do. Except we'd only
> allow DISKS. You could add something like
>
> register_disk_driver("compaq-ciss", nr_disks,
On Mon, 14 May 2001, David S. Miller wrote:
>
> Larry McVoy writes:
> > Hell, that's the OS that gave us mmap, remember that?
>
> Larry, go read up on TOPS-20. :-) SunOS did give unix mmap(), but it
> did not come up the idea.
s/TOPS-20/Multics/
-
To unsubscribe from this list: send the
On Mon, 14 May 2001, Linus Torvalds wrote:
> The current page cache is completely non-coherent (with _anything_: it's
> not coherent with other files using a page cache because they have a
> different index, and it's not coherent with the buffer cache because that
> one isn't even in the same n
Larry McVoy writes:
> Hell, that's the OS that gave us mmap, remember that?
Larry, go read up on TOPS-20. :-) SunOS did give unix mmap(), but it
did not come up the idea.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, 14 May 2001, Larry McVoy wrote:
> Hell, that's the OS that gave us mmap, remember that?
"I got it from Agnes..."
Don't get me wrong, SunOS 4 was probably the nicest thing Sun had ever
released and I love it, but mmap(2) was _not_ the best of ideas. Files
as streams of bytes and file
hello all:
--
Best Regard!
Àñ£¡
--
mail from: hugang [ºú¸Õ]
mail : [EMAIL PROTECTED] [EMAIL PROTECTED]
company : [EMAIL PROTECTED]
China Beijing Soul [±±¾©ÖÚÖ¾ºÏ´ï]
--
sd_2.4.4.diff
On Mon, 14 May 2001, Linus Torvalds wrote:
>
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page cache.
>
> And keeping it coherent would be _extremely_ expensive. How do we
> know? Because we used to do that. Remember
On Mon, May 14, 2001 at 09:00:44PM -0700, Linus Torvalds wrote:
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page cache.
Not that Linus needs any backing up but Sun got rid of the buffer cache
and just had a page cache
On Mon, 14 May 2001, Alan Cox wrote:
>
> Except that Linus wont hand out major numbers, which means I can't even boot
> simply off such a device. I bet the vendors in question dont think the sun
> shines out of linus backside any more.
Actually, it does. It's just that some people have gotten s
On Mon, 14 May 2001, Alan Cox wrote:
>
> Yet another 2.5 project. If Linus wants to go play with name driven devices
> and you want to help him great, but if he'd care to put out
> linux-2.5.0.tar.gz _before_ starting that would be good for all of us
ACK! .. 2.5?? .. gawd .. I just installed 2.
On Mon, 14 May 2001, Rik van Riel wrote:
> It would be cool if one of you two could update the docs ;)
OK, here is my attempt, as a patch to Configure.help in 2.4.5-pre1. I
hope it is clear, accurate, and not too long-winded, and that my mailer
does not munge patches.
Cheers,
Wayne
--- linux-
On Mon, 14 May 2001, Alan Cox wrote:
> Subject: Re: LANANA: To Pending Device Number Registrants
>
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
While reading the "getting fs access events" thread I remembered
something which I've been meaning to look at for ages.
[some history]
I don't trust programs which dump file systems by reading the data
directly from the block device (I'm never sure that they get things
right). I prefer to do bac
On Mon, 14 May 2001, Richard Gooch wrote:
>
> Is there some fundamental reason why a buffer cache can't ever be
> fast?
Yes.
Or rather, there is a fundamental reason why we must NEVER EVER look at
the buffer cache: it is not coherent with the page cache.
And keeping it coherent would be _ext
On Mon, 14 May 2001, Andi Kleen wrote:
[.]
> Packets are dropped when a device queue
> fills, and when one sender is much faster than the other the faster sender
> often wins the race, while the packets of the slower one get dropped.
[.]
Speaking of queues on routers/servers, does such
Mihai Moldovanu wrote:
>
> In 2.4.2 the driver for this was e100.o
> Can someOne tell me wich one is in 2.4.4 ?
You need to download that from Intel, it's not in the official kernel
and never has been. "eepro100" is the in-kernel driver for those series
of cards.
--
Jeff Garzik | Game ca
In 2.4.2 the driver for this was e100.o
Can someOne tell me wich one is in 2.4.4 ?
--
MihaiM
-
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 th
On Mon, 14 May 2001, Jeff Golds wrote:
> Oh I get it NOW. "Off" means the docs are just plain "off".
It is ... "off" means we do 1GB-128MB = 896MB of memory.
It would be cool if one of you two could update the docs ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, witho
I've implemented most of these as you suggest, with these exceptions:
> > + default:
> > + printk(KERN_INFO "scsi%d (%d:%d): Unexpected message %s: ",
> > + host->host_no, pun, lun,
> > + NCR_700_phase[(dsps & 0xf00) >> 8]);
> > + print_msg(
You can get a working tree from www.fsmlabs.com/linuxppcbk.html or just
apply the patches in ftp.kernel.org/pub/linux/kernel/people/cort/
If you have any trouble with that, let me know.
} [1.] One line summary of the problem:
} 2.4.4 fails to compile for G3 ppc
}
} [2.] Full description of the
Brian Gerst wrote:
> >
> > It seems obvious once you know why the limits are there. The 1 GB
> > limit (actually 1024-128 MB = 896 MB) is a software limit; the 4 GB
> > and 64 GB limits are hardware limits and are exact.
>
> Even with the 4GB and 64GB options, some physical address space has to
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:Rik van Riel <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > On Mon, 14 May 2001, Wayne Whitney wrote:
> > > In mailing-lists.linux-kernel, you wrote:
> > >
> > > > You need to compile highmem support into
On Tuesday 15 May 2001 01:19, Richard Gooch wrote:
> Linus Torvalds writes:
> > On Sun, 13 May 2001, Richard Gooch wrote:
> > > So, why can't the page cache check if a block is in the buffer
> > > cache?
> >
> > Because it would make the damn thing slower.
> >
> > The whole point of the page cache
I cannot for the life of me get LFS working.
I have recompiled the glibc rpm (the 2.2.1 one)
for i686 and installed it. I have recompiled
fileutils against that glibc. It still tells
me that the file is too large when I do a
dd if=/dev/zero of=bigfile bs=8192
it stops at 2.0GB (ls -lh). What am
Again battling with my SDT-9000, tonight first experiment was:
- Moderately huge file (339443712 bytes). Obtained cat'ing some large
tar.bz2, so essentially 'random data'
- Fixed block size (dd bs=32KB, mt bs=512=default)
- HW data compression at default (enabled)
- Variable machine load (vary
Rik van Riel wrote:
> Where did you get the mythical "1GB" option?
>
> Last I looked we had "off", "4GB" and "64GB" ;)
We do .. under 2.4.x
In 2.2.x we have 1 Gb and 2 GB ... 2.2.19 at least
--
=
Mohammad A. Haque
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote:
> For those of you with Via interrupting routing issues (or
> interrupt-not-being-delivered issues, etc), please try out this patch
> and let me know if it fixes things. It originates from a tip from
> Adrian Cox... thanks Adrian!
Just
On Mon, 14 May 2001 23:55:37 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> > And lilo ?
>Also hdparm
>raidtools
>psmisc
>mtools
>mt-st
>gpm
>joystick
kmod, /etc/modules.conf:
alias block-major-what-random-number-did-the-kernel-pick-this-time driver_name
-
To unsubscribe from this list: s
Rik van Riel wrote:
>
> On Mon, 14 May 2001, Jeff Golds wrote:
>
> > Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option =
> > 4GB. Can I assume a linear relation and get 66.2 MB when I
> > select the 64 MB option?
>
> Where did you get the mythical "1GB" option?
>
> Last I looked w
On Mon, 14 May 2001, Marcelo Tosatti wrote:
> On Mon, 14 May 2001, Rik van Riel wrote:
>
> > + /* XXX: dynamic free target is complicated and may be wrong... */
> > int freetarget = freepages.high + inactive_target / 3;
>
> I think its better if we just remove " + inactive_target / 3" here -
On Mon, 14 May 2001, Jeff Golds wrote:
> Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option =
> 4GB. Can I assume a linear relation and get 66.2 MB when I
> select the 64 MB option?
Where did you get the mythical "1GB" option?
Last I looked we had "off", "4GB" and "64GB" ;)
cheers,
On Mon, 14 May 2001, Alan Cox wrote:
> > I've been doubting whether to work on both the -ac kernels
> > and the -linus tree, but this is a pretty good argument for
> > sticking with -ac and just ignoring the -linus tree...
>
> Time will make that decision. Linus kindly gave us all the power
> to
Followup to: <[EMAIL PROTECTED]>
By author:Rik van Riel <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, 14 May 2001, Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, you wrote:
> >
> > > You need to compile highmem support into the kernel if you want to
> > > use more th
On Mon, 14 May 2001, Ben LaHaise wrote:
> Hey folks,
Hi.
>
> The patch below consists of 3 seperate fixes for helping remove the
> deadlocks present in current kernels with respect to highmem systems.
> Each fix is to a seperate file, so please accept/reject as such.
> The third patch (t
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > Note that using dev->name during probe was always incorrect. Think
> > about the error case:
> ...
> > So, using interface name in this manner was always buggy because it
> > conveys no useful information to the user.
>
> I used to think about cases of
On Mon, 14 May 2001, Rik van Riel wrote:
> Hi Linus,
>
> the following patch does:
> pg_data_t *pgdat = pgdat_list;
> int sum = 0;
> int freeable = nr_free_pages() + nr_inactive_clean_pages();
> + /* XXX: dynamic free target is complicated and may be wrong... */
>
> Why can't we configure this in user space? I think of something like
> /etc/major-numbers. We could then tell the kernel at module load time what
> major number to use for a given driver.
We've got one of those lists. H Peter Anvin maintains it.
Don't get me wrong - if in 2.5.x someone can pro
On Mon, May 14, 2001 at 11:21:00PM +0100, Alan Cox wrote:
> You can make it a string if you like but at the end of the day
> has to be an opaque handle. For constant devices it also has to be
> a constant name. Otherwise the /dev file I archived with the corporate
> backup
Andi Kleen writes:
> On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote:
> > Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> > no more, and I will _not_ accept a "manage by hand" approach any more. The
> > time has long since come to say "No". Which I've done
On Sun, 13 May 2001, Linus Torvalds wrote:
>
> On Sun, 13 May 2001, Rik van Riel wrote:
> >
> > This means that the swapin path (and the same path for
> > other pagecache pages) doesn't take the page lock and
> > the page lock doesn't protect us from other people using
> > the page while we h
Hey folks,
The patch below consists of 3 seperate fixes for helping remove the
deadlocks present in current kernels with respect to highmem systems.
Each fix is to a seperate file, so please accept/reject as such.
The first patch adding __GFP_FAIL to GFP_BUFFER is needed to fix a
livelock caused
Alan Cox writes:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name driven
> devices and you wa
Jeff Golds wrote:
>
> Rik van Riel wrote:
> >
> > On Mon, 14 May 2001, Wayne Whitney wrote:
> > > In mailing-lists.linux-kernel, you wrote:
> > >
> > > > You need to compile highmem support into the kernel if you want to
> > > > use more than 890 MB of RAM, set it to maximum 4GB for best
> > > >
Alan Cox writes:
> > > (c) does not require devfs. most distros ship without it afaik, and
> > > switching to it is not an overnight process, and requires devfsd to be
> > > useful in the real world.
> > >
> >
> > It does, however, not manage permissions, nor does it provide for a sane
> > name
Rik van Riel wrote:
>
> On Mon, 14 May 2001, Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, you wrote:
> >
> > > You need to compile highmem support into the kernel if you want to
> > > use more than 890 MB of RAM, set it to maximum 4GB for best
> > > performance...
> >
> > On a similar
> > 323
> > Also hdparm
> > raidtools
> > psmisc
> > mtools
> > mt-st
> > gpm
> > joystick
>
> so we now have a list of stuff that needs to be fixed 8)
> or at least, a cross section sampling of stuff to design a new API for.
Yes. Most of it actually uses the major stuff to answer the questi
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
/me looks and barfs.
Alan, had you actually looked at it? It will require massive changes
whenever you introduce new major. And most of such areas are stuff
that doesn't matter for new devices anyway - geometry, e
On Mon, 14 May 2001, Alan Cox wrote:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name driv
On Mon, 14 May 2001, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, you wrote:
>
> > You need to compile highmem support into the kernel if you want to
> > use more than 890 MB of RAM, set it to maximum 4GB for best
> > performance...
>
> On a similar note, what is the maximum physical memo
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> That's why you want mount-root-by-partition-label, not by device
Which in itself adds the 'and how does the label tell me what modules
Before merging both hard disks I saw each of them as a separate SCSI
device, at boot time and when the system booted up. After building the
RAID1, when the system boots I only see one RAID device recognized, and so
do I when linux recognizes it.
[root@lala log]# cat /proc/scsi/dpt_i2o/0
Vendor: D
In article <[EMAIL PROTECTED]> you wrote:
> That's not the issue. LILO takes whatever you pass to root= and converts
> it to a device number at /sbin/lilo time. An idiotic practice on the
> part of LILO, in my opinion, that ought to have been fixed a long time
> ago.
That's why you want mount-
Linus Torvalds writes:
>
>
> On Sun, 13 May 2001, Richard Gooch wrote:
> >
> > OK, provided the prefetch will queue up a large number of requests
> > before starting the I/O. If there was a way of controlling when the
> > I/O actually starts (say by having a START flag), that would be ideal,
> >
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
> Also hdparm
> raidtools
> psmisc
> mtools
> mt-st
> gpm
> joystick
so we now have a list of stuff that needs to be fixed 8)
or at least, a cross section sampling of stuff to design a new API for.
-Dan
-
To unsubs
On Mon, 14 May 2001, H. Peter Anvin wrote:
> > LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> > on the kernel side. Ask Andries how much do they have in common with
> > BIOS drive numbers.
> >
>
> That's not the issue. LILO takes whatever you pass to root= and conv
Hi,
I built a nice mp3 player out of a AMD 486-DX133 and a soundblaster
es1371. I always used 2.2.16 and it worked properly. Due to several
reasons I want to switch to 2.4, so I tried my luck with 2.4.4-ac6.
Basically it works but the sound gets interrupted (around 0.5 - 5seconds
silence) from ti
> > And lilo ?
>
> LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> on the kernel side. Ask Andries how much do they have in common with
> BIOS drive numbers.
grep MAJOR lilo-21.4.4/*|wc -l
323
Also hdparm
raidtools
psmisc
mtools
mt-st
gpm
joystick
and that is a si
> Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> prepare_namespace() (rootfs patch). BFD.
Yet another 2.5 project. If Linus wants to go play with name driven devices
and you want to help him great, but if
In mailing-lists.linux-kernel, you wrote:
> You need to compile highmem support into the kernel if you want to
> use more than 890 MB of RAM, set it to maximum 4GB for best
> performance...
On a similar note, what is the maximum physical memory supported by
the 4GB option?
Cheers, Wayne
-
To u
On Mon, 14 May 2001, Alan Cox wrote:
> > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > simply off such a device. I bet the vendors in question dont think the sun
> > > shines out of linus backside any more.
> >
> > Not really. Special-casing for mounting
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
>
> Not really. Special-casing for mounting root is trivially solvable. BTDT,
> and you've rev
Alexander Viro wrote:
>
> On Mon, 14 May 2001, Alan Cox wrote:
>
> > > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > > simply off such a device. I bet the vendors in question dont think the sun
> > > > shines out of linus backside any more.
> > >
> > > Not
On Mon, 14 May 2001, Alan Cox wrote:
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
>
> Except that Linus wont hand out major numbers, which mea
Alexander Viro wrote:
>
> On Mon, 14 May 2001, H. Peter Anvin wrote:
>
> > Correct. At least at one time it used the offset of the directory entry
> > when that particular inode was last "seen" by the kernel... meaning that
> > when it finally dropped out of the inode cache, it would change ino
What makes you think /dev/sda is the raid? For me cat /proc/scsi/scsi
lists all 4 drives which, to me, implies that it is raw.
fdisk could not partition the raid by default. I needed to use sfdisk the
first time. After that fdisk worked fine.
If I have both modules loaded I can mount /dev/i2
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Daniel writes:
> > I was originally thinking we should give the admin the ability to
> > create a nonindexed directory if desired, and that's how it used to
> > be before we changed the setting of INDEX_FL from directory
> > creation time to lat
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Maybe we can have a "noindex" mount option for this?
We need that regardless, I just keep forgetting to put it in. I assume
the semantics are obvious: no new indexes are created but existing ones
are maintained. I.e., -o noindex does not me
> Would you mind demonstrating such wonder? Old devices are still there,
> AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> the ability to create device nodes for them.
Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I b
> buz.c references KMALLOC_MAXSIZE which appears to be no longer defined.
> In order to build it, I've had to re-add this define to slab.h.
>
> Saw it in 2.4.3. Still in 2.4.4
buz.c is dead. Use the -ac kernel and the ZR36067 driver
-
To unsubscribe from this list: send the line "unsubscribe li
> It's not so much about hardcoding the names as hardcoding the *STRUCTURE*
> of the names. For example, the current devfs has /dev/misc/* which is
> completely bogus -- it exposes an implementation detail (using the
The fact kernel space touches on naming directly is itself bogus. devfsd doing
On Mon, May 14, 2001 at 03:50:01PM -0400, Stuart MacDonald wrote:
> What version of serial.c? I'm assuming 5.05.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
> Define "go kablooey". We haven't noticed any problems, and we supplied
> this bit of code.
"G
[EMAIL PROTECTED] wrote on 11.05.01 in <[EMAIL PROTECTED]>:
> I think man is the best help system ever devised. (The GNU Info system,
> however, is the spawn of Satan. :-)
Both have good and bad parts. HTML and PDF are yet other such candidates.
Something better is needed, but no two people s
buz.c references KMALLOC_MAXSIZE which appears to be no longer defined.
In order to build it, I've had to re-add this define to slab.h.
Saw it in 2.4.3. Still in 2.4.4
sorry new to this list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Mon, 14 May 2001, Alan Cox wrote:
> Abstract device file systems are beautiful concepts but they don't solve
> the device name space problem and they introduce hideous incompatibilities
> with existing software.
let me get it straight. You are talking about software that would be
a
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> Daniel, you write:
> > Now, if the check routine tells us how much good data it found we
> > could use that to set a limit for the dirent scan, thus keeping the
> > same robustness as the old code but without having all the checks
> > in the inn
Jesper Juhl ([EMAIL PROTECTED]) said:
> I have made a patch against 2.4.4-ac8 that makes the change, it is
> below. I guess someone more knowledgeable than me can probably see if
> this is correct. If this is completely bogus, then please just disregard
> this email.
Yup, it's right. My bad.
> > Then When I tried to fdisk /dev/sda (/dev/sda is a RAID1 of two
> > Quantum disks) syslog shows this:
>
> is /dev/sda the raid or the disks raw ?
/dev/sda is the RAID1
> > So, I don't know if I'm doing something wrong or what, but I haven't been
> > able to get it working on 2.4.4 yet... ple
On Mon, 14 May 2001, H. Peter Anvin wrote:
> Correct. At least at one time it used the offset of the directory entry
> when that particular inode was last "seen" by the kernel... meaning that
> when it finally dropped out of the inode cache, it would change inode
> numbers. I thought that was
On Mon, May 14, 2001 at 04:15:12PM -0500, Samuel Meder wrote:
> I'm seeing a similar effect myself. When I use all my available sdsl
> bandwidth (say doing a bulk data transfer), DNS lookups will often
> time out. This is with the default buffer settings/2.4.4.
The problem is that the DNS resolv
Hi,
This patch renames some PCI_IDS in net drivers to use namespace from
pci_ids.h.
Also the "__{dev,}initdata" variables in pcnet32.c put together.
It seems that the "section type conflict" in pcnet32.c some -ac kernels ago
was caused by __initdata variables not declared together (some public /
On Monday May 14, [EMAIL PROTECTED] wrote:
> > This means that we need some analogue to {get,put}_unnamed_dev that
> > manages a range of dynamically allocated majors.
> > Is there such a beast already, or does someone need to write it?
> > What range(s) should be used for block devices?
> >
> >
1 - 100 of 244 matches
Mail list logo
