On Fri, 22 Sep 2000, Linus Torvalds wrote:
> On Fri, 22 Sep 2000, Molnar Ingo wrote:
> >
> > i'm still getting VM related lockups during heavy write load, in
> > test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
> > last VM related fix-patch
On Fri, 22 Sep 2000, Molnar Ingo wrote:
>
> i'm still getting VM related lockups during heavy write load, in
> test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
> last VM related fix-patch, correct?). Here is a histogram of such a
> lockup:
Rik,
If the process that barfed is swapper then this is the oops that I got
in test9-pre4 w/o any patches.
http://marc.theaimsgroup.com/?l=linux-kernel&m=96936789621245&w=2
On Fri, 22 Sep 2000, André Dahlqvist wrote:
> On Fri, Sep 22, 2000 at 07:27:30AM -0300, Rik van Riel wrote:
>
> > Linus,
> >
> I had to type the oops down by hand, but I will provide ksymoops
> output soon if you need it.
Let's hope I typed down the oops from the screen without misstakes. Here
is the ksymoops output:
ksymoops 2.3.4 on i586 2.4.0-test9. Options used
-V (default)
-k 2922143001.ksyms (spec
On Fri, Sep 22, 2000 at 07:27:30AM -0300, Rik van Riel wrote:
> Linus,
>
> could you please include this patch in the next
> pre patch?
Rik,
I just had an oops with this patch applied. I ran into BUG at
buffer.c:730. The machine was not under load when the oops occured, I
was just reading e-ma
On Fri, 22 Sep 2000, Molnar Ingo wrote:
> yep this has done the trick, the deadlock is gone. I've attached the full
> VM-fixes patch (this fix included) against vanilla test9-pre5.
Linus,
could you please include this patch in the next
pre patch?
(in the mean time, I'll go ba
yep this has done the trick, the deadlock is gone. I've attached the full
VM-fixes patch (this fix included) against vanilla test9-pre5.
Ingo
--- linux/fs/buffer.c.orig Fri Sep 22 02:31:07 2000
+++ linux/fs/buffer.c Fri Sep 22 02:31:13 2000
@@ -706,9 +706,7 @@
static
On Fri, 22 Sep 2000, Rik van Riel wrote:
> 894 if (current->need_resched && !(gfp_mask & __GFP_IO)) {
> 895 __set_current_state(TASK_RUNNING);
> 896 schedule();
> 897 }
> The idea was to not allow processes which have IO locks
> to schedul
On Fri, 22 Sep 2000, Molnar Ingo wrote:
> i'm still getting VM related lockups during heavy write load, in
> test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
> last VM related fix-patch, correct?). Here is a histogram of such a
> lockup:
> this lockup
btw. - no swapdevice here.
Ingo
-
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/
i'm still getting VM related lockups during heavy write load, in
test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
last VM related fix-patch, correct?). Here is a histogram of such a
lockup:
1 Trace; 4010a720 <__switch_to+38/e8>
5 Trace; 4010a74b <
Douglas Gilbert wrote:
> @@ -1298,18 +1302,20 @@
> }
>
> #ifdef MODULE
> -
> MODULE_PARM(def_reserved_size, "i");
> MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
> +#endif /* MODULE */
MODULE_xxx typically doesn't need to be surrounded by ifdef MODULE.
Also not
Linus,
This patch has been generated in response to the thread:
"[2.4.0-test9-pre5] SCSI still broken, trident/mixer
still broken" on lkml today. Simon Kirby reported that
the SCSI generic (sg) wasn't working in the latest
pre-release when the driver was built into the kernel.
T
Sometime between test9-pre3 and test9-pre5, the alternative UHCI driver
(uhci.o) got screwed up - with my MS Natural Keyboard Pro in USB mode &
using the keybdev + hid + uhci driver, pressing one of caps/num/scroll
lock
turns the appropriate light on, but then when pressing the same
caps
On Thu, Sep 21 2000, Douglas Gilbert wrote:
> Torben Mathiasen wrote:
> >
> > Ok, small patch cooked up. Not tested, not compiled. Give
> > it a try, and if it works please send it off to Linus.
> > I really need to get some work done on a project...
>
> Here is a very similar patch that has bee
Cannot boot with 2.4.0-test9-pre5
gcc 2.7.3
compiled as PIII
the .config is the same of previous mails :)
Yuri
--
"I bambini nascono per essere felici"
J
On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...
This worked, thanks. :)
Simon-
[ Stormix Technologies In
Torben Mathiasen wrote:
>
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...
Here is a very similar patch that has been tested
[with a USB zip drive using sg (builtin) to read
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben
On Thu, Sep 21 2000, Douglas Gilbert wrote:
[delete]
> > At one point before I followed some of the debug/logging commands listed
> > at the top of sg.c and got an Oops as well...
>
> Seems as though I've got a lot of retesting to do.
>
Please note that the changes to the scsi midlayer require
On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote:
> I do nearly all of my testing with sg as a module.
> So this looks like (another recent) breakage.
>
> It is beginning to look like the sg driver is not
> (properly) initialized when it is built into the
> kernel. Perhaps you cou
Simon Kirby wrote:
>
> On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
>
> > Interesting. 'cat /proc/scsi/scsi' should show the same
> > devices as 'cat /proc/scsi/sg/device_strs' [and
> > 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> > mid-level is not calling sg_detect
7;ll check with my scsi
> > scanner this evening.
> >
>
> Well first of all the sg driver needs to be updated the
> same way sd and sr was.
Well looking at sr in test9-pre5 the only changes are the
addition of 'static' before the sr_template definition
and various functions.
On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
> Interesting. 'cat /proc/scsi/scsi' should show the same
> devices as 'cat /proc/scsi/sg/device_strs' [and
> 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> mid-level is not calling sg_detect() [in sg.c] for
> all new scsi d
On Thu, Sep 21 2000, Douglas Gilbert wrote:
[deleted]
> It is not clear to me what "hacking" sg requires as
> Torben Mathiasen suggested in his response. This seems
> like a mid level problem. I'll check with my scsi
> scanner this evening.
>
Well first of all the sg driver needs to be updated
Just tested it with a plain 2.4.0-test9-pre5 kernel and the problem is now
fixed.
Thanks to all involved,
Frank.
--
+ --- -- - - --
|Frank van de Pol -o)
| [EMAIL PROTECTED] /\\
| _\_v
|Linux - Why use Windows
Simon Kirby wrote:
> Around 2.4.0-test9-pre2 (or so, definitely in pre3) both my SCSI scanner
> and trident sound card stopped being happy. They are still both broken
> in pre5. On test8, both work perfectly.
>
> On test8:
>
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
> Ven
My IntelliMouse Explorer USB doesn't work with test9-pre5 if I use the
uhci.o module. With usb-uhci.o, it does work fine.
The last kernel I tried was pre9-test2, which was ok.
Other details:
modules loaded:
usbcore
uhci (or usb
On Thu, Sep 21 2000, Simon Kirby wrote:
> ... on test9pre5 and test9pre3:
>
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
> Vendor: Model: Scanner Rev: 1.70
> Type: ScannerANSI SCSI revision: 04
> (scsi0:0:3:0) Synchronous at 8.
Hi n' stuff,
Around 2.4.0-test9-pre2 (or so, definitely in pre3) both my SCSI scanner
and trident sound card stopped being happy. They are still both broken
in pre5. On test8, both work perfectly.
On test8:
(scsi0:6:0) Synchronous Data Transfer Request was rejected
Vendor: Model:
- pre1:
- USB: OHCI controller unlink and bandwidth reclamation fixes
- USB: storage update
- sparc64: register window race. Non-deadlock rwlocks.
- name clash in hamradio/pi2.c and hamradio/pt.c
- epic100 credits, 8139too driver update, sr.c initcalls
- acenic update
31 matches
Mail list logo
