this works fine in pre8. thanks all!
Joseph Cheek wrote:
> copying files off a loopback-mounted vfat filesystem exposes this bug.
> test11 worked fine.
>
> loop.o built as module. this hard crashes the machine, every time
> [PIII-450]. i don't know how to debug this, is there a FAQ?
>
>
this works fine in pre8. thanks all!
Joseph Cheek wrote:
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
>
> I did a test. I disabled readahead except for reading all 4 buffers in
> map_4sectors.
>
> I observed 14% slowdown on walking directories with find and 4% slowdown
> on grepping one my working directory (10M, 281 files).
>
> If you can't make it
On Sat, 9 Dec 2000, Alexander Viro wrote:
> On Sat, 9 Dec 2000, Andries Brouwer wrote:
>
> > On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> >
> > > > @@ -1210,7 +1204,6 @@
> > > [breada()]
> > > Umm... why do we keep it, in the first place? AFAICS the only
> > > in-tree
Linus Torvalds <[EMAIL PROTECTED]> writes:
> > Modulo the comments above - fine with me. However, there is stuff in
> > drivers/md that I don't understand. Ingo, could you comment on the use of
> > ->b_end_io there?
>
> I already sent him mail about it for the same reason.
How about
On Sat, 9 Dec 2000, Alexander Viro wrote:
> Fine
> > - atomic_inc(>b_count);
>
> Why? It's cleaner the old way - why bother postponing that until we
> lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_io =
-pre6-LVM-REISERFS/ (specified)
-m /boot/System.map-2.4.0-test12-pre6-LVM-REISERFS (specified)
No modules in ksyms, skipping objects
Unable to handle kernel paging request at virtual address 0228
swapper(0): Oops 1
pc = [] ra = [] ps = 0007
Using defaults from ksymoops -t elf64
On Fri, 8 Dec 2000, Alexander Viro wrote:
> BTW, what do you think about the following:
> * add_to_page_cache() is not exported and never used. Kill?
I have my eye on that for execute-in-place of romfs from real ROM chips -
making up struct pages for parts of the ROM chips and inserting
Date:Sat, 9 Dec 2000 00:45:51 -0800 (PST)
From: Linus Torvalds <[EMAIL PROTECTED]>
out:
-if (nr) {
-ll_rw_block(WRITE, nr, arr);
-} else {
-UnlockPage(page);
-}
+UnlockPage(page);
ClearPageUptodate(page);
On Sat, 9 Dec 2000, Andries Brouwer wrote:
> On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
>
> > > @@ -1210,7 +1204,6 @@
> > [breada()]
> > Umm... why do we keep it, in the first place? AFAICS the only
> > in-tree user is hpfs_map_sector() and it doesn't look like we
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
> > @@ -1210,7 +1204,6 @@
> [breada()]
> Umm... why do we keep it, in the first place? AFAICS the only
> in-tree user is hpfs_map_sector() and it doesn't look like we really
> need it there. OTOH, trimming the buffer.c down is
On Sat, 9 Dec 2000, Linus Torvalds wrote:
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
>
> If somebody wants to run with this, please try it out, but realize that
>
On Sat, 9 Dec 2000, Linus Torvalds wrote:
>
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and
On Fri, 8 Dec 2000, Alexander Viro wrote:
> On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
> > Looking more at this issue, I suspect that the easiest pretty solution
> > that everybody can probably agree is reasonable is to either pass down the
> > end-of-io callback to ll_rw_block as you
On Fri, 8 Dec 2000, Alexander Viro wrote:
On Fri, 8 Dec 2000, Linus Torvalds wrote:
Looking more at this issue, I suspect that the easiest pretty solution
that everybody can probably agree is reasonable is to either pass down the
end-of-io callback to ll_rw_block as you suggested, or,
On Sat, 9 Dec 2000, Linus Torvalds wrote:
This is a preliminary patch that I have not compiled and probably breaks,
but you get the idea. I'm going to sleep, to survive another night with
three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and
On Sat, 9 Dec 2000, Linus Torvalds wrote:
This is a preliminary patch that I have not compiled and probably breaks,
but you get the idea. I'm going to sleep, to survive another night with
three small kids.
If somebody wants to run with this, please try it out, but realize that
it's a
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is hpfs_map_sector() and it doesn't look like we really
need it there. OTOH, trimming the buffer.c down is
On Sat, 9 Dec 2000, Andries Brouwer wrote:
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is hpfs_map_sector() and it doesn't look like we really
need
Date:Sat, 9 Dec 2000 00:45:51 -0800 (PST)
From: Linus Torvalds [EMAIL PROTECTED]
out:
-if (nr) {
-ll_rw_block(WRITE, nr, arr);
-} else {
-UnlockPage(page);
-}
+UnlockPage(page);
ClearPageUptodate(page);
On Fri, 8 Dec 2000, Alexander Viro wrote:
BTW, what do you think about the following:
* add_to_page_cache() is not exported and never used. Kill?
I have my eye on that for execute-in-place of romfs from real ROM chips -
making up struct pages for parts of the ROM chips and inserting
-pre6-LVM-REISERFS/ (specified)
-m /boot/System.map-2.4.0-test12-pre6-LVM-REISERFS (specified)
No modules in ksyms, skipping objects
Unable to handle kernel paging request at virtual address 0228
swapper(0): Oops 1
pc = [fc3c8fc0] ra = [fc3c8fbc] ps = 0007
Using
On Sat, 9 Dec 2000, Alexander Viro wrote:
Fine
- atomic_inc(bh-b_count);
Why? It's cleaner the old way - why bother postponing that until we
lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_io =
Linus Torvalds [EMAIL PROTECTED] writes:
Modulo the comments above - fine with me. However, there is stuff in
drivers/md that I don't understand. Ingo, could you comment on the use of
-b_end_io there?
I already sent him mail about it for the same reason.
How about sending mail to
On Sat, 9 Dec 2000, Alexander Viro wrote:
On Sat, 9 Dec 2000, Andries Brouwer wrote:
On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
@@ -1210,7 +1204,6 @@
[breada()]
Umm... why do we keep it, in the first place? AFAICS the only
in-tree user is
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
I did a test. I disabled readahead except for reading all 4 buffers in
map_4sectors.
I observed 14% slowdown on walking directories with find and 4% slowdown
on grepping one my working directory (10M, 281 files).
If you can't make it
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> Looking more at this issue, I suspect that the easiest pretty solution
> that everybody can probably agree is reasonable is to either pass down the
> end-of-io callback to ll_rw_block as you suggested, or, preferably by just
> forcing the _caller_ to
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> I'm quite aware of that fact ;-) However, you said
>
>On the other hand, I have this suspicion that there is an even simpler
>solution: stop using the end_buffer_io_sync version for writes
>altogether.
>
> If that happens (i.e. if
On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2000, Alexander Viro wrote:
> >
> > Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> > but that will make for somewhat bigger patch. Hey, _you_ are in position
> > to change the locking rules, freeze or
Linus Torvalds wrote:
>
> On Fri, 8 Dec 2000, Daniel Phillips wrote:
> >
> > [ flush-buffers taking the page lock ]
> >
> > This is great when you have buffersize==pagesize. When there are
> > multiple buffers per page it means that some of the buffers might have
> > to wait for flushing just
On Fri, 8 Dec 2000, Daniel Phillips wrote:
>
> [ flush-buffers taking the page lock ]
>
> This is great when you have buffersize==pagesize. When there are
> multiple buffers per page it means that some of the buffers might have
> to wait for flushing just because bdflush started IO on some
On Fri, 08 Dec 2000, Linus Torvalds wrote:
> Btw, I also think that the dirty buffer flushing should get the page lock.
> Right now it touches the buffer list without holding the lock on the page
> that the buffer is on, which means that there is really nothign that
> prevents it from racing with
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> but that will make for somewhat bigger patch. Hey, _you_ are in position
> to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Fix: postpone changing ->b_end_io until the call of ll_rw_block(); if by
> the time of ll_rw_block() some fragments will still have IO in progress -
> wait on them.
>
> Comments?
Yes.
On the other hand, I have this suspicion that there is an
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change ->b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to
On Thu, Dec 07, 2000 at 09:59:18PM -0500, Alexander Viro wrote:
> On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > > BTW, could we finally lose mpx(2)?
> >
> > Maybe we lost it - I find sys_mpx only in a comment in arch/arm/kernel/calls.S
>
> Sure, but man2/mpx.2 is alive and well...
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
*
[EMAIL PROTECTED] said:
> Can you test some more? In particular, I'd love to hear if this
> happens with vfat even without loopback, or with loopback even without
> vfat (make an ext2 filesystem or similar instead). That woul dnarrow
> down the bug further.
Loopback-mounted iso9660 does it
[EMAIL PROTECTED] said:
Can you test some more? In particular, I'd love to hear if this
happens with vfat even without loopback, or with loopback even without
vfat (make an ext2 filesystem or similar instead). That woul dnarrow
down the bug further.
Loopback-mounted iso9660 does it too.
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
*
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change -b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to
On Fri, 8 Dec 2000, Alexander Viro wrote:
Fix: postpone changing -b_end_io until the call of ll_rw_block(); if by
the time of ll_rw_block() some fragments will still have IO in progress -
wait on them.
Comments?
Yes.
On the other hand, I have this suspicion that there is an even
On Fri, 8 Dec 2000, Alexander Viro wrote:
Erm... So you want to make -commit_write() page-unlocking? Fine with me,
but that will make for somewhat bigger patch. Hey, _you_ are in position
to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit more.
On Fri, 08 Dec 2000, Linus Torvalds wrote:
Btw, I also think that the dirty buffer flushing should get the page lock.
Right now it touches the buffer list without holding the lock on the page
that the buffer is on, which means that there is really nothign that
prevents it from racing with the
On Fri, 8 Dec 2000, Daniel Phillips wrote:
[ flush-buffers taking the page lock ]
This is great when you have buffersize==pagesize. When there are
multiple buffers per page it means that some of the buffers might have
to wait for flushing just because bdflush started IO on some other
On Fri, 8 Dec 2000, Linus Torvalds wrote:
On Fri, 8 Dec 2000, Alexander Viro wrote:
Erm... So you want to make -commit_write() page-unlocking? Fine with me,
but that will make for somewhat bigger patch. Hey, _you_ are in position
to change the locking rules, freeze or not, so if
On Fri, 8 Dec 2000, Alexander Viro wrote:
I'm quite aware of that fact ;-) However, you said
On the other hand, I have this suspicion that there is an even simpler
solution: stop using the end_buffer_io_sync version for writes
altogether.
If that happens (i.e. if write
On Fri, 8 Dec 2000, Linus Torvalds wrote:
Looking more at this issue, I suspect that the easiest pretty solution
that everybody can probably agree is reasonable is to either pass down the
end-of-io callback to ll_rw_block as you suggested, or, preferably by just
forcing the _caller_ to do
Linus Torvalds wrote:
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pr
On Thu, 07 Dec 2000 17:23:51 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>i'll check it out. i'm compiling ksymoops now, is there a way to get it to
>work without a static libbfd? all i've got is a libbfd.so, and i'm going to
>need to recompile binutils if i must have a libbfd.a.
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
>
> See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
Got them, thanks.
> > BTW, could we finally lose mpx(2)?
>
> Maybe we lost it - I find sys_mpx only in a comment in
old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pre6+ detects it, and thus the BUG().
>
> Your stack trace isn't symboli
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
> Your stack trace isn't symbolic (see
unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG().
Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
it's impossible to debug, but it's already interesting information to
On Thu, 07 Dec 2000 14:42:38 -0800,
Joseph Cheek <[EMAIL PROTECTED]> wrote:
>loop.o built as module. this hard crashes the machine, every time
>[PIII-450]. i don't know how to debug this, is there a FAQ?
linux/Documentation/oops-tracing.txt
-
To unsubscribe from this list: send the line
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
[transcribed by hand]:
# mount -o loop /tmp/cdboot.288 /mnt/cd
# cd /mnt/cd
On Thu, 7 Dec 2000, Andries Brouwer wrote:
> On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
>
> > Al, currently walking through the /usr/share/man/man2 and swearing silently...
>
> Swearing? At the POSIX decisions or at the man page quality?
Mostly at the
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
> Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
In the latter case, additions and corrections are very welcome.
Make sure that you have
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote:
>
> Oh, lovely - where the hell had the following come from?
> % man truncate
> ...
>EINVAL The pathname contains a character with the high-
> order bit set.
> ...
> Andries, would you mind removing that,
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> yet. So far you only said that a different implementation, i.e. a
> different place to put the checks, is preferrable.
-EPERM returned by permission() if we ask for write access to immutable.
Al, currently walking through the /usr/share/man/man2
On Thu, 7 Dec 2000, Alexander Viro wrote:
> On Thu, 7 Dec 2000, Tigran Aivazian wrote:
>
> > The rationale for being compatible with 4.4BSD on append-only but not on
> > immutable is -- for immutable we can do the test by means of permission()
> > fast but for append-only we would need an extra
On Thu, 7 Dec 2000, Alexander Viro wrote:
> So correct solution may very well be to change the return value of
> permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that
> knfsd already has something like that. It makes sense for directories,
> BTW - having may_delete() drop the
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> The rationale for being compatible with 4.4BSD on append-only but not on
> immutable is -- for immutable we can do the test by means of permission()
> fast but for append-only we would need an extra if() above permission so
> let's just be
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> a) we don't hit that test because permission takes care of it (for
> regulars/dirs/symlinks but here only regulars are important)
omit what is in brackets but everything in email and the patch itself are
valid and tested. The detail in bracket above
On Wed, 6 Dec 2000, Alexander Viro wrote:
> On Wed, 6 Dec 2000, Linus Torvalds wrote:
> > Why remove the EROFS test?
>
> there, so if it's not a regular file we die before the call of permission(),
> if it is and fs is readonly - we get -EROFS from permission() and die
> there. In either case we
On Wed, 6 Dec 2000, Alexander Viro wrote:
On Wed, 6 Dec 2000, Linus Torvalds wrote:
Why remove the EROFS test?
there, so if it's not a regular file we die before the call of permission(),
if it is and fs is readonly - we get -EROFS from permission() and die
there. In either case we don't
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
The rationale for being compatible with 4.4BSD on append-only but not on
immutable is -- for immutable we can do the test by means of permission()
fast but for append-only we would need an extra if() above permission so
let's just be
On Thu, 7 Dec 2000, Alexander Viro wrote:
So correct solution may very well be to change the return value of
permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that
knfsd already has something like that. It makes sense for directories,
BTW - having may_delete() drop the
On Thu, 7 Dec 2000, Alexander Viro wrote:
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
The rationale for being compatible with 4.4BSD on append-only but not on
immutable is -- for immutable we can do the test by means of permission()
fast but for append-only we would need an extra if()
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
yet. So far you only said that a different implementation, i.e. a
different place to put the checks, is preferrable.
-EPERM returned by permission() if we ask for write access to immutable.
Al, currently walking through the /usr/share/man/man2 and
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote:
looking at the truncate(2) manpage
Oh, lovely - where the hell had the following come from?
% man truncate
...
EINVAL The pathname contains a character with the high-
order bit set.
...
Andries, would
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
In the latter case, additions and corrections are very welcome.
Make sure that you have
On Thu, 7 Dec 2000, Andries Brouwer wrote:
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
Mostly at the
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
[transcribed by hand]:
# mount -o loop /tmp/cdboot.288 /mnt/cd
# cd /mnt/cd
On Thu, 07 Dec 2000 14:42:38 -0800,
Joseph Cheek [EMAIL PROTECTED] wrote:
loop.o built as module. this hard crashes the machine, every time
[PIII-450]. i don't know how to debug this, is there a FAQ?
linux/Documentation/oops-tracing.txt
-
To unsubscribe from this list: send the line
unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG().
Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
it's impossible to debug, but it's already interesting information to
see that it seems
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
Your stack trace isn't symbolic (see
test.
Apparently loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG().
Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
it's impossible to debug, but it's
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
Got them, thanks.
BTW, could we finally lose mpx(2)?
Maybe we lost it - I find sys_mpx only in a comment in
On Thu, 07 Dec 2000 17:23:51 -0800,
Joseph Cheek [EMAIL PROTECTED] wrote:
i'll check it out. i'm compiling ksymoops now, is there a way to get it to
work without a static libbfd? all i've got is a libbfd.so, and i'm going to
need to recompile binutils if i must have a libbfd.a.
Linus Torvalds wrote:
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG
I'm glad to say that this is the first 2.4 kernel that works on my noritake
alpha with a pci-pci bridge.
I have a small problem. If I reboot, the srm console can't boot from dka0.
Doing a: show dev
doesn't list any of the hard drives in the machine.
doing an init causes it to reset and find all
Andrew Morton wrote:
> Wakko Warner wrote:
> >
> > > - pre6:
> > > - Andrew Morton: exec_usermodehelper fixes
> >
> > pre4 oopsed all over the place on my alpha with modules and autoloading
> > turned on as soon as it mounted / and freed unused memory. I take it this
> > was seen on i386
> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
>
...
> Now, this is with a bog-standard PIIX irq router, so we
> definitely know
> that we have the pirq table parsing right. I even have unofficial
> confirmation from intel engineers on this.
>
> But I see something obviously wrong there:
Erik Mouw wrote:
> On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
>
>> But I see something obviously wrong there: you have busmaster disabled.
>>
>> Looking into the UHCI controller code, I notice that neither UHCI driver
>> actually does the (required)
>>
>>
Jeff Garzik wrote:
> eh? It's self-evident from Erik's patch that pci_enable_device's return
> call is already being tested, thus you only need to add a call to
> pci_set_master.
Sorry. I'll shut up now and go back to doing something
I actually am somewhat knowledgable about -- namely,
Miles Lane wrote:
>
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
eh? It's self-evident from Erik's patch that pci_enable_device's return
call is already being tested, thus you only need to add a call to
pci_set_master.
Jeff
--
Jeff
On Wed, Dec 06, 2000, Miles Lane <[EMAIL PROTECTED]> wrote:
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
Hmm. Your patch doesn't test whether pci_enable_device(dev)
was successful, does it?
I think what you want is:
diff -u --new-file drivers/usb/uhci.c~ drivers/usb/uhci.c
--- drivers/usb/uhci.c~ Tue Dec 5 23:55:38 2000
+++ drivers/usb/uhci.c Wed Dec 6 14:50:00 2000
@@ -2380,8 +2380,10 @@
On Wed, 6 Dec 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> >
> > This patch combines your previous patch with 2 changes I have just
> > suggested. Both changes are obvious (and correct).
>
> Why remove the EROFS test?
Tigran has a point - permission()
Erik Mouw wrote:
>
> On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
> > But I see something obviously wrong there: you have busmaster disabled.
> >
> > Looking into the UHCI controller code, I notice that neither UHCI driver
> > actually does the (required)
> >
> >
On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
> But I see something obviously wrong there: you have busmaster disabled.
>
> Looking into the UHCI controller code, I notice that neither UHCI driver
> actually does the (required)
>
> pci_set_master(dev);
>
> Please add
On Wed, 6 Dec 2000, Erik Mouw wrote:
> >
> > Can you tell me what device it is that doesn't work for you?
>
> The USB controller. That's device 00:07.2:
>
> 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller
>(prog-if 00 [UHCI])
> Control: I/O+ Mem-
On Wed, Dec 06, 2000 at 10:38:51AM -0800, Linus Torvalds wrote:
> On Wed, 6 Dec 2000, Erik Mouw wrote:
> > So at first the PCI code can't allocate an IRQ for devices 00:00.1
> > (audio), 00:07.2 (USB), and 00:09.0 (winmodem), but after the audio and
> > USB modules get inserted, IRQ 5 and 11 get
On Wed, 6 Dec 2000, Erik Mouw wrote:
>
> So at first the PCI code can't allocate an IRQ for devices 00:00.1
> (audio), 00:07.2 (USB), and 00:09.0 (winmodem), but after the audio and
> USB modules get inserted, IRQ 5 and 11 get allocated.
No, the irq stuff is a two-stage process: at first it
On Tue, Dec 05, 2000 at 11:25:55PM -0800, Linus Torvalds wrote:
> Concering the PCI irq routing fixes in particular, I'd ask people with
> laptops to start testing their kernels with PnP OS set to "yes" in the
> BIOS setup. We shoul dbe at a stage where it should basically work all the
> time,
Tobias Ringstrom wrote:
> The way I see it, 2.4.0-test12-pre6 is just a much longer name for 2.4.0.
> Keep going like this and we may end up calling you Linus "Santa" Torvalds!
> It has a nice ring to it, don't you think? :-) Or should that be *-<:-)
I appr
gt; time, and it would be interesting to hear about cases that we don't handle
> right.
It works fine here on a Mitac laptop (the one that needed a Win98
warm-boot a few weeks ago), but it is quite noisy about IRQs that are also
used for other devices. (PCI: The same IRQ used for device 00:08.0)
The way I
Wakko Warner wrote:
>
> > - pre6:
> > - Andrew Morton: exec_usermodehelper fixes
>
> pre4 oopsed all over the place on my alpha with modules and autoloading
> turned on as soon as it mounted / and freed unused memory. I take it this
> was seen on i386 as well?
No... The problems showed
> - pre6:
> - Andrew Morton: exec_usermodehelper fixes
pre4 oopsed all over the place on my alpha with modules and autoloading
turned on as soon as it mounted / and freed unused memory. I take it this
was seen on i386 as well?
Will try pre6.
--
Lab tests show that use of micro$oft
1 - 100 of 141 matches
Mail list logo
