On Thu, 14 Jun 2001, Roger Larsson wrote:
> On Thursday 14 June 2001 10:47, Daniel Phillips wrote:
> > On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> > > On Wed, 13 Jun 2001, Tom Sightler wrote:
> > > > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> > > > > After the initial burst, the
Hallo:
My name is Ma Hong Wei,I'm glad to meet you.Do you like antigues
with oriental style? From no on,I believe ,we'll become friends.
I like antigues very much and loun a small antigue shop selling
porcelain and pottery wares, jade articles,fossils,calligrapiy and
paintings and
well... I doubt whether buddy allocator would take u to a situation where pages
0 and 2 are used and 1 and 3 are free...
try reading __get_free_pages in mm/page_alloc.c
[EMAIL PROTECTED] on 06/15/2001 12:39:20 AM
To: [EMAIL PROTECTED]
cc:(bcc: Amol Lad/HSS)
Subject: Buddy System
Insteresting that this thread fell into this. I just had one of those
cards that came across my desk phreak out. It was 2 days old and placed
in a win2k server. Last night it started dumping errors about firmware
and bad microcde.
Have yet to test it out on another machine, but I beleive the
This seems to be drifting into that old argument(s) of a forked kernel..
And of course here I am adding to the flotsams..and threadsomes
2.5 for Pentium Plus generation.
<2.4 For older hardware..
Ducking the inevitable flames, I think for the most part, there might be
justification for some
I'm using an old Inel EtherExpress Pro/10 ISA (i82595-based) to connect my
testbox (AMD K6-3 400, VIA MVP3 chipset, running Debian woody with kernel
2.4.5) to my home LAN, which connects to the net through 608/128 kbit ADSL.
The problem I'm seeing is after long periods of sustained activity, the
A couple people have requested a test case.
The problem first showed up in a very large java app. Since then I
wrote a small perl program to duplicate the behavior of the large app
by sending the same data, in the same order, in the same sized blocks,
from the server to the client.
If you want
I thought that when you compiled a kernel as UP it replaced the spin-lock
macros with versions that are blank. As a result a UP kernel spends no
time doing spinlocks at all.
that's why a SMP kernel on a UP box is slightly slower, there is more code
to be executed
David Lang
On Thu, 14 Jun
Em Fri, Jun 15, 2001 at 11:09:13AM +0800, [EMAIL PROTECTED] escreveu:
> hi:
> I write a serial driver for linux , and have a personal test . I went
> to patch this driver into kernel
> but I don't know how to contact serial.c author ..
> can any one help me ?
Look at MAINTAINERS in
On Thu, 14 Jun 2001, Roger Larsson wrote:
> On Thursday 14 June 2001 23:05, you wrote:
> > On Thu, 14 Jun 2001, Roger Larsson wrote:
> > > Hi,
> > >
> > > Wait a minute...
> > >
> > > Spinlocks on a embedded system? Is it _really_ SMP?
> >
> > The embedded system is not SMP. However, there is
Am Freitag, 15. Juni 2001 04:30 schrieb John Cavan:
> Dieter Nützel wrote:
> > Hello Alan,
> >
> > I see 4.29 GB under shm with your latest try.
> > something wrong?
>
> total:used:free: shared: buffers: cached:
> Mem: 1053483008 431419392 622063616 122880 24387584 260923392
hi:
I write a serial driver for linux , and have a personal test . I went
to patch this driver into kernel
but I don't know how to contact serial.c author ..
can any one help me ?
rich.liu
-
To unsubscribe from this list: send the
I've installed several thousand 3com cards of various ages and
types. I've had less than 20 bad cards.
Nick
On Thu, 14 Jun 2001, Dr. Kelsey Hudson wrote:
> On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > Erm, that is going to be a problem. Crypto benifits more from open source
> >
On Thu, 14 Jun 2001, Kip Macy wrote:
> As I mentioned previously IP heavy is a euphemism for commodity.
...and 3Com is notoriuos for putting out commodity, cheesy hardware.
Kelsey Hudson [EMAIL PROTECTED]
Software Engineer
Compendium Technologies,
On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
> Erm, that is going to be a problem. Crypto benifits more from open source
> than any other market segment, and binary only drivers for linux are not
> the way to go. I guess I need to get rid of my 5-10 3cr990s and replace
> them with someone
Kurt Garloff wrote:
>
> On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote:
> > Question 2: What is the purpose of the code sequence, "repz nop"
>
> Puts iP4 into low power mode.
Umm, slightly more accurate would be to say that it makes the P4 processor
wait before resuming the
Hello Alan,
I see 4.29 GB under shm with your latest try.
something wrong?
Regards,
Dieter
SunWave1>cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 327802880 322592768 5210112 4294184960 8417280 253640704
Swap: 1052794880 95768576 957026304
Dieter Nützel wrote:
>
> Hello Alan,
>
> I see 4.29 GB under shm with your latest try.
> something wrong?
total:used:free: shared: buffers: cached:
Mem: 1053483008 431419392 622063616 122880 24387584 260923392
Swap: 3947642880 394764288
MemTotal: 1028792 kB
On Wednesday June 13, [EMAIL PROTECTED] wrote:
>
> I might just do that first step (find_ino) and offer it as as an
> experimental patch to the growing number of people who have asked for
> nfs exporting of FAT filesystems, and see how reliable it is in
> practice.
Following is a patch against
Odds are it's a raw socket receive buffer issue. Stock pings only ask for
a ~96k socket buffer, which means that they can only hold one ~64k packet
at a time. So, if you're ever slow grabbing packets out of the buffer,
you're going to drop traffic.
You can fix this by upping the socket buffer
Christopher Friesen wrote:
>
> I'm attempting to write a piece of code that will validate the physical ethernet
> link from a NIC to the nearest router/hub/switch. What I'd like to do is to
> send out an ethernet packet addressed to me, bounce it off the
> hub/switch/router, and then read it
On Thursday, 14 June 2001, at 14:17:11 -0700,
[EMAIL PROTECTED] wrote:
>
> 1. When pinging a machine using kernel 2.2.19 I consistently get an 80%
> packet loss when doing a ping -f with a packet size of 64590 or higher.
>
What happens here is (under kernel 2.2.19):
ping -f -s 49092 localhost
On Thu, Jun 14, 2001 at 04:42:29PM -0600, [EMAIL PROTECTED] wrote:
> 2. The main thread sets up the data (which are global) and then signals
> that there is work to be done on the same condition variable. The first
> thread to get awaken takes the work. the remaining threads keep waiting.
For
> Hello,
>
> I have implemented thread pooling (with an environment variable
> where I can give the number of threads to be created). Results:
>
> 1. Linux, no change in the times (not under 2.2.x or 2.4)
[snip]
> I am now pretty much inclined to believe that it is either a) hardware
> issue
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
In terms of going through the code audit almost all the sound drivers still
need fixing to lock against format changes during a
Hello,
I have implemented thread pooling (with an environment variable
where I can give the number of threads to be created). Results:
1. Linux, no change in the times (not under 2.2.x or 2.4)
2. SGI/Solaris/OSF/1: times decrease when the number of threads matched
the number of processors
> any problems since 2.4.5 was published, they seem to have surfaced
> immediately after I created a rather big file capturing video with
> broadcast2000 (video card is bt848). Filesystem is ext2.
Thats something I've seen reported elsehwere. The high bandwidth capture card
stuff seems to show
>It's funny you mention this because I have been working on something
>similar recently. Basically making xfree86 int10 and VGA poking happy
>on sparc64.
Heh, world is small ;)
>But this has no real use in the kernel. (actually I take this back,
>read below)
yup, fbcon at least...
>You
On Thu, 14 Jun 2001, John Stoffel wrote:
> Rik> There's another issue. If dirty data is written out in small
> Rik> bunches, that means we have to write out the dirty data more
> Rik> often.
>
> What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
> I don't see how delaying
Jeff Garzik writes:
> I think rth requested pci_ioremap also...
It really isn't needed, and I understand why Linus didn't like the
idea either. Because you can encode the bus etc. info into the
resource addresses themselves.
On sparc64 we just so happen to stick raw physical addresses into
So it would seem. Here is the polite message I received in response my
inquiry regarding the crypto interface to the card:
>
>
> Thank you for your inquiry. We do not offer the
> technical spec;s for the IPSec
> features of this NIC, due to the intellectual
> property-heavy nature of this
>
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>Use pre2. Linus applied a patch that changed the PCI power management stuff
>and broke all the drivers.
It shouldn't have broken anything. The warning happens, but the
function call ends up doing the same thing as it used
Rik> There's another issue. If dirty data is written out in small
Rik> bunches, that means we have to write out the dirty data more
Rik> often.
What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
I don't see how delaying writes until the buffer is almost full really
helps us.
In article <[EMAIL PROTECTED]>,
Stelian Pop <[EMAIL PROTECTED]> wrote:
>
>Well, not quite... I've had several X lockups while using the YUV
>acceleration code. Let's say one lockup per half an hour.
Strange. I've watched DVD's etc. Maybe it's not the Xv code, but your
camera code?
>Even the
On Thursday 14 June 2001 23:05, you wrote:
> On Thu, 14 Jun 2001, Roger Larsson wrote:
> > Hi,
> >
> > Wait a minute...
> >
> > Spinlocks on a embedded system? Is it _really_ SMP?
>
> The embedded system is not SMP. However, there is definite
> advantage to using an unmodified kernel that
Erm, that is going to be a problem. Crypto benifits more from open source
than any other market segment, and binary only drivers for linux are not
the way to go. I guess I need to get rid of my 5-10 3cr990s and replace
them with someone else's product?
Nick
On Thu, 14 Jun 2001, Kip
On Thursday, 14 June 2001, at 12:30:02 -0600,
[EMAIL PROTECTED] wrote:
> Folks,
>
> I checked 2.4.x source code but did not find any code for IPsec. Does
> anyone know that current or latest Linux support IPsec? Or does anyone know
> who is working on this ipv6 issue?
>
Check FreeS/WAN
IPsec support will be binary only.
-Kip
On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
> So what is the truth to the rumors 3com was throwing around about the
> "linux driver with ipsec support"?
> Nick
>
> On Thu, 14 Jun 2001, Martin Moerman wrote:
>
> >
> >
> > On Thu, 14 Jun
So what is the truth to the rumors 3com was throwing around about the
"linux driver with ipsec support"?
Nick
On Thu, 14 Jun 2001, Martin Moerman wrote:
>
>
> On Thu, 14 Jun 2001, Brent D. Norris wrote:
>
> > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT
>
1. When pinging a machine using kernel 2.2.19 I consistently get an 80%
packet loss when doing a ping -f with a packet size of 64590 or higher.
2. A "ping -f -s 64589" to a machine running kernel 2.2.19 results in 0%
packet loss. By incrementing the packetsize by one "ping -f -s 64590" or
On Thu, 14 Jun 2001, Brent D. Norris wrote:
> > Now, if the NIC were to integrate with OpenSSL and offload some of THAT
> > donkey work... Just offloading DES isn't terribly useful, as Pavel says:
> > apart from anything else, DES is a bit elderly now - SSH using 3DES or
> > Blowfish etc...
Riley Williams wrote:
>
> Hi Ion.
>
> >> Shawn, I'd suggest you tell the said sales guy that IF he can
> >> get you the FULL specs TOGETHER WITH permission to freely
> >> distribute them...
>
> > Permission to freely distribute the specs isn't necessary,
> > although it is nice indeed.
On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote:
> Great to hear, but I cannot find anything that backs it up.
> I really want to see the final RFC.
>
> Perhaps you could send me an URL pointing to it?
Usually takes a few days until the RFC editor will announce and
publish
On Thu, 14 Jun 2001, Roger Larsson wrote:
> Hi,
>
> Wait a minute...
>
> Spinlocks on a embedded system? Is it _really_ SMP?
>
The embedded system is not SMP. However, there is definite
advantage to using an unmodified kernel that may/may-not
have been compiled for SMP. Of course spin-locks
I'm attempting to write a piece of code that will validate the physical ethernet
link from a NIC to the nearest router/hub/switch. What I'd like to do is to
send out an ethernet packet addressed to me, bounce it off the
hub/switch/router, and then read it back in. This is all at the ethernet
Guus, there isn't a really official version of it..
At http://pdsf.nersc.gov/linux/ifenslave.c is the last version I
produced, that works with bonding in v2.2 and v2.4 kernels.
Please note; I'm currently bound up in DOE/LBNL contract issues, that
prevent any work on any GPL code on DOE/LBNL
Hi,
Wait a minute...
Spinlocks on a embedded system? Is it _really_ SMP?
What kind of performance problem do you have?
My guess, since you are mentioning spin locks, is that you are
having a latency problem - RT process does not execute/start
quickly enough?
If that is the case you should
Holger Lubitz wrote:
>
> "D. Stimits" proclaimed:
> > down to 1.44 MB. But then it would also have to be self-extracting,
> > which complicates it, so I'm wondering how effective this current
> > compression is, and if a more bzip2-like system would be beneficial as
> > kernels get larger?
>
>
Roger> It does if you are running on a laptop. Then you do not want
Roger> the pages go out all the time. Disk has gone too sleep, needs
Roger> to start to write a few pages, stays idle for a while, goes to
Roger> sleep, a few more pages, ...
That could be handled by a metric which says if the
On Thursday 14 June 2001 10:47, Daniel Phillips wrote:
> On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> > On Wed, 13 Jun 2001, Tom Sightler wrote:
> > > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> > > > After the initial burst, the system should stabilise,
> > > > starting the writeout of
Jeff Garzik writes:
> ok with me. would bus #0 be the system or root bus? that would be my
> preference, in a tiered system like this.
Bus 0 is controller 0, of whatever bus type that happens to be.
If we want to do something special we could create something
like /proc/bus/root or
"David S. Miller" wrote:
>
> Jeff Garzik writes:
> > Thinking a bit more independently of bus type, and with an eye toward's
> > 2.5's s/pci_dev/device/ and s/pci_driver/driver/, would it be useful to
> > go ahead and codify the concept of PCI domains into a more generic
> > concept of bus
bert hubert wrote:
>
>
> I see lots of people only using:
> pthread_create()/pthread_join()
> mutex_lock/unlock
> sem_post/sem_wait
> no signals
>
> My gut feeling is that you could implement this subset in a way that is both
> fast and right - although it would
> Now, if the NIC were to integrate with OpenSSL and offload some of THAT
> donkey work... Just offloading DES isn't terribly useful, as Pavel says:
> apart from anything else, DES is a bit elderly now - SSH using 3DES or
> Blowfish etc... How dedicated is this card? Could it be used to offload
>
On Wed, 13 Jun 2001, Colonel wrote:
>>I really think doing a clean up is worthwhile. Maybe while looking for stuff
>
>You left out all the old non-IDE CDROM drives.
And also UP systems. I've got 2 SMP boxes here now. Why not
remove support for any system with less than 2 processors? ;o)
On Wed, 13 Jun 2001, Daniel wrote:
>i386, i486
>The Pentium processor has been around since 1995. Support for these older
>processors should go so we can focus on optimizations for the pentium and
>better processors.
[SNIP]
Boy, if this isn't a troll, I don't know what is. Obviously
someone
Diff between 2.4.6pre2aa2 and 2.4.6pre3aa1:
-
Moved on top of 2.4.6pre3.
Only in 2.4.6pre2aa2: 00_alpha-compile-swapon-1
Only in 2.4.6pre2aa2: 00_x86-entry.S-fix-1
Merged in 2.4.6pre3.
Only in 2.4.6pre3aa1:
Yo Eddie!
On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
> I checked 2.4.x source code but did not find any code for IPsec. Does
> anyone know that current or latest Linux support IPsec? Or does anyone know
> who is working on this ipv6 issue?
www.freeswan.org
RGDS
GARY
On Wed, Jun 13, 2001 at 01:55:00PM +0200, Miquel Colom Piza wrote:
> I should add 1 giga of RAM to a machine which already has 1 giga. I know
> I will have to configure bigmem support in the kernel (2.2.19). I would
> like to know if this option is considered really stable and tested or I
> can
Alex,
Looking at the back of a Linksys EtherFast 10/100 manual I happen to have,
they describe two different remote wake-up events, Magic Packet and Link
Change. The first one is pretty obvious and is probably not related to
your problems, but the second one may be. The manual states ""Link
I just noticed that file "rc.hints" mentioned in modules.txt
does not exist anywhere in the module utilities package.
I looked in modutils-2.4.2 as documented in Changes.
If rc.hints really doesn't exist, perhaps the sentence in
parenthesis should be removed, since it doesn't assist the reader.
Folks,
I checked 2.4.x source code but did not find any code for IPsec. Does
anyone know that current or latest Linux support IPsec? Or does anyone know
who is working on this ipv6 issue?
Many thanks!
Eddie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Some days ago I posted patch to introduce KDKBDREP ioctl
to i386 keyboard routines. KDKBDREP is defined in linux/kd.h
but now he is used only on m68k. In sparc architectures is used
KIOCSRATE, on i386 -- user-space utility kbdrate and I know
nothing about others. It seems to be better to use one
On Thursday 14 June 2001 17:10, John Stoffel wrote:
> >> The file _could_ be a temporary file, which gets removed before
> >> we'd get around to writing it to disk. Sure, the chances of this
> >> happening with a single file are close to zero, but having 100MB
> >> from 200 different temp files
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> > within glibc, and (2) making these accesses slower since they
> > will be considered O_DIRECT after the change.
>
> and then read/write will return -EINVAL
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
> On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> > within glibc, and (2) making these accesses slower since they
> > will be considered O_DIRECT after the change.
>
> and then read/write will return -EINVAL
Hi,
For this scenario consider a set of 4 page frames.
Frames 0 and 2 are used while frames 1 and 3 are free.
The question is would the bitmap for order 1 be a 1 or 0 for this scenario.
I am not on the list so please cc me on your response.
Thanks in advance.
Ramil J.Santamaria
Toshiba
> Abit KT7A, kernel oops right after boot... :( Can be solved to turning off
> 'Enhance Chip Performance' in the BIOS, but then our chip performance is
> un'Enhance'd, and we can't have that! So back to the K6 kernel.
And praying it doesnt go wrong on you - has it not occurred to you that
David Monniaux wrote:
>I replaced this mobo+Duron with an ASUS A7V133+Athlon, which
>work perfectly well.
>Athlon-optimized kernel, UDMA100, no problem whatsoever.
>
Which is odd, because that's exactly my combination (ASUS A7V133 +
Athlon), and I get crashes with DMA on anything from
On Thu, 14 Jun 2001, Richard Henderson wrote:
> Yes, I saw those. What is the effect of O_NOFOLLOW? To not
> follow symbolic links when opening the file. If you open a
> regular file, in effect nothing happens. Moreover, if these
> opens were not finding files now, the system wouldn't
On 2.4.4, with the aic7xxx driver loaded, if a test unit ready
command (0) is sent to a device which is not loaded via the
generic scsi interface, it results in the driver rolling out
of memory, even though sg may have open file handles for
/dev/sgX, etc. active.
Jeff
-
To unsubscribe
On Thursday 14 June 2001 12:44 pm, David Monniaux wrote:
> So we have two kinds of problems:
> - *certain* 686B motherboards crash if used with an Athlon kernel
> (and it does not depend on the compiler options, rather on hand-made
> Athlon optimizations)
Abit KT7A, kernel oops right after
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote:
> You're missing the point -- it's a bad precedent.
>
> How many kernel forks and patches exist out there on the net?
How many of them are applied to 90% of kernels running out there? How
many of them will get merged eventually? How
David S. Miller writes:
> Jeff Garzik writes:
>> According to the PCI spec it is -impossible- to have more than 256
>> buses on a single "hose", so you simply have to implement multiple
>> hoses, just like Alpha (and Sparc64?) already do. That's how the
>> hardware is forced to implement it...
Andrea Arcangeli wrote:
>
> On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> > They don't hurt but it's also a bad precedent - you don't want to add a
> > ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> > disagree with this patch.
>
> If tux will ever be
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> within glibc, and (2) making these accesses slower since they
> will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is life-threatening.
O_DIRECT like rawio via /dev/raw imposes special
Due to a catastrophic fan short-circuit, I was forced to exchange my
686A-based motherboard for a 686B. Bad idea!
The 686A MB (MSI-6330 aka K7T-Pro) worked perfectly well: no crashes,
UDMA 66. It accepted Athlon-optimized kernels.
The 686B MB (K7T-Lite) crashed if used with DMA (any kind -
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> They don't hurt but it's also a bad precedent - you don't want to add a
> ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> disagree with this patch.
If tux will ever be merged into mainline eventually I don't
I have an athlon system with a iwill kk266 motherboard (via kt133A). I
have a linksys 10/100 PCI ethernet card with wake on lan capabilities.
Anyway, when I shut the PC down it turns off, but refuses to stay off.
Within a minute or two, it turns itself on again. If i run over and
turn it off
Marty Leisner wrote:
>
> I'm read Bovet's "Understand the Linux Kernel"
> and looked at the assembly routine setup_idt...
>
> I noticed the assembly has SYMBOL_NAME
> (its all over the place).
>
> This is define in include/linux/linkage.h
>
> to just:
> #define SYMBOL_NAME(X) X
>
> (this
On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote:
> Question 2: What is the purpose of the code sequence, "repz nop"
Puts iP4 into low power mode.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers
> > Would it be possible to maintain a dirty-rate count
> > for the dirty buffers?
> >
> > For example, we it is possible to figure an approximate
> > disk subsystem speed from most of the given information.
>
> Disk speed is difficult. I may enable and disable swap on any number of
...
> You
On Thu, Jun 14, 2001 at 07:21:22PM +0200, Andrea Arcangeli wrote:
> Richard are you sure we can break O_NOFOLLOW and still expect the machine to
> boot?
[uses in glibc]
Yes, I saw those. What is the effect of O_NOFOLLOW? To not
follow symbolic links when opening the file. If you open a
Andrea Arcangeli wrote:
> Here the third, it registers the tux syscall at for the alpha so other
> people won't use such same syscall for something else (I didn't remove
> the #ifdefs since they don't hurt as they're undefined in mainline).
>
> diff -urN ref/arch/alpha/kernel/entry.S
I __finally__ got back on "the list". They finally fixed the
company firewall!
During my absence, I had the chance to look at some SMP code
because of a performance problem (a few microseconds out of
spec on a 130 MHz embedded system) and I have a question about
the current spin-locks.
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote:
> I just got the email from Richard that he prefers to break O_NOFOLLOW
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOLLOW,
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote:
> is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're
> just screwed as we just need a wrapper anyways to make complex programs like
I just got the email from Richard that he prefers to break O_NOFOLLOW
than to
On Thursday 14 June 2001 08:14, David Luyer wrote:
> Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a
> very small "kernel package" which has a config script, a list of config
> options and the files they depend on and an appropriately tagged CVS tree
> which can then be
Daniel Phillips writes:
> On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> > On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > > This sounds a lot like apt-get, doesn't it?
> >
> > Folks, RTFFAQ, please. URL is attached to the end of each posting.
>
> The FAQ blesses the idea of people
Ok here are my only 2cents, I use some of this hardware that this clean up
would kill, I dont like that thought, and my brand spanking new 1.2ghz
athalon has a single ISA slot and on board parallel / serial ports all of
which are in use so maybee those should be kept, I however I do agree that a
On Thursday 14 June 2001 14:59, Marcelo Tosatti wrote:
> --- linux/mm/page_alloc.c.origThu Jun 14 11:00:14 2001
> +++ linux/mm/page_alloc.c Thu Jun 14 11:32:56 2001
> @@ -453,6 +453,12 @@
> int progress = try_to_free_pages(gfp_mask);
>
There are a number of changes in kernel API visisble to userspace that
are unregistered in 2.4 mainline. I recommend to merge them ASAP to
avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in
sync. They must be
Hi *!
I got this Oops at unmounting a already renamed NFS source.
The umount got a SEGFAULT.
I compiled my 2.4.5 with 2.95.4 20010319 (Debian prerelease).
Regards,
-Gregor
ksymoops 2.4.1 on i686 2.4.5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules
On 12 Jun 2001 12:20:58 -0700, Ken Brownfield wrote:
> Or you could keep your hardware and try the Intel driver, which seems to
> work fine. It only works as a module, though. This might also help
> narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.
I did that, and it
> What kind of network card, and what network driver?
I've got 3 NICs:
ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])
Last modified Nov 1, 2000 by Paul Gortmaker
NE*000 ethercard probe at 0x300: 00 c0 df 64 7b d5
eth0: NE2000 found at 0x300, using IRQ 9.
NE*000 ethercard probe at 0x340:
[EMAIL PROTECTED] wrote:
> SUBJECT:
> Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
>
>
> DRIVER RESULTS:
> Works fine in 2.4.0 kernel.
> Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1).
> Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb).
>
I've seen the exact same problem when trying to compile for sparc. I
might try and fix it myself, as it doesn't seemed to be fixed in the vger
cvs tree, or any other patch for that matter.
Regards,
Aaron
On Tue, 29 May 2001, John wrote:
> Sorry if this is a repeat. Can't find anything on
I'm read Bovet's "Understand the Linux Kernel"
and looked at the assembly routine setup_idt...
I noticed the assembly has SYMBOL_NAME
(its all over the place).
This is define in include/linux/linkage.h
to just:
#define SYMBOL_NAME(X) X
(this wasn't in Bovet's book).
What's the purpose?
Kernel community,
Sorry for intrusion, but I could use some guidance and/or direction in
tracking
down the source of a problem. None of the messages I have seen in the
archives quite seem to match this problem (if there is one please let me
know). I am looking for where or how to dig (deeper)
What kernel are you using?? I used to get it after I switced from a
Linux-supported winmodem to a hardware modem, but the messages are now
mysteriously absent from me logs. If you're running something prior to
2.4.5, I'd say it was fixed there. Also, it could've been fixed in
Alan's tree; I'm
1 - 100 of 323 matches
Mail list logo
