On Tue, 7 Nov 2000, Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Keith Owens wrote:
>
> > On Mon, 6 Nov 2000 16:31:23 -0500 (EST),
> > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> > >However when running, the new kernel 2.4.0-test9, can't be used to
> > >make a usable initrd ram disk. T
On Tue, 7 Nov 2000, Keith Owens wrote:
> On Mon, 6 Nov 2000 16:31:23 -0500 (EST),
> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> >However when running, the new kernel 2.4.0-test9, can't be used to
> >make a usable initrd ram disk. The result being that 2.4.0-test9
> >can't, itself, build an
On Mon, 6 Nov 2000 16:31:23 -0500 (EST),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>However when running, the new kernel 2.4.0-test9, can't be used to
>make a usable initrd ram disk. The result being that 2.4.0-test9
>can't, itself, build an "initrd" bootable system.
>
>Before everybody scr
On Mon, 6 Nov 2000, Richard Rak wrote:
> I don't have any problems building initrd images here (using
> RAMDISKs). Can I take a look at your scripts and see what is going on?
>
Here is the script to boot off a hard disk.
#!/bin/bash
#
# This installs the kernel on a system that
I don't have any problems building initrd images here (using
RAMDISKs). Can I take a look at your scripts and see what is going on?
"Richard B. Johnson" wrote:
>
> Linux 2.4.0-test9 can be built and booted via initrd when running
> a 2.2.17 kernel.
>
>
Linux 2.4.0-test9 can be built and booted via initrd when running
a 2.2.17 kernel.
However when running, the new kernel 2.4.0-test9, can't be used to
make a usable initrd ram disk. The result being that 2.4.0-test9
can't, itself, build an "initrd" bootable system.
Before ev
On Sat, 4 Nov 2000, Keith Owens wrote:
> On Fri, 3 Nov 2000 17:54:51 -0500 (EST),
> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> >(1) I have SCSI modules that have to be installed upon boot
> >from initrd. Insmod failed with "Can't find the kernel version that
> >this module was compiled w
On Fri, 3 Nov 2000 17:54:51 -0500 (EST),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>(1)I have SCSI modules that have to be installed upon boot
>from initrd. Insmod failed with "Can't find the kernel version that
>this module was compiled with..."
"Can't find the kernel version that thi
Ingo Oeser wrote:
>
> On Fri, Nov 03, 2000 at 10:12:31PM -0500, Jeff Garzik wrote:
> > But if you are going to eliminate info->vxi_base, it seems like that
> > would flush out all direct de-refs, whether they are buried in an
> > obscure macro or not. And if you find all that crap, you might as
On Fri, Nov 03, 2000 at 10:12:31PM -0500, Jeff Garzik wrote:
> But if you are going to eliminate info->vxi_base, it seems like that
> would flush out all direct de-refs, whether they are buried in an
> obscure macro or not. And if you find all that crap, you might as well
> use readb/writel at th
"Richard B. Johnson" wrote:
> On Fri, 3 Nov 2000, Jeff Garzik wrote:
> > "Richard B. Johnson" wrote:
> > > (3) With the new kernel, I can't access screen memory anymore. When
> > > testing software drivers for hardware that I don't have, I usually use
> > > the screen-regen buffer to emulate
On Fri, 3 Nov 2000, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> > I have, again, tried to use a new kernel. It is linux-2.4.0-test9
> > Apparently a newer version was just put up while downloading this
> > one. This is possible because it took a day to d
"Richard B. Johnson" wrote:
> I have, again, tried to use a new kernel. It is linux-2.4.0-test9
> Apparently a newer version was just put up while downloading this
> one. This is possible because it took a day to download it );
If you could download patch-2.4.0-test10, and t
I have, again, tried to use a new kernel. It is linux-2.4.0-test9
Apparently a newer version was just put up while downloading this
one. This is possible because it took a day to download it );
The following problems exist:
(1) I have SCSI modules that have to be installed upon boot
from
> I'll assume for the moment that I'm liable to suffer some form of brain
> h=E6morrhage and go along with this dastardly plan - so enlighten me. H=
> ow
> would I conspire with M-Systems to do so?
Not a lot. Even if you joined M-Systems you could make no difference. In fact
as it stands now M-Sy
On Sat, 28 Oct 2000, Gregory Maxwell wrote:
> See section 7 of the GPL.
"If you cannot distribute so as to satisfy simultaneously your obligations
under this License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all."
But I can, so I may. See t
On Sat, 28 Oct 2000, Mark Spencer wrote:
> Now firstly, let's eliminate the ISDN red-herring from consideration
> because the authors of the code do not place any additional restrictions
> on the GPL whatsoever, they simply bring it to your attention that using
> an un-certified ISDN stack may be
Alan Cox wrote:
>
> > In this case, Debian (or any organization who isn't big enough not to fear
> > M-systems) may not ship the standard kernel because it has additional patent
> > restrictions.
>
> Why. There are no distribution restrictions
>
> > There is a clear ability here for the autho
> In this case, Debian (or any organization who isn't big enough not to fear
> M-systems) may not ship the standard kernel because it has additional patent
> restrictions.
Why. There are no distribution restrictions
> There is a clear ability here for the author of the driver and m-systems to
>
On Sat, Oct 28, 2000 at 05:24:19PM +0100, Alan Cox wrote:
> The authors of the NTFL layer dont place any additional restrictions on your
> use of the code either. They are merely warning you that if you use it in
> some ways you are going to get your ass kicked by a third party. WHats the
> differ
> Now firstly, let's eliminate the ISDN red-herring from consideration
> because the authors of the code do not place any additional restrictions
> on the GPL whatsoever, they simply bring it to your attention that using
> an un-certified ISDN stack may be illegal in some countries.
The authors o
I've been looking at the MTD (memory technology device) additions to the
linux 2.4.0 kernels. In particular I'm very interested in the DiskOnChip
2000 and NFTL drivers. However, as terribly useful as this driver is, was
I the only one who caught the following notice at the top of the driver
sour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I've propably found some bug in MOXA Smartio driver for linux (kernel
version 2.4.0-test9). Module recognizes my C168H/PCI as C104H/PCI and
allows to use only first 4 ports.
Following patch solves the problem:
- --- mxser.c.old Wed Oct 25
[EMAIL PROTECTED] (Peter De Schrijver) wrote..
> Does anyone have experience trying to run a 2.4.0-test9 kernel on
> an AMD ELAN SC520 based board ? (More specifically the Microspace
> MSN586SE). It resets a few milliseconds after starting the kernel.
Maybe the A20 stuff that was added in test9.
Hi,
Does anyone have experience trying to run a 2.4.0-test9 kernel on an AMD ELAN
SC520 based board ? (More specifically the Microspace MSN586SE). It resets
a few milliseconds after starting the kernel. It seems to always reset after
the same amount of time, independant from the code being execut
Hi all ,
At first, thank you Jeff Garzik for your advise. I added
debug infomations to apm.c and have tried it. See below:
(APM driver enabled and output tons of debug messages)...
apm_do_idle(): line 564
apm_bios_call_simple(): line 484
..
(and yenta driver was loaded and it proved pcmcia
> James has just posted a big patch against this code, so you should
> coordinate this with him.
>
> One point: you should have included linux/spinlock.h rather than
> asm/spinlock.h. Obviously someone is already including this file, so
> you can simply remove the #include altogether.
I alread
Yong Chi wrote:
>
> My first contribution to kernel =) Someone please look over this one
> carefully =)
That's a good patch.
It is "obviously correct", it saves seven calls to __global_cli() for
each \n-terminated write to the console and it fixes the
death-with-dual-deadlock problem which Mis
My first contribution to kernel =) Someone please look over this one
carefully =)
Thanks
--- vgacon.c.bakTue Oct 10 13:50:09 2000
+++ vgacon.cTue Oct 10 14:48:06 2000
@@ -27,6 +27,9 @@
* flashing on RHS of screen during heavy console scrolling .
* Oct 1996, Paul Gortma
Date: Fri, 6 Oct 2000 00:19:20 -0700
From: Richard Henderson <[EMAIL PROTECTED]>
Seems to me that if you want to play games and be sure that they
stay played, that you'd have to put all the variables into a
struct.
Indeed, I've hacked this up and will send the fix to linus.
Later
On Sat, Oct 07, 2000 at 12:42:16PM -0400, Brian Gerst wrote:
> "Forever shall I be." wrote:
> >
> > I got this OOPS while unloading the ns558 module.. I don't think it did
> > this in 2.4.0-test8, but I don't recall ever unloading it in test8..
> >
> > I've attached the ksymoops output..
> >
>
Hi,
I dunno for the first poster but unloading ns558 causes
problems for me too (SB 128 PCI gameport). Some dmesg exerpts :
Linux version 2.4.0-test9-rous6
([EMAIL PROTECTED]) (gcc version 2.96 2731
(Red Hat Linux 7.0)) #12 sam oct 7 02:01:57 CEST 2000
[...]
es1371: version v0.26 time 01:
On Sat, Oct 07, 2000 at 12:42:16PM -0400, Brian Gerst wrote:
> "Forever shall I be." wrote:
> >
> > I got this OOPS while unloading the ns558 module.. I don't think it did
> > this in 2.4.0-test8, but I don't recall ever unloading it in test8..
> >
> > I've attached the ksymoops output..
> What
"Forever shall I be." wrote:
>
> I got this OOPS while unloading the ns558 module.. I don't think it did
> this in 2.4.0-test8, but I don't recall ever unloading it in test8..
>
> I've attached the ksymoops output..
>
> --
> Zinx Verituse(See headers for gpg/pgp key info
I got this OOPS while unloading the ns558 module.. I don't think it did
this in 2.4.0-test8, but I don't recall ever unloading it in test8..
I've attached the ksymoops output..
--
Zinx Verituse(See headers for gpg/pgp key info)
ksymoops 2.3.4 on i686 2.4.0-test9. Optio
Keith Owens wrote:
> >Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
> >and it should do what you want.
> >
> >Heck, section ".bss" might give you the alignment without the allocation
> >but I'm not as confident about that.
>
> Call me mad but you could actually try this i
On Thu, Oct 05, 2000 at 09:59:08PM -0700, David S. Miller wrote:
>Compile with -fno-common and you'll get .bss, but not COMMON,
>variables. It's the COMMON bits that are screwing your games.
Oh, I was just thinking too -- have you given any thought
to what happens on .sdata hosts even wi
Date: Thu, 5 Oct 2000 22:05:08 -0700
From: Richard Henderson <[EMAIL PROTECTED]>
Compile with -fno-common and you'll get .bss, but not COMMON,
variables. It's the COMMON bits that are screwing your games.
This might be useful to catch people using extern properly
as well.
Later,
Da
On Wed, Oct 04, 2000 at 05:25:44PM -0700, David S. Miller wrote:
> These items are specifically placed into the data section, not the
> BSS, because these alignment games are not possible in the BSS.
Compile with -fno-common and you'll get .bss, but not COMMON,
variables. It's the COMMON bits th
On Fri, 6 Oct 2000 01:19:16 +0200,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>David S. Miller wrote:
>>> These items are specifically placed into the data section, not the
>>> BSS, because these alignment games are not possible in the BSS.
>>
>>That would mean the BSS needs support ali
Date:Fri, 6 Oct 2000 01:19:16 +0200
From: Jamie Lokier <[EMAIL PROTECTED]>
Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
and it should do what you want.
Heck, section ".bss" might give you the alignment without the allocation
but I'm not as conf
David S. Miller wrote:
>> These items are specifically placed into the data section, not the
>> BSS, because these alignment games are not possible in the BSS.
>
>That would mean the BSS needs support alignment games.
>
> The problem is it doesn't work, please go try it.
> So until i
From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
Date: Thu, 5 Oct 2000 00:23:33 -0400 (EDT)
David S. Miller writes:
> These items are specifically placed into the data section, not the
> BSS, because these alignment games are not possible in the BSS.
That would mean the BSS needs
David S. Miller writes:
> These items are specifically placed into the data section, not the
> BSS, because these alignment games are not possible in the BSS.
That would mean the BSS needs support alignment games.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Date:Tue, 3 Oct 2000 09:43:35 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
- pre8:
- initialize to zero -> put it in the .bss instead
Can the person who made these changes in tcp_ipv4.c talk
to me?
That particular instance screwed up all the cache line games I
Hi all,
I've tried Linux-2.4.0-test[7-9] kernel on my laptop, and got
a trouble with them. When yenta_socket and apm driver are installed,
system hangs. Each driver works fine without another one. Why?
Thanks,
A.Yoshiyama <[EMAIL PROTECTED]>
p.s.
My Laptop: NEC LaVie NX (Japan local
- final:
- USB: ohci controller update, round-robin device numbering
- ksymoops moved: document
- sparc updates
- sg.c: get rid of more #ifdef MODULE code
- pre9:
- USB: documentation.
- Yeah. MD/LVM should really be fixed this time.
- SH architecture update
- i8
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map-2.4.0-test9 (specified)
Unable to handle kernel paging request at virtual address 0010
c012eca
> On mtrr.c, it assume that CPU is CyrixIII when cpuid is 0x06XX, and
> try to use intel compatible MTRR, so Cyrix MII with MTRR can't work.
Oops it shouldnt fall through any more. My fault
> Here is the ad hoc patch.
And here is a non AdHoc one (the Cyrix III reports itself as CENTAUR which
ma
Hi. I found a bug on test9-pre7 mtrr.c about Cyrix MII.
When I use linux-2.4.0-test9-pre4 with MTRR enable, it works fine.
But when I try to boot linux-2.4.0-test9-pre7,
GPF occur after "mtrr: v1.36" message, and kernel freeze.
My Cyrix MII's cpuid is 0x0628, and CyrixIII'
Byron Stanoszek wrote:
>
> After about 3 days running 2.4.0-test9-pre2 (32mb i586 machine), I switched on
> the system console and saw these messages. Nothing seems to be wrong with the
> system. Can anyone enlighten me?
>
> Flags; bus-master 1, full 0; dirty 1267452(12) current 1267456(0).
B
On Tue, 19 Sep 2000, Tom Rini wrote:
> On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote:
> > The VM work has been scheduled to go in for a while. If you check the TODO
> > emails from months back, it's always been there.
>
> I wasn't arguing that (really) it's just that it really shou
After about 3 days running 2.4.0-test9-pre2 (32mb i586 machine), I switched on
the system console and saw these messages. Nothing seems to be wrong with the
system. Can anyone enlighten me?
Flags; bus-master 1, full 0; dirty 1267452(12) current 1267456(0).
Transmit list 010c72f0 vs. c10c72c0.
> "Barry K. Nathan" <[EMAIL PROTECTED]> said:
>
> > In other words, if I understand things correctly, once we have Linux
> > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of
> > testing before release, 2.4.0-pre1 will be next...
>
> That so? Must get Linus an Alpha or SPAR
"Barry K. Nathan" <[EMAIL PROTECTED]> said:
[...]
> In other words, if I understand things correctly, once we have Linux
> 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of
> testing before release, 2.4.0-pre1 will be next...
That so? Must get Linus an Alpha or SPARC64 ASA
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> I'm tired of you screwing up the VM and then complaining the elevator. At least
> try to vary and choose something else to complain. At test1 time you may been
> right, but now we're so permissive in the default settings exactly to be sure
> the elev
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> > One of the issues which seems to be affecting performance
> > is the elevator starvation bug, though, so I'm not sure how
>
> You are contraddicting yourself. If you decrease the laten
On Wed, Sep 20, 2000 at 03:24:28PM +0200, Andi Kleen wrote:
> That would just break the whole idea behind softnet. When you're juggling
I agree ;(.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ a
On Wed, Sep 20, 2000 at 03:29:39PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> > 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 automatic
On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> 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 number check,
> but all we still do is
On Tue, Sep 19, 2000 at 08:56:57PM -0700, David S. Miller wrote:
>Just use __cacheline_aligned instead, like I did with the
>ip_local_data in the patch you just rejected. There is still the
>problem that generic SMP x86 kernels use a 32byte cacheline. Not a
>problem currently becau
David S. Miller writes:
> Why not just
> tell these people "why are you working on experimental stuff, put
> together PPC stress test and kernel regression suites if you are
> bored, because we know 2.4.x isn't read for prime time"
Mainly because:
1. the people providing the new "features" hav
Tom Rini wrote:
> I wasn't arguing that (really) it's just that it really should have gone in
> sooner. It's all really a moot point I understand, but still. major
I understand your gripe but it couldn't be helped as it was. If more people stepped
forward who really understood the mechanics a
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 th
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 2
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 c
> 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 n
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 numb
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
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 use
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 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
>
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
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
}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
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
} 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 n
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 faste
} 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?
} > >
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 o
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 silentl
>> 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 sin
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote:
>
>
> 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 direct
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> One of the issues which seems to be affecting performance
> is the elevator starvation bug, though, so I'm not sure how
You are contraddicting yourself. If you decrease the latency (so if you fix the
starvation) the global disk throu
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 silently just doesn't inline it.
And the
On Sun, 17 Sep 2000, Mark Orr wrote:
> Has anyone else tried 240-test9-pre2 on low-memory systems?
>
> I compiled 240t9p2, bzlilo'ed it, and rebooted. During
> boot it tripped up on e2fsck -- it was at maximum mount count
> and it stopped during the check.
> Sys: pentium 100, 16Mb RAM + 17 Mb
Linus Torvalds wrote:
>
>
> On Mon, 18 Sep 2000, David Woodhouse wrote:
> >
> > [EMAIL PROTECTED] said:
> > > Note that with most versions of gcc this is all a complete non-issue,
> > > as most versions of gcc will _always_ inline a function that the user
> > > has asked to be inlined. So the
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote:
>
> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associ
Hi!
> Ok. I think we're getting to the point where there are no major known
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept
> any patches that don't have a critical problem (as defined by Teds list)
> associated with them.
> So when you send me a patch, either bug T
"Dunlap, Randy" <[EMAIL PROTECTED]> said:
[]
> > Good thing I promised Ted to bring another bottle of
> > that Brazillian liquor to the next event we meet ;)
> Rik, does it have to be Brazilian liquor?
> I still have patches for 2.4.0-final also.
You'd have to ask Ted...
BTW folks, please
On Mon, Sep 18, 2000 at 05:11:35PM +0100, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > 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?
I know t
[EMAIL PROTECTED] said:
> 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?
:)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Mon, 18 Sep 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Note that with most versions of gcc this is all a complete non-issue,
> > as most versions of gcc will _always_ inline a function that the user
> > has asked to be inlined. So the issue seldom actually comes up.
>
> I
On Sun, 17 Sep 2000, Mark Orr wrote:
> Has anyone else tried 240-test9-pre2 on low-memory systems?
Hmmm... I am getting periodic hangs on reading floppies AFTER initrd
inititialization Maybe once every 20 boots.. same thing.. strange hang,
and a control gets by whatever process was hanging
[EMAIL PROTECTED] said:
> Note that with most versions of gcc this is all a complete non-issue,
> as most versions of gcc will _always_ inline a function that the user
> has asked to be inlined. So the issue seldom actually comes up.
I thought that 'extern inline' was in fact the intended usage
Ted,
How does one identify the "critical" items in the
2.4 Status/TODO list?
Will you be adding a "critical" section or adding
"(critical)" on some items on the 2.4 Status/TODO list?
I'm updating the USB list now and wondering how to
mark items as critical.
Thanks,
~Randy
Linus Torvalds writes:
> So when you send me a patch, either bug Ted to mark the issue as
> "critical" first, or pay me money. It's that easy.
Linus,
Where do architecture maintainers stand when they don't submit their
problems to linux-kernel or the great Ted Bug List(tm)?
_
|_| -
When trying to compile I get:
drivers/scsi/scsidrv.o: In function `init_sd':
drivers/scsi/scsidrv.o(.text+0x68ae): undefined reference to
`scsi_register_module'
drivers/scsi/scsidrv.o: In function `exit_sd':
drivers/scsi/scsidrv.o(.text+0x68c3): undefined reference to
`scsi_unregister_module'
dri
H. Peter Anvin wrote:
> Ideally, the linker should have some kind of merging pass to merge
> these multiple instances -- this really could help C++ template
> instantiation problems as well -- but for now, the only "safe" way is
> pretty much to provide a library with non-inlined versions and hope
1 - 100 of 112 matches
Mail list logo
