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 a
> 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: you
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)
>>
>> pci_set_mast
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, testi
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 Garzik
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
t
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 @@
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)
> >
> > pci_set_
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 tha
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- BusM
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 a
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
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, and
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 appreciate your enthusiasm, but I'd
On Tue, 5 Dec 2000, 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, and it would be interesti
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 t
> - 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 cause
On Wed, 6 Dec 2000, Alexander Viro wrote:
> They are not Linux-specific (check where they came from), so I would rather
> check 4.4BSD and SuSv2[1] be damned. I'll look it up tomorrow, right now I'm
> going down. Sorry.
4.4BSD (FreeBSD 4.2-release) returns EPERM for truncate on immutable (schg
or
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> > error = -EPERM;
> > if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> > goto dput_and_out;
>
> also, while we are here -- are you sure that EPERM is a good idea for
> IS_IMMUTABLE(inode
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> error = -EPERM;
> if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> goto dput_and_out;
also, while we are here -- are you sure that EPERM is a good idea for
IS_IMMUTABLE(inode)? Other parts of Linux return EACCES in this
case. Ma
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> minutes ago... maybe you could merge it into yours and re-send to Linus?
here is the merged patch:
--- linux/fs/open.c Thu Oct 26 16:11:21 2000
+++ work/fs/open.c Wed Dec 6 07:38:30 2000
@@ -102,7 +102,12 @@
goto out;
Oh, Alexander your patch conflicts (well, not strictly but causes
patch(1) to spew warnings) with the one I just wanted to send to Linus 10
minutes ago... maybe you could merge it into yours and re-send to Linus?
Mine is obvious, see below (vfs_permission does have enough to fail with
EROFS on a
ext2_get_block() should return -EFBIG if the block number is
too large for our block size. It returns -EIO and prints a warning
right now. Fix: don't generate bogus warnings (we can legitimately
get larger-than-maximum arguments; there is no way in hell VFS or VM
could know the ext2-specif
truncate() and ftruncate() return values are different from the
POSIX requirements and from the values returned by other Unices (and from
our own manpages, BTW). Trivial fix follows. Rationale: see truncate(2),
ftruncate(2), POSIX or try to call the thing on other Unices.
Please,
If get_block() fails in block_prepare_write() we should zero
the blocks we've allocated and mark them dirty. We don't (i.e. we leave
the random junk in file in that case). Fix: do it. Moreover, if
->prepare_write() fails generic_file_write() is not going to write the user's
data into that
ext2_update_inode() marks the filesystems as having large files
if there the file becomes too large for old driver (2.2 one). Unfortunately,
it gets the limit wrong - it's not 2^32, it's 2^31. So we should check
for ->i_size_high being non zero _or_ ->i_size having bit 31 set. Please,
appl
On Tue, 5 Dec 2000, Linus Torvalds wrote:
>
> Ok, I almost called this the final test12, but I wanted to get some more
> feedback on the keyboard controller stuff and PCI irq routing.
Linus, could you apply the following bunch of fixes (split into separate
emails):
* dentry leak upon
27 matches
Mail list logo
