On Tue, 24 Oct 2000, Pavel Machek wrote:
> Hi!
>
> > > [EMAIL PROTECTED] said:
> > > > You can also pretty trivially keep track of an error term so that the
> > > > clock is right on average:
> > >
> > > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > > Shifti
Hi!
> > [EMAIL PROTECTED] said:
> > > You can also pretty trivially keep track of an error term so that the
> > > clock is right on average:
> >
> > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > Shifting the timer tick onto the RTC will give me that.
> >
>
On Tue, 24 Oct 2000, Petr Vandrovec wrote:
> On 23 Oct 00 at 23:05, Alexander Viro wrote:
>
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
> > Unfortunately, clean test would take the backpo
On 23 Oct 00 at 23:05, Alexander Viro wrote:
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
> Unfortunately, clean test would take the backport of ext2 changes
> (truncate-related, happened around
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Note that if there really are only 9 "nopage" routines, then it is a lot
> easier to just add the single "SetPageUptodate(page)" into those 9
> routines, and thus let the VM know of the race.
Works for me. And yes, the list of ->nopage instances tha
On Tue, 24 Oct 2000, Alexander Viro wrote:
>
> It's not the only problem, but I would feel _much_ safer if pagefault
> wouldn't rely on pagecache miss. Actually... Hey. Why don't we do the
> insertion into page tables _within_ ->nopage()?
NO!
We used to do this a LOONG time ago.
Distributing
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
>
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
>
> I don't think that is it - that code loo
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very straightforward (and is
needed on some silly architect
Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively stabl
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Also, the fact that Petr didn't see anything trigger in nopage() makes me
> nervous again. Even if the problem happened during read-ahead, it should
> have gotten into the address space only through nopage. Maybe there is
> some vma that isn't added
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> I'm starting to suspect that we leave this path as-is, and just fix the
> mapping case (and PageUptodate() can work there). That should also avoid
> the nasties.
..and even that looks like I'd have to do the quick-and-dirty case with
the race stil
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /
Actually, it turns out that even with this issue fixed, there's the more
serious issue that the page _has_ to be removed from the page
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /.
Yeah, the way the truncate logic works right now truncate_whole_page() has
to remove the page from the inode list - otherwise truncat
On 23 Oct 00 at 14:34, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> > >
> > > Nope, that just makes the race window smaller. We should check for i_size
> > > after we've gotten the page table lock and just before actually ente
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > Nope, that just makes the race window smaller. We should check for i_size
> > after we've gotten the page table lock and just before actually entering
> > the page into the page tables. Otherwise
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. With sleep(60) no oops occur (it takes ~45 secs to exit child).
> This signals to me: should not vmtruncate_list acquire mm->mmap_sem,
> if it modifies page tables?
No.
It should get the page_table lock, but that is sufficient for anybody
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> > obvious ones:
> > * filemap_nopage() needs the second check for ->i_size. Upon exit.
>
> Nope, that just makes
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> obvious ones:
> * filemap_nopage() needs the second check for ->i_size. Upon exit.
Nope, that just makes the race window smaller. We should check for i_size
afte
On 23 Oct 00 at 13:57, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> > First page->mapping == NULL entry in syslog is dated 22:23:58, but
> > couple of entries was lost before (probably I should print only '.' for
> > each such page; this run there was more than 100 such
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > > the race open, and make truncate_complete_page() just leave such a "
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. Bad news. No problem was catched in filemap_nopage, but one
> (of 57000) pages was dirty and had page->mapping == NULL... (maybe
> only one was caused that this was just after bootup, with plenty of memory)
> Maybe I should look at readahead c
On Mon, 23 Oct 2000, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race,
On 23 Oct 00 at 16:13, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race, a
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Al, any ideas? I have this feeling that the simplest fix is just to leave
> the race open, and make truncate_complete_page() just leave such a "racy"
> page in the page cache. It will still race, and the invalid page will
> still exist, but the end res
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> > I'll take a better look at the truncate case (I consider the invalidate
> > case closed). Do you have a simple test-program around?
>
> Well, I cannot say simple. As I was not able to reproduce it with only
> one task, code below:
Ok, without runn
On 23 Oct 00 at 12:09, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> >
> > Hi Linus,
> > unfortunately, this does not explain problem I reported. In my case,
> > underlying fs is ext2, and there is no locking around - only one task
> > does ftruncate() on (big) shareable
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Hi Linus,
> unfortunately, this does not explain problem I reported. In my case,
> underlying fs is ext2, and there is no locking around - only one task
> does ftruncate() on (big) shareable mapped file (original code does it to
> prevent dirty p
On 23 Oct 00 at 10:33, Linus Torvalds wrote:
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> >As for simply settling for a self-consistent mmap() rather than
> >tackling the problem of rereading; the main crime is that you're
> >rendering file locking unusable.
...
> This is not a crime.
>
..
In article <[EMAIL PROTECTED]>,
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
>As for simply settling for a self-consistent mmap() rather than
>tackling the problem of rereading; the main crime is that you're
>rendering file locking unusable.
This is not a crime.
Anybody who uses file locking ov
On Mon, 23 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > You can also pretty trivially keep track of an error term so that the
> > clock is right on average:
>
> True, but I don't want 'right on average'. I want 'not screwed with at all'.
> Shifting the timer tick onto the
[EMAIL PROTECTED] said:
> You can also pretty trivially keep track of an error term so that the
> clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that.
Even if we _do_ get the maths righ
On Mon, 23 Oct 2000, David Woodhouse wrote:
> See arch/i386/kernel/time.c:
>
> /* This function must be called with interrupts disabled
> * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
> *
> * However, the pc-audio speaker driver changes the divisor so that
> * it get
[EMAIL PROTECTED] said:
> Apparently Linus doesn't like the way it handles interrupts or
> something, and is therefore 'wrong.' ::shrug:: As long as it's
> available though, I'll use it ;p
It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to
shift the system timer onto the RT
ROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3
>
>> Is there a major compelling reason that this patch isn't included
>> in the standard kernel tree?
>>
>>
>> -
> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
>
>
> --
> Mike A. Harris - Linux advocate - Open source advocate
> Computer Consultant - Capslock Consul
Greetings all:
I was doing some benchmark between kernels and i came out with
this results, for what I can see, 2.2.17 with the ide_patch is faster,
although it uses more CPU, but then again i could be wrong, any ideas?
-Rodrigo
2.4.0-test10-pre3 FS=ext2 AMD v1.2 (viper
On Sat, Oct 21, 2000 at 02:14:21PM +0100, Russell King wrote:
> Something weird is going on with VFS return codes with kernel
> 2.4.0-test10-pre3:
>
> [root@sturm glibc-2.1.92]# df /var/tmp
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/hda3
On 16 Oct 2000, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:[EMAIL PROTECTED]
> In newsgroup: linux.dev.kernel
> >
> > > but intel refuse to guarantee they wont produce an actual '786' class
> > > CPU.
> >
> > Worry about that if/when it happens ?
>
> Dare one gues
Hi,
Something weird is going on with VFS return codes with kernel
2.4.0-test10-pre3:
[root@sturm glibc-2.1.92]# df /var/tmp
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 127383127383 0 100% /var
[root@sturm glibc-2.1.92]# df -i /var/tmp
On Thu, 19 Oct 2000, Linus Torvalds wrote:
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty one */
Wait a second. invalidate_inode_page
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> Again, consider the case when two processes share the
> mapping. Process A has page faulted in. Page is
> invalidated. Process B tries to access the same page. If you
> leave it in page tables of A you _MUST_ leave it i
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> For the general case of the page cache I think we can keep them quite
> simple:
>
> + We do in any case want to drop all pages that are unreferenced. (The
> reason for flushing may be that the file size has changed.)
>
> + For pages that are refer
On 20 Oct 2000, Trond Myklebust wrote:
> > " " == Russell King <[EMAIL PROTECTED]> writes:
>
> > invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> > do_fcntl sys_fcntl
>
> > So I guess that NFS locking is really bad if the region is
> > mmapped!
>
> Yep, bu
On 20 Oct 2000, Trond Myklebust wrote:
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
OK, so what should happen if user does mmap() on NFS file, dirties t
On Fri, 20 Oct 2000, Roger Larsson wrote:
> Is it legal/good practice to unmap the file after closing it?
Yes.
> (Since the sharing needs the fd to mmap it)
It doesn't. Mapping needs struct file * and it doesn't care about
fd. mmap() takes a reference to struct file by fd you've passed and af
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> > " " == David S Miller <[EMAIL PROTECTED]> writes:
>
> > Actually, judging by the trace you provided Russell, I'd say
> > this is some peculiarity with NFS silly rename handling, and
> > it'd be best to look for the bug in that
[ Final comment, and then I'll shut up ]
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty o
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> I'm saying that we're much much better off guaranteeing local consistency
> over knowingly breaking local consistency over a uncertain global
> consistency issue. Especially as NFS has never guaranteed global
> consistency in the first place, and w
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> which is really really bad, because now you have the case that
> you have 'n' copies of the same page in memory, with 'n' users,
> out of which 'n-1' users have the wrong page. And those 'n-1'
> users don't even have an
On 20 Oct 2000, Trond Myklebust wrote:
>
> The problem here is that NFS pages have 3 rather than 2 states:
> 1) mmapped & correct.
> 2) mmapped & incorrect. (but possibly dirty)
> 3) Unmapped
>
> For case 1), we clearly want to have the page in inode->i_mapping.
> For cases 2) & 3) we do
On 20 Oct 2000, Trond Myklebust wrote:
>
> > invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> > do_fcntl sys_fcntl
>
> > So I guess that NFS locking is really bad if the region is
> > mmapped!
>
> Yep, but that's a symptom, not a cause. We want to be able to ru
On 20 Oct 2000, Trond Myklebust wrote:
>
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
> The existence of file locks that aren't page aligned, as well as
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> The advantage of clearing the uptodate flag (as opposed to
> doing what we do now - dropping the page altogether) is that
> there would be no cache aliasing issues, and there would be no
> issues with a page and its as
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, that "invalidate_inode_pages()" thing is just wrong - we
> can't just remove pages that are mapped etc, because that would
> result in no end of fun aliasing problems etc.
> How about adding a test in invalidate_
Alexander Viro writes:
> Trond, I'm not asking about implementation - the question being what
> semantics do you want for nfs_zap_caches() wrt user-mapped pages.
Ok, looking through sendmail, and then db2, the situation is
created by the db2 library. If the process does the following:
1. create
On 19 Oct 00 at 16:32, Linus Torvalds wrote:
> How about adding a test in invalidate_inode_pages() like
>
> /* We cannot invalidate a locked page */
> if (TryLockPage(page))
> continue;
>
> + /* We cannot invalidate a page that is in use */
> + if (page_c
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> So what exactly do you want it to do when page is mapped by
> user process? Should it remain visible or not? What should
> happen if process writes to that page?
> Trond, I'm not asking about implementation - the ques
On Fri, 20 Oct 2000, Trond Myklebust wrote:
>
> The problem lies with writes that haven't yet been msync()ed (and
> hence do not have writebacks). For shared mappings, one should perhaps
> schedule an automatic msync() of the dirty pages (???). For private
> mappings, perhaps the best thing wou
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> How about adding a test in invalidate_inode_pages() like
> /* We cannot invalidate a locked page */ if
> (TryLockPage(page))
> continue;
> + /* We cannot invalidate a page that
> " " == Russell King <[EMAIL PROTECTED]> writes:
> invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> do_fcntl sys_fcntl
> So I guess that NFS locking is really bad if the region is
> mmapped!
Yep, but that's a symptom, not a cause. We want to be able to run
i
> " " == Russell King <[EMAIL PROTECTED]> writes:
> Indeed. page->mapping is set to NULL in two places, one in
> __remove_inode_pages() and the other one in the swap code after
> we've checked that it was NULL. I hadn't found the particular
> call trace that caused us to
> " " == David S Miller <[EMAIL PROTECTED]> writes:
> Actually, judging by the trace you provided Russell, I'd say
> this is some peculiarity with NFS silly rename handling, and
> it'd be best to look for the bug in that code (early inode
> reference loss, for example?)
R
Linus Torvalds writes:
> Can you get a full stack trace?
filemap_write_page
filemap_sync
filemap_unmap
do_munmap
sys_munmap
> How about adding a test in invalidate_inode_pages() like
(Added, along with a call to drop a stack trace out).
Yes, this does stop the problem in filemap_write_page. T
In article <8snvuj$1l0$[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>Hmm.. Looks like page->mapping was cleared by truncate_inode_pages()
>when the inode was free'd, and there was still write-back activity on
>one of the pages in question.
Looking some more, the fact that the
In article <[EMAIL PROTECTED]>,
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>> " " == Petr Vandrovec <[EMAIL PROTECTED]> writes:
>
> > You do not have to use NFS - look for my postings with
> > 'page->mapping == NULL' in archive. Your code uses shared mmap,
> > 'page->isn't
> >
In article <[EMAIL PROTECTED]>,
Russell King <[EMAIL PROTECTED]> wrote:
>Petr Vandrovec writes:
>> ... or from sys_exit() if you forget to unmap. Or from anywhere if
>> swapping code decides to swap such page. I'm trying to hunt it down
>> for more than month, but I have no idea what's wrong. In
From: Russell King <[EMAIL PROTECTED]>
Date:Fri, 20 Oct 2000 00:07:55 +0100 (BST)
Trond Myklebust writes:
> It's probably particularly nasty under NFS because of
> invalidate_inode_pages(). The latter empties the page cache whenever
> we can no longer trust it and calls
Trond Myklebust writes:
> It's probably particularly nasty under NFS because of
> invalidate_inode_pages(). The latter empties the page cache whenever
> we can no longer trust it and calls remove_inode_page() on every
> unlocked page. It won't care whether the page is mmapped or not.
>
> My guess
> " " == Petr Vandrovec <[EMAIL PROTECTED]> writes:
> You do not have to use NFS - look for my postings with
> 'page->mapping == NULL' in archive. Your code uses shared mmap,
> 'page->isn't
> it? Probably shared by couple of processes.
It's probably particularly nasty und
Roger Larsson writes:
> Will it work correctly if 4. is done before 3. (even before 2?)
> Is it legal/good practice to unmap the file after closing it?
> (Since the sharing needs the fd to mmap it)
Dunno, haven't tried that yet. I'll have a go tomorrow, but I think
it'll work correctly. I'll al
Russell King wrote:
>
> Petr Vandrovec writes:
> > ... or from sys_exit() if you forget to unmap. Or from anywhere if
> > swapping code decides to swap such page. I'm trying to hunt it down
> > for more than month, but I have no idea what's wrong. In my case
> > way to trigger bug is:
>
> I actu
Petr Vandrovec writes:
> ... or from sys_exit() if you forget to unmap. Or from anywhere if
> swapping code decides to swap such page. I'm trying to hunt it down
> for more than month, but I have no idea what's wrong. In my case
> way to trigger bug is:
I actually think its as simple as:
1. shar
ork
(4) from child dirty pages
(5) from parent truncate file
(6) exit both tasks
(7) oops
Just in case you'll not find oops demo code in archive... Last tested
under 2.4.0-test10-pre3. With -pre4 I cannot decide whether to comment
out BUG() in vmscan, or not, so I did not test -pr
Hi,
I'm seeing an oops caused by a NULL pointer dereference in mm/filemap.c,
filemap_write_page. The NULL pointer in question is page->mapping.
The box on which this is happening is using a root NFS filesystem (in
fact all but one of its filesystems are NFS).
So the file that was mapped has bee
Here's a patch which should improve Pentium IV support in test10-pre.
The test10-pre3 patch detects Pentium IV (family code 15) but resets
boot_cpu_data.x86 to 6 in this case.
The advantage of doing this is that the places in the kernel which
construct cpu family names (i386 .. i686) still
On Wed, 18 Oct 2000, Mike Galbraith wrote:
> On Wed, 18 Oct 2000, Gary E. Miller wrote:
>
> > Yo Mike!
> >
> > On Wed, 18 Oct 2000, Mike Galbraith wrote:
> >
> > > > Help! See below for my kernel oops. I have not been able to use any
> > > > kernel after 2.4.0-test5 due to this problem. It
On Wed, 18 Oct 2000, Mike A. Harris wrote:
> It's RNCD: Roman Numeral Coded Decimal. The new standard for
> information interchange. A new proprietary feature of Intel
> CPU's that will bring new high performance web sites to the reach
> of the masses! Now you can access these special custom
On Tue, 17 Oct 2000, David Weinehall wrote:
> On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote:
> >
> > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> > > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> >
> > > Why Intel chose family 15 is still beyond me though.
> >
> > IV is 15
"Mike A. Harris" wrote:
>
> On Tue, 17 Oct 2000, Michael H. Warfield wrote:
>
> >> > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> >> > > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> >
> >> > > Why Intel chose family 15 is still beyond me though.
> >
> >> > IV is 15 if you just translate th
On Tue, 17 Oct 2000, Michael H. Warfield wrote:
>> > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
>> > > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
>
>> > > Why Intel chose family 15 is still beyond me though.
>
>> > IV is 15 if you just translate the symbols, but ignore the meaning
>> > eith
Hi!
The isapnp change in 2.4.0-test10-pre beaks the detection of
my non-pnp soundblaster AWE32 card (compiled into the kernel,
as modular operation oopses - see mail with Subject:sound related OOPS
(2.4.0-test9-pre7) from Sun, 1 Oct 2000 15:49:46). The kernel
hangs after printing the message
sb:
On Wed, 18 Oct 2000, Gary E. Miller wrote:
> Yo Mike!
>
> On Wed, 18 Oct 2000, Mike Galbraith wrote:
>
> > > Help! See below for my kernel oops. I have not been able to use any
> > > kernel after 2.4.0-test5 due to this problem. It happens shortly
> > > after booting the kernel and is very
Yo Mike!
On Wed, 18 Oct 2000, Mike Galbraith wrote:
> > Help! See below for my kernel oops. I have not been able to use any
> > kernel after 2.4.0-test5 due to this problem. It happens shortly
> > after booting the kernel and is very repeatable.
> Are you sure that you used the right System
On Tue, 17 Oct 2000, Gary E. Miller wrote:
> Yo All!
>
> Help! See below for my kernel oops. I have not been able to use any
> kernel after 2.4.0-test5 due to this problem. It happens shortly
> after booting the kernel and is very repeatable.
>
> This is a dual PII system with PIIX4 ide,
Yo All!
Help! See below for my kernel oops. I have not been able to use any
kernel after 2.4.0-test5 due to this problem. It happens shortly
after booting the kernel and is very repeatable.
This is a dual PII system with PIIX4 ide, 53c875 scsi and Raid 1.
It is not a production system so I a
On Wed, Oct 18, 2000 at 12:12:39AM +0200, David Weinehall wrote:
> On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote:
> > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> > > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> > > Why Intel chose family 15 is still beyond me though.
> >
On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote:
>
> On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> > On Tue, 17 Oct 2000, Mikael Pettersson wrote:
>
> > Why Intel chose family 15 is still beyond me though.
>
> IV is 15 if you just translate the symbols, but ignore the meaning
>
On Tue, Oct 17, 2000 at 05:17:38PM -0400, [EMAIL PROTECTED] wrote:
> When I tried 2.4.0-test10-pre3 on my IBM Thinkpad 380XD (the 233 MHz
> flavor), PCMCIA slot #1 (the lower one) seemed to be dead: inserting and
> removing cards gave me no beeps and no log messages. Slot #0 (the up
When I tried 2.4.0-test10-pre3 on my IBM Thinkpad 380XD (the 233 MHz
flavor), PCMCIA slot #1 (the lower one) seemed to be dead: inserting and
removing cards gave me no beeps and no log messages. Slot #0 (the upper
one) behaved fine. It didn't matter whether I had one or two cards in.
t
On Tue, 17 Oct 2000, Mike A. Harris wrote:
> >Well as Intel isn't even shipping P4 samples yet, most of this is just
> >guesswork based upon preliminary datasheets. I wouldn't be surprised
> >if we find other fun things to work around when we start seeing
> >silicone in use.
>
> Heck, you don't
On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote:
> On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> Why Intel chose family 15 is still beyond me though.
IV is 15 if you just translate the symbols, but ignore the meaning
either that or someone was smoking alot of crack.
--
/*-
> >Thanks to Erik Inge Bols=F8 for porting it to 2.3.45, this saving me m=
> ost of=20
> >the work.
>
> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
It goes hacking around with the clock
-
To unsubscribe from this list: send the line "unsubscr
> [root@wr5z linux]# make bzImage
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include scripts/split-include.c
> In file included from /usr/include/errno.h:36,
> from scripts/split-include.c:26:
> /usr/include/bits/errno.h:25: linux/errno.h: No such
On Tue, 17 Oct 2000 [EMAIL PROTECTED] wrote:
>*grin*
>
>Well as Intel isn't even shipping P4 samples yet, most of this is just
>guesswork based upon preliminary datasheets. I wouldn't be surprised
>if we find other fun things to work around when we start seeing
>silicone in use.
Heck, you don't
In message <[EMAIL PROTECTED]> you write:
> --- linux/net/ipv6/netfilter/Config.in.oldMon Oct 16 17:25:17 2000
> +++ linux/net/ipv6/netfilter/Config.inMon Oct 16 17:46:07 2000
> +if [ "$CONFIG_IP6_NF_TARGET_MARK" = "y" -a "$CONFIG_IP_NF_IPTABLES" != "
y" ]; then
> + define_boo
On Tue, 17 Oct 2000, Mike A. Harris wrote:
> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
It does _evil_ things with the timers. If we shift the system timer tick
onto the RTC, it won't be so evil, and I'd consider trying to submit it
for 2.5.
On Tue, 17 Oct 2000 00:45:13 -0500 (CDT),
Thomas Molina <[EMAIL PROTECTED]> wrote:
>I patched from 2.4.0-test9 to 2.4.0-test10-pre3 successfully. I then
>did make mrproper, make oldconfig, make dep successfully. make bzImage
>resulted in the following error:
>
>[root@wr5z
On Tue, 17 Oct 2000, Thomas Molina wrote:
> I patched from 2.4.0-test9 to 2.4.0-test10-pre3 successfully. I then
> did make mrproper, make oldconfig, make dep successfully. make bzImage
> resulted in the following error:
Would someone please hand me one of those brown paper bags.
I patched from 2.4.0-test9 to 2.4.0-test10-pre3 successfully. I then
did make mrproper, make oldconfig, make dep successfully. make bzImage
resulted in the following error:
[root@wr5z linux]# make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
scripts/split-include scripts
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
>
> > but intel refuse to guarantee they wont produce an actual '786' class
> > CPU.
>
> Worry about that if/when it happens ?
>
Dare one guess the 786 is actually the Itanic in x86 mode?
1 - 100 of 118 matches
Mail list logo
