Hello,
On Tue, 19 Sep 2000, Robert H. de Vries wrote:
> It would be better to change SI_SIGIO in all the
> include/asm-*/siginfo.h files from -5 to __SI_CODE(__SI_SIGIO, -5)
> __SI_SIGIO would become (6 << 16).
This is not needed for SI_SIGIO. It is not generated from
the
On Sep 19, 8:39am, Richard Henderson wrote:
>
> On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> > IMHO it's a bug in gcc that it does not inline the comparison inside the
> > switch expression, since it already does it in all other places. Perhaps
> > some problem with the
Hello,
On Tue, 19 Sep 2000, Chuck Lever wrote:
> also, the test at issue here (from line 363 of kernel/signal.c):
>
> /* If this was sent by a rt mechanism, try again. */
> if (info->si_code != SI_USER) {
> ret =
> - Linux developers often do horribly stupid things, and use 64-bit
>division etc instead of using a simple shift. Again, not linking
>against libgcc finds those things early rather than late, because the
>horribly stupid things end up requireing libgcc support.
I would have
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote:
> Tom Rini wrote:
>
> > >that. I see that 2.4 is getting all kinds of changes merged in
> > >that should be going on with 2.5. The recent VM changes have left
> > >us with deadlocks that we didn't have before. Shouldn't
Jeff Garzik writes:
> Ok, it's time to get test9 running on my laptop, so I played the "what
> code didn't get cut-n-pasted" game.
>
> With the attached tested patch against 2.4.0-test9-pre4, CardBus is
> working again for me. This patch makes the logic match that of the
> old code.
What
Ok, it's time to get test9 running on my laptop, so I played the "what
code didn't get cut-n-pasted" game.
With the attached tested patch against 2.4.0-test9-pre4, CardBus is
working again for me. This patch makes the logic match that of the old
code.
Jeff
-
To unsubscribe from this
Jeff Garzik wrote:
> With the attached tested patch against 2.4.0-test9-pre4, CardBus is
> working again for me. This patch makes the logic match that of the old
> code.
-ENOSLEEP. Here is the patch.
Index: drivers/pci/pci.c
===
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote:
> > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
> > small stuff (maybe my memory just sucks tho).
>
> I don't think there ever were any 2.2.0-testX patches - my recollection is
> that we went from
On Sep 19, 10:35am, Eric Youngdale wrote:
>
> OK, my guess is that we may need to do some tweaking to the Makefile.
> The basic idea is that you need to probe for hosts in a specific order.
> The reason for this is that some host adapters emulate other types of
> hardware. For example, some
Tom Rini wrote:
> >that. I see that 2.4 is getting all kinds of changes merged in
> >that should be going on with 2.5. The recent VM changes have left
> >us with deadlocks that we didn't have before. Shouldn't that have
> >gone into 2.5 not 2.4?
> Well, I think the bitterness
> to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
> small stuff (maybe my memory just sucks tho).
I don't think there ever were any 2.2.0-testX patches - my recollection is
that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we
seem to be having
Date:Tue, 19 Sep 2000 19:23:42 -0700
From: Richard Henderson <[EMAIL PROTECTED]>
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled in a subroutine from libgcc that
does 128/64 bit division, which is all we need here.
So
Date:Wed, 20 Sep 2000 04:38:24 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
We must be talking about different things. It of course detects it
on ACK input, but only for data it did send itself. Every TCP detects
reordering automatically on the input with the sequence
Problem:
The md driver doesn't handle large physical blocks in 2.2.x
Pardon the long introduction, but it might be interesting to the non IBM
types.
I'm doing some work with Linux/S390 and need to access about 100GB of
disk. The 3390 drives I can use are about 2.3GB each and that comes out
On Tue, Sep 19, 2000 at 04:11:30PM -0700, David S. Miller wrote:
> Unfortunately, gcc does not make inline functions as cheap as "macros
> with type checking". There are extra costs and often the register
> allocator cannot cope and stuff starts getting spilled to the stack.
It is supposedly on
[EMAIL PROTECTED] said:
> I tested vanilla test7 with ptrace() patch. It breaks uml exactly
> like I see with any kernel > test7.
> exec_user.c:29 ptrace(PTRACE_SYSCALL, 4901, 0, 0) = 0
> And voila, we got SIGSEGV instead of happy running child:
> Child 4901 exited with signal 11
Yuri, I
Hello,
I searched Documents and couldn't find what /proc/sys/fs/inode_max has been
changed to... because after 800 simultaneous open socket connections I get a
"Too many open files" EMFILE error
Thanks,
lee
__
FREE Personalized Email at Mail.com
Sign
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
>Date: Tue, 19 Sep 2000 18:07:20 -0600
>From: Cort Dougan <[EMAIL PROTECTED]>
>
>Do you really think that's forcing people to concentrate of fixing
>bugs? Tell me if you disagree, I'd like to understand how you see
Hello,
How do I increase the maximum number of socket connections I can have open
in the 2.4 series kernel?
Please let me know which list to post these types of questions to.
Thanks,
Lee
__
FREE Personalized Email at Mail.com
Sign up at
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:51:37 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>>Receiver side SMP reordering is still there, but I'm not sure if it is
>>fixable (but it'll surely hit people that cannot
On Tue, Sep 19, 2000 at 09:52:15AM -0700, Richard Henderson wrote:
> > Instead of *= 0.5, try /= 2.0
>
> Yes indeed you've found a bug in the kernel's FP emulation.
> I'll see about fixing it.
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled in
Date: Wed, 20 Sep 2000 03:51:37 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
>Receiver side SMP reordering is still there, but I'm not sure if it is
>fixable (but it'll surely hit people that cannot use Linux senders, I
>just see the reports)
>
> Reordering is
On Wed, 20 Sep 2000, Henner Eisen wrote:
[some suggestions for the next re-incarnation of the doc deleted]
>
> jamal> I have experimented with two schemes: one which samples the
> jamal> queue via a timer and one which does it per-packet and
> jamal> found that the per-packet
Hello,
I have a program that makes HTTP requests in a loop to a box runing Linux.
It goes through another Linux box, which is using proxy ARP and is connected
to the client and the web server using a cross over cable
[CLIENT][PROXY][WEBSERVER]
When the proxy machine uses 2.2 series
Dave,
I did a
rpm -rebuild egcs
rpm -rebuild glibc
ldconfig
ldconfig
and it went away.
I reinstalled a clean Open Linux 2.4 and just did
ldconfig
ldconfig
without rebuilding and it went also went away, so I don't think rebuilding
had much to do with it. I did spend any time looking further
Date:Tue, 19 Sep 2000 19:44:30 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
It does not seem to be saving any memory space doing it this way,
since I've noticed tons of these little segments all over the
place.
None of them can be eliminated because each one branches
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:14:10 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>The ipid handling is still fishy, it will break when you talk to
>more destinations than the inetpeer cache can take (I fixed it in
>
Hello,
You cannot use MMX registers in the kernel either, since the kernel doesen't
save and restore FX state (fxsave, fxrstor) either (just like
(fsave/frstor).
Best Wishes,
Lyle
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on
Tue,
19 Sep 2000 11:58:34 -0400 (EDT)
Keith,
I've seen a some problems with the way Linus (or whoever) did this. I
had a bug I worked on for 5 weeks related to the buggy 2.7 gcc linker on
Caldera Linux 2.4 that would for whatever reason fail to fixup all the
.test.lock code sections in a file (probably because there were so many
On Tue, 19 Sep 2000, Horst von Brand wrote:
> Random crashes is usually a hardware problem: Bad RAM, overheated CPU,
> overclocking, ...
Yeah it probably is a dud CPU, but I'm just trying to be optimistic. :)
I've tried two other CPUs and they work fine, so it's definitely the CPU
that's the
On Tue, 19 Sep 2000 19:53:19 +0200,
Jorge Nerin <[EMAIL PROTECTED]> wrote:
>All the traces end up in stext_lock, so I think it' the same bug
>>>EIP; c01df3aa<=
>Trace; c015db32
>Trace; c015dd03
>Trace; c0136149
>Trace; c01363fd
>Trace; c01079bb
>Code; c01df3aa
> <_EIP>:
Hello.
I am trying to mmap a frame buffer device (which I wrote) and it
doesn't seem to work. I verified the address - it appears OK.
However, whatever I write out to the address from my userland program,
the bits appear to go into the bit bucket.
I am trying to figure out remap_page_range;
Date: Wed, 20 Sep 2000 03:14:10 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
The ipid handling is still fishy, it will break when you talk to
more destinations than the inetpeer cache can take (I fixed it in
my local tree with the appended patch)
I don't like this change, please
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
> And hey, guess what, as a result of this right now my "non-driver
> caused" core/ipv4/ipv6 networking bug list is pretty much empty right
> now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid
On Tue, 19 Sep 2000, Matthias Andree wrote:
> Do you have the chance to borrow another of those K6-2s, possibly faster
> ones (if your board supports those)? Is the case in a proper state (has
> never been dropped, all perpendicular and so on)?
A K6-2 500 has become available for me to try,
Date:Tue, 19 Sep 2000 13:59:53 +0200
From: Florian Lohoff <[EMAIL PROTECTED]>
while porting a serial multiport driver to sparc64 i disovered that the
function get_tty_baud_rate() only returns 50 or 75 Baud
for 57600 and 115200 which is *aehm* not what i expected.
Is
"Juan J. Quintela" wrote:
>
> Hi
> while I am running mmap002 in test9-pre4 I got the computer
> frozen, it don't answer to my open windows anymore, it answers
> only to pings. I have got the attached traces. The machine
> is SMP with IDE disks.
I run from
Date: Tue, 19 Sep 2000 18:07:20 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
Do you really think that's forcing people to concentrate of fixing
bugs? Tell me if you disagree, I'd like to understand how you see
that. I see that 2.4 is getting all kinds of changes merged in
that
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
> Andrea Arcangeli wrote:
> >
> > On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > > Better would be to use statement blocks like
> > > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
> >
> > Agreed.
>
> Not
On Wed, Sep 20, 2000 at 01:55:58AM +0200, Martin Dalecki wrote:
> The GCC manual doesn't lie on that ANY LONGER with respect to EGCS.
> And we should adpat for the modern versions of the compiler instead
> of dragging the *ugly* code with us until the earth stops spinning, iff
> the only concern
}Date: Tue, 19 Sep 2000 16:49:00 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}If anyone else wants access to the 2.5 tree we have as a place to
}keep experimental changes I'm happy to open it up to the outside.
}
} Well, let's first step back for a second and really
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
> Not agreed. In this case older version of GCC will have
> almost exactly the same provlems as with functions.
I guess the object was to remove the mistake-prone side effects anyway...
Andrea
-
To unsubscribe from this list: send
Date: Wed, 20 Sep 2000 01:58:32 +0200
From: Martin Dalecki <[EMAIL PROTECTED]>
Andrea Arcangeli wrote:
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with functions.
Care to show an example? I do not believe this is
Andrea Arcangeli wrote:
>
> On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > Better would be to use statement blocks like
> > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > 7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2]
> p
> With point `p' I mean the request after last barrier in the queue.
Ah, I suspected we were talking past each other.
> Then when we try to insert 99
On Tue, 19 Sep 2000, Linus Torvalds wrote:
>
>
> On Tue, 19 Sep 2000, David S. Miller wrote:
> >
> > Would you mind taking a look at the difference in code output when
> > register pressure in a given function is moderate to high? :-)
>
> Immaterial.
>
> If somebody cares about
Andi Kleen wrote:
>
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual
On Tue, 19 Sep 2000, Andrew Morton wrote:
> > This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
> > domain of the sparc ports into include/linux. This publishes an
...
> This is good. It would be useful to have this in place ASAP so driver
> authors have something to look
Hi
while I am running mmap002 in test9-pre4 I got the computer
frozen, it don't answer to my open windows anymore, it answers
only to pings. I have got the attached traces. The machine
is SMP with IDE disks.
I had no additional/local patches applied.
Date:Tue, 19 Sep 2000 16:49:00 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
If anyone else wants access to the 2.5 tree we have as a place to
keep experimental changes I'm happy to open it up to the outside.
Well, let's first step back for a second and really think about
what
On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > +static inline __u16 ___swab16(__u16 x)
> > +{
> > + return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
> > +}
> > +static inline __u32 ___swab16(__u32 x)
>
On Wed, 20 Sep 2000, Andi Kleen wrote:
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> +static inline __u16 ___swab16(__u16 x)
> +{
> + return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
> +}
> +static inline __u32 ___swab16(__u32 x)
^
> +{
> + return ((x &
} Cort Dougan writes:
} > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
} > experimentation or experimentation in the stable trees.
}
} Well, you're not alone. There's a lot going on in the ARM side of Linux
} which looks very promising; yes it is true that ARM is
On Tue, 19 Sep 2000, David S. Miller wrote:
>
> Would you mind taking a look at the difference in code output when
> register pressure in a given function is moderate to high? :-)
Immaterial.
If somebody cares about performance, they'd just better create the proper
architecture-specific
Date:Tue, 19 Sep 2000 19:13:31 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
Nice spotting, but bad fix, IMO. swab...() stuff is a perfect
example of the dangerous use of macros. BTW, 2.4 has the same
problem.
Would you mind taking a look at the difference in code
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> the dangerous use of macros. BTW, 2.4 has the same problem.
inlines usually generate worse code than macros (the gcc manual lies on that),
e.g. the
23:43 2000
+++ include/linux/byteorder/swab.h.new Tue Sep 19 22:29:07 2000
@@ -13,31 +13,35 @@
* See asm-i386/byteorder.h and suches for examples of how to provide
* architecture-dependent optimized versions
*
+ * They shouldn't be macros, damnit. AV, 2919
+ *
*/
/* casts are necessary
On Wed, 20 Sep 2000, Andi Kleen wrote:
>
> This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre
> (look up the definition of le32_to_cpu on BE machines without a special
> assembler version for it and on machines that have it)
>
> Patch against 2.2.18pre9
Wrong fix.
Date:Wed, 20 Sep 2000 00:50:06 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
This patch fixes an obvious bug introduced with the ext2 changes in
2.2.18pre (look up the definition of le32_to_cpu on BE machines
without a special assembler version for it and on machines that
On Wed, 20 Sep 2000, Torben Mathiasen wrote:
>
> I can't seem to find a clean way of getting the drivers outside "drivers/scsi"
> to link _after_ the other low-level drivers. My linux Makefile abilities is
> limited though, so if someone with the knowledge would do what Eric requests
> above
This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre
(look up the definition of le32_to_cpu on BE machines without a special
assembler version for it and on machines that have it)
Patch against 2.2.18pre9
-Andi
--- linux-work/fs/ext2/inode.c-EXT2 Fri Sep 15
Cort Dougan writes:
> I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
> experimentation or experimentation in the stable trees.
Well, you're not alone. There's a lot going on in the ARM side of Linux
which looks very promising; yes it is true that ARM is not the
On Tue, Sep 19 2000, Eric Youngdale wrote:
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
>
Okay, I've just spent a couple of hours browsing through the scsi code,
compiling different configs, and trying to figure out
> "jamal" == jamal <[EMAIL PROTECTED]> writes:
jamal> Packets in flight?
>> In the extreme case, there could still arrive up to the window
>> size frames.
jamal> Assuming this depends on path latency and not some bad
jamal> programming
Yes. Although the latter could
> "jamal" == jamal <[EMAIL PROTECTED]> writes:
[...]
Nice introduction!
jamal> The driver uses the feedback information to intelligently
jamal> adjust its sending rate. (i.e reduce or increase calls to
jamal> netif_rx() or send a congestion-experienced frame to its
jamal>
On 2000-09-19 8:33:49 Michael Zieger wrote:
>I just found a big bug in kernel 2.4.0-test8 that leads to a major
>crash because PID 4 [kupdate] dies.
>I could reproduce the problem by doing this:
>- Open StarOffice under KDE
>- Create new textfile
>- Try to save it under a via NFS mounted
Daniel Grimwood <[EMAIL PROTECTED]> said:
> am having many random fatal oopses with my K6-2 350. Can't find
> anything related on the mailing list archive, so here it is. Also, I'm
> not subscribed to the mailing list but do read it via NNTP, a CC: would
> be much appreciated :). TIA.
Random
Hi,
I too tested to stress the new VM
Quintelas mmap002 "deadlocks" for me.
PPro, 96 MB, UP
active: 22337 (I think this varies, have too lock a 2nd time)
inactive_dirty: 324 varies
inactive_clean: 0
free: 288
... 1x 512 = 512 kB
... 2 x 16 + 1 x 32 + 1 x 64 = 640 kB
My feeling when looking at
On Tue, Sep 19, 2000 at 11:09:47PM +0200, Peter Osterlund wrote:
> So that leaves two choices:
>
> 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second
>patch.)
We can try with 1. first.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Jens Axboe <[EMAIL PROTECTED]> writes:
> > modification Peter suggested there can be more and we should track the one
> > more on the back of the queue. I don't think it's worthwhile.
>
> Agree, I don't think the added complexity would be worth it.
So that leaves two choices:
1. Perfect
On Tue, Sep 19, 2000 at 10:38:52PM +0200, Jens Axboe wrote:
> I haven't had a chance to really look at Peter's mods yet, but surely
> the current elevator can have many entries with 0 sequence. As an
> example, say the start sequence is 3 and we received request sector
> 10...1 in descending
Linus Torvalds wrote:
In article <[EMAIL PROTECTED]>, Dag Bakke <[EMAIL PROTECTED]> wrote:
>Tigran Aivazian wrote:
>>
>> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>>
>> > On 18 Sep 2000, Alex Romosan wrote:
>> >
>> > I get the same thing with a Xircon realport 10/100/modem card. Works
>> >
On Tue, 19 Sep 2000, Martin Mares wrote:
> Anyway, can you send me your /proc/ioports and /proc/iomem, please?
Yes, sure:
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000d-000d0fff : Extension ROM
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
} >
} >
} > >> Linus,
} > >
} > >> Where do architecture maintainers stand when they don't submit their
} > >> problems to linux-kernel or the great Ted Bug List(tm)?
} > >
} > >Up against the wall so we can shoot them?
} > >
Greetings everyone.
I have been running Linux kernel 2.4.0-test7 for some time now on my
dual celeron (BP6) system. I have an AGP video card, one ethernet card,
one IDE sound card, ps/2 keyboard and mouse, and two IDE hard drives.
(No floppy, no CD.)
I get errors of this sort on a regular basis
On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
>
>
> >> Linus,
> >
> >> Where do architecture maintainers stand when they don't submit their
> >> problems to linux-kernel or the great Ted Bug List(tm)?
> >
> >Up against the wall so we can shoot them?
> >
> >:)
>
> So I am
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > I don't see any reason why there can't be multiple p points in the current
> > elevator.
>
> Without the proposed modification after the last barrier in the queue all the
> requests should be in order.
I haven't had a chance to really look at
On Tue, Sep 19, 2000 at 04:16:07PM -0400, John Wehle wrote:
> Umm ... "miscompilation"? As in the compiler produced the wrong code
> based on the input provided?
That's not a gcc bug (gcc is doing the right thing). It's the kernel that
should use the "memory" clobber in the spinlock
Indeed, my copy of the SCSI 3 SPC-1
(ftp://ftp.t10.org/t10/drafts/spc/spc-r11a.pdf dated 21-Mar-1997) and SPC-2
(ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf dated 21-May-2000) show them
differently. SPC-3 isn't available for download.Anyone have the "final"
copy (if indeed it's not still
Hi Linus,
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> Do the above two fixes help? If not, I suspect that we're better off
> just reverting the new PCI bus allocation until it's fixed.
No, unfortunately they don't help at all, neither individually nor in
pair. So far, the only working case
Linus Torvalds writes:
>
>
>On Tue, 19 Sep 2000, Rogier Wolff wrote:
>>
>> If gcc starts shouting:
>>
>> somefile.c:1234: declared inline function 'serial_paranoia_check' is
>> somefile.c:1234: larger than 1k. Declining to honor the inline directive.
>
>That's not what gcc does.
>
>Gcc
On Tue, Sep 19, 2000 at 12:48:14PM -0700, Christoph Lameter wrote:
> On Tue, 19 Sep 2000, Marko Kreen wrote:
> > On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote:
> > > Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
> > > is empty.
> > It 'moved'. Do
> I see. So Jamie was right and we reproduced a case of miscompilation.
Umm ... "miscompilation"? As in the compiler produced the wrong code
based on the input provided?
int * p;
...
a = *p;
movl p,%eax
movl (%eax),%edx
The assembly code appears to load the address
Hi Tigran!
Sorry for the delay, I'm now finishing up for my final exams, so I get to
answering my mail once per day if I'm lucky.
> Yes, doing it like this works:
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7
( This has been resend, [EMAIL PROTECTED] already got a copy as well as the usb-uhci
maintainer as listed in MAINTAINERS )
DISCLAIMER: This oops may very well be categorized in the 'user
shoots himself' department but I still thought it interesting enough
to post a bugreport and see if
Hello Jeff,
I tested vanilla test7 with ptrace() patch.
It breaks uml exactly like I see with any kernel > test7.
Seems like the ORIG_EAX != -1 is needed to correctly restart syscall
after PTRACE_SYSCALL, but I did not check this codepath thoroughly.
Following what is going with uml, just
Hello,all
I use kernel 2.4.0-test8.
When i load the dmascc module my monitor turn off(power save mode).
It works well in 2.2.17.
Any idea?
Regards,
Metod
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tue, Sep 19, 2000 at 09:41:17PM +0200, Jens Axboe wrote:
> I don't see any reason why there can't be multiple p points in the current
> elevator.
Without the proposed modification after the last barrier in the queue all the
requests should be in order.
Andrea
-
To unsubscribe from this list:
>> Linus,
>
>> Where do architecture maintainers stand when they don't submit their
>> problems to linux-kernel or the great Ted Bug List(tm)?
>
>Up against the wall so we can shoot them?
>
>:)
So I am one of the guys who will be shot ... I wanted to do an update for
the s/390 architecture
On Tue, 19 Sep 2000, Marko Kreen wrote:
> On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote:
> > Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
> > is empty.
> It 'moved'. Do a 'cd /dev/scsi; ln ../host0' for temporary workaround.
>
> Well, I 'tried
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > But there may be several p points in the queue, how are you going
> > to keep track of all of them?
>
> With the current elevator there should be only 1 p point, but with the
I don't see any reason why there can't be multiple p points in the
On Tue, Sep 19, 2000 at 09:17:51PM +0200, Jens Axboe wrote:
> But there may be several p points in the queue, how are you going
> to keep track of all of them?
With the current elevator there should be only 1 p point, but with the
modification Peter suggested there can be more and we should
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [ Btw, has autorun ever worked with non-scsi devices?
Yes, with IDE disks at least.
--
Shields.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tue, 19 Sep 2000, Tigran Aivazian wrote:
> On Mon, 18 Sep 2000, Horst von Brand wrote:
>
> > Tigran Aivazian <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > did you try this patch?
> > >
> > > --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> > > +++ work/drivers/pci/pci.c
On Tue, 19 Sep 2000, Jeff V. Merkey wrote:
>
> This will break NWFS and require I put back in all the locks Al Viro
> told me to remove.
This will also break _every_ writable filesystem in tree and outside. Case
closed. Author of suggestion took it back about a week ago, IIRC.
BTW, Linus,
Linus Torvalds writes:
> [ Btw, has autorun ever worked with non-scsi devices? They've mostly had
> the new initialization order for a long time.. ]
Hmm, I hope it will do, since a 2.2.17 kernel with Ingos RAID patches
works, and it'd be a shame to break all those RAID root filesystems out
On Tue, Sep 19, 2000 at 08:30:05PM +0200, Peter Osterlund wrote:
> It is however possible to decide in O(1) time if the correct insertion
> point is at the end of the queue. We have to keep track of the point,
Right.
> [..] How long
> can the request queue be? Does it have a fixed upper size,
1 - 100 of 376 matches
Mail list logo
