On Sun, Dec 10, 2000 at 01:35:26AM -0500, Victor J. Orlikowski wrote:
> Steven,
>
> One question:
> Do you have MTRR enabled?
> If so, a temporary workaround is to re-compile the kernel with
> it disabled.
To confirm, yes, I do have MTRR's enabled. I'll see if that fixes
Steven,
One question:
Do you have MTRR enabled?
If so, a temporary workaround is to re-compile the kernel with
it disabled.
This is getting to be something of an epidemic.
As I said, AMD's docs state that the write-combining was
altered in the model and
to reboot. Not just SysRq+b, but also SysRq+s. This has
happened at least 3 times. The system is a AMD-K6/2 500MHz Model 8,
Steeping 12, kernel 2.4.0-test12-pre5+reiserfs, running XFree86 4.0.1
No other useful debug information could be obtained.
--
-Steven
"Voters decide nothing. Vote cou
>>EIP; c0270c21<=
Trace; c01f488e
Trace; ca8578be <[audio]usbout_completed+7e/c0>
Trace; c01ffc3e
Trace; c01ffd49
1. process_urb() obtains the urb_list_lock.
2. Then calls urb->complete() which is audio.c::usbout_complete()
3. Which in turn calls usb_submit_urb()
4. Which calls
On Fri, 8 Dec 2000, Johannes Erdfelt wrote:
> Actually, looking back at your previous email, enabling bus mastering
> may make this error go away.
>
> Could you give -pre7 a try? Or have you already?
This is pre7
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, 8 Dec 2000, Johannes Erdfelt wrote:
Actually, looking back at your previous email, enabling bus mastering
may make this error go away.
Could you give -pre7 a try? Or have you already?
This is pre7
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
EIP; c0270c21 stext_lock+4e6d/8f50 =
Trace; c01f488e usb_submit_urb+1e/30
Trace; ca8578be [audio]usbout_completed+7e/c0
Trace; c01ffc3e process_urb+1de/230
Trace; c01ffd49 uhci_interrupt+b9/120
1. process_urb() obtains the urb_list_lock.
2. Then calls urb-complete() which is
to reboot. Not just SysRq+b, but also SysRq+s. This has
happened at least 3 times. The system is a AMD-K6/2 500MHz Model 8,
Steeping 12, kernel 2.4.0-test12-pre5+reiserfs, running XFree86 4.0.1
No other useful debug information could be obtained.
--
-Steven
"Voters decide nothing. Vote cou
Steven,
One question:
Do you have MTRR enabled?
If so, a temporary workaround is to re-compile the kernel with
it disabled.
This is getting to be something of an epidemic.
As I said, AMD's docs state that the write-combining was
altered in the model and
On Sun, Dec 10, 2000 at 01:35:26AM -0500, Victor J. Orlikowski wrote:
Steven,
One question:
Do you have MTRR enabled?
If so, a temporary workaround is to re-compile the kernel with
it disabled.
To confirm, yes, I do have MTRR's enabled. I'll see if that fixes it...
it
On Fri, Dec 08, 2000, Johannes Erdfelt <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> > On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
> >
> > > Could you try the alternate UHCI driver? You may need to disable the
> > > UHCI driver you have
On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
>
> > Could you try the alternate UHCI driver? You may need to disable the
> > UHCI driver you have configured for the option to become visible.
>
> Differently broken:
> uhci:
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
> Could you try the alternate UHCI driver? You may need to disable the
> UHCI driver you have configured for the option to become visible.
Differently broken:
uhci: host controller process error. something bad happened
uhci: host
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
Could you try the alternate UHCI driver? You may need to disable the
UHCI driver you have configured for the option to become visible.
Differently broken:
uhci: host controller process error. something bad happened
uhci: host
On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
Could you try the alternate UHCI driver? You may need to disable the
UHCI driver you have configured for the option to become visible.
Differently broken:
uhci: host
On Fri, Dec 08, 2000, Johannes Erdfelt [EMAIL PROTECTED] wrote:
On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
Could you try the alternate UHCI driver? You may need to disable the
UHCI driver you have configured for the
On Thu, Dec 07, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
> this magically go away? I doubt it.
Probably not. Enabling bus mastering is the difference between USB
working at all (transfering data to the device) and
> This code in fs/fat/file.c::fat_get_block() is getting triggered when I
> run wine:
>
> if (iblock<<9 != MSDOS_I(inode)->mmu_private) {
> BUG();
> return -EIO;
> }
[I'd suggest you don't run the FAT file system code in 2.4test* unless you are
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
this magically go away? I doubt it.
This happened when trying to run excel under wine. Dual Celeron with
CONFIG_USB_UHCI.
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
Using defaults from
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
this magically go away? I doubt it.
This happened when trying to run excel under wine. Dual Celeron with
CONFIG_USB_UHCI.
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[c0270c21]
Using defaults
On Thu, Dec 07, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
this magically go away? I doubt it.
Probably not. Enabling bus mastering is the difference between USB
working at all (transfering data to the device) and not
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
> What drive are you using? AFAIR, Andre Hedrick once said certain Maxtor
> drives aren't quite safe with DMA.
Depends on the controller. Maxtor drives play badly with Highpoint
controllers, but are OK with Promise.
-Dan
-
To unsubscribe from this
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
> I also have an A7V and both of my IBM IDE drives are connected to the
> Promise controller, running in UDMA-5 mode. There hasn't been any
> corruption on either of the drives that had to do with UDMA-5 mode.
> And the ext2 bugs that 2.4 kernels had,
ely, none of the damage has been irrecoverable. I checked
> linux-kernel to see if anyone else was seeing the same thing. The recent
> threads on corruption seemed to be consistent with the behavior I saw:
> ide disk access light remains lit, system hangs, fsck finds bad inodes.
>
This code in fs/fat/file.c::fat_get_block() is getting triggered when I
run wine:
if (iblock<<9 != MSDOS_I(inode)->mmu_private) {
BUG();
return -EIO;
}
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
"Udo A. Steinberg" wrote:
> What drive are you using? AFAIR, Andre Hedrick once said certain Maxtor
> drives aren't quite safe with DMA.
Using an IBM 45GB udma5 capable drive. The problems only occur under
_heavy_ disk activity. I have -d 1 -c 3 -m 16 set.
Have you tried thrashing your drive
On Wed, 6 Dec 2000, Skip Collins wrote:
> For now I am going to fall back to the slower ide bus. But I wanted to
> let people know that there still may be problems with ext2 corruption in
> the latest test kernel.
If your kernel halts, you should not be surprised if you get file system
errors.
Skip Collins wrote:
>
> I have a 900MHz Athlon/Asus A7V mobo system with an onboard ata100
> promise controller. I have only had problems when my ata100/udma5
> harddrive is connected to the promise controller. Using the ATA66 ide
> bus eliminates the problem. I typically see the corruption when
I'd be more inclined to think its the combination of drive/controller
more than an ext2fs problem. If it was a fs corruption issue, you should
still see it on the slower bus.
On Wed, 6 Dec 2000, Skip Collins wrote:
> I have a 900MHz Athlon/Asus A7V mobo system with an onboard ata100
> promise
on corruption seemed to be consistent with the behavior I saw:
ide disk access light remains lit, system hangs, fsck finds bad inodes.
I think test12-pre5 was supposed to fix the problem. But after upgrading
my kernel, I can still get the errors.
I have a 900MHz Athlon/Asus A7V mobo system with an onboard
On Mon, 4 Dec 2000, Linus Torvalds wrote:
>
> Ok, this contains one of the fixes for the dirty inode buffer list (the
> other fix is pending, simply because I still want to understand why it
> would be needed at all). Al?
>
> Also, it has the final installment of the PageDirty handling, and now
Hello linux-kernel,
I tried to compile linux-2.4.0-test12-pre5, but it gives two errors:
make[3]: Entering directory `/usr/src/linux-2.4.0-test12-pre5/fs/udf'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test12-pre5/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing
Hello linux-kernel,
I tried to compile linux-2.4.0-test12-pre5, but it gives two errors:
make[3]: Entering directory `/usr/src/linux-2.4.0-test12-pre5/fs/udf'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test12-pre5/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing
On Mon, 4 Dec 2000, Linus Torvalds wrote:
Ok, this contains one of the fixes for the dirty inode buffer list (the
other fix is pending, simply because I still want to understand why it
would be needed at all). Al?
Also, it has the final installment of the PageDirty handling, and now
on corruption seemed to be consistent with the behavior I saw:
ide disk access light remains lit, system hangs, fsck finds bad inodes.
I think test12-pre5 was supposed to fix the problem. But after upgrading
my kernel, I can still get the errors.
I have a 900MHz Athlon/Asus A7V mobo system with an onboard
I'd be more inclined to think its the combination of drive/controller
more than an ext2fs problem. If it was a fs corruption issue, you should
still see it on the slower bus.
On Wed, 6 Dec 2000, Skip Collins wrote:
I have a 900MHz Athlon/Asus A7V mobo system with an onboard ata100
promise
Skip Collins wrote:
I have a 900MHz Athlon/Asus A7V mobo system with an onboard ata100
promise controller. I have only had problems when my ata100/udma5
harddrive is connected to the promise controller. Using the ATA66 ide
bus eliminates the problem. I typically see the corruption when
On Wed, 6 Dec 2000, Skip Collins wrote:
For now I am going to fall back to the slower ide bus. But I wanted to
let people know that there still may be problems with ext2 corruption in
the latest test kernel.
If your kernel halts, you should not be surprised if you get file system
errors. You
"Udo A. Steinberg" wrote:
What drive are you using? AFAIR, Andre Hedrick once said certain Maxtor
drives aren't quite safe with DMA.
Using an IBM 45GB udma5 capable drive. The problems only occur under
_heavy_ disk activity. I have -d 1 -c 3 -m 16 set.
Have you tried thrashing your drive
of the damage has been irrecoverable. I checked
linux-kernel to see if anyone else was seeing the same thing. The recent
threads on corruption seemed to be consistent with the behavior I saw:
ide disk access light remains lit, system hangs, fsck finds bad inodes.
I think test12-pre5 was supposed
This code in fs/fat/file.c::fat_get_block() is getting triggered when I
run wine:
if (iblock9 != MSDOS_I(inode)-mmu_private) {
BUG();
return -EIO;
}
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
I also have an A7V and both of my IBM IDE drives are connected to the
Promise controller, running in UDMA-5 mode. There hasn't been any
corruption on either of the drives that had to do with UDMA-5 mode.
And the ext2 bugs that 2.4 kernels had, have
On Wed, 6 Dec 2000, Udo A. Steinberg wrote:
What drive are you using? AFAIR, Andre Hedrick once said certain Maxtor
drives aren't quite safe with DMA.
Depends on the controller. Maxtor drives play badly with Highpoint
controllers, but are OK with Promise.
-Dan
-
To unsubscribe from this
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> The question is whether or not it is worth taking a lock again (with
> that non-zero cost) to achieve the gain of doing the 92-byte memset and
> the atomic_set in parallel with other CPUs. In other words, by locking
> and unlocking twice, you reduce
Hi,
On Tue, Dec 05, 2000 at 03:17:07PM -0500, Alexander Viro wrote:
>
>
> On Tue, 5 Dec 2000, Linus Torvalds wrote:
>
> > And this is not just a "it happens to be like this" kind of thing. It
> > _has_ to be like this, because every time we call clear_inode() we are
> > going to physically
[[EMAIL PROTECTED]]
> dummy.c: In function `dummy_init_module':
> dummy.c:103: invalid type argument of `->'
Known bug. They say the fix is in Linus's patch queue.
--- include/linux/module.h~ Tue Dec 5 00:53:23 2000
+++ include/linux/module.h Tue Dec 5 17:24:47 2000
@@ -345,7 +345,7
: invalid type argument of `->'
make[3]: *** [dummy.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test12-pre5/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test12-pre5/drivers/net'
make[1]: *** [_subdir_net] Error 2
make[1]: Leav
[Peter Samuelson]
> > Whether a memset of 92 bytes (on 32-bit arch), plus an
> > atomic_set(), are worth deserializing, I do not know.
[Tigran Aivazian]
> Of course, they are worth it. Actually, I don't understand how can
> you even doubt it?
Clearly we are talking at cross-purposes here. I
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > The only reason one could think of was to "hold the lock for as short
> > time as possible" but a minute's thought reveals that such reason is
> > invalid (i.e. one is more likely to waste time spinning on the lock
> > than to
[Tigran Aivazian]
> The only reason one could think of was to "hold the lock for as short
> time as possible" but a minute's thought reveals that such reason is
> invalid (i.e. one is more likely to waste time spinning on the lock
> than to save it by dropping/retaking it, given the relative
On Tue, 5 Dec 2000, Daniel Phillips wrote:
>
> OK, I see - this isn't easy at all. You start the io if necessary, and
> some time later it completes.
Right. You don't know when. Once completed, it will unlock the page and
wake up waiters. It will also set PG_Uptodate if the read was
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > I think 'flags' is what it used to be called ages ago but that is
> > irrelevant -- everyone presumably already changed all their software
> > to use 'features' (I did, for example) and forgot about the old
> > 'flags'
> > presumably already changed all their software to use 'features' (I did,
> > for example) and forgot about the old 'flags' forever
>
> Blessed vmware-config.pl contains
>
> \(flags\|features\).*
>
> so it should run...
vmware-config as used by the other 99.% of people does not
-
[Tigran Aivazian]
> I think 'flags' is what it used to be called ages ago but that is
> irrelevant -- everyone presumably already changed all their software
> to use 'features' (I did, for example) and forgot about the old
> 'flags' forever
Ages ago? s/flags/features/ happened in
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> And this is not just a "it happens to be like this" kind of thing. It
> _has_ to be like this, because every time we call clear_inode() we are
> going to physically free the memory associated with the inode very soon
> afterwards. Which means that
On Tue, 5 Dec 2000, Alexander Viro wrote:
> >
> > Stephen is _wrong_ wrt fsync().
> >
> > Why?
> >
> > Think about it for a second. How the hell could you even _call_ fsync() on
> > a file that no longer exists, and has no file handles open to it?
> ^^
>
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> > So Stephen is right wrt fsync() (it will not get that stuff on disk).
> > However, it's not a bug - if that crap will not end up on disk we
> > will only win.
>
> Stephen is _wrong_ wrt fsync().
>
> Why?
>
> Think about it for a second. How the
Hi,
On Tue, Dec 05, 2000 at 09:48:51AM -0800, Linus Torvalds wrote:
>
> On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
> >
> > That is still buggy. We MUST NOT invalidate the inode buffers unless
> > i_nlink == 0, because otherwise a subsequent open() and fsync() will
> > have forgotten what
On Tue, 5 Dec 2000, Alexander Viro wrote:
>
> Sigh. OK, let me put it that way:
>
> * we _can_ have dirty blocks on the list when inode gets freed.
Agreed.
> * no, CAN_UNUSE will not see them.
CAN_UNUSE() is not used at all for the final forcible removal of an inode
that has no
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> Get your acts together, guys. Stop blathering and frothing at the mouth.
> The only time clear_inode() should be called is (a) when we prune the
> inode cache - and we CLEARLY cannot prune an inode if it still has dirty
> blocks associated with it
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
>
> On Mon, Dec 04, 2000 at 08:00:03PM -0800, Linus Torvalds wrote:
> >
> > On Mon, 4 Dec 2000, Alexander Viro wrote:
> > >
> > This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
> >
> > void clear_inode(struct inode
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
> That is still buggy. We MUST NOT invalidate the inode buffers unless
> i_nlink == 0, because otherwise a subsequent open() and fsync() will
> have forgotten what buffers are dirty, and hence will fail to
> synchronise properly with the disk.
Hi,
On Mon, Dec 04, 2000 at 08:00:03PM -0800, Linus Torvalds wrote:
>
> On Mon, 4 Dec 2000, Alexander Viro wrote:
> >
> This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
>
> void clear_inode(struct inode *inode)
> {
> if
Linus Torvalds wrote:
> NOTE! There's another change to "writepage()" semantics than just dropping
> the "struct file": the new writepage() is supposed to mirror the logic of
> readpage(), and unlock the page when it is done with it. This allows the
> VM system more visibility into what IO is
On 5 Dec 00 at 12:25, Tigran Aivazian wrote:
> In case you haven't noticed yet -- the 'features' field of /proc/cpuinfo
> has been changed again so vmware won't run anymore. The fix is just as
> obvious as the previous one -- to change /usr/bin/vmware-config.pl script
> from grepping for
Hi Petr,
In case you haven't noticed yet -- the 'features' field of /proc/cpuinfo
has been changed again so vmware won't run anymore. The fix is just as
obvious as the previous one -- to change /usr/bin/vmware-config.pl script
from grepping for 'features' to grep for 'flags'. I think 'flags' is
Apparently, in linux 2.4.0-test12-pre5,
address_space_operations->writepage went from having two parameters
to just one. fs/udf/inode.c apparently was overlooked in the patch.
Here is the one line change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Su
> Hello,
> The drivers/net/dummy.c compile error still exists..Looks like the
> module.h patch wasn't included.
Its in Linus queue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Hello,
The drivers/net/dummy.c compile error still exists..Looks like the
module.h patch wasn't included.
Its in Linus queue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Apparently, in linux 2.4.0-test12-pre5,
address_space_operations-writepage went from having two parameters
to just one. fs/udf/inode.c apparently was overlooked in the patch.
Here is the one line change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
On 5 Dec 00 at 12:25, Tigran Aivazian wrote:
In case you haven't noticed yet -- the 'features' field of /proc/cpuinfo
has been changed again so vmware won't run anymore. The fix is just as
obvious as the previous one -- to change /usr/bin/vmware-config.pl script
from grepping for 'features'
Linus Torvalds wrote:
NOTE! There's another change to "writepage()" semantics than just dropping
the "struct file": the new writepage() is supposed to mirror the logic of
readpage(), and unlock the page when it is done with it. This allows the
VM system more visibility into what IO is pending
Hi,
On Mon, Dec 04, 2000 at 08:00:03PM -0800, Linus Torvalds wrote:
On Mon, 4 Dec 2000, Alexander Viro wrote:
This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
void clear_inode(struct inode *inode)
{
if
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
That is still buggy. We MUST NOT invalidate the inode buffers unless
i_nlink == 0, because otherwise a subsequent open() and fsync() will
have forgotten what buffers are dirty, and hence will fail to
synchronise properly with the disk.
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
On Mon, Dec 04, 2000 at 08:00:03PM -0800, Linus Torvalds wrote:
On Mon, 4 Dec 2000, Alexander Viro wrote:
This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
void clear_inode(struct inode *inode)
{
On Tue, 5 Dec 2000, Linus Torvalds wrote:
Get your acts together, guys. Stop blathering and frothing at the mouth.
The only time clear_inode() should be called is (a) when we prune the
inode cache - and we CLEARLY cannot prune an inode if it still has dirty
blocks associated with it and
On Tue, 5 Dec 2000, Alexander Viro wrote:
Sigh. OK, let me put it that way:
* we _can_ have dirty blocks on the list when inode gets freed.
Agreed.
* no, CAN_UNUSE will not see them.
CAN_UNUSE() is not used at all for the final forcible removal of an inode
that has no
Hi,
On Tue, Dec 05, 2000 at 09:48:51AM -0800, Linus Torvalds wrote:
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
That is still buggy. We MUST NOT invalidate the inode buffers unless
i_nlink == 0, because otherwise a subsequent open() and fsync() will
have forgotten what buffers are
On Tue, 5 Dec 2000, Linus Torvalds wrote:
So Stephen is right wrt fsync() (it will not get that stuff on disk).
However, it's not a bug - if that crap will not end up on disk we
will only win.
Stephen is _wrong_ wrt fsync().
Why?
Think about it for a second. How the hell could
On Tue, 5 Dec 2000, Alexander Viro wrote:
Stephen is _wrong_ wrt fsync().
Why?
Think about it for a second. How the hell could you even _call_ fsync() on
a file that no longer exists, and has no file handles open to it?
^^
clear_inode() -
On Tue, 5 Dec 2000, Linus Torvalds wrote:
And this is not just a "it happens to be like this" kind of thing. It
_has_ to be like this, because every time we call clear_inode() we are
going to physically free the memory associated with the inode very soon
afterwards. Which means that _any_
[Tigran Aivazian]
I think 'flags' is what it used to be called ages ago but that is
irrelevant -- everyone presumably already changed all their software
to use 'features' (I did, for example) and forgot about the old
'flags' forever
Ages ago? s/flags/features/ happened in test11pre5. I
presumably already changed all their software to use 'features' (I did,
for example) and forgot about the old 'flags' forever
Blessed vmware-config.pl contains
\(flags\|features\).*
so it should run...
vmware-config as used by the other 99.% of people does not
-
To
On Tue, 5 Dec 2000, Peter Samuelson wrote:
[Tigran Aivazian]
I think 'flags' is what it used to be called ages ago but that is
irrelevant -- everyone presumably already changed all their software
to use 'features' (I did, for example) and forgot about the old
'flags' forever
Ages
On Tue, 5 Dec 2000, Daniel Phillips wrote:
OK, I see - this isn't easy at all. You start the io if necessary, and
some time later it completes.
Right. You don't know when. Once completed, it will unlock the page and
wake up waiters. It will also set PG_Uptodate if the read was successful
[Tigran Aivazian]
The only reason one could think of was to "hold the lock for as short
time as possible" but a minute's thought reveals that such reason is
invalid (i.e. one is more likely to waste time spinning on the lock
than to save it by dropping/retaking it, given the relative
On Tue, 5 Dec 2000, Peter Samuelson wrote:
[Tigran Aivazian]
The only reason one could think of was to "hold the lock for as short
time as possible" but a minute's thought reveals that such reason is
invalid (i.e. one is more likely to waste time spinning on the lock
than to save it by
[Peter Samuelson]
Whether a memset of 92 bytes (on 32-bit arch), plus an
atomic_set(), are worth deserializing, I do not know.
[Tigran Aivazian]
Of course, they are worth it. Actually, I don't understand how can
you even doubt it?
Clearly we are talking at cross-purposes here. I do
: invalid type argument of `-'
make[3]: *** [dummy.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.0-test12-pre5/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.0-test12-pre5/drivers/net'
make[1]: *** [_subdir_net] Error 2
make[1]: Leaving
[[EMAIL PROTECTED]]
dummy.c: In function `dummy_init_module':
dummy.c:103: invalid type argument of `-'
Known bug. They say the fix is in Linus's patch queue.
--- include/linux/module.h~ Tue Dec 5 00:53:23 2000
+++ include/linux/module.h Tue Dec 5 17:24:47 2000
@@ -345,7 +345,7 @@
Hi,
On Tue, Dec 05, 2000 at 03:17:07PM -0500, Alexander Viro wrote:
On Tue, 5 Dec 2000, Linus Torvalds wrote:
And this is not just a "it happens to be like this" kind of thing. It
_has_ to be like this, because every time we call clear_inode() we are
going to physically free the
On Tue, 5 Dec 2000, Peter Samuelson wrote:
The question is whether or not it is worth taking a lock again (with
that non-zero cost) to achieve the gain of doing the 92-byte memset and
the atomic_set in parallel with other CPUs. In other words, by locking
and unlocking twice, you reduce the
Linus Torvalds wrote:
>
> Ok, this contains one of the fixes for the dirty inode buffer list (the
> other fix is pending, simply because I still want to understand why it
> would be needed at all). Al?
I've run the same test suite against vanilla test12-pre5 on two machines fo
The following fixes to many arguments error in fs/udf/inode.c for
test12-pre5
--- fs/udf/inode.c.orig Mon Dec 4 23:34:23 2000
+++ fs/udf/inode.c Tue Dec 5 00:26:59 2000
@@ -202,7 +202,7 @@
mark_buffer_dirty(bh);
udf_release_data(bh);
- inode->i_data.a_
On Mon, 4 Dec 2000, Linus Torvalds wrote:
> So? Why wouldn't clear_inode() get rid of it?
It will. Mea culpa. However, other reasons for taking the bh of freed
block from the list still stand. IOW, consider that part as an
optimization.
-
To unsubscribe from this list: send the line
On Mon, 4 Dec 2000, Alexander Viro wrote:
>
> On Mon, 4 Dec 2000, Linus Torvalds wrote:
> >
> > Ok, this contains one of the fixes for the dirty inode buffer list (the
> > other fix is pending, simply because I still want to understand why it
> > would be needed at all). Al?
>
> See previous
On Mon, 4 Dec 2000, Linus Torvalds wrote:
>
> Ok, this contains one of the fixes for the dirty inode buffer list (the
> other fix is pending, simply because I still want to understand why it
> would be needed at all). Al?
See previous posting. BTW, -pre5 doesn't do the right thing in
Hello,
The drivers/net/dummy.c compile error still exists..Looks like the
module.h patch wasn't included.
Regards,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Ok, this contains one of the fixes for the dirty inode buffer list (the
other fix is pending, simply because I still want to understand why it
would be needed at all). Al?
Also, it has the final installment of the PageDirty handling, and now
officially direct IO can work by just marking the
Ok, this contains one of the fixes for the dirty inode buffer list (the
other fix is pending, simply because I still want to understand why it
would be needed at all). Al?
Also, it has the final installment of the PageDirty handling, and now
officially direct IO can work by just marking the
1 - 100 of 105 matches
Mail list logo
