* Re: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-09 23:14 UTC (permalink / raw)
To: lm; +Cc: lm, acahalan, linux-kernel
In-Reply-To: <20030108135109.GA8049@work.bitmover.com>
It is you and the FSF organization which are behind this GNU stuff and
since I've been around since before you started, I'm well aware of
how much work you did and how much was work that was simply assigned
over to the FSF.
Some GNU programs are FSF-copyrighted; when people contribute to them,
we ask them to assign their copyrights to the FSF. Other GNU programs
are not FSF-copyrighted; their developers retain the copyright. For
those programs, the developers decide how to deal with the copyright
on contributions.
So if you count up the code that is FSF-copyrighted, that is just a
portion of the GNU software.
If we remove all the work that you did not do, then
it's vividly clear that Linux is a larger effort.
If you assume that the whole system is Linux, and count every part
that isn't GNU software as part of the "Linux effort", then the part
you count as "Linux" will be much bigger than the GNU software, and
this will "prove" the assumption you started with--that the whole
system is Linux.
In the past 8 years I've seen plenty of arguments that the system is
justly called "Linux". Some are based on inaccurate facts; those are
sometimes clear and rational, just mistaken. But most of them involve
a well-understood logical fallacy, artfully disguised so that it takes
a some thought to find it. With practice, people can become expert at
spotting the fallacies.
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Michael Madore @ 2003-01-09 23:15 UTC (permalink / raw)
To: linux-kernel
I received the following oops while running the Cerberus stress test on
2.4.21-pre3-ac2. The hardware is an ASUS A7N8X single AMD Athlon XP
motherboard with the Nvidia nforce2 chipset. The test was only running
for about 5 minutes when the oops occurred. Running the stress test for
more than 24 hours on 2.4.21-pre3 + 2.4.21-pre3-2420ide-1 was successful.
ksymoops 2.4.4 on i686 2.4.21-pre3-ac2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-pre3-ac2/ (default)
-m /boot/System.map-2.4.21-pre3-ac2 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00000004
c01354e2
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01354e2>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
esi: c1a6e950 edi: 00000000 ebp: 00001550 esp: f79fbbac
ds: 0018 es: 0018 ss: 0018
Process kjournald (pid: 124, stackpage=f79fb000)
Stack: c01415f2 0017a908 c03c9390 f7e7ee40 c03c92e0 00000000 c1a6e950
00000000
c1a6e950 00000020 00001550 c0134ad7 0000052a f79fa000 00000200
00000070
c02fab34 f79fa000 00000000 00000000 00000000 00000020 00000070
00000006
Call Trace: [<c01415f2>] [<c0134ad7>] [<c0134c70>] [<c0134cec>]
[<c01357d0>]
[<c0135a8b>] [<c013b110>] [<c013b36e>] [<c013b26c>] [<c020182c>]
[<c02018b1>]
[<c0201b77>] [<c0201e4f>] [<c013f276>] [<c0201ec1>] [<c0202057>]
[<c013f297>]
[<c0173393>] [<c0172aad>] [<c0171c1f>] [<c01747d6>] [<c0174680>]
[<c01071d6>]
[<c01746a0>]
Code: 89 58 04 89 03 89 53 04 89 59 5c 89 7b 0c ff 41 68 83 c4 1c
>>EIP; c01354e2 <__free_pages_ok+282/2a0> <=====
Trace; c01415f2 <try_to_free_buffers+d2/160>
Trace; c0134ad7 <shrink_cache+387/3b0>
Trace; c0134c70 <shrink_caches+50/90>
Trace; c0134cec <try_to_free_pages_zone+3c/60>
Trace; c01357d0 <balance_classzone+60/200>
Trace; c0135a8b <__alloc_pages+11b/170>
Trace; c013b110 <alloc_bounce_page+10/a0>
Trace; c013b36e <create_bounce+12e/15c>
Trace; c013b26c <create_bounce+2c/15c>
Trace; c020182c <__make_request+ac/5b0>
Trace; c02018b1 <__make_request+131/5b0>
Trace; c0201b77 <__make_request+3f7/5b0>
Trace; c0201e4f <generic_make_request+11f/140>
Trace; c013f276 <__refile_buffer+56/60>
Trace; c0201ec1 <submit_bh+51/70>
Trace; c0202057 <ll_rw_block+177/1c0>
Trace; c013f297 <refile_buffer+17/20>
Trace; c0173393 <__try_to_free_cp_buf+33/40>
Trace; c0172aad <journal_brelse_array+1d/30>
Trace; c0171c1f <journal_commit_transaction+3af/10dd>
Trace; c01747d6 <kjournald+136/210>
Trace; c0174680 <commit_timeout+0/10>
Trace; c01071d6 <kernel_thread+26/30>
Trace; c01746a0 <kjournald+0/210>
Code; c01354e2 <__free_pages_ok+282/2a0>
00000000 <_EIP>:
Code; c01354e2 <__free_pages_ok+282/2a0> <=====
0: 89 58 04 mov %ebx,0x4(%eax) <=====
Code; c01354e5 <__free_pages_ok+285/2a0>
3: 89 03 mov %eax,(%ebx)
Code; c01354e7 <__free_pages_ok+287/2a0>
5: 89 53 04 mov %edx,0x4(%ebx)
Code; c01354ea <__free_pages_ok+28a/2a0>
8: 89 59 5c mov %ebx,0x5c(%ecx)
Code; c01354ed <__free_pages_ok+28d/2a0>
b: 89 7b 0c mov %edi,0xc(%ebx)
Code; c01354f0 <__free_pages_ok+290/2a0>
e: ff 41 68 incl 0x68(%ecx)
Code; c01354f3 <__free_pages_ok+293/2a0>
11: 83 c4 1c add $0x1c,%esp
1 warning issued. Results may not be reliable.
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Richard Stallman @ 2003-01-09 23:13 UTC (permalink / raw)
To: yodaiken; +Cc: billh, mark, lm, linux-kernel, paul, riel
In-Reply-To: <20030108082615.A2271@hq.fsmlabs.com>
Just for the record, "operating system", and "kernel" are used as
synonyms in the research literature.
The term "operating system" has been used in both ways for a long
time. When people speak about the "Linux operating system," most of
them mean the larger GNU/Linux system--they are not using "operating
system" to mean "kernel".
If you use some other term instead of "operating system" for the
larger collection of software, it might remove one cause of confusion.
That won't eliminate the question of what this collection's name
should properly be, or correct the misinformation about how it was
developed and by whom.
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-09 23:13 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E1C3D87.7030605@debian.org>
Calling the system "Linux" denies the GNU Project credit for the GNU
operating system. Most of the people who do that still give us credit
for the specific programs we developed. These words
GNU is not so important in new system. I take gcc and glibc as to be
outside the GNU project.
take a further step: they deny the GNU Project the credit even for GNU
programs (he said, earlier, this is on the grounds that companies have
contributed to them). That's like denying Linus Torvalds the credit
for writing the kernel, Linux, because companies have helped that too.
When people become sufficiently attached to a false conclusion, they
sometimes fabricate ever more extreme falsehoods in order to deny it.
If you insist with such arguments, you risk that someone will rewrite
the basic GNU tools outside the GNU project
Some GNU packages are tools; some are not tools.
People can, of course, write other programs to do the same jobs as GNU
packages. They might do this for many reasons. That message seems to
suggest that people might do this simply to deny the GNU Project the
appreciation that we now get for the work we have done.
Has anyone been so completely warped by hatred of GNU? I don't know,
but it does not really matter. The role of GCC in the development and
popularity of GNU/Linux is a fact of history, and subsequent
developments cannot change it.
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Richard Stallman @ 2003-01-09 23:13 UTC (permalink / raw)
To: billh; +Cc: mark, lm, linux-kernel, paul, riel, billh
In-Reply-To: <20030108115327.GA5020@gnuppy.monkey.org>
There is no such thing as an open source community. The people who
founded the open source movement in 1998, and the people who support
it now, are part of the free software community. (We in the free
software movement built the community in the 80s with our determined
effort.)
These people are legitimate members of our community, and they have a
right to form a movement to promote their views; but their views
didn't build the community, so it should not be named after their
movement.
It's not ment to be a disrespect to you and what you've
done certainly, but it's definitely smashed the scale and scope
of free software projects.
The GNU system, with Linux added, had a great deal of success, but
attributing that success entirely to Linux is a misinterpretation of
the events.
Why do so many people misinterpret the events this way? The practice
of calling the system "Linux" leads to and encourages the
misinterpretation. It leads people to suppose that the most important
part of the development of the system must have occurred when Linus
Torvalds started to work on it.
^ permalink raw reply
* 2.4.21-pre3-ac1/2 and CONFIG_CPU_FREQ failure
From: Richard A Nelson @ 2003-01-09 23:11 UTC (permalink / raw)
To: Linux Kernel Mailing List
If CONFIG_CPU_FREQ is set, and CONFIG_SMP isn't,
./arch/i386/kernel/time.c will fail to compile at line 946:
#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_SMP)
cpufreq_register_notifier(&time_cpufreq_notifier_block,
CPUFREQ_TRANSITION_NOTIFIER);
#endif
There is no definition of time_cpufreq_notifier_block
--
Rick Nelson
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.
(Arno Schaefer's .sig)
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: Bill Davidsen @ 2003-01-09 23:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0301081502270.7688-100000@penguin.transmeta.com>
On Wed, 8 Jan 2003, Linus Torvalds wrote:
> Nope.
>
> System binaries match the kernel. It's as easy as that. So what if 90% of
> the user binaries use 32-bit mode because it's smaller and faster? We're
> talking about a system binary that is _very_ intimate with the kernel.
>
> Just make it a compile-time option and be done with it.
s/the kernel/the booted kernel/ in that. Isn't the reason for wanting this
information because it isn't (necessarily) constant? You could rebuild the
tools that care at boot time, with configuration options, but you still
have to be able to get the information to do the rebuild.
Rather than fight this battle repeatedly, is there some way to make
information like this available at run time, in some more reliable way
than uname, so that useful tools could simply configure themselves.
Depending on the kernel and all the tools to set things like this via
configurations is less robust than providing a way for the applications to
tell for certain the environment. There are not all that many values to
check, so perhaps having a single way to make them all available is
desirable. Like various config options for extra checking in kernel
builds, in some cases reliability justifies the overhead.
I'm not making any suggestings on how to do this, /proc certainly makes
the information readily available to shell/perl scripts, some magic value
to sysconf? Whatever, this is not the first time someone has wanted to be
able to access config information, a good solution in one place might be
appropriate.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Re: NFS as a Cluster File System.
From: Brian Tinsley @ 2003-01-09 23:02 UTC (permalink / raw)
To: Brian Jackson; +Cc: nfs, linux-ha
In-Reply-To: <200301091604.07132.brian@mdrx.com>
[-- Attachment #1: Type: text/html, Size: 1389 bytes --]
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: GertJan Spoelman @ 2003-01-09 23:06 UTC (permalink / raw)
To: Jeff Garzik, linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
On Thursday 09 January 2003 23:27, Jeff Garzik wrote:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
If you look at ftp.suse.com/unitedlinux/1.0/src there is a file
kernel-source....nosrc.rpm which contains all the kernel patches.
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
>
> I'm also surprised the even-more-pro-GPL-than-me people have not jumped
> on UnitedLinux for not distributing source code.
>
> Jeff, looking for useful [rumored] drivers/net patches
--
GertJan
^ permalink raw reply
* Re: Gauntlet Set NOW!
From: Oliver Xymoron @ 2003-01-09 23:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: rms, linux-kernel
In-Reply-To: <3E1D2E12.27417587@digeo.com>
On Thu, Jan 09, 2003 at 12:08:50AM -0800, Andrew Morton wrote:
> Richard Stallman wrote:
> >
> > ...
> > That's not the FSF's view. Our view is that just using structure
> > definitions, typedefs, enumeration constants, macros with simple
> > bodies, etc., is NOT enough to make a derivative work. It would take
> > a substantial amount of code (coming from inline functions or macros
> > with substantial bodies) to do that.
>
> The last part doesn't make a lot of sense.
>
> Use of an inline function is just that: usage. It matters not at
> all whether that function is invoked via inline integration or via
> subroutine call. This is merely an implementation detail within
> the code which provides that function.
>
> Such functions are part of the offered API which have global scope,
> that's all.
I think part of the problem is that 'derived work' here is not
something the FSF or the GPL is really in a position to define. It is
instead the other side of the 'fair use' coin of copyright law. The
question is really how much use of header files is fair use (and
therefore completely independent of copyright) and how much
constitutes a derived work (and therefore subject to the rules of the
GPL)? Only a court can decide.
However, I suspect that 'function' is not a bright line here. There
are certainly plenty of inline functions that are trivial. You can
quote f(x)=x^2 from a paper and not be infringing. Similarly,
most if not all structure definitions are also trivial in the sense
that they're simply lists of names and types - you can copy ingredient
lists, phone directories and the like wholesale and also not be
infringing. You're much more likely to get into trouble with things
like the spinlock or semaphore code which are complex, original, and
fairly unique.
(I first typed that as uniq - enough shell hacking for today)
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* lifecycle of a packet
From: Tony Clayton @ 2003-01-09 22:54 UTC (permalink / raw)
To: netfilter
I've been reading the various docs linked to from netfilter.org, hoping
to figure out the exact order in which a packet traverses the various
tables and chains as it passes through the network stack.
Unfortunately, I couldn't find a definative resource that contained this
information, so I decided to figure it out myself.
I build a quick script to insert LOG rules into every chain of every
table, so that I could log the order in which the tables and chains are
traversed.
Here are my findings, using the three test cases below:
---
TEST A:
Sending http request from masqueraded client, through firewall, to
external box
Request from client
1. mangle: PREROUTING
2. nat: PREROUTING (first packet only)
3. mangle: FORWARD
4. filter: FORWARD
5. mangle: POSTROUTING
6. nat: POSTROUTING (first packet only)
Reply from external box
1. mangle: PREROUTING
2. mangle: FORWARD
3. filter: FORWARD
4. mangle: POSTROUTING
TEST B
Sending http request from masqueraded client to firewall
Request from client
1. mangle: PREROUTING
2. nat: PREROUTING (first packet only)
3. mangle: INPUT
4. filter: INPUT
Reply from firewall
1. mangle: OUTPUT
2. filter: OUTPUT
3. mangle: POSTROUTING
TEST C
Sending http request from firewall to external box:
Request from firewall
1. mangle: OUTPUT
2. nat: OUTPUT (first packet only)
3. filter: OUTPUT
4. mangle: POSTROUTING
5. nat: POSTROUTING (first packet only)
Reply from external box
1. mangle: PREROUTING
2. mangle: INPUT
3. filter: INPUT
---
This is quite interesting, and not at all what I was expecting based on
what I'd read.
I have a list of questions about this behaviour, keeping in mind that
I'm fairly new to iptables/netfilter:
1. Why does only the first packet for a TCP/IP connection seem to pass
through the nat table? Does connection tracking take over if the packet
is (ESTABLISHED,RELATED) and work some magic under the covers?
2. Why do both OUTPUT and POSTROUTING chains get traversed for packets
that the firewall sends out? Is this useful at all?
3. Most of the documents I looked at were fairly old. Is there a
somewhat recent document that perhaps might benefit from including these
tests?
thanks,
Tony
^ permalink raw reply
* Re: Re: NFS as a Cluster File System.
From: Lorn Kay @ 2003-01-09 22:51 UTC (permalink / raw)
To: alanr; +Cc: nfs, linux-ha
>NFS V3 and before have problems with "cache coherency". That is, the
>different nodes in the cluster are not guaranteed to see the same contents.
>
>I think this is supposed to be fixed in v4.
>
>
>--
> Alan Robertson <alanr@unix.sh>
>
>"Openness is the foundation and preservative of friendship.... Let me
>claim from you at all times your undisguised opinions." - William
>Wilberforce
>
I think this can be resolved with the "noac" mount option (prior to V4).
--K
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*
http://join.msn.com/?page=features/virus
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Tom Sightler @ 2003-01-09 23:00 UTC (permalink / raw)
To: Jeff Garzik, linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
Not a source RPM but you can get the source and patches in a tarball at
ftp://ftp.suse.com/pub/people/mantel/next/ those tarballs are what are used
to build the RPMS in that directory and all but certain those RPMS are the
same as the ones recently released for testing to
ftp://ftp.suse.com/pub/suse/i386/supplementary/commercial/Oracle/sles-8/kern
el/
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
I think the above will get you there and if not I'm sure they will provide
the source if asked (which I think meets the letter of the law in the GPL).
Perhaps they just haven't got them posted in a more obvious location yet.
Later,
Tom
^ permalink raw reply
* strange sparc64 -> i586 intermittent but reproducible NFS write errors to one and only one fs
From: Nix @ 2003-01-09 22:56 UTC (permalink / raw)
To: Linux Kernel Development
When I rebooted my systems into 2.4.20 (from 2.4.19), I started seeing
EIO write() errors to files in my ext3 home directory (NFS-mounted,
exported async).
So I knocked up a test program (included below) to try to track the
failing writes down, and got more confused.
The properties of the failing writes that I've been able to determine
thus far are as follows; look out, they're weird as hell:
- the failures are definitely from write(), not open().
- writes from sparc64 to one filesystem, and only one filesystem, on
i586, both running 2.4.20, UDP NFSv3; rquotad and quotas are on, but
I am well within my quota. (quota 3.06, nfs-utils 1.0). Writes to
other filesystems on the same machine, even if they too are using
ext3, even if they too have user quotas for the same user.
What differs between filesystems that work and the one that fails I
can't tell; other FSen *on the same block device* work... (the block
device is an un-RAIDed SCSI disk.)
- local writes to the same filesystem, with the same test program,
never fail.
- writes from another IA32 box (all these boxes are near-clones of
each other as far as software is concerned) to the NFS server box
never fail.
- It happens if I mount the fs with -o soft (my default for all NFS
mounts for robustness-in-the-presence-of-machine-failure reasons),
but also if I mount with -o hard :(( besides, the timeouts happen far
too fast for it to be major timeout expiry that casues the EIOs.
- The failure always occurs for writes that cross the 2^21 byte
boundary, but not all such writes fail. You seem to need to have
done a lot of write()s before, perhaps even starting with O_TRUNC
and write()ing like mad from there on up (the WRITES_PER_OPEN
#define is a way to test that; I've never had a failure for a file
opened with O_APPEND, even if it crossed the 2^21 byte boundary).
- It happens whether _LARGEFILE_SOURCE / _FILE_OFFSET_BITS are
defined or not (I'd be amazed if this affected it, actually, but
it never hurts to check).
- Despite the EIO, the write actually *succeeds* most of the time
(perhaps not all the time; again, I'm not sure yet). In fact...
- It is quite thoroughly inconsistent. If you #define REPRODUCE to 1
in the test program and fill out sizes_to_reproduce[] with a set
of write() sizes that have caused the error in the past, the error
happens again, but not always:
done
done
Input/output error writing buffer size 246392, total size 2253462, iteration 9, writes since open() 9
Sizes used: (278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392)
done
Input/output error writing buffer size 246392, total size 2253462, iteration 9, writes since open() 9
Sizes used: (278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392)
done
Input/output error writing buffer size 246392, total size 2253462, iteration 9, writes since open() 9
Sizes used: (278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392)
done
Input/output error writing buffer size 246392, total size 2253462, iteration 9, writes since open() 9
Sizes used: (278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392)
done
done
done
done
done
done
done
Input/output error writing buffer size 246392, total size 2253462, iteration 9, writes since open() 9
Sizes used: (278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392)
done
(This is pretty much exactly what running the test program looks like if
REPRODUCE is off, as well, except that with it off the failing numbers
differ each time. :) )
The kernel logs are quite empty of anything at the time these errors
occur; there's not even an NFS timeout error.
I'm using gcc-3.2.1 and glibc-2.2.5; the kernel compilers were
egcs64-19980921.1 on the sparc64 side and gcc-2.95.4pre-as-of 2001-10-02
on the i586 side.
Anyway, here's the test program; --std=gnu99 required unless you make a
few tiny changes:
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE 1
#define _GNU_SOURCE 1
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <time.h>
#define MAXSIZE 400000
#define ITERATIONS 10
#define WRITES_PER_OPEN 10
#define FNAME "/home/nix/tmp/test-big-write"
#define REPRODUCE 0
#if REPRODUCE
size_t sizes_to_reproduce[ITERATIONS]={278831, 368095, 327921, 177734, 341464, 74705, 104763, 266303, 313646, 246392};
#endif
int main (void)
{
int foo;
errno=0;
if ((foo=open (FNAME, O_WRONLY | O_CREAT | O_TRUNC | O_LARGEFILE, 0644))<0)
{
perror ("opening file: ");
exit (1);
}
srandom (time (NULL));
int i=0;
int writes_since_open=0;
size_t size;
char *buf = NULL;
size_t sizes_used[ITERATIONS];
for (i=0; i<ITERATIONS; ++i, ++writes_since_open)
{
#ifdef REPRODUCE
size=sizes_to_reproduce[i];
#else
size=(((double)random()/RAND_MAX)*MAXSIZE);
#endif
sizes_used[i]=size;
free (buf);
errno=0;
if ((buf=(char *)calloc (size,1))==NULL)
{
perror ("allocating memory: ");
close (foo);
unlink (FNAME);
exit (2);
}
errno=0;
if ((write (foo, buf, size))<0)
{
struct stat foostat;
fstat (foo, &foostat);
fprintf (stderr,"%s writing buffer size %lu, total size %lli, iteration %i, writes since open() %i\n",strerror (errno),size,foostat.st_size, i, writes_since_open);
fprintf (stderr,"Sizes used: (");
for (int j=0; j<i; ++j)
{
fprintf (stderr, "%lu, ", sizes_used[j]);
}
fprintf (stderr, "%lu)\n", sizes_used[i]);
}
if (writes_since_open > WRITES_PER_OPEN)
{
writes_since_open=0;
close (foo);
if ((foo=open (FNAME, O_WRONLY | O_APPEND | O_LARGEFILE, 0644))<0)
{
perror ("reopening file: ");
exit (1);
}
}
}
close (foo);
unlink (FNAME);
printf ("done\n");
return 0;
}
Change FNAME to point to a file you don't mind losing ;) set ITERATIONS,
MAXSIZE and WRITES_PER_OPEN such that some of the
randomly-sized-sets-of-writes will go over the 2^21-byte limit, and see
if you can reproduce it.
Here's the .config on the sparc64 side (there's more below this, scroll
down):
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_BBC_I2C=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SPARC64=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_SBUS=y
CONFIG_SBUSCHAR=y
CONFIG_BUSMOUSE=y
CONFIG_SUN_MOUSE=y
CONFIG_SERIAL=y
CONFIG_SUN_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SUN_KEYBOARD=y
CONFIG_SUN_CONSOLE=y
CONFIG_SUN_AUXIO=y
CONFIG_SUN_IO=y
CONFIG_PCI=y
CONFIG_RTC=y
CONFIG_PCI_NAMES=y
CONFIG_SUN_OPENPROMFS=m
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_SPARC32_COMPAT=y
CONFIG_BINFMT_ELF32=y
CONFIG_BINFMT_ELF=m
CONFIG_BINFMT_MISC=m
CONFIG_SOLARIS_EMUL=m
CONFIG_ENVCTRL=m
CONFIG_WATCHDOG_CP1XXX=m
CONFIG_PROM_CONSOLE=y
CONFIG_SUN_OPENPROMIO=m
CONFIG_SUN_MOSTEK_RTC=y
CONFIG_SAB82532=y
CONFIG_OBP_FLASH=m
CONFIG_SUN_AURORA=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_RARP=y
CONFIG_IP_MROUTE=y
CONFIG_SYN_COOKIES=y
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=10
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_HAPPYMEAL=y
CONFIG_SUNBMAC=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=1024
CONFIG_QUOTA=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_UFS_FS=m
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_SUN_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
And here's the .config on the i586 side:
CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M586MMX=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_MCE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_X86_TSC=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
CONFIG_APM=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=10
CONFIG_BLK_DEV_SR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_PLIP=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=y
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_RTC=y
CONFIG_QUOTA=y
CONFIG_REISERFS_FS=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS=m
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_YM3812=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
Modules loaded, i586 side:
Module Size Used by Not tainted
opl3 11040 0
sb 7348 1
sb_lib 32334 0 [sb]
uart401 6020 0 [sb_lib]
sound 51756 1 [opl3 sb_lib uart401]
nls_iso8859-1 2844 1 (autoclean)
nls_cp437 4348 1 (autoclean)
(No modules are loaded on the sparc64 side.)
Anyone got any ideas? This is really, really weird.
--
`I knew that there had to be aliens somewhere in the universe. What I
did not know until now was that they read USENET.' --- Mark Hughes,
on those who unaccountably fail to like _A Fire Upon The Deep_
^ permalink raw reply
* Re: 2.5.54 problem with IDE ICH4 and aic7xxx -> fixed in 2.5.55
From: Gregoire Favre @ 2003-01-09 22:56 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030105165441.GA8215@ulima.unil.ch>
Hello,
I don't have this very long boot delay under 2.5.55 ;-)
Thank you very much,
Grégoire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:greg@ulima.unil.ch
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Cort Dougan @ 2003-01-09 22:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
Have you actually asked for the source?
} Anybody know where the source rpm for UnitedLinux kernel is?
} [to be distinguished from kernel-source rpm]
}
} AFAICS they are not distributing source code to their published kernel
} binaries... which is a very obvious GPL violation.
}
} I'm also surprised the even-more-pro-GPL-than-me people have not jumped
} on UnitedLinux for not distributing source code.
}
} Jeff, looking for useful [rumored] drivers/net patches
}
}
}
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Philip Dodd @ 2003-01-09 22:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
Jeff Garzik wrote:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
>
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
>
> I'm also surprised the even-more-pro-GPL-than-me people have not jumped
> on UnitedLinux for not distributing source code.
>
> Jeff, looking for useful [rumored] drivers/net patches
>
With all due respect, I believe that the terms of the GPL only require
them to make it available to people who have the binaries, and only then
upon request.
What exactly do you mean by "are not distributing"?
Cheers,
Philip
^ permalink raw reply
* Re: [OCF]re: [gfs-users]Cluster Aware MD Driver
From: Daniel McNeil @ 2003-01-09 22:44 UTC (permalink / raw)
To: ocf; +Cc: Steven Dake, opengfs-users, linux-raid
In-Reply-To: <20030106165353.CNUQ901.imf00bis.bellsouth.net@marsha>
Many of us are interested in cluster-aware volume management.
AFAIK, OCF has not specified anything at this layer yet.
On Mon, 2003-01-06 at 08:49, Greg Freemyer wrote:
> Steven,
>
> I have posted this to the OpenCF (Open Cluster Framework) list as well.
> <ocf@lists.community.tummy.com>
>
> They are trying to come up with a common set of cluster components and APIs
> for Linux clusters. Several of the major cluster solution teams are
> participating in the effort.
I agree. OCF is trying to come up with a common set of cluster APIs.
>
> In particular, your clusterips extension and election logic is something I
> believe they have existing draft proposals to handle. They have definitely
> had very detailed discussions on how to define these APIs.
AFAIK, OCF has no existing proposals for these. The membership
API can potentially help by providing the list of cluster members
in a well defined order on all nodes. The event API could be
used for delivering MD state transition on its own "topic."
So far, the event API only describes how to subscribe and receive
events, but it does not (yet) describe how to publish/send events.
Another option is group messaging, which has not yet been defined
either.
Daniel
>
> I don't think they have much implementation code written yet, but I do
> think they have include files that match their draft proposals.
>
> Using their .h files would give you a solid starting point, and make
> it likely that you will be OCF compliant when they start releasing specs.
>
> Greg Freemyer
>
> >> Brian,
>
> >> The way to fix this problem is to enable the MD layer and MD tools to be
> >> cluster aware. I hope sometime before March 03 to have this
> >> functionality implemented in 2.4 and mdadm 1.0.1.
>
> >> During startup, a userland daemon runs which opens a TCP port. Then the
> >> daemon attempts to connect to a list of other servers in a configuration
> >> file (/etc/clusterips). On each connection, a master of the cluster is
> >> elected by an election algortihm. Once the daemon makes connections, it
> >> culls its file descriptor list such that it only has one connection per
> >> server to each other server. Whenever a state change occurs (raid set
> >> faulty, raid array failed, raid hot added, raid hot removed, raid start,
> >> raid stop, etc) the state change is transmitted via the server to all
> >> other server nodes. When the server receives a state change message, it
> >> will handle appropriately by using the md ioctls to update its internal
> >> state. There are more complications, such as heartbeating to detect
> >> dead nodes, etc. All of this keeps the arrays in sync across the entire
> >> cluster. The big changes here are to the mdadm package to use the local
> >> server to execute operations and to create a server which processes the
> >> state changes and executes the appropriate MD layer ioctls.
>
> >> The question you might be asking is, how do you protect from each server
> >> overwritting similiar data such as the superblock or resync data. The
> >> trick is to add an ioctl to the MD layer that turns writes on or off.
> >> During master election above, the master will turn its writes on. All
> >> non-masters will turn their writes off before any RAID arrays are
> >> started. Also, resyncs have to be communicated across the cluster such
> >> that /proc/mdstat displays correct information so I believe an ioctl
> >> will have to be added to indicate this and allow resync from a specific
> >> spot in case the current master dies in a resync. The changes to the MD
> >> layer should be fairly minimal and noninvasive and also work well for
> >> non-cluster configurations. The writes will default to on to ensure
> >> that non-clusters work properly even with autostart.
>
> >> The only downside of this approach is that RAID autostart can no longer
> >> be used. The only solution to supporting that feature for clusters is
> >> to write all of the above userspace code into the kernel which would be
> >> a big pain and likely not accepted into the mainline.
>
> >> Thanks
> >> -steve
>
> >> Brian Jackson wrote:
>
> >> > At the moment if one node goes down, the rest of the nodes will
> >> > continue to run as expected. The only single point of failure from a
> >> > node point of view is the lock server. Dominik is working on
> >> > integrating the OpenDLM to get rid of that single point of failure. If
> >> > one disk in the shared storage dies, that will bring you down. I have
> >> > tried to stack pool on top of software raid, but the MD driver doesn't
> >> > play well with clusters so that won't work. We are trying to figure
> >> > out a way to fix this, but when GFS was originally designed the pool
> >> > driver(that does GFS's volume management) only had stripping(raid0). I
> >> > hope this answers your questions.
> >> > --Brian Jackson
> >> > P.S. I am not sure, but it sounds like you have some misconception
> >> > about how OpenGFS works. It does not use the disks on your nodes. It
> >> > uses some kind of shared storage.
> >> > Vittorio Ballestra writes:
> >> >
> >> >> Escuse me if this is a stupid or repetead question, I've searched
> >> >> into the docs (?) and the mailinglists but I'm not able to understand
> >> >> if openGFS has some sort of fault-tollerance.
> >> >> This are my doubts :
> >> >> What happens if one host is down or one disk on one host is down ?
> >> >> Will the entire openGFS filesystem be down ? If one disk is broken
> >> >> and its content corrupted, will the whole openGFS be corrupted ?
> >> >> If openGFS is not supporting any kind of fault-tollerance, can one
> >> >> use raid disks on each node ?
> >> >> Thanks,
> >> >> V
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Bill Davidsen @ 2003-01-09 22:50 UTC (permalink / raw)
To: Andrew McGregor
Cc: Fabio Massimo Di Nitto, Wichert Akkerman, netdev, linux-kernel
In-Reply-To: <78180000.1042055993@localhost.localdomain>
On Thu, 9 Jan 2003, Andrew McGregor wrote:
> Probably on the server's side it got an ICMP Host Unreachable or two as
> some router updated its tables, and decided to close the connection. The
> FIN jumped the queue in one/several of the routers in the path, so it got
> reordered relative to the data. This would imply that the router in
> question had its route to you back by the time the FIN got there.
>
> Wierd, but far from impossible.
Nothing is impossible with routers, including sending ICMP packets using
different routing than TCP (and doing odd things with UDP as well).
Sometimes ICMP will be sent over a low bandwidth link with hopefully less
latency. The phrase "the less traveled way" comes to mind.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: [PATCH][TRIVIAL] checksum.h header fixes for 2.4
From: Eric Weigle @ 2003-01-09 22:52 UTC (permalink / raw)
To: Alan Cox; +Cc: Marcelo Tosatti, Trivial Patch Monkey, Linux Kernel Mailing List
In-Reply-To: <1042153307.28469.15.camel@irongate.swansea.linux.org.uk>
> On Thu, 2003-01-09 at 20:06, Eric Weigle wrote:
> > I'm making a loadable module that will send IP packets; and need to
> > do IP
> > checksums. Unfortunately a simple #include of checksum.h fails
> > because that
> > file does not itself include the headers required to compile
> > correctly.
> > Several of the arch-specific files are this way.
> Include the other files you need first. The kernel headers are not
> really intended to always include everything you might want. That
> rapidly becomes unmanagable
These files include the ipv6 and VERIFY_* stuff unconditionally. _EVERY_
caller must know to include the in6.h/uaccess.h header files simply to get
it to compile. This is what the net/checksum.h file does. There are 31 files
including <asm/checksum.h> directly, and all of these _must_ track down the
dependencies by hand.
This isn't a _want_, it's an unconditional requirement. The files are broken.
<flamebait>
Of course, it's really C's bug, by doing brain-dead textual inclusion.
Trust me, I know the difficulties in managing #includes.
</flamebait>
-Eric
--
------------------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Jeff Garzik @ 2003-01-09 22:46 UTC (permalink / raw)
To: Jeff V. Merkey; +Cc: linux-kernel
In-Reply-To: <20030109164534.A6653@vger.timpanogas.org>
On Thu, Jan 09, 2003 at 04:45:34PM -0700, Jeff V. Merkey wrote:
>
>
> Jeff,
>
> They only have to provide it if someone asks for it. I suggest sending them
> a request asking for it to be disclosed and copy LKML on the request.
I had hoped that a member in good standing of the Linux community would
not put such roadblocks in place. :(
> Jeff
> (a great name to have)
agreed :)
Jeff
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Linus Torvalds @ 2003-01-09 22:16 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Benjamin Herrenschmidt, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030110010917.A693@localhost.park.msu.ru>
On Fri, 10 Jan 2003, Ivan Kokshaysky wrote:
>
> Note that in most cases PCI-PCI bridges can be safely excluded from
> pci_read_bases() simply because they have neither regular BARs nor
> ROM BAR (even though PCI spec allows that).
This might be a good approach to take regardless - don't read pci-pci
bridge BAR (or host-bridge BAR's for that matter), simply because
(a) bridges are more "interesting" than regular devices, and disabling
part of them might be a stupid thing.
(b) we're generally not really interested in the end result anyway
Hmm?
Linus
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Ivan Kokshaysky @ 2003-01-09 22:40 UTC (permalink / raw)
To: Grant Grundler
Cc: Ivan Kokshaysky, Linus Torvalds, Alan Cox, Paul Mackerras,
Benjamin Herrenschmidt, Eric W. Biederman, davidm,
Linux Kernel Mailing List, greg
In-Reply-To: <20030109195231.GB16698@cup.hp.com>
On Thu, Jan 09, 2003 at 11:52:31AM -0800, Grant Grundler wrote:
> Can the EXPORT_SYMBOL(pci_scan_bus) be removed now?
No, I think. Looks like it's used by ibm hotplug which can be a module.
Ivan.
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: John Adams @ 2003-01-09 22:41 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1042153890.28469.21.camel@irongate.swansea.linux.org.uk>
On Thursday 09 January 2003 06:11 pm, Alan Cox wrote:
>
> and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
> who know what her networking related patent is on)
Google makes this too easy.
http://www.german-way.com/cinema/lamarr.html
i
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: Linus Torvalds @ 2003-01-09 22:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1042153388.28469.17.camel@irongate.swansea.linux.org.uk>
In article <1042153388.28469.17.camel@irongate.swansea.linux.org.uk>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>Note btw that the support ends rather abruptly on the console input side.
>There is no support for 3 or 4 byte utf8 input sequences and the delete
>key code in the kernel has no understanding of or support for UTF8
>deletion behaviour
UTF8 delete behaviour should be pretty trivial to add. It's liketly to
be more involved than simply adding a
/* multi-char UTF8 thing? Continue until we hit the first one */
if (tty->utf8 && (c & 0x80) && !(c & 0x40))
continue;
to the loop in n_tty.c: eraser(), but it might not be _much_ more than
that.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.