No problems here... with 2.4.3
Here is the dump from dmesg.
regards,
Royans
-
SCSI subsystem driver Revision: 1.00
aacraid raid driver version, Apr 28 2001
percraid device detected
Device mapped to virtual address 0xf8806000
percraid:0 device initialization successful
percraid:0
Followup to: <[EMAIL PROTECTED]>
By author:Richard Gooch <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > In x86-64 there are special vsyscalls btw to solve this problem that export
> > a lockless kernel gettimeofday()
>
> Whatever happened to that hack that was discussed a year
At 2:04 PM -0400 2001-04-28, Albert D. Cahalan wrote:
>It is a disaster waiting to happen. Instead of having the offending
>process get killed, your machine could suffer extreme thrashing.
>
>Have enough swap for idle processes and no more.
Let's altogether now say "working set".
(Does Linux
Russell King writes:
> Can someone please explain to me the rationale behind the zerocopy
> implementation that has appeared in 2.4.4 please?
You've had at least 2 months to ask this question. Like I have asked
several others I am going to ask you, why you are complaining now?
I see you
The user-mode port of 2.4.4 is available.
The swap problems that were in the 2.4.3 UML are fixed.
It is now possible to attach already-running debuggers and debuggers other
than gdb to UML. See http://user-mode-linux.sourceforge.net/debugging.html
for details. There, I give an example of
I am having dificulty getting an ASIX AX88140 ethernet card to work under
the 2.4.3 kernel.
It works perfectly under a 2.2.19 kernel and is found properly, but when
trying the 2.4.3 kernel it fails with the message:
tulip: eth1: MMIO region (0x0@0x0) unavailable, aborting
tulip-diag
Michael Rothwell wrote:
>
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > "dcim" probably stands for "digital camera images". At least Canon
> > digital cameras always put their data in a directory named dcim.
>
> Makes sense. FAT's root directory is limited in the number of entries it can
>
Look and enjoy. If prune_icache() doesn't shoot its goal, it
tries to sync some dirty inodes and look for freeable ones one more
time. The sad thing being, counter is not reset on the second pass.
I.e. you end up with nr_unused decremented by 2 * freed_at_the_first_pass +
In another few minutes I'll be posting the script itself to
fa.linux.kernel that produced this
...
FLAGS00010282
0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0
N O D I T S Z A P C
e v i n r
On Sat, Apr 28, 2001 at 05:02:21PM +0200, [EMAIL PROTECTED] wrote:
> I just got a Dane-Elec PhotoMate Combo SmartMedia/CompactFlash reader
> manufactured by SCM Microsystems. It is a USB device with ID 04e6:0005.
>
> The http://www.qbik.ch/usb/devices/ list of supported devices
> calls this
All the 2.4.x kernels are failing on my dual Intel PII system with a kernel
panic. I have tried everything I could (disable swap, setting memory size,
build kernel with minimal options, etc..) and have been unable to boot the
kernel so I suspect there may be a bug. The 2.4.x kernels build without
Kernel: 2.4.4
Well, for all those people getting "audio drain" messages
when trying to play audio with your via82cxxx driver try
passing the "noapic" option to your kernel on bootup to
see if it works.
I did manage to get mine to work, but only with xmms. When I
try to use other programs,
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> "dcim" probably stands for "digital camera images". At least Canon
> digital cameras always put their data in a directory named dcim.
Makes sense. FAT's root directory is limited in the number of entries it can
contain, to something like 32. Cameras
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED] (Rogier Wolff)
In newsgroup: linux.dev.kernel
>
> # l /mnt/d1
> total 16
> drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> -r-xr-xr-x 1 root root0 May 23 2000 memstick.ind*
> #
>
> Where the
> > Obvious question is, which compiler.
>
> I hadn't seen any locks, but (on a dual Pmmx 200) it started crawling
> right after the NIC module (tulip) was loaded. System load decided to
> skyrocket.
>
> Yadda... 2.2.19 with devfs patch.
> bicycle:~# gcc -v
> Reading specs from
Hi,
Can someone please explain to me the rationale behind the zerocopy
implementation that has appeared in 2.4.4 please?
The reason I ask is that even on x86, it seems to me to be extremely
silly to have the expense of doing unaligned checksumming for the gain
of zerocopy.
Just think - if you
On Sun, Apr 29, 2001 at 01:16:04AM +0200, bert hubert wrote:
> On Sat, Apr 28, 2001 at 02:21:29PM -0700, Ion Badulescu wrote:
> > Hi Alan,
> >
> > Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
> > the it keeps locking up whenever the disks are stresses a bit, e.g.
> 001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02
> 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00
P]'...Yn
> 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
..U*
> 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i..
Andi Kleen writes:
> On Sat, Apr 28, 2001 at 05:52:42PM +0200, Ingo Molnar wrote:
> >
> > On Sat, 28 Apr 2001, Andi Kleen wrote:
> >
> > > You can also just use the cycle counter directly in most modern CPUs.
> > > It can be read with a single instruction. In fact modern glibc will do
> > > it
Hello,
On Sat, 28 Apr 2001, Jens Axboe wrote:
> Is the CDROM on the 1542?
All three CDROM's are on the 1542. Sorry, you can't see that from [7.6].
> And could you include full panic info, please?
How do I get "full panic info"? Pointers would help.
I copied the info from the screen to
Hi,
I have a Sony memory stick in my system. When I display all the
interesting (i.e. not all 0xff and not all 0x00 data), I see (on a
recently formatted stick):
% hd /dev/hde | grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" | grep -v
"00 00 00 00 00 00 00 00 00 00 00 00 00 00
On Sat, Apr 28, 2001 at 02:21:29PM -0700, Ion Badulescu wrote:
> Hi Alan,
>
> Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
> the it keeps locking up whenever the disks are stresses a bit, e.g. when
> updatedb is running. I get the following messages on the console:
Hi all!
Compiling plain 2.4.4 kernel on a i486 with_out_ PCI support, I encountered the
following error with PC parallel port as a module:
parport_pc.c: In function `parport_pc_find_ports':
parport_pc.c:2618: too many arguments to function `parport_pc_init_superio'
make[2]: *** [parport_pc.o]
On Sat, Apr 28, 2001 at 11:29:15AM -0700, David Lang wrote:
> what sort of switch are you plugged into? some Cisco switches have a
> 'feature' that ignores all traffic from a port for X seconds after a
> machine is plugged in / powered on on a port (they claim somehting about
> preventing loops)
> questions, but lots of people here don't even like UIs. :)
... except make menuconfig. I prefer DOS 3.3 over any Windoze/KDE out
there :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi all,
I was unable to find out who the maintainers of those three framebuffer
drivers are (Amiga, Atari, Mach64) and therefore I'm asking here on lkml.
All three of the drivers define a function named strtoke for their private
use which does almost the same as strsep (that in turn lives in
--- linux-2.4.4/drivers/parport/parport_pc.c~ Sat Apr 28 21:43:38 2001
+++ linux-2.4.4/drivers/parport/parport_pc.cSat Apr 28 22:37:29 2001
@@ -2576,7 +2576,7 @@
}
#else
static struct pci_driver parport_pc_pci_driver;
-static int __init parport_pc_init_superio(void) {return 0;}
+static
Thus spake Steven Walter ([EMAIL PROTECTED]):
> I'm also seeing what would appear to be exactly this.
>
> The problem, for me, doesn't occur when I write directly to /dev/dsp
> (i.e., use the OSS output plugin for xmms). The problem only occurs
> with esd.
>
> It would appear that something
Hi!
Quite many changes went to nbd in 2.4.4, but no change to initial
comment with version/copyrights. Would author please credit himself?
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Russell King writes:
> >From x86 vmlinux.lds:
>
> /* Sections to be discarded */
> /DISCARD/ : {
> *(.text.exit)
> *(.data.exit)
> *(.exitcall.exit)
> }
Thanks, this is the part I didn't catch. If you had said this in
the first email, I would have
David Lang wrote:
> at the low end useing a bit of disk for swap doesn't hurt, I ran into a
> case a couple years ago on AIX systems. we buy them with 2G ram so that we
> don't need to swap, but discovered (the hard way) that we also needed to
> allocate 4G of disk space for those boxes
Hmmm... this is the kernel list... not only the wrong place to ask UI
questions, but lots of people here don't even like UIs. :)
http://www.gnome.org
-M
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 28, 2001 2:13 PM
Subject: Common GUI
Albert D. Cahalan wrote:
> So that is a factor of 50 in price. It's what, a factor of 100
> in access time?
Actually it's only about 10.
> > That disk space is just sitting there. Never to be used. I spent $400
> > on the RAM, and I'm now reserving about $8 worth of disk space for
> >
On Sat, Apr 28, 2001 at 02:07:53PM -0700, David S. Miller wrote:
> Why would ip_nat_cleanup() be removed by the linker?
Because we explicitly tell the linker to drop all code marked as
__exit:
#define __exit __attribute__ ((unused, __section__(".text.exit")))
>From x86 vmlinux.lds:
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
updatedb is running. I get the following messages on the console:
wait_on_bh, CPU 1:
irq: 1 [1 0]
bh: 1 [1 0]
<[8010af71]>
over and
...and inocent one, but please apply, anyway.
Pavel
Index: slab.h
===
RCS file: /home/cvs/Repository/linux/include/linux/slab.h,v
retrieving revision 1.1.1.2
diff -u -u
I'm also seeing what would appear to be exactly this.
The problem, for me, doesn't occur when I write directly to /dev/dsp
(i.e., use the OSS output plugin for xmms). The problem only occurs
with esd.
It would appear that something in the kernel broke esd.
On Sat, Apr 28, 2001 at 10:50:01AM
Looking for the best way to give all users a common desktop, which comes from one
source (for easy administration).
Found copying my /root/.gnome & .sawfish directories to a user home breaks the user's
GUI, implying a symlink wouldn't work. I am told .gnome & .sawfish can be copied to
Russell King writes:
> ip_nat_standalone.c:
>
> static int init_or_cleanup(int init)
> {
> ...
> cleanup_nat:
> ip_nat_cleanup();
> ...
> }
Call ip_nat_cleanup();
> ip_nat_core:
>
> void __exit ip_nat_cleanup(void)
> {
> ip_ct_selective_cleanup(_nat, NULL);
>
To recap: running Panasonic LF-D101 DVDRAM drive on SCSI (AHA2740) and
getting segfaults. On-disk format is UDF2.0, as 2.1 won't mount.
Mount, ls, umount, mount, ls, umount, etc - no problem.
Mount, cp <20Mfile>, umount, mount, ls, (20Mfile), umount, mount, ls, (20Mfile),
rpm -q 20Mfile,
On 28-Apr-2001 Tony Hoyle wrote:
> On 28 Apr 2001 13:44:48 -0700, Davide Libenzi wrote:
>> Sorry but why don't You run Your application with gdb ?
>> Once Your program crashes You'll get the prompt and You'll be able to
>> stack-trace and watching whatever You need.
>> The solution I use to be
On 28 Apr 2001 13:44:48 -0700, Davide Libenzi wrote:
> Sorry but why don't You run Your application with gdb ?
> Once Your program crashes You'll get the prompt and You'll be able to
> stack-trace and watching whatever You need.
> The solution I use to be able to get inside the program even when
David Lang wrote:
>
> watch the resonate heartbeat and see if it is getting lost in the network
> traffic (the resonate logs will show missing heartbeat packets). think
> seriously of setting the resonate stuff to run at a higher priority so
> that it doesn't get behind.
>
> depending on how
On 28-Apr-2001 Tony Hoyle wrote:
> Is there a way (kernel or userspace... doesn't matter) that gdb/ddd
> could be invoked when a program is about
> to dump core, or perhaps on a certain signal (that the app could deliver
> to itself when required). The latter case
> is what I need right now, as
Tony Hoyle ([EMAIL PROTECTED]) wrote:
> Is there a way that gdb/ddd could be invoked when a program is about
> to dump core...?
Yes, I use that to get a symbolic stack dump after a crash,
although I find that the gdb so invoked doesn't accept interactive
commands, and I have to use 'kill -9'
Is there a way (kernel or userspace... doesn't matter) that gdb/ddd
could be invoked when a program is about
to dump core, or perhaps on a certain signal (that the app could deliver
to itself when required). The latter case
is what I need right now, as I have to debug an app that breaks
Peter Osterlund wrote:
>
> I have noticed that 2.4.4 feels a lot less responsive than 2.4.3 under
> fork load. This is caused by the "run child first after fork" patch. I
> have tested on two different UP x86 systems running redhat 7.0.
>
> For example, when running the gcc configure script,
On Sat, Apr 28, 2001 at 05:52:42PM +0200, Ingo Molnar wrote:
>
> On Sat, 28 Apr 2001, Andi Kleen wrote:
>
> > You can also just use the cycle counter directly in most modern CPUs.
> > It can be read with a single instruction. In fact modern glibc will do
> > it for you when you use
On Fri, 27 Apr 2001, David S. Miller wrote:
> Kai, can you try this patch out? I think it does the right
> thing. What I'm mostly interested in is if your ipchains
> setup works for the resulting kernel, I've already checked
> that it links properly. :-)
I'm not Kai, but I also reported
Hi,
>I met follwing erros which was workarounded by put
>define KMALLOC_MAXSIZE 131072
>borrowed from af_unix.c of 2.4.3-ac14. But I'm convinced of
>this.
>below lines were wrapped by me for readabilities' sake.
my fix in an earlier e-mail to the list explained that the
proper way of fixing it
what sort of switch are you plugged into? some Cisco switches have a
'feature' that ignores all traffic from a port for X seconds after a
machine is plugged in / powered on on a port (they claim somehting about
preventing loops) it may be that the new kernel now boots up faster then
the old one
linux-2.4.4/drivers/video/Config.in allowed the user to select
some Atari and SuperH architecture video drivers that would not compile
on other architectures. This patch causes those drivers to be offered
only on architectures on which they will compile.
By the way, this patch
linux-2.4.4 changes one line in drivers/scsi/pci2220i.c that
used to call scsi_set_pci_device to call the undefined routine
scsi_set_pci_info. That is the only change to pci2220i.c in linux-2.4.4.
I don't know what the intention of this change was. Perhaps a renaming
of
at the low end useing a bit of disk for swap doesn't hurt, I ran into a
case a couple years ago on AIX systems. we buy them with 2G ram so that we
don't need to swap, but discovered (the hard way) that we also needed to
allocate 4G of disk space for those boxes (allocating less then 2G meant
that
On Sat, Apr 28 2001, Jonathan Hudson wrote:
> In article <[EMAIL PROTECTED]>,
> Jens Axboe <[EMAIL PROTECTED]> writes:
> JA> On Sat, Apr 28 2001, Roman Fietze wrote:
> >> Hello,
> >>
> >> I reported this before and the bug still exists in 2.4.4. The problem can
> >> be circumvented by
On Sat, 28 Apr 2001, Linus Torvalds wrote:
> > Reverting the fork patch makes all these problems go away on my machine.
>
> Reverting it outright may be an acceptable approach. I'll think about
> it: the arguments _for_ the patch are true and real, and it shows up as
> real improvements on some
> (on problems with ne2k-pci on SMP-systems)
Seems you're experiencing the effects of the infamous IO-APIC problem
('erratum' in Intel-lingo). There's a patch for these problems by Maciej W.
Rozycki, which should (IMnsHO) really be accepted into the main kernel tree
since many people are
On Sat, 28 Apr 2001, Mark Hemment wrote:
> Hi,
>
> d_move() in fs/dcache.c is checking the kernel lock is held
> (switch_names() does the same, but is only called from d_move()).
>
> My question is why?
> I can't see what it is using the kernel lock to sync/protect against.
Metric
Hi,
d_move() in fs/dcache.c is checking the kernel lock is held
(switch_names() does the same, but is only called from d_move()).
My question is why?
I can't see what it is using the kernel lock to sync/protect against.
Anyone out there know?
Thanks,
Mark
-
To unsubscribe from this
In article <[EMAIL PROTECTED]>,
Jens Axboe <[EMAIL PROTECTED]> writes:
JA> On Sat, Apr 28 2001, Roman Fietze wrote:
>> Hello,
>>
>> I reported this before and the bug still exists in 2.4.4. The problem can
>> be circumvented by using drivers/scsi/sr.c from kernel 2.4.[01]. This
>> "fix"
I've had this network bug for the entire to 2.3 dev to 2.4 final and now even
in 2.4.4. Whenever I have high network traffic I get an ethernet transmit
timeout error by netdev watchdog. This is with a ne2k-pci network card, and
smp celeron machine. Reinstalling the module doesn't fix it,
Howdy,
I've got an "Adaptec AHA-2940UW Pro Ultra SCSI host adapter" using
the aic7xxx driver (the new one, not the old one), and have had no
problems, I have a zip drive on ID5, and a 12X Smart & Friendly CD-RW on
ID6, haven't had any problems on 2.4.3-ac14, or 2.4.4, just an FYI.
I had received info that this may have been fixed in 2.4.3-ac5. I
didn't get the chance to test it there, but I installed 2.4.4 this
morning. Alas, I receive exactly the same errors with 2.4.4 as I did
previously with 2.4.3.
One thing that did differ, though, shortly after I sent this first
On Sat, Apr 28, 2001 at 08:22:25PM +0200, Matthias Andree wrote:
> These have further devices (CD writer, CD-ROM drive), and these machines
> are 100% in 2.2.19. With 2.4.3 and 2.4.4-pre8, I get this problem
> (pencil & paper copy for Machine #2, DO NOT "grep"):
>
> AIC 7XXX EISA/VLB/PCI SCSI
Hi,
I have several machines here, with either onboard aic7880 or with
AHA2940 (I don't recall) sitting on the PCI bus, which share the same
problem: they fail to detect the first disk (Id #0). The information
below is from lspci and /proc/scsi/scsi of Linux 2.2.19, in that order,
all Kernels
Patch rediffed to 2.4.4, otherwise - no changes (2.4.4 has a
fix for ext2 race, but it's unrelated to the thing).
Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
Please, help with testing.
Al
-
To
I am now maitaining two versions of the directory indexing patch, one
for the "old-style" ext2 directory code and another based on Al Viro's
directory-in-page-cache patch, which hasn't made it into the main tree
yet. The current patches are:
Rogier Wolff writes:
> Wakko Warner wrote:
>>> So you've spent almost $200 for RAM, and refuse to spend
>>> $4 for 1Gb of swap space. Fine with me.
So that is a factor of 50 in price. It's what, a factor of 100
in access time?
> That disk space is just sitting there. Never to be used. I
John Kacur <[EMAIL PROTECTED]> writes:
> >Peter Osterlund wrote:
> >>
> >> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> >> not possible to interrupt with ctrl-c.
>
> >Same thing here.
>
> I'm not having any problems. Just a quick question, is everyone
On Sat, Apr 28 2001, Roman Fietze wrote:
> Hello,
>
> I reported this before and the bug still exists in 2.4.4. The problem can
> be circumvented by using drivers/scsi/sr.c from kernel 2.4.[01]. This
> "fix" did not help just me, but somebody else I had contact with on the
> net.
Is the CDROM
On Sat, 28 Apr 2001, Peter Osterlund wrote:
>
> For example, when running the gcc configure script, the X mouse pointer is
> very jerky. The configure script itself runs approximately as fast as in
> 2.4.3.
Ok. Fair enough. The new "run the child first" approach has advantages,
but it is
Hello,
I reported this before and the bug still exists in 2.4.4. The problem can
be circumvented by using drivers/scsi/sr.c from kernel 2.4.[01]. This
"fix" did not help just me, but somebody else I had contact with on the
net.
[1.] One line summary of the problem:
Kernel Panic and mount
I met follwing erros which was workarounded by put
define KMALLOC_MAXSIZE 131072
borrowed from af_unix.c of 2.4.3-ac14. But I'm convinced of this.
below lines were wrapped by me for readabilities' sake.
-D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall -Wstrict-prototypes -O2
[EMAIL PROTECTED] said:
> Richard, can you add this URL to the FAQ ?
--- index.html.orig Sat Apr 28 18:03:32 2001
+++ index.html Sat Apr 28 18:04:41 2001
@@ -5570,8 +5570,9 @@
Contributing Contributions are welcome on
-this FAQ. These can be submitted by Email to Richard (see the
I used Peanut Linux (debian based from ibiblio.org/peanut), and gcc 2.95.2 to compile
the 2.2.19 kernel I run now. No problems here.
--
home page:
http://members.fortunecity.com/fretburn1
AIM: GhiZzard
ICQ: 34778276
(When I'm on those things of course! :))
Hello *,
I hope that this is the right place to document my problems:
After some changes in the bios settings and/or rebuilding the kernel
(I don't remember the exact chronology of this..) I get the following
kernel message when I try to mount a vfat partition (either ide/hdd
or a ZIP connected
net/network.o: In function `init_or_cleanup':
net/network.o(.text+0x4a530): relocation truncated to fit: R_ARM_PC24 ip_nat_cleanup
says it all.
ip_nat_standalone.c:
static int init_or_cleanup(int init)
{
...
cleanup_nat:
ip_nat_cleanup();
...
}
ip_nat_core:
void __exit
>Peter Osterlund wrote:
>>
>> Another thing is that the bash loop "while true ; do /bin/true ; done" is
>> not possible to interrupt with ctrl-c.
>Same thing here.
I'm not having any problems. Just a quick question, is everyone who is
having a problem running with more than one cpu?
On Sat, 28 Apr 2001, Andi Kleen wrote:
> You can also just use the cycle counter directly in most modern CPUs.
> It can be read with a single instruction. In fact modern glibc will do
> it for you when you use clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)
well, it's not reliable while using
I too have this problem. The first time dhcpcd is executed it fails due
to timeout.
If we execute it again it works fine. Looks like the first packets
sent/received through the interface don't get treated right.
If I reverse the 2.4.4 patch to 2.4.3 it starts working well again.
Something's up
On Sat, 28 Apr 2001, Michael F Gordon wrote:
> dhcpcd stops working if I install 2.4.4. Replacing the 2.4.4 version of
> 8139too.c with the 2.4.3 version and leaving everything else exactly
> the same gets things working again. Configuring the interface by hand
> after dhcpcd has timed out
Peter Osterlund wrote:
>
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
Same thing here.
> A third thing I noticed is that starting a gnome session in redhat 7.0
> takes longer. (It takes more time for the gnome
OK, I'm sending both variants (rediffed to 2.4.4). Take your pick.
Variant 1: invalidate_device(dev) (see below)
Variant 2: invalidate_device(dev, do_sync) (next posting; I've switched the
cases using sync_dev to fsync_dev, so do_sync is boolean)
diff -urN S4/drivers/acorn/block/mfmhd.c
... and here's the promised second variant
Al
diff -urN S4/drivers/acorn/block/mfmhd.c
S4-invalidate_device-2/drivers/acorn/block/mfmhd.c
--- S4/drivers/acorn/block/mfmhd.c Fri Feb 16 18:37:01 2001
+++
dhcpcd stops working if I install 2.4.4. Replacing the 2.4.4 version of
8139too.c with the 2.4.3 version and leaving everything else exactly
the same gets things working again. Configuring the interface by hand
after dhcpcd has timed out also works. Has anyone else seen this?
ISC DHCP 2.0,
I just got a Dane-Elec PhotoMate Combo SmartMedia/CompactFlash reader
manufactured by SCM Microsystems. It is a USB device with ID 04e6:0005.
The http://www.qbik.ch/usb/devices/ list of supported devices
calls this thing unsupported, and [EMAIL PROTECTED] writes:
"I want this to work ! I'll help
On Sat, 28 Apr 2001, Martin Dalecki wrote:
> I think in the context you are inventig the proposed function,
> the drivers has allways an inode at hand. And contrary to what Linus
Read the patch. Almost all cases are of the "loop over partitions of foo"
kind.
> says, drivers not just know
Alexander Viro wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function? Actually, that's what I've done in namespace
>
On 04.28 Rogier Wolff wrote:
>
> I've ALWAYS said that it's a rule-of-thumb. This means that if you
> have a good argument to do it differently, you should surely do so!
>
I'm not so sure it's only a 'rule of thumb'. Do not know the state of
paging in just released 2.4.4, but in previuos
Peter Osterlund wrote:
>
> I have noticed that 2.4.4 feels a lot less responsive than 2.4.3 under
> fork load. This is caused by the "run child first after fork" patch. I
> have tested on two different UP x86 systems running redhat 7.0.
>
> For example, when running the gcc configure script,
With over 40 years of experience in the field of recycling, I
have put together one of the most valuable resources for the
entire recycling community.
http://recycler_1.tripod.com/recyclersguide/
Whether you are handling PLASTIC, METALS, WOOD, TEXTILES, TIRES,
ELECTRONICS, ETC., this is the
On 04.28 Peter Osterlund wrote:
>
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
>
Just tried that under 2.4.4 on two terminals at the same time and the system
even noticed it. Both cpus were running at about
Wakko Warner wrote:
> > So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> > swap space. Fine with me.
> I put this much ram into the system to keep from having swap. I
> still say swap=2x ram is a stupid idea. I fail to see the logic in
> that. Disk is much much
On Sat, Apr 28, 2001 at 04:30:30PM +0300, Ville Herva wrote:
> Yes, that's vaguely resembles what I had in mind. Of course I had no idea
> about the data structures Tux or X15 use internally, so I couldn't think it
> too thoroughly.
You can also just use the cycle counter directly in most modern
On Sat, 28 Apr 2001, Erik Mouw wrote:
> On Sat, Apr 28, 2001 at 03:16:34PM +0800, Xiong Zhao wrote:
> > hello. i read linux kernel internal. are there other books/papers
> > like that which dwell with linux kernel in detail,especially on
> > process mechanism,for example,how pthread and fork
> or such. tar/cpio and friends don't deal properly with
> a. holes inside of files.
> b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a
> So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> swap space. Fine with me.
I put this much ram into the system to keep from having swap. I still say
swap=2x ram is a stupid idea. I fail to see the logic in that. Disk is
much much slower than ram and if you're
daniel sheltraw wrote:
> Hello kernel listees
>
> I have a busmaster question I am hoping you can help me with.
> If a PCI device is acting as a busmaster and the processor initiates a
> read/write to another device on the PCI bus while the busmater-device is in
> control of the bus what happens
On Sat, Apr 28, 2001 at 03:24:25PM +0200, you [Ingo Molnar] claimed:
>
> On Sat, 28 Apr 2001, Ville Herva wrote:
>
> > Uhh, perhaps I'm stupid, but why not cache the date field and update
> > the field once a five seconds? Or even once a second?
>
> perhaps the best way would be to do this
On Sat, 28 Apr 2001, Ville Herva wrote:
> Uhh, perhaps I'm stupid, but why not cache the date field and update
> the field once a five seconds? Or even once a second?
perhaps the best way would be to do this updating in the sending code
itself.
first there would be a 'current time thread',
1 - 100 of 225 matches
Mail list logo
