Alan Cox <[EMAIL PROTECTED]> said:
> In-Reply-To: <[EMAIL PROTECTED]> from "Keith Owens" at Dec 14, 2000 0
> ***9:05:13 AM
> > previously because nobody used those options. Since these are bugs in
> > the modules and only a few modules are affected (less than 5 reported),
> > the fix is to
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> >Thanks for posting this. Unfortunately, the kernel won't build unless you
> >restore this macro to the namespace after aic7xxx_linux.h blows it away:
> >
> >--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
> >+++
Were you connected to a network or receiving/sending anything?
dep wrote:
>
> okay. got it here this morning, too. solid lock -- no dumping out of
> x, no changing terminals, no mouse, no keyboard.
>
> k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. kernel
> built with gcc-2.95-2
okay. got it here this morning, too. solid lock -- no dumping out of
x, no changing terminals, no mouse, no keyboard.
k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. kernel
built with gcc-2.95-2 against glibc-2.2. nothing remarkable underway
-- was composing a message in kmail,
Chris Lattner <[EMAIL PROTECTED]> writes:
> > p9fs exists. I didn't see these patches since August, but probably I can poke
> > Roman into porting it to the current tree. 9P is quite simple and unlike
> > CORBA it had been designed for taking kernel stuff to userland. Besides,
> > authors
Hmmm, does syslog sending to another machine catch oops? I guess we'll
find out.
Ingo Oeser wrote:
> I have no oops yet of this lockup, because of X, but I'll ask a
> friend of mine, whether the remote logging made it to him and
> send you the results.
--
On Wed, Dec 13, 2000 at 10:48:56PM -0500, Mohammad A. Haque wrote:
> Trace; c0105000
> Trace; c0100191
I locked a Cyrix III machine up on boot and hat these both
elements in my trace, too.
It Oopsed and locked up after the Message: "CPU: Before vendor
init".
I locked up too with another
On Thursday December 14, [EMAIL PROTECTED] wrote:
> Dear kernel maintainers,
> I will report my problem around 2.4.0-test kernel.
>
> Thanks in advance.
The simplest fix for this is the patch below. Exactly what will get
into test13 has not yet been decided.
NeilBrown
--- drivers/md/raid5.c
OK, I've just tried repeating this experiment on 2.2.18 (no devfs) and
it oopsed this time, so there's obviously something else going on
here.
$ ksymoops -m /boot/System.map-2.2.18 < oops2.txt
ksymoops 2.3.4 on i586 2.2.18. Options used
-V (default)
-k /proc/ksyms (default)
-l
> Looks like a devfs problem; complain to the appropriate people. I refuse
> to touch that particular devfs code.
I've had a quick look at both the 2.2.18 and 2.4.0-test12 drivers for
msr and cpuid, and I've noticed something curious.
This is the comment from 2.4.0-test12, cpuid.c:
/*
*
Hello,
Is this normal:
Dec 14 12:33:32 alien kernel: __alloc_pages: 2-order allocation failed.
System deadlocked about one minute later.
I have hard resource limits set.
- Jussi Laako
--
PGP key fingerprint: 3827 6A53 B7F9 180E D971 362B BB53 C8A1 B578 D249
Available at:
> I use 2.2.18 with ne2k-pci from kernel and that of scyld, and work fine under
> 2.91 (egcs)
>
> BTW, when a resync of 2.2 net drivers with scyld ? perhaps 2.2.19 ?
I have no plan to do this. Don's drivers depend on some extra glue that was
rejected from the main kernel tree. Said glue is
On Thu, 14 Dec 2000 11:23:14 Alan Cox wrote:
> > I just want to let other know that kernel 2.2.18 does not work properly (*)
> > on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
> > release). Instead gcc-2.7.2.3 works ok.
> >
> > (*) the network driver PCI NE2000 does not
> I just want to let other know that kernel 2.2.18 does not work properly (*)
> on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
> release). Instead gcc-2.7.2.3 works ok.
>
> (*) the network driver PCI NE2000 does not work with all three cards. It
> just sees them but they
Devfs might explain the 2.4.0-test12 oopses, but it can't possibly
explain the oops with 2.2.18. I don't use devfs with 2.2.18.
Chris
> Looks like a devfs problem; complain to the appropriate people. I refuse
> to touch that particular devfs code.
>
> > I have just compiled Linux 2.2.18
> I'll update my patch tomorrow to restore the definition of current.
> I do fear, however, that this will perpetuate the polution of the
> namespace should "current" ever get cleaned up.
It can probably get cleaned up after 2.4 by making current() the actual
inline. For 2.2 it won't change.
Dear kernel maintainers,
I will report my problem around 2.4.0-test kernel.
Thanks in advance.
---
[1.] failed in BUG() at fs/buffer.c:765
[2.]
My linux 2.4.0-test12 box failed on writing some files on soft-raid
partition. It seems to touch BUG() macro at fs/buffer.c:765, when file
buffer
[Alan DID not say this:]
> > There is a large perception of CORBA being slow, but for the most part it
> > is unjustified.
Really? I have that same perception but I can't claim that I've measured it.
On the other hand, I have measured the overhead of straight UDP, TCP, and
Sun RPC ping/pong
> There is a large perception of CORBA being slow, but for the most part it
> is unjustified. I believe that the act of _designing_ a completely new
> protocol, standardizing it, and making it actually work would be a huge
> process that would basically reinvent CORBA (obviously some of the
> bug was discovered. Ever since, I have two boxes here
> that keep falling over. Box A will randomly lock without
> warning and box B will die and start printing this message
> repeatedly on the screen until I physically hit reset:
What are these two boxes doing ?
> Is there a patch out
Hi,
I believe I've found an inconsistency between the behaviour of poll(2)
and select(2); select() is restartable in the face of signals
(sys_select() returns ERESTARTNOHAND if a signal is pending), whilst
poll() is not (sys_poll() returns EINTR). On Feb 13 2000, Andi Kleen
posted a patch for
On Thu, Dec 14, 2000 at 10:23:15AM +0100, josef höök wrote:
> Plan9 aint unix/posix though it has its Ape environment.
> What we do need to look at is a good implementation for distributed resources.
> The ideal would bee getting 9P and IL into linux. Think of having thousand of small
>
> linux
Alexander Viro spake thus:
> Maybe... I definitely agree that 14 is below the limit, but 30... Hell knows,
> from what I see on the box I'm using right now it seems to fall into several
> cathegories:
> * Very-Long-And-Verbose-Named-HOWTO.html
> * manpages for X and Tcl functions
Chris Lattner wrote:
> > > Err shame on you, don't forget about lcall and exceptions, and interrupts,
> > > and... That is technically more than _o_n_e_ "entry point". :) Oh wait,
> > > what about sysenter/exit too? :)
> > OK, you got me on lcall (however, that's iBCS-only, IIRC), but the
On Wed, Dec 13, 2000 at 12:41:19AM +0100, J . A . Magallon wrote:
> There are various patches-ways-to-do available, kernel gurus are still working
> on it...
> (leave always some 4% of mem for root, kill some process when mem is exhausted,
> which one to kill...)
which is a bad idea; 4% of 1GB
On Thu, Dec 14, 2000 at 12:53:46AM -0800, [EMAIL PROTECTED] wrote:
> Sorry is this is too far off topic, but it seems to me the
> kernel may be helping in this break in or maybe some magic
> aspect of the filesystem.
I doubt that from this description, you've been hacked. Even if your
Sorry is this is too far off topic, but it seems to me the
kernel may be helping in this break in or maybe some magic
aspect of the filesystem.
I noted in an ls that
-rwxr-xr-x 1 root root36784 Jul 17 05:06 rpc.mountd*
-rwxr-xr-x 1 root root 3368 Jul 17 05:06
Hello,
I just want to let other know that kernel 2.2.18 does not work properly (*)
on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
release). Instead gcc-2.7.2.3 works ok.
(*) the network driver PCI NE2000 does not work with all three cards. It
just sees them but they do
I've also been experiencing lockups and oopses since upgrading to
test12 from test11.
These were very lengthy oops messages during the init script, following
immediate lockups (or shortly after running X), which printed "Aiee,
killing interrupt handler" at the end.
test11 doesn't show these
I've also been experiencing lockups and oopses since upgrading to
test12 from test11.
These were very lengthy oops messages during the init script, following
immediate lockups (or shortly after running X), which printed "Aiee,
killing interrupt handler" at the end.
test11 doesn't show these
Sorry is this is too far off topic, but it seems to me the
kernel may be helping in this break in or maybe some magic
aspect of the filesystem.
I noted in an ls that
-rwxr-xr-x 1 root root36784 Jul 17 05:06 rpc.mountd*
-rwxr-xr-x 1 root root 3368 Jul 17 05:06
On Thu, Dec 14, 2000 at 12:53:46AM -0800, [EMAIL PROTECTED] wrote:
Sorry is this is too far off topic, but it seems to me the
kernel may be helping in this break in or maybe some magic
aspect of the filesystem.
I doubt that from this description, you've been hacked. Even if your
On Wed, Dec 13, 2000 at 12:41:19AM +0100, J . A . Magallon wrote:
There are various patches-ways-to-do available, kernel gurus are still working
on it...
(leave always some 4% of mem for root, kill some process when mem is exhausted,
which one to kill...)
which is a bad idea; 4% of 1GB is a
Chris Lattner wrote:
Err shame on you, don't forget about lcall and exceptions, and interrupts,
and... That is technically more than _o_n_e_ "entry point". :) Oh wait,
what about sysenter/exit too? :)
OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest...
what
Alexander Viro spake thus:
Maybe... I definitely agree that 14 is below the limit, but 30... Hell knows,
from what I see on the box I'm using right now it seems to fall into several
cathegories:
* Very-Long-And-Verbose-Named-HOWTO.html
* manpages for X and Tcl functions with
On Thu, Dec 14, 2000 at 10:23:15AM +0100, josef höök wrote:
Plan9 aint unix/posix though it has its Ape environment.
What we do need to look at is a good implementation for distributed resources.
The ideal would bee getting 9P and IL into linux. Think of having thousand of small
linux boxes
Hi,
I believe I've found an inconsistency between the behaviour of poll(2)
and select(2); select() is restartable in the face of signals
(sys_select() returns ERESTARTNOHAND if a signal is pending), whilst
poll() is not (sys_poll() returns EINTR). On Feb 13 2000, Andi Kleen
posted a patch for
bug was discovered. Ever since, I have two boxes here
that keep falling over. Box A will randomly lock without
warning and box B will die and start printing this message
repeatedly on the screen until I physically hit reset:
What are these two boxes doing ?
Is there a patch out there
There is a large perception of CORBA being slow, but for the most part it
is unjustified. I believe that the act of _designing_ a completely new
protocol, standardizing it, and making it actually work would be a huge
process that would basically reinvent CORBA (obviously some of the design
[Alan DID not say this:]
There is a large perception of CORBA being slow, but for the most part it
is unjustified.
Really? I have that same perception but I can't claim that I've measured it.
On the other hand, I have measured the overhead of straight UDP, TCP, and
Sun RPC ping/pong tests
I'll update my patch tomorrow to restore the definition of current.
I do fear, however, that this will perpetuate the polution of the
namespace should "current" ever get cleaned up.
It can probably get cleaned up after 2.4 by making current() the actual
inline. For 2.2 it won't change.
Dear kernel maintainers,
I will report my problem around 2.4.0-test kernel.
Thanks in advance.
---
[1.] failed in BUG() at fs/buffer.c:765
[2.]
My linux 2.4.0-test12 box failed on writing some files on soft-raid
partition. It seems to touch BUG() macro at fs/buffer.c:765, when file
buffer
Devfs might explain the 2.4.0-test12 oopses, but it can't possibly
explain the oops with 2.2.18. I don't use devfs with 2.2.18.
Chris
Looks like a devfs problem; complain to the appropriate people. I refuse
to touch that particular devfs code.
I have just compiled Linux 2.2.18 (UP) and
I just want to let other know that kernel 2.2.18 does not work properly (*)
on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
release). Instead gcc-2.7.2.3 works ok.
(*) the network driver PCI NE2000 does not work with all three cards. It
just sees them but they do not
On Thu, 14 Dec 2000 11:23:14 Alan Cox wrote:
I just want to let other know that kernel 2.2.18 does not work properly (*)
on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
release). Instead gcc-2.7.2.3 works ok.
(*) the network driver PCI NE2000 does not work with
I use 2.2.18 with ne2k-pci from kernel and that of scyld, and work fine under
2.91 (egcs)
BTW, when a resync of 2.2 net drivers with scyld ? perhaps 2.2.19 ?
I have no plan to do this. Don's drivers depend on some extra glue that was
rejected from the main kernel tree. Said glue is also
Hello,
Is this normal:
Dec 14 12:33:32 alien kernel: __alloc_pages: 2-order allocation failed.
System deadlocked about one minute later.
I have hard resource limits set.
- Jussi Laako
--
PGP key fingerprint: 3827 6A53 B7F9 180E D971 362B BB53 C8A1 B578 D249
Available at:
Looks like a devfs problem; complain to the appropriate people. I refuse
to touch that particular devfs code.
I've had a quick look at both the 2.2.18 and 2.4.0-test12 drivers for
msr and cpuid, and I've noticed something curious.
This is the comment from 2.4.0-test12, cpuid.c:
/*
*
OK, I've just tried repeating this experiment on 2.2.18 (no devfs) and
it oopsed this time, so there's obviously something else going on
here.
$ ksymoops -m /boot/System.map-2.2.18 oops2.txt
ksymoops 2.3.4 on i586 2.2.18. Options used
-V (default)
-k /proc/ksyms (default)
-l
On Thursday December 14, [EMAIL PROTECTED] wrote:
Dear kernel maintainers,
I will report my problem around 2.4.0-test kernel.
Thanks in advance.
The simplest fix for this is the patch below. Exactly what will get
into test13 has not yet been decided.
NeilBrown
--- drivers/md/raid5.c
On Wed, Dec 13, 2000 at 10:48:56PM -0500, Mohammad A. Haque wrote:
Trace; c0105000 empty_bad_page+0/1000
Trace; c0100191 L6+0/2
I locked a Cyrix III machine up on boot and hat these both
elements in my trace, too.
It Oopsed and locked up after the Message: "CPU: Before vendor
init".
I locked
Hmmm, does syslog sending to another machine catch oops? I guess we'll
find out.
Ingo Oeser wrote:
I have no oops yet of this lockup, because of X, but I'll ask a
friend of mine, whether the remote logging made it to him and
send you the results.
--
Chris Lattner [EMAIL PROTECTED] writes:
p9fs exists. I didn't see these patches since August, but probably I can poke
Roman into porting it to the current tree. 9P is quite simple and unlike
CORBA it had been designed for taking kernel stuff to userland. Besides,
authors definitely
okay. got it here this morning, too. solid lock -- no dumping out of
x, no changing terminals, no mouse, no keyboard.
k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. kernel
built with gcc-2.95-2 against glibc-2.2. nothing remarkable underway
-- was composing a message in kmail,
Were you connected to a network or receiving/sending anything?
dep wrote:
okay. got it here this morning, too. solid lock -- no dumping out of
x, no changing terminals, no mouse, no keyboard.
k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. kernel
built with gcc-2.95-2 against
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
Thanks for posting this. Unfortunately, the kernel won't build unless you
restore this macro to the namespace after aic7xxx_linux.h blows it away:
--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
+++
Alan Cox [EMAIL PROTECTED] said:
In-Reply-To: [EMAIL PROTECTED] from "Keith Owens" at Dec 14, 2000 0
***9:05:13 AM
previously because nobody used those options. Since these are bugs in
the modules and only a few modules are affected (less than 5 reported),
the fix is to correct the
This is unrelated to the signal 11 problem, but something to consider
for "random crashes and segfaults", ie are you using this compiler
and glibc version combination.
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general than just their
Devik writes:
I just tried to narrow problem with DFE530 card and found
another (rather fatal) bug in 2.4.0-test12.
I attached both my config and ksymoops output. It seems
that ip_defrag is called with skb where skb-dev is NULL.
It then crashes in ip_queue_frag.
I can trigger it regulary by
Rogier Wolff writes:
Alan Cox wrote:
What better interactivity ;)
Thus to me, 2.4 FEELS much less interactive. When I move windows they
don't follow the mouse in real-time.
Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
2.2, which is smoother than 2.4. I hope
[EMAIL PROTECTED] writes:
Your guess? 8) Of course, it is incorrect. I even have no idea
how it is possible to put system into such sad state.
Though... probably, you forgot to up loopback.
I've seen exactly the same thing here. I have ipv6 in -test11 built as
a module, and after the machine
Joseph Cheek writes:
i'm using test12 to perform a clean linux install. as soon as i get to
a command prompt, ps axufw shows swapper at 99.8% CPU usage. this
didn't repro with test11, and doesn't repro if i don't use an initrd.
What pid does this task have? The only process that should be
On Thursday 14 December 2000 07:15, Mohammad A. Haque wrote:
| Were you connected to a network or receiving/sending anything?
a conditional yes -- little lan here, d-link dfe-530tx+ (rtl8139) to
dlink hub, di-701 gateway, cable modem. so far as i know, i was
neither sending nor receiving at
there are many situations in which a 16550 is KNOWN to be overrunable, all
of which can occur in your common PPP connection.
More importantly - if you have 2 16550's talking together (Which is
EXACTLY what you have, when you hook it to a modem) there are even MORE
overrun possibilities.
Hello!
I see similar effects with IDE DMA. It isn't that bad but it may be
related.
The difference is that I use 2.2.18. Whether I use the
ide.2.2.18.1209.patch or not makes no difference.
My box doesn't lockup, but since I bought a second IDE harddisk I cannot
use DMA anymore.
Boot messages
Pretty cool huh?
Let me know if you would like a copy of the code.
A quick strace shows that it binds to port 24000.
It also contains a list of 5 IP addrs. I suspect it doesn't
broadcast, but allows people in from those IPs.
Anyone know what has happened? I religiously install
I tried it against clean 2.2.18 and patches did not work.
Some drawbacks:
- the patch adds config info for AIX7XXX in the top level Makefile, instead
of in the Makefile in the scsi dir.
Yes, this will be fixed today. The aic7xx directory will build the module
or main driver file into the scsi
I surely hope that this thread wont end here. It's extremely important to look
at this since we're heading towards distributed resources, where humans dont
work on a server but towards other people through servers.
/josef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
I'll update my patch tomorrow to restore the definition of current.
I do fear, however, that this will perpetuate the polution of the
namespace should "current" ever get cleaned up.
It can probably get cleaned up after 2.4 by making current() the actual
inline. For 2.2 it won't change.
On Thu, 14 Dec 2000 11:51:19 Alan Cox wrote:
I have no plan to do this. Don's drivers depend on some extra glue that was
rejected from the main kernel tree. Said glue is also buggy causing the same
card to be multiply detected.
If folks want to strip the glue out and get real changes
Hi, I need to check for *only* Intel P6 processors, so no Classic Pentium,
and no Pentium 4. setup.c is a bit obscure; is this check correct :
if (current_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
current_cpu_data.x86 != 6)
return NOT_P6;
if (current_cpu_data.x86_model 5)
On Thu, 14 Dec 2000 14:45:53 Justin T. Gibbs wrote:
- The subdir for aic7xxx has not a Makefile, or at least it is not created
with the patches for 2.2.18.
It was supposed to be part of the patches for 2.2.18 (each kernel version
requires a slightly different Makefile which is why it is
Hi,
One of the things we've been lacking in the Linux implementation of
RPC is the 'ping' routine. The latter is used on most *NIX
implementations in order to test whether or not the RPC server is
alive. To do so, it simply calls procedure-0 (the NULL procedure),
which is always set up to
Dear Linus, please apply!
This patch fixes a bug in the VFAT code.
When creating files with short file names, the VFAT driver decides that a file name
starting with a lower case character is always a short (MSDOS style) name, despite any
other character of the file name that would need to be
BSD has curproc, but that is considerably less likely to be
used in "inoccent code" than "current". I mean, "current what?".
It could be anything, current privledges, current process, current
thread, the current time...
I see and I assume calling a random collection of data
This Oops happened with mutt as the only active user process.
I'd been using uhci for a while with test kernels, as usb-uhci had
been oopsing on first mouse use. However, with test12 I found a
problem with uhci:
Dec 13 12:13:24 bloch kernel: PCI: Found IRQ 5 for device 00:07.2
Dec 13 12:13:24
On Thu, Dec 14, 2000 at 10:23:14AM +, Alan Cox wrote:
I just want to let other know that kernel 2.2.18 does not work properly (*)
on my box if I compile it with egcs-2.91.66 19990314/Linux (egcs-1.1.2
release). Instead gcc-2.7.2.3 works ok.
(*) the network driver PCI NE2000 does
Mohammad A. Haque wrote:
Were you connected to a network or receiving/sending anything?
dep wrote:
okay. got it here this morning, too. solid lock -- no dumping out of
x, no changing terminals, no mouse, no keyboard.
k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset.
This is where a 654 or an 854 (I'm only listing startech design chips.
there are others that would do the job.) come in handy. They can pause
their transmitter WITH bytes in their fifo. (Automated hardware/software
flow control.)
Indeed. Most chips I've seen are 1 16550, or pretend to
On Thu, 14 Dec 2000, Justin T. Gibbs wrote:
I'll update my patch tomorrow to restore the definition of current.
I do fear, however, that this will perpetuate the polution of the
namespace should "current" ever get cleaned up.
It can probably get cleaned up after 2.4 by making current()
On Wed, Dec 13, 2000 at 05:27:03PM -0500, David Riley wrote:
DMESG: http://kocour.ms.mff.cuni.cz/~macok/kernel/dmesg (Abit
PX5, P166 (ovrclckd to 166), 128MB RAM, 2x IDE HDD, 3com509b ISA,
Opti931)
Overclocking is a guaranteed way to get random hangups. Put it back
to its recommended
I figured as much. I will test for the #define, stash it in a #define
unique within my namespace, and #define it back in hosts.c should my
local define exist.
Justin,
While you're at it, can you have the new driver provide status information
under /proc/scsi/aic7xxx? There is simply an
"Justin T. Gibbs" wrote:
BSD has curproc, but that is considerably less likely to be
used in "inoccent code" than "current". I mean, "current what?".
It could be anything, current privledges, current process, current
thread, the current time...
I see and I assume calling a random
What's wrong with current? It's perfectly fine, since it's the main data
context entity you are working with during it's usage... Just remember
it as
CURRENT MAIN PROBLEM the kernel is struggling with at time.
What's wrong with the aic7xxx driver storing the "user", "goal", and
"current"
Hello,
Just writing in to report a bug in 2.4.0-test12.
Hardware:
PCI-Matrox_Mill
PCI-Adaptec 39160 / 160M scsi card
PCI-Generic TNT-2 card
PCI-Sound blaster -128 (es1370)
CPU 21164a - Alpha
Problem:
There is a race condition in the aic7 driver that causes the
kernel to lock
Hi,
I'm looking at a frame buffer driver, and I'm getting a little confused...
To remove any confusion (since I know that people get confused with the
terminology here), here is how I define these addresses:
virtual space- address space that the kernel runs in
physical space -
In article [EMAIL PROTECTED] you wrote:
For those
of you building the driver as a module, take note that the module
name is now "aic7xxx_mod" rather than "aic7xxx".
Could you please undo that change?
Postfixing a module name with _mod does not make sense.
Yes, some modules use it - but that's
"Justin T. Gibbs" wrote:
What's wrong with current? It's perfectly fine, since it's the main data
context entity you are working with during it's usage... Just remember
it as
CURRENT MAIN PROBLEM the kernel is struggling with at time.
What's wrong with the aic7xxx driver storing the
While running the test12 kernel with the test11 arch/i386, I've trapped an
Oops message in my log. I'm not sure if it has something to do with using
the arch/i386 code from test11, but it seems necessary to post it since
test12 introduces changes to kswapd-bdflush.
I am currently running test11
hi all,
I have some trouble in testing a Perl module.
The "make test" gives me this problem:
t/07io..Your vendor has not defined Socket macro MSG_PEEK,
used at blib/lib/Convert/BER.pm line 968
dubious
and I didn't find this macro defined in "sys/types.h" or in
"sys/socket.h" or in
In article [EMAIL PROTECTED] you wrote:
For those
of you building the driver as a module, take note that the module
name is now "aic7xxx_mod" rather than "aic7xxx".
Could you please undo that change?
Postfixing a module name with _mod does not make sense.
Yes, some modules use it - but that's
Alexander Viro wrote:
Err... how about this: Give me two or three kORBit syscalls and I can get
rid of all the other 100+ syscalls! :)
Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as
On Wed, 13 Dec 2000, Chris Lattner wrote:
1. kORBit adds about 150k of code to the 2.4t10 kernel.
2. kNFS adds about 100k of code to the 2.4t10 kernel.
3. kORBit can do everything kNFS does, plus a WHOLE lot more: For example
implement an NFS like server that uses SSL to send files and
1. kORBit adds about 150k of code to the 2.4t10 kernel.
2. kNFS adds about 100k of code to the 2.4t10 kernel.
So can you implement a kNFS server in kORBit that takes
less than 50kB of RAM? Otherwise it's still a contributor
to bloat and this argument won't work ;)
Actually the kORBitNFS
Erik Mouw writes:
The Crystal CS89x0 ethernet chip is also used in quite some embedded
systems that don't have an ISA bus at all, so the CONFIG_ISA option in
drivers/net/Config.in is inapropriate. Here is a patch against
2.4.0-test12 to fix that. Please consider applying.
I don't think this
On 14 Dec 00 at 15:16, Russell King wrote:
virtual space- address space that the kernel runs in
physical space - address space that the CPU sits in
PCI memory space - memory address space that the PCI peripherals sit in
== bus address...
Many, if not all ARM architectures
Russell King wrote:
Erik Mouw writes:
The Crystal CS89x0 ethernet chip is also used in quite some embedded
systems that don't have an ISA bus at all, so the CONFIG_ISA option in
drivers/net/Config.in is inapropriate. Here is a patch against
2.4.0-test12 to fix that. Please consider
I don't know when the /proc stuff will return or what data will be
provided there.
At the risk of tooting my own horn, you might put there that which I do for my
Qlogic driver- it lists current perio/offset values per target and a list of
currently running commands. It's very easy to support
Yeah. most of this crap is manufactured as all-in-1 chips. (IDE, FDC, SER,
PAR, etc.) and right along with that, you get 2 16550AFN's. Now. they
hyped the heck out of 16550's when they came out, because "You can use
your 28.8kbps modem without overruns!". Yeah. clocking it at 38400 or
57600
There is a large perception of CORBA being slow, but for the most part
it is unjustified.
Well, I've measured using function calls through ORBit is 300 times
slower than using dynamic loading.
...
Which gives me the dl is about 333 times faster than ORBit.
You leave so many details
201 - 300 of 452 matches
Mail list logo