On Tue, 24 Oct 2000, Dan Kegel wrote:
Linus Torvalds wrote:
Basically, the main loop would boil down to
for (;;) {
static struct event ev_list[MAXEV];
get_event(ev_list, MAXEV, tmout);
.. timeout handling here
On Tue, 24 Oct 2000, Mitchell Blank Jr wrote:
I think everyone should take a timeout and look at Solaris 8's /dev/poll
interface. This discussion is reinventing the wheel, the lever, and the
inclined plane.
http://docs.sun.com/ab2/coll.40.6/REFMAN7/@Ab2PageView/55123
I think
On Tue, 24 Oct 2000, Simon Kirby wrote:
However, isn't there already something like this, albeit maybe without
the ability to return multiple events at a time? When discussing
select/poll on IRC a while ago with sct, sct said:
sct Simon: You just put your sockets into
In article [EMAIL PROTECTED],
Chris Evans [EMAIL PROTECTED] wrote:
On Mon, 23 Oct 2000, Jeff Garzik wrote:
First test was with 2.4.0-test10-pre3.
Next four tests were with 2.4.0-test10-pre4.
Final four tests were with 2.2.18-pre17.
All are 'virgin' kernels, without any patches.
[...]
On Tue, 24 Oct 2000, Dan Kegel wrote:
But user code currently written for poll() has the luxury of dropping
events because poll() will happily report on the current readiness of
the socket every time. /dev/poll is level-triggered because it's trying
to make conversion of poll()-based
On Tue, 24 Oct 2000, Abramo Bagnara wrote:
Linus Torvalds wrote:
struct event {
int fd;
unsigned long mask;
void *opaque;
void (*event_fn)(ind fd, unsigned long mask, void *opaque);
My experience say
On Tue, 24 Oct 2000, Jeff Garzik wrote:
I agree with you and Rik that this array needs to go away... but
ripping out the feature is not the answer, IMHO.
Actually, the _real_ answer is to make fs/block_dev.c use the page cache
instead - and generic_file_read() does read-ahead that
On Tue, 24 Oct 2000, jamal wrote:
(Now that i see Martin alive).
Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
On Tue, 24 Oct 2000, Andrew Morton wrote:
if the person who sent you the -pre4 patch against module.c
had Cc:'ed this mailing list then your kernel would do
something useful when compiled with gcc-2.7.2.3.
It seems that gcc-2.7.2.3 is terminally ill. I'd rather change
On Tue, 24 Oct 2000, Evan Jeffrey wrote:
Multiple event queues are bad, because it completely breaks the notion of
even-driven programming. How do you want to listen to them all? You can't.
You can only listen to one event queue at a time - unless you create some
You can listen to
On Wed, 25 Oct 2000, Rik van Riel wrote:
OTOH, block-dev readahead makes sense for filesystems where
the packing locality is close to the access pattern BUT NOT
close to anything the page cache would recognise as being
close.
I dunno. The main reason I'd like to get the block devices
On Thu, 22 Feb 2001, Jeff Lessem wrote:
In your message of: Thu, 22 Feb 2001 20:37:15 PST, you write:
Hmm.. You shouldn't be loading any i82365 module at all. You should load
the "yenta_socket" module.
I had gone back to my old ways of useing the external PCMCIA stuff.
Here are the
On Fri, 23 Feb 2001, Andrea Arcangeli wrote:
I think that can't happen. Infact I think the whole section:
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
if (pmd_present(*pmd) || !pmd_present(*pmd_k))
In article [EMAIL PROTECTED],
Reto Baettig [EMAIL PROTECTED] wrote:
We would volounteer to improve vmalloc if there is any chance of
getting it into the main kernel tree. We also have an idea how we
Could do that (quite similar to the process address space management):
1. Create a generic
On Sun, 25 Feb 2001, Steve Whitehouse wrote:
Here is a new version of the patch I recently sent to the list with some
NBD cleanups and a bug fix in ll_rw_blk.c. The changes to NBD have Pavel
Machek's approval as I've left out the two changes as he suggested.
The bug fix in ll_rw_blk.c
On Wed, 28 Feb 2001, Steve Whitehouse wrote:
I tested the patch with a printk() which printed whenever the new call to the
request function was triggered. It didn't happen once in normal fs use
with ext2 on a scsi disk.
As far as I can tell, the patch will trigger only for a not-empty
In article [EMAIL PROTECTED], Jens Axboe [EMAIL PROTECTED] wrote:
I think most of the "we want to disable plugging" behaviour stems
from the way task queues behave. Once somebody starts a tq_disk
run, the list is fried and walked one by one. Both old loop
and nbd drop the io_request_lock and
In article [EMAIL PROTECTED],
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2001 at 06:20:49PM +, Alan Cox wrote:
It's not broken, it's not there any longer as somebody dropped it between test7
and 2.4.2, may I ask why?
Linus took it out because it was breaking things.
If
In article [EMAIL PROTECTED],
Alexander Viro [EMAIL PROTECTED] wrote:
Alan, fix is really quite simple. Especially if you have vmtruncate()
returning int (ac1 used to do it, I didn't check later ones). Actually
just a generic_cont_expand() done on expanding path in vmtruncate()
will be enough -
In article [EMAIL PROTECTED],
Rik van Riel [EMAIL PROTECTED] wrote:
I haven't tested it yet for a number of reasons. The most
important one is that the FreeBSD people have been playing
with this thing for a few years now and Matt Dillon has
told me the result of their tests ;)
Note that the
On Fri, 2 Mar 2001, David Howells wrote:
Surely, doing the merge will always have take longer than not doing the merge,
no matter how finely optimised the algorithm... But merging wouldn't be done
very often... only on memory allocation calls.
Ehh.. If the merging doesn't actually happen,
In article [EMAIL PROTECTED],
Jeremy Hansen [EMAIL PROTECTED] wrote:
The SCSI adapter on the raid array is an Adaptec 39160, the raid
controller is a CMD-7040. Kernel 2.4.0 using XFS for the filesystem on
the raid array, kernel 2.2.18 on ext2 on the IDE drive. The filesystem is
not the
On Sat, 3 Mar 2001, Benjamin Herrenschmidt wrote:
Especially, my question is about the code in enable_irq() which checks
for IRQ_PENDING, and then
"replays" the interrupt by asking the APIC to issue it again.
I don't have a simple way on PPC to cause the interrupt to happen again,
as
On Sat, 3 Mar 2001, David Hinds wrote:
In drivers/pcmcia/cardbus.c in cb_alloc(), PCI_INTERRUPT_LINE and
dev-irq are not filled in until after calling pci_enable_device().
The result is a cryptic message like:
PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try using
In article [EMAIL PROTECTED],
Cort Dougan [EMAIL PROTECTED] wrote:
More generic in terms of using irq_desc[] and some similar structures I can
see. Making do_IRQ() and enable/disable use the same names and structures
as x86 isn't sensible. They're different ports, with different design
In article [EMAIL PROTECTED],
Richard B. Johnson [EMAIL PROTECTED] wrote:
I -- S T R O N G L Y -- suggest that nobody use this kernel with
a BusLogic SCSI controller until this problem is fixed.
Ho humm..
Anybody who has any ideas or input, please holler. There are no actual
BusLogic
In article [EMAIL PROTECTED],
Scott M. Hoffman [EMAIL PROTECTED] wrote:
It may not be related, but out of five boot attempts, only one got past
the IDE driver stage(ie, below from 2.4.2 :
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode:
On Tue, 6 Mar 2001, Jonathan Morton wrote:
It's pretty clear that the IDE drive(r) is *not* waiting for the physical
write to take place before returning control to the user program, whereas
the SCSI drive(r) is.
This would not be unexpected.
IDE drives generally always do write
On Tue, 6 Mar 2001, Douglas Gilbert wrote:
On the other hand, it's also entirely possible that IDE is just a lot
better than what the SCSI-bigots tend to claim. It's not all that
surprising, considering that the PC industry has pushed untold billions of
dollars into improving IDE,
On Tue, 6 Mar 2001, Alan Cox wrote:
I don't know if there is any way to turn of a write buffer on an IDE disk.
You want a forced set of commands to kill caching at init?
Wrong model
You want a write barrier. Write buffering (at least for short intervals) in
the drive is very
In article [EMAIL PROTECTED],
Jamie Lokier [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
the space allowed for arguments is not a userland issue, it is a kernel
limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one
wanted to without breaking any userland.
Which is
In article [EMAIL PROTECTED],
Justin T. Gibbs [EMAIL PROTECTED] wrote:
I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890
Ultra II scsi controller. I'm attaching the console grab when booting
2.4.3-pre2. The controller BIOS is configured to boot off the disk with
scsi id 0 on
In article [EMAIL PROTECTED],
Rik van Riel [EMAIL PROTECTED] wrote:
OK, I'll write some code to prevent multiple threads from
stepping all over each other when they pagefault at the
same address.
What would be the preferred method of fixing this ?
- fixing do_swap_page and all -nopage
On Sun, 18 Mar 2001, Jens Axboe wrote:
The 256 is _not_ a bug in the driver, it's more likely a bug in your
drive. 256 is a perfectly legal transfer size. That said, maybe it is
a good idea to leave it at 255 just for safety on drives not handling
0 sectors == 128kB transfer.
Agreed. That
On Sun, 18 Mar 2001, Rik van Riel wrote:
Indeed, having threaded apps do multiple page faults at the
same time is the main goal of this patch. However, I don't
see how it would be good for scalability to have multiple
threads fault in the same page at the same time, when they
could just
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
Agreed. That would be a trivially easy bug in the firmware, limiting to
255 sectors seems safer.
Linus
Yes, possibly.
I checked old standards, and see that "0 means 256 as a sector count"
is already in ATA-1.
Yes. But we
In article 001801c0af8e$bda30c10$5517fea9@local,
Manfred Spraul [EMAIL PROTECTED] wrote:
Unortunately schedule() with disabled interrupts is a feature, it's
needed for the old (deprecated and waiting for termination in 2.5)
sleep_on() functions.
Yes. But that should only cover "sleep_on()" and
Now the code is beautiful and it might even be bugfree ;)
I'm applying this to my tree - I'm not exactly comfortable with this
during the 2.4.x timeframe, but at the same time I'm even less comfortable
with the current alternative, which is to make the regular semaphores
fairer (we tried it
On Mon, 19 Mar 2001, Linus Torvalds wrote:
Excellent point. We used to do all the looping and re-trying, but it got
ripped out a long time ago (and in any case, it historically didn't do
SMP, so the old code doesn't really work).
Actually, funnily enough, I see that the old thread-safe
On Tue, 20 Mar 2001, Manfred Spraul wrote:
Rik, did you check that {pte,pmd}_alloc are thread safe? At least in
2.4.2 they aren't (include/asm-i386/pgalloc.h), and your patch doesn't
touch pgalloc.
Excellent point. We used to do all the looping and re-trying, but it got
ripped out a long
There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org.
The complete changelog is appended, but the biggest recent change is the
mmap_sem change, which I updated with new locking rules for pte/pmd_alloc
to avoid the race on the actual page table build.
This has only been tested on i386
On Tue, 20 Mar 2001, Andrew Morton wrote:
Linus Torvalds wrote:
There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org.
I can't see it. Where did you hide it?
Ahh. The mirroring is apparently broken. I put my stuff on a faster local
connection to "master.kernel.org",
On Tue, 20 Mar 2001, Rik van Riel wrote:
(ie the patch really isn't ready yet to be included in the
main kernel ... OTOH, the changes needed to make it ready
are all trivial and tedious ;))
They are trivial and tedious only if done wrong - which will also add tons
of new places where we
On Tue, 20 Mar 2001, Marcelo Tosatti wrote:
Could the IDE one cause corruption ?
Only with broken disks, as far as we know right now. There's been so far
just one report of this problem, and nobody has heard back about which
disk this was.. And it should be noisy about it when it happens -
On Tue, 20 Mar 2001, Marcelo Tosatti wrote:
I'll put pre5 in and try to reproduce the problem (I hitted it while
running pgbench + shmtest).
I found a case where pre5 will forget to unlock the page_table_lock (in
copy_page_range()), and one place where I had missed the lock altogether
(in
On Tue, 20 Mar 2001, Alessandro Suardi wrote:
2.4.3-pre3 and synced-up versions of the -ac series remove support for
PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
files are modified to exclude serial_cb and the serial_cb.c file itself
is removed by the patch.
In article [EMAIL PROTECTED],
Pau [EMAIL PROTECTED] wrote:
I've been running 2.4.3-pre4 for a few days now and today I've got this
message in the logs a couple of times. Is it harmless?
It's harmless.
It's really a warning that says: the mm that you allocated a new LDT for
may have multiple
On Tue, 20 Mar 2001, Serge Orlov wrote:
I upgraded one of our computer happily running 2.2.13 kernel
to 2.4.2. Everything was OK, but compilation time of our C++
project greatly increased (1.4 times slower). I investigated the
issue and found that g++ spends 7 times more time in kernel.
In article [EMAIL PROTECTED],
Anton Blanchard [EMAIL PROTECTED] wrote:
It was not surprising the BKL was one of the main offenders. Looking at the
stats ext2_get_block was the bad guy (UTIL is % of time lock was busy for,
WAIT is time spent waiting for lock):
Actually, I find the BKL fairly
On Wed, 21 Mar 2001, Mike Galbraith wrote:
I have a repeatable deadlock when SMP is enabled on my UP box.
EIP; c021e29a stext_lock+1556/677b =
When you see something like this, please do
gdb vmlinux
(gdb) x/10i 0xc021e29a
and it will basically show you where the
In article [EMAIL PROTECTED],
Nigel Gamble [EMAIL PROTECTED] wrote:
Why is the kernel lock held around sync_supers() and sync_inodes() in
sync_old_buffers() and fsync_dev(), but not in sync_dev()? Is it just
to serialize calls to these functions, or is there some other reason?
A lot of the FS
On Wed, 21 Mar 2001, Linus Torvalds wrote:
The deadlock implies that somebody scheduled with page_table_lock held.
Which would be really bad.
..and it is probably do_swap_page().
Despite the name, "lookup_swap_cache()" does more than a lookup - it will
wait for the page that it
On Thu, 22 Mar 2001, Stephen C. Tweedie wrote:
There is what appears to be a simple thinko in kswapd. We really
ought to keep kswapd running as long as there is either a free space
or an inactive page shortfall; but right now we only keep going if
_both_ are short.
Hmm.. The comment
On Tue, 21 Nov 2000, Jeff Garzik wrote:
A caveat to this whole scheme is that usb-uhci -already- calls
pci_enable_device before checking dev-irq, and yet cannot get around
the "assign IRQ to USB: no" setting in BIOS. I hope that is an
exception rather than the rule.
Do we have a recent
On Thu, 23 Nov 2000 [EMAIL PROTECTED] wrote:
I never read assembler, but looking at the code produced
by gcc (2.95.2) it seemed peculiar, maybe an attempt to
optimize something combining the
if (filp-f_pos = inode-i_size)
with the
while (filp-f_pos inode-i_size)
slightly
On Tue, 21 Nov 2000, Tobias Ringstrom wrote:
Tobias, can you confirm that calling pci_enable_device before reading
dev-irq fixes the 3c59x.c problem for you?
Nope. The interrupts do not seem to get through. Packets are transmitted,
but that's it. I've copied the interesting parts
On Thu, 23 Nov 2000, Ragnar Hojland Espinosa wrote:
Yup, indeed it solves the dir/namei problem.
Can you check whether the single patch of _just_ removing the extra "f_pos
= i_size" test in do_isofs_readdir() fixes it? The other changes of
Andries patch look like they should not affect
On Thu, 23 Nov 2000, Jeff Garzik wrote:
It hangs in start_uhci():
/* disable legacy emulation */
pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
Try changing the thing around a bit: make the above place say
/* disable legacy
In article [EMAIL PROTECTED],
Guest section DW [EMAIL PROTECTED] wrote:
(But I described the situation where the data on disk was correct
and the date in core was not - almost certainly this is not an IDE problem.)
Ehh.. It only means that it would have been a read failure instead of a
write
Oh, well. Some people saw the (unannounced, and not for public
consumption) pre1, so here's pre2. pre1 was just meant to be an interim
patch to sync up with the ISDN patches.
Due to the birth of my third daughter last week (yes, I got /.'ed), if you
sent me patches that aren't in pre2, you can
On Tue, 28 Nov 2000, Neil Brown wrote:
What happens about the stuff that went in to 2.4.0test11-ac{1,2,3,4}?
Are you going to "sync-up" with Alan, or should we send bits directly
to you?
Either, or both.
Alan feeds me his patches in small chunks anyway, and does a good job of
keeping
On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote:
I did again a large test comparing two identical trees.
Found again corruption, and, upon inspection, the disk
files did not differ - this is in-core corruption only.
Ok. It definitely looks like the 1kB thing has become broken somehow.
The
The bulk of this is architecture updates (most lately mips64). The most
interesting (but fairly small) part is the VM cleanups. Any day now
kiobuf's can just use PageDirty on everything, and we won't have any nasty
races any more.
Linus
- pre3:
- me: more PageDirty /
On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote:
can you give a rough estimate on when you suspect you started seeing it?
I reported both cases. That is, I started seeing it a few days ago.
I wasn't trying to imply that you hadn't reported them well.
It's just that I was born with a highly
On Wed, 29 Nov 2000, Jens Axboe wrote:
I agree with your reasoning, even if the s390 behaviour is a bit
"non-standard" wrt block devices. Linus, could you apply?
--- drivers/block/ll_rw_blk.c~Wed Nov 29 15:17:33 2000
+++ drivers/block/ll_rw_blk.c Wed Nov 29 15:18:43 2000
@@
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
On Wed, 29 Nov 2000, Linus Torvalds wrote:
That still leaves the SCSI corruption, which could not have been due to
the request issue. What's the pattern there for people?
one more thing I
On Wed, 29 Nov 2000, Alexander Viro wrote:
Problem fixed by Jens' patch had been there since March, so if it's a
mix of __make_request() screwing up and something else... Urgh.
No, the bug really got introduced in test11 due to the request merging
stuff.
The patch may _look_ like it fixed
In article 90a065$5ai$[EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] wrote:
Anyway, I do have this machine working now, although not everything is
to my liking. Unlike older picture-books, for example, this one has a
WinModem. Ugh. And the sound chip is supported, but only by the ALSA
On Sat, 2 Dec 2000, Ion Badulescu wrote:
If it's the same bug that locks up the ATI chipset on my Dell laptop,
then you can safely enable DPMS if only enable the standby mode,
not the others (suspend and off). The panel gets turned off anyway,
even in standby.
Yup, same bug, and yes,
On Sat, 2 Dec 2000, Alan Cox wrote:
But the camera is cool, and works beautifully (once you get XFree86
happy) thanks to Andrew Tridgell. (If I could just coax the X server
into giving my a YUV overlay I could play DVD's with this thing).
Start at
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
Linus
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
-
On Tue, 5 Dec 2000, Andrew Morton wrote:
- test12-pre4
- aviro bforget patch
Is the bforget patch really needed?
If clear_inode() gets rid of dirty buffers, I don't see how new dirty
buffers can magically appear. I may have missed part of the discussion on
all this.
I think
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
On Mon, 4 Dec 2000, Alexander Viro wrote:
Well, to start with you don't want random bh's floating around on the
inode's list. With the current code truncate()+fsync() can send a lot
of already freed stuff to disk. Even though we can survive that (making
clear_inode() to get rid of the
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 posting
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, 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, 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, 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
Ok, I now have two confirmations from independent people (Adam Richter
and Kai Germaschewski) who have completely different hardware, but have
the same problem: irq routing seems to not work for them.
In both cases it is because the PCI device config space already has an
entry for the
On Wed, 6 Dec 2000, Urban Widmark wrote:
Hardlinks are not supported by smbfs, but they may be supported on the
server side (ntfs). Haven't looked if smb has anything on this. Not sure
if there are any implications on caching and such for smbfs. (If hardlinks
need to be handled, smbfs is
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
Okay, here is my latest attempt to find a way to toggle A20M# that
genuinely works on all machines -- including Olivettis, IBM Aptivas,
bizarre notebooks, yadda yadda.
I really think that the 0x92 accesses are still unsafe.
I will bet that the
On Wed, 6 Dec 2000, Kai Germaschewski wrote:
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
If you have had A20M# problems with any kernel -- recent or not --
*please* try this patch, against 2.4.0-test12-pre5:
Just a datapoint: This patch doesn't fix the problem here (Sony
On Wed, 6 Dec 2000, Kai Germaschewski wrote:
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
If you have had A20M# problems with any kernel -- recent or not --
*please* try this patch, against 2.4.0-test12-pre5:
Just a datapoint: This patch doesn't fix the problem here (Sony
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
I might hack on using INT 15h to do the jump to protected mode, as ugly
as it is, but I won't have time before my trip. It would require quite a
bit of restructuring in setup.S, and would probably break LOADLIN.
Right now this is my interim patch
On Tue, 5 Dec 2000, Linus Torvalds wrote:
Right now this is my interim patch (to clean test11). The thing to note is
that I decreased the keyboard controller timeout by a factor of about 167,
while making the "delay" a bit longer.
Oh, btw, I forgot to ask people to give this
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.
The biggest part of this is the budding parisc stuff, but it's unlikely
that we'll see full parisc support in 2.4.0 - the remaining pieces that
actually touch
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 only
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- BusMaster-
On Wed, 6 Dec 2000, Miles Lane wrote:
If I insert both my 3c575 and Belkin BusPort Mobile USB host-controller
and then enable both of them, "modprobe usb-ohci" hangs. If I then
attempt "modprobe -r 3c59x", that process hangs, too. lsmod shows:
usb-ohci 15072 1
The only reason for this pre7 is to resolve some warring patches in the
cs46xx driver.
Linus
---
- test7:
- Kai Germaschewski: ymfpci cleanups and resource leak fixes
- me: UHCI drivers really need to enable bus mastering.
- Trond Myklebust: fix up
On Wed, 6 Dec 2000, Miles Lane wrote:
Here is what goes wrong:
Dec 6 04:21:32 agate kernel: eth0: Host error, FIFO diagnostic register .
But it continues to work, right?
I bet that your ethernet card is just unhappy that it couldn't get DMA in
time, because the bus was so busy.
On Thu, 7 Dec 2000, Russell King wrote:
Is it intentional that pci_assign_unassigned_resources should:
1. enable all devices?
2. enable bus master on all devices?
Probably intentional, but probably for all the wrong reasons.
The device enabling is still required for all drivers that
On Thu, 7 Dec 2000, Martin Diehl wrote:
btw, I'm thinking I could guess the routing from the VLSI config space,
but I don't have any doc's. Would it be worth to try to add some specific
get/set methods for this device? What about testers (or people who have
access to the docs)?
Please
In article [EMAIL PROTECTED],
Joseph Cheek [EMAIL PROTECTED] wrote:
copying files off a loopback-mounted vfat filesystem exposes this bug.
test11 worked fine.
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
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
muddled together and hard to debug. Running with page aging convinces me that
2.2.19 we need to sort some of the vm issues out badly, and make it faster
On 8 Dec 2000, Christoph Rohland wrote:
here is my first shot for cleaning up the shm handling. It did survive
some basic testing but is not ready for inclusion.
The only comment I have right now is that you probably should not mark the
page dirty in "nopage" - theoretically somebody
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, 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
401 - 500 of 24431 matches
Mail list logo
