* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Linus Torvalds @ 2003-01-09 23:35 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: <20030110021904.A15863@localhost.park.msu.ru>
On Fri, 10 Jan 2003, Ivan Kokshaysky wrote:
>
> PCI-PCI, PCI-ISA bridges - probably, but not host bridges. On x86 they
> often have quite a few BARs, like AGP window, AGP MMIO, power management
> etc., which we cannot ignore.
Oh, but we _can_ ignore it.
All those things are stuff that if the kernel doesn't use them, the kernel
doesn't even need to know they are there.
Sure, if we support AGP, we need to see the aperture size etc, but then
we'd have the AGP driver just do the "pci_enable_dev()" thing to work it
out.
The only real reason to worry about BAR sizing is really to do resource
discovery in order to make sure that out bridges have sufficiently big
windows for the IO regions. Agreed?
And that should be a non-issue especially on a host bridge, since we
almost certainly don't want to reprogram the bridge windows there anyway.
So I'd like to make the _default_ be to probe the minimal possible,
_especially_ for host bridges. Then, the PCI quirks could be used to
expand on that default.
Linus
^ permalink raw reply
* Re: [PATCH/RFC] New module refcounting for net_proto_family
From: David S. Miller @ 2003-01-09 23:53 UTC (permalink / raw)
To: maxk; +Cc: linux-kernel
In-Reply-To: <5.1.0.14.2.20030109124152.07a18e28@mail1.qualcomm.com>
From: Max Krasnyansky <maxk@qualcomm.com>
Date: Thu, 09 Jan 2003 12:45:37 -0800
Those guys will have to bump mod refcount themselves then.
sock_init_data() and sock_graft() have access to ->owner field but sk_alloc()
doesn't. So we either have to change sk_alloc() API or make call to
sock_init_data()/sock_graft() a must. Any other suggestions ?
This isn't rocket science, just make a new sock_foo() interface
that merely does the module owner setup.
^ permalink raw reply
* Minature NUMA scheduler
From: Martin J. Bligh @ 2003-01-09 23:54 UTC (permalink / raw)
To: Erich Focht, Michael Hohnbaum, Robert Love, Ingo Molnar
Cc: linux-kernel, lse-tech
I tried a small experiment today - did a simple restriction of
the O(1) scheduler to only balance inside a node. Coupled with
the small initial load balancing patch floating around, this
covers 95% of cases, is a trivial change (3 lines), performs
just as well as Erich's patch on a kernel compile, and actually
better on schedbench.
This is NOT meant to be a replacement for the code Erich wrote,
it's meant to be a simple way to get integration and acceptance.
Code that just forks and never execs will stay on one node - but
we can take the code Erich wrote, and put it in seperate rebalancer
that fires much less often to do a cross-node rebalance. All that
would be under #ifdef CONFIG_NUMA, the only thing that would touch
mainline is these three lines of change, and it's trivial to see
they're completely equivalent to the current code on non-NUMA systems.
I also believe that this is the more correct approach in design, it
should result in much less cross-node migration of tasks, and less
scanning of remote runqueues.
Opinions / comments?
M.
Kernbench:
Elapsed User System CPU
2.5.54-mjb3 19.41s 186.38s 39.624s 1191.4%
2.5.54-mjb3-mjbsched 19.508s 186.356s 39.888s 1164.6%
Schedbench 4:
AvgUser Elapsed TotalUser TotalSys
2.5.54-mjb3 0.00 35.14 88.82 0.64
2.5.54-mjb3-mjbsched 0.00 31.84 88.91 0.49
Schedbench 8:
AvgUser Elapsed TotalUser TotalSys
2.5.54-mjb3 0.00 47.55 269.36 1.48
2.5.54-mjb3-mjbsched 0.00 41.01 252.34 1.07
Schedbench 16:
AvgUser Elapsed TotalUser TotalSys
2.5.54-mjb3 0.00 76.53 957.48 4.17
2.5.54-mjb3-mjbsched 0.00 69.01 792.71 2.74
Schedbench 32:
AvgUser Elapsed TotalUser TotalSys
2.5.54-mjb3 0.00 145.20 1993.97 11.05
2.5.54-mjb3-mjbsched 0.00 117.47 1798.93 5.95
Schedbench 64:
AvgUser Elapsed TotalUser TotalSys
2.5.54-mjb3 0.00 307.80 4643.55 20.36
2.5.54-mjb3-mjbsched 0.00 241.04 3589.55 12.74
-----------------------------------------
diff -purN -X /home/mbligh/.diff.exclude virgin/kernel/sched.c mjbsched/kernel/sched.c
--- virgin/kernel/sched.c Mon Dec 9 18:46:15 2002
+++ mjbsched/kernel/sched.c Thu Jan 9 14:09:17 2003
@@ -654,7 +654,7 @@ static inline unsigned int double_lock_b
/*
* find_busiest_queue - find the busiest runqueue.
*/
-static inline runqueue_t *find_busiest_queue(runqueue_t *this_rq, int this_cpu, int idle, int *imbalance)
+static inline runqueue_t *find_busiest_queue(runqueue_t *this_rq, int this_cpu, int idle, int *imbalance, unsigned long cpumask)
{
int nr_running, load, max_load, i;
runqueue_t *busiest, *rq_src;
@@ -689,7 +689,7 @@ static inline runqueue_t *find_busiest_q
busiest = NULL;
max_load = 1;
for (i = 0; i < NR_CPUS; i++) {
- if (!cpu_online(i))
+ if (!cpu_online(i) || !((1 << i) & cpumask) )
continue;
rq_src = cpu_rq(i);
@@ -764,7 +764,8 @@ static void load_balance(runqueue_t *thi
struct list_head *head, *curr;
task_t *tmp;
- busiest = find_busiest_queue(this_rq, this_cpu, idle, &imbalance);
+ busiest = find_busiest_queue(this_rq, this_cpu, idle, &imbalance,
+ __node_to_cpu_mask(__cpu_to_node(this_cpu)) );
if (!busiest)
goto out;
---------------------------------------------------
A tiny change in the current ilb patch is also needed to stop it
using a macro from the first patch:
diff -purN -X /home/mbligh/.diff.exclude ilbold/kernel/sched.c ilbnew/kernel/sched.c
--- ilbold/kernel/sched.c Thu Jan 9 15:20:53 2003
+++ ilbnew/kernel/sched.c Thu Jan 9 15:27:49 2003
@@ -2213,6 +2213,7 @@ static void sched_migrate_task(task_t *p
static int sched_best_cpu(struct task_struct *p)
{
int i, minload, load, best_cpu, node = 0;
+ unsigned long cpumask;
best_cpu = task_cpu(p);
if (cpu_rq(best_cpu)->nr_running <= 2)
@@ -2226,9 +2227,11 @@ static int sched_best_cpu(struct task_st
node = i;
}
}
+
minload = 10000000;
- loop_over_node(i,node) {
- if (!cpu_online(i))
+ cpumask = __node_to_cpu_mask(node);
+ for (i = 0; i < NR_CPUS; ++i) {
+ if (!(cpumask & (1 << i)))
continue;
if (cpu_rq(i)->nr_running < minload) {
best_cpu = i;
^ permalink raw reply
* Linux/Hurd vs GNU/Linux (was Re: Nvidia and its choice to read the GPL "differently")
From: Vlad@Vlad.geekizoid.com @ 2003-01-10 0:01 UTC (permalink / raw)
To: rms; +Cc: Lkml (E-mail)
In-Reply-To: <E18WlsS-0000Xp-00@fencepost.gnu.org>
Your last sentence there is telling. Hurd is both GNU and Linux, yet you
don't seem to be interested in giving credit where credit is due. If you
can't do that, you don't have any credibility left.
-----Original Message-----
From: Richard Stallman [mailto:rms@gnu.org]
Sent: Thursday, January 09, 2003 5:14 PM
To: Vlad@Vlad.geekizoid.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Nvidia and its choice to read the GPL "differently"
I would expect that both GNU code and Linux make up smaller fractions
of current GNU/Linux distros, because so many other programs have been
added over the years. It's a good thing that so many free programs
have been developed, and that so many people have contributed, but
this doesn't change the system's history. It started out as the
combination of GNU and Linux.
^ permalink raw reply
* Re: Re: NFS as a Cluster File System.
From: Donavan Pantke @ 2003-01-09 23:45 UTC (permalink / raw)
To: Lorn Kay, lmb, nfs, linux-ha
In-Reply-To: <F43H06Ym8Es5FEnoLH80000317f@hotmail.com>
On Thursday 09 January 2003 18:13, Lorn Kay wrote:
>
> Sorry, still confused about what a "CFS" really is. In "In Search Of
> Clusters" Gregory Pfister takes the position that a distributed file sy=
stem
> is what he calls a valid "single system image" file system, what I woul=
d
> take to mean a cluster file system (though he doesn't use those words).
>
> I guess you are saying a clustered file system isn't necessarily suppor=
ting
> a cluster of application servers but is itself stored on a cluster. (A
> single server can be the only server using a cluster file system.) ?
>
=09Typically, the term CFS refers to a set of servers that work on the sa=
me=20
storage at the same time. What this means is that my central storage syst=
em=20
could have multiple servers mounting a file system at the same time.=20
Currently, preforming this is still in development; the difficulty is tha=
t=20
all nodes have to tell each other in some way about exactly what they're=20
doing to keep from corrupting the data on storage. Until this matures for=
=20
production use (It's my presonal opinion that there are still too many bu=
gs=20
in current implementations), the next best answer is for a highly availab=
le=20
cluster of servers that handle data requests. This is where NFS comes in.=
=20
Although I agree that in some applications this isn't workable with NFS, =
I've=20
found it to be quite a boon. At my workplace, we have a great many machin=
es=20
accessing common data. We started with a M$ cluster using SMB, but the na=
ture=20
of the protocol means that when the cluster fails, each client can't acce=
ss=20
currently open files. they have to close and re-open each handle. The=20
stateless nature of NFSv3 and v2 is stateless. This means that a cluster =
can=20
fail over and clients simply pause requests untile the filesystem is=20
accessible again. Not a good soution for applications with very high resp=
onse=20
time requirements, but it works for us. BTW: When describing clusters her=
e=20
I'm referring to a active-passive pair of servers where resources move wh=
en a=20
failure has been detected.
=09Donavan Pantke
-------------------------------------------------------
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: Nvidia and its choice to read the GPL "differently"
From: Matthias Andree @ 2003-01-09 23:45 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E18Wlrc-0000Ph-00@fencepost.gnu.org>
On Thu, 09 Jan 2003, Richard Stallman wrote:
> 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.
Richard, some people are going to offer this "GNU/" attribution, some
won't. I belong to the latter group although I recognize what the GNU
project has achieved so far. It's a fairness issue, as has been pointed
out. If we need to credit, then we need to credit every major
contributor, and that's, as has been pointed out, a term that's pretty
unusable to name that thing. You want Linux to subordinate under GNU?
Fine. What sold GNU to the masses? Linux. They're friends. Still, you
don't make friends change their names. Now finish that thread.
> 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.
There is not hatred of GNU. There is alienation by your horrible waste
of time and energy. This is the wrong forum, this is only full of people
who make ONE SINGLE component of what YOU want to be named GNU/Linux.
You're about to get GNU credited but neglect all the other major
contributors, XFree86 has been named, BSD is one.
GNU code borrows interfaces from Solaris (and then does it wrong, for
example the GNU libc name service switch is broken in that it does not
retry NIS queries and then reports temporary errors through interfaces
that cannot return temporary conditions such as getpwnam -- no way to
place TRYAGAIN=forever into /etc/nsswitch.conf with GNU glibc, but
required for reliable operation and possible to configure on Solaris). I
ask you to rename all occurrences of Name Service Switch to Sun
Microsystems Solaris Name Service Switch. Add [tm] and ® symbols as
appropriate. Solaris gave you the ideas of NSS. So credit Sun.
And now get this bloody discussion off-list.
--
Matthias Andree
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Jean-Daniel Pauget @ 2003-01-09 23:37 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <200301090139.h091d9G26412@devserv.devel.redhat.com>
I had some strange bug using 2.4.21pre3-ac2 :
at rebooting after a freeze (my machine freezes from time to time
whatever the kernel is, I'm still diging that point)
fsck.ext2 was not able to finish checking my /home (59Gb), it
systematically got a signal 11 (I tried several times).
rebooting using my previous kernel (2.4.20 with a minor patch for the
i845G AGP mess-up) was enough so that the fsck worked fine at the first
attempt with this kernel.
this triggers two questions :
o is the new piix-ide faulty ?
o are 256 Mb of memory enough for fscking a 58Gb partition ?
about signal 11, I tested my machine with several concurent kernel
built with no signal 11 before (with 2.4.20 and prior)
the machine is an ASUS P4PE motherboard, 2,4GHz PIV 256Mb
and a nvidia Ge4-Ti4200. (at signal 11, the nvidia tainted module was
not loaded yet :)
thanks in advance for any enlightment...
here-below, the lspci and /proc/pci...
--
Quand les plombs pêtent : « Ðïsjüñ£t.¢€× »
--
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4200] (rev a3)
02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
02:05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)
--
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 2).
Prefetchable 32 bit memory at 0xf0000000 [0xf7ffffff].
Bus 0, device 1, function 0:
PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge (rev 2).
Master Capable. Latency=64. Min Gnt=8.
Bus 0, device 29, function 0:
USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 2).
IRQ 11.
I/O at 0xd800 [0xd81f].
Bus 0, device 29, function 1:
USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 2).
IRQ 5.
I/O at 0xd400 [0xd41f].
Bus 0, device 29, function 2:
USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 2).
IRQ 9.
I/O at 0xd000 [0xd01f].
Bus 0, device 29, function 7:
USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 2).
Non-prefetchable 32 bit memory at 0xe5800000 [0xe58003ff].
Bus 0, device 30, function 0:
PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 130).
Master Capable. No bursts. Min Gnt=6.
Bus 0, device 31, function 0:
ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 2).
Bus 0, device 31, function 1:
IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 2).
IRQ 9.
I/O at 0x0 [0x7].
I/O at 0x0 [0x3].
I/O at 0x0 [0x7].
I/O at 0x0 [0x3].
I/O at 0xf000 [0xf00f].
Non-prefetchable 32 bit memory at 0x10000000 [0x100003ff].
Bus 0, device 31, function 5:
Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 2).
IRQ 10.
I/O at 0xa800 [0xa8ff].
I/O at 0xa400 [0xa43f].
Non-prefetchable 32 bit memory at 0xe4000000 [0xe40001ff].
Non-prefetchable 32 bit memory at 0xe3800000 [0xe38000ff].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4200] (rev 163).
IRQ 11.
Master Capable. Latency=248. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xe6000000 [0xe6ffffff].
Prefetchable 32 bit memory at 0xe8000000 [0xefffffff].
Prefetchable 32 bit memory at 0xe7800000 [0xe787ffff].
Bus 2, device 3, function 0:
FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 128).
IRQ 5.
Master Capable. Latency=32. Max Lat=32.
Non-prefetchable 32 bit memory at 0xe5000000 [0xe50007ff].
I/O at 0xb800 [0xb87f].
Bus 2, device 5, function 0:
Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 2).
IRQ 10.
Master Capable. Latency=64. Min Gnt=64.
Non-prefetchable 64 bit memory at 0xe4800000 [0xe480ffff].
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: David D. Hagood @ 2003-01-09 23:40 UTC (permalink / raw)
To: rms; +Cc: linux-kernel
In-Reply-To: <E18Wlrd-0000Po-00@fencepost.gnu.org>
Richard Stallman wrote:
> If you use some other term instead of "operating system" for the
> larger collection of software, it might remove one cause of confusion.
Might I suggest the term "operation environment" - thus things like the
kernel, and "got-to-have-it-or-we-no-go" bits like libc and the dynamic
loader system are "the operating system", and
"we-can-live-without-it-but-who-wants-to" bits like the browser, editor,
HTTP/FTP/etc. libraries are part of the "operating environment".
> 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.
>
OT: Thank you, Richard, for what you've done for the industry. My first
exposure to Gnu was on the Atari ST, where an individual sent me GCC on
about 20 floppy disks. Been hooked ever since - I've often thought the
GPL would make a great "Wonder of the World" in FreeCiv...
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Larry McVoy @ 2003-01-09 23:39 UTC (permalink / raw)
To: Richard Stallman; +Cc: Vlad@Vlad.geekizoid.com, linux-kernel
In-Reply-To: <E18WlsS-0000Xp-00@fencepost.gnu.org>
On Thu, Jan 09, 2003 at 06:14:20PM -0500, Richard Stallman wrote:
> GNU, the system we were developing, was most of the early GNU/Linux
> system in 1992. GNU in 1992 included non-GNU packages such as X11,
> and TeX.
Wow. That might be one for the quotes file:
"GNU ... was of the early GNU/Linux system. GNU ... included non-GNU"
Well, that certainly explains a lot. If you define GNU as "anything
which might be found on a Linux distro including non-GNU packages",
your position starts to make a certain twisted sense. Only one problem
with that: if it wasn't GNU, it wasn't GNU, which means, Richard, you
are crackin' smoke and may need a vacation. 19 years of hard effort is
a long time, have you considered retirement? You've certainly earned it.
Oh, by the way, have you updated the GNU kernel pages to reflect the new
proper name: Linux/Hurd? I'd really appreciate it if you could get to that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Hardware IP [was: Re: Why is Nvidia given GPL'd code ...]
From: Ken Ryan @ 2003-01-09 23:35 UTC (permalink / raw)
To: Linux Kernel Mailing List
Helge Hafting (helgehaf@aitel.hist.no) wrote:
>Perhaps their driver contains some IP. But I seriously doubt the
>programming specs for their chips contains such secrets. It is
>not as if we need the entire chip layout - it is basically
>things like:
>
>"To achieve effect X, write command code 0x3477 into register 5
>and the new coordinates into registers 75-78. Then wait 2.03ms before
>attempting to access the chip again..."
>
>Something is very wrong if they _can't_ release that sort of
>information.
>Several other manufacturers have no problem with this.
Note I have absolutely no knowledge of the internals of NVidia chips,
though I have had exposure to others (and designed two).
First, there is lots of closed IP blocks available for ASICs. Things
like PCI interfaces, memory controllers, embedded processors, etc.
Generally they have very strict NDAs. Generally it is possible to design
a clean-room equivalent to substitute for something licensed, but with the
pace of development required to stay competitive in the graphics business
it's unlikely NVidia can spare the dozens of engineers necessary to design
and validate an IP block just so they can opensource drivers. They might
save some royalties, but with royalties spread over a bazillion shipped
chips it's unlikely to be significant.
Second, a device like a GPU is extremely complex. Write-wait-write
works fine for a printer port, but a GPU amounts to an entire
processing subsystem in its own right, with all that implies (see
SMP, distributed processing, etc. and all the joy associated with those).
Especially modern high-performance GPUs which have on-chip resources for
coordinate transforms and programmable shaders, the complexity far exceeds
that of the entire rest of the computer.
Third, even if it weren't for IP licensing, the programming information
for a chip can be very sensitive.
For example: one aspect of a GPU which is extremely sensitive to any
graphics vendor is framebuffer architecture. How are the color components
stored, how is data read for texture mapping vs. video vs. Z buffer,
how does it make effective use of DRAM devices (which have extremely
different behavior when accessed linearly vs. randomly), how is data
cached, how is arbitration done among multiple accesses, the list goes on.
It is nearly impossible to write a high performance OpenGL driver without
knowing at least some of that information, and these architecture choices
can make or break the performance of a GPU. So to me it's entirely
understandable that NVidia doesn't want anyone to know how they do
it. [Note that for console stuff or basic graphics all GPUs I've heard
of can be put into a VGA compatibility mode which may or may not have some
degree of accelleration].
To some extent these details can be buried; I imagine this is how ATI
can consider releasing open-source drivers for their chips (I have no
knowledge of ATI chips either). The notion that their closed-source
drivers will be higher performance tells me that the real juicy stuff
is still being kept under wraps. Perhaps that same strategy isn't
possible with NVidia's architecture. Or perhaps ATI simply figures they
can release driver source but not chip information itself, and assume by
the time a competitor can puzzle out their code they'll be selling the
next generation parts!
Just my 2-cent attempt to add some information into the flamewar...
Ken Ryan
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: David D. Hagood @ 2003-01-09 23:32 UTC (permalink / raw)
To: Wolfgang Fritz; +Cc: linux-kernel
In-Reply-To: <3E1D79CB.5010503@gmx.net>
Well, I found out that while we have the DTMF test tape at work, it is
exactly that - a cassette tape that is copyrighted. So, no easy/legal
way to make it available for testing...
^ permalink raw reply
* Re: Honest does not pay here ...
From: Bill Davidsen @ 2003-01-09 23:27 UTC (permalink / raw)
To: Philip Dodd; +Cc: Hell.Surfers, linux-kernel
In-Reply-To: <3E1C913F.101@free.fr>
On Wed, 8 Jan 2003, Philip Dodd wrote:
> > im working on GPLd support for USB under W95.
>
> I think you just hosed your "Freedom is bliss" arguments.
>
> WTF have GPLed drivers for Win95 got to do with free software. If you
> want freedom please work on the Hurd. You are wasting your time working
> on GPLed DOS drivers.
Is it not *his* time? And his evaluation of its value?
This reminds me of woman's lib folks who fight for the right of women to
do anything they want as long as long as it isn't stay home and be a
housewife. Thank you, I prefer the taste of my open source software
without the bitter tang of political correctness.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Larry McVoy @ 2003-01-09 23:24 UTC (permalink / raw)
To: Richard Stallman; +Cc: lm, acahalan, linux-kernel
In-Reply-To: <E18Wlsj-0000Zr-00@fencepost.gnu.org>
On Thu, Jan 09, 2003 at 06:14:37PM -0500, Richard Stallman wrote:
> 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.
And isn't that exactly the line of reasoning which leads you to the
conclusion that Linux should be GNU/Linux? Why do you think that
you deserve special billing ahead of anyone else? You haven't
contributed any more than anyone else, that's for sure. GCC is
nice and all, but by your own reasoning if GCC didn't exist, a
different compiler would have shown up. The only reason they
didn't is that GCC made that itch go away.
It really seems like you are trying to leverage a comparitively tiny
amount of source into top billing. Why are you more important than
the entire windowing system, which is dramatically more source and
more effort?
And when are you going to start referring to your kernel by its
proper name: Linux/Hurd? Or do you have plans to remove the
Linux components?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Jeff Garzik @ 2003-01-09 23:23 UTC (permalink / raw)
To: Lars Marowsky-Bree; +Cc: linux-kernel
In-Reply-To: <20030109231959.GP2437@marowsky-bree.de>
On Fri, Jan 10, 2003 at 12:19:59AM +0100, Lars Marowsky-Bree wrote:
> On 2003-01-09T17:27:48,
> Jeff Garzik <jgarzik@pobox.com> said:
>
> > Anybody know where the source rpm for UnitedLinux kernel is?
> > [to be distinguished from kernel-source rpm]
>
> The complaint is valid, it should be advertised better, I had to look myself,
> but I believe that
> ftp://ftp.suse.com/pub/unitedlinux/1.0/src/kernel-source-2.4.19.SuSE-82.nosrc.rpm
> is what you are looking for.
>
> I've forwarded the request because I believe we can and should do better, but
> I hope the complaint of a GPL violation has been settled ;-)
Yes, thanks much.
Jeff
^ permalink raw reply
* Re: NFS as a Cluster File System.
From: Lorn Kay @ 2003-01-09 23:13 UTC (permalink / raw)
To: lmb, nfs, linux-ha
>However, it is NOT a "CFS", which people commonly use to refer to a
>filesystem
>which is distributed and usually shares the same storage system connected
>to
>all nodes.
>
>I believe there might be a confusion of words here ;-)
>
>
>Sincerely,
> Lars Marowsky-Brée <lmb@suse.de>
Sorry, still confused about what a "CFS" really is. In "In Search Of
Clusters" Gregory Pfister takes the position that a distributed file system
is what he calls a valid "single system image" file system, what I would
take to mean a cluster file system (though he doesn't use those words).
I guess you are saying a clustered file system isn't necessarily supporting
a cluster of application servers but is itself stored on a cluster. (A
single server can be the only server using a cluster file system.) ?
--K
_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
-------------------------------------------------------
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: [patch 2.5] 2-pass PCI probing, generic part
From: Ivan Kokshaysky @ 2003-01-09 23:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ivan Kokshaysky, Benjamin Herrenschmidt, Alan Cox, Grant Grundler,
Paul Mackerras, Eric W. Biederman, davidm,
Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301091413520.1436-100000@penguin.transmeta.com>
On Thu, Jan 09, 2003 at 02:16:20PM -0800, Linus Torvalds wrote:
> 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
PCI-PCI, PCI-ISA bridges - probably, but not host bridges. On x86 they
often have quite a few BARs, like AGP window, AGP MMIO, power management
etc., which we cannot ignore.
OTOH, with that patch we can control probing for any given class of
devices with a 4-5 lines fixups, per architecture. :-)
Ivan.
^ permalink raw reply
* Re: access memory mapped registers
From: Wolfgang Denk @ 2003-01-09 23:14 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: linuxppc-embedded
In-Reply-To: <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM>
In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM> you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?
You don't. Design a proper device driver interface instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
By the way, ALL software projects are done by iterative prototyping.
Some companies call their prototypes "releases", that's all.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Lars Marowsky-Bree @ 2003-01-09 23:19 UTC (permalink / raw)
To: Jeff Garzik, linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
On 2003-01-09T17:27:48,
Jeff Garzik <jgarzik@pobox.com> said:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
The complaint is valid, it should be advertised better, I had to look myself,
but I believe that
ftp://ftp.suse.com/pub/unitedlinux/1.0/src/kernel-source-2.4.19.SuSE-82.nosrc.rpm
is what you are looking for.
I've forwarded the request because I believe we can and should do better, but
I hope the complaint of a GPL violation has been settled ;-)
Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
^ permalink raw reply
* [BK PATCH] ACPI updates
From: Grover, Andrew @ 2003-01-09 23:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A, Greg KH
Hi Linus, please do a
bk pull http://linux-acpi.bkbits.net/linux-acpi
(The diffstat is artificially huge because of the global change from
typedefed structs to explicit struct tags.)
Regards -- Andy
This will update the following files:
arch/i386/kernel/mpparse.c | 2
drivers/acpi/acpi_bus.h | 21
drivers/acpi/acpi_drivers.h | 4
drivers/acpi/battery.c | 24
drivers/acpi/bus.c | 6
drivers/acpi/button.c | 75 +-
drivers/acpi/dispatcher/dsfield.c | 76 +-
drivers/acpi/dispatcher/dsinit.c | 34
drivers/acpi/dispatcher/dsmethod.c | 60 -
drivers/acpi/dispatcher/dsmthdat.c | 94 +-
drivers/acpi/dispatcher/dsobject.c | 86 +-
drivers/acpi/dispatcher/dsopcode.c | 134 +--
drivers/acpi/dispatcher/dsutils.c | 64 -
drivers/acpi/dispatcher/dswexec.c | 34
drivers/acpi/dispatcher/dswload.c | 60 -
drivers/acpi/dispatcher/dswscope.c | 22
drivers/acpi/dispatcher/dswstate.c | 140 +--
drivers/acpi/ec.c | 24
drivers/acpi/events/evevent.c | 20
drivers/acpi/events/evgpe.c | 84 +-
drivers/acpi/events/evmisc.c | 56 -
drivers/acpi/events/evregion.c | 86 +-
drivers/acpi/events/evrgnini.c | 92 +-
drivers/acpi/events/evsci.c | 14
drivers/acpi/events/evxface.c | 76 +-
drivers/acpi/events/evxfevnt.c | 40 -
drivers/acpi/events/evxfregn.c | 42 -
drivers/acpi/executer/exconfig.c | 72 -
drivers/acpi/executer/exconvrt.c | 86 +-
drivers/acpi/executer/excreate.c | 100 +-
drivers/acpi/executer/exdump.c | 64 -
drivers/acpi/executer/exfield.c | 38 -
drivers/acpi/executer/exfldio.c | 116 +--
drivers/acpi/executer/exmisc.c | 62 -
drivers/acpi/executer/exmutex.c | 34
drivers/acpi/executer/exnames.c | 44 -
drivers/acpi/executer/exoparg1.c | 56 -
drivers/acpi/executer/exoparg2.c | 46 -
drivers/acpi/executer/exoparg3.c | 26
drivers/acpi/executer/exoparg6.c | 20
drivers/acpi/executer/exprep.c | 42 -
drivers/acpi/executer/exregion.c | 108 +-
drivers/acpi/executer/exresnte.c | 20
drivers/acpi/executer/exresolv.c | 46 -
drivers/acpi/executer/exresop.c | 34
drivers/acpi/executer/exstore.c | 44 -
drivers/acpi/executer/exstoren.c | 24
drivers/acpi/executer/exstorob.c | 18
drivers/acpi/executer/exsystem.c | 44 -
drivers/acpi/executer/exutils.c | 46 -
drivers/acpi/hardware/hwacpi.c | 14
drivers/acpi/hardware/hwgpe.c | 72 -
drivers/acpi/hardware/hwregs.c | 106 +-
drivers/acpi/hardware/hwsleep.c | 32
drivers/acpi/hardware/hwtimer.c | 22
drivers/acpi/include/acconfig.h | 4
drivers/acpi/include/acdebug.h | 222 +++---
drivers/acpi/include/acdispat.h | 370 +++++-----
drivers/acpi/include/acevents.h | 102 +-
drivers/acpi/include/acexcep.h | 2
drivers/acpi/include/acglobal.h | 212 ++---
drivers/acpi/include/achware.h | 62 -
drivers/acpi/include/acinterp.h | 546 +++++++-------
drivers/acpi/include/aclocal.h | 669 ++++++++----------
drivers/acpi/include/acmacros.h | 16
drivers/acpi/include/acnamesp.h | 324 ++++----
drivers/acpi/include/acobject.h | 415 +++++------
drivers/acpi/include/acoutput.h | 2
drivers/acpi/include/acparser.h | 216 ++---
drivers/acpi/include/acpi.h | 2
drivers/acpi/include/acpiosxf.h | 168 ++--
drivers/acpi/include/acpixf.h | 258 +++----
drivers/acpi/include/acresrc.h | 304 ++++----
drivers/acpi/include/acstruct.h | 190 ++---
drivers/acpi/include/actables.h | 110 +--
drivers/acpi/include/actbl.h | 150 +---
drivers/acpi/include/actbl1.h | 134 +--
drivers/acpi/include/actbl2.h | 195 ++---
drivers/acpi/include/actbl71.h | 140 +--
drivers/acpi/include/actypes.h | 732 +++++++++-----------
drivers/acpi/include/acutils.h | 532 +++++++-------
drivers/acpi/include/amlcode.h | 2
drivers/acpi/include/amlresrc.h | 381 ++++------
drivers/acpi/include/platform/acenv.h | 2
drivers/acpi/include/platform/acgcc.h | 2
drivers/acpi/include/platform/aclinux.h | 2
drivers/acpi/namespace/nsaccess.c | 48 -
drivers/acpi/namespace/nsalloc.c | 74 +-
drivers/acpi/namespace/nsdump.c | 70 -
drivers/acpi/namespace/nsdumpdv.c | 20
drivers/acpi/namespace/nseval.c | 64 -
drivers/acpi/namespace/nsinit.c | 48 -
drivers/acpi/namespace/nsload.c | 36
drivers/acpi/namespace/nsnames.c | 34
drivers/acpi/namespace/nsobject.c | 62 -
drivers/acpi/namespace/nsparse.c | 18
drivers/acpi/namespace/nssearch.c | 44 -
drivers/acpi/namespace/nsutils.c | 142 +--
drivers/acpi/namespace/nswalk.c | 38 -
drivers/acpi/namespace/nsxfeval.c | 112 +--
drivers/acpi/namespace/nsxfname.c | 40 -
drivers/acpi/namespace/nsxfobj.c | 34
drivers/acpi/osl.c | 171 +---
drivers/acpi/parser/psargs.c | 76 +-
drivers/acpi/parser/psopcode.c | 12
drivers/acpi/parser/psparse.c | 62 -
drivers/acpi/parser/psscope.c | 38 -
drivers/acpi/parser/pstree.c | 38 -
drivers/acpi/parser/psutils.c | 44 -
drivers/acpi/parser/pswalk.c | 28
drivers/acpi/parser/psxface.c | 18
drivers/acpi/pci_bind.c | 10
drivers/acpi/pci_irq.c | 22
drivers/acpi/pci_link.c | 28
drivers/acpi/pci_root.c | 28
drivers/acpi/power.c | 4
drivers/acpi/processor.c | 85 --
drivers/acpi/resources/rsaddr.c | 116 +--
drivers/acpi/resources/rscalc.c | 100 +-
drivers/acpi/resources/rscreate.c | 60 -
drivers/acpi/resources/rsdump.c | 84 +-
drivers/acpi/resources/rsio.c | 96 +-
drivers/acpi/resources/rsirq.c | 78 +-
drivers/acpi/resources/rslist.c | 44 -
drivers/acpi/resources/rsmemory.c | 92 +-
drivers/acpi/resources/rsmisc.c | 104 +-
drivers/acpi/resources/rsutils.c | 36
drivers/acpi/resources/rsxface.c | 26
drivers/acpi/scan.c | 16
drivers/acpi/system.c | 4
drivers/acpi/tables/tbconvrt.c | 56 -
drivers/acpi/tables/tbget.c | 68 -
drivers/acpi/tables/tbgetall.c | 30
drivers/acpi/tables/tbinstal.c | 56 -
drivers/acpi/tables/tbrsdt.c | 34
drivers/acpi/tables/tbutils.c | 38 -
drivers/acpi/tables/tbxface.c | 48 -
drivers/acpi/tables/tbxfroot.c | 72 -
drivers/acpi/thermal.c | 4
drivers/acpi/toshiba_acpi.c | 12
drivers/acpi/utilities/utalloc.c | 156 ++--
drivers/acpi/utilities/utcopy.c | 168 ++--
drivers/acpi/utilities/utdebug.c | 86 +-
drivers/acpi/utilities/utdelete.c | 42 -
drivers/acpi/utilities/uteval.c | 58 -
drivers/acpi/utilities/utglobal.c | 100 +-
drivers/acpi/utilities/utinit.c | 8
drivers/acpi/utilities/utmath.c | 58 -
drivers/acpi/utilities/utmisc.c | 210 ++---
drivers/acpi/utilities/utobject.c | 84 +-
drivers/acpi/utilities/utxface.c | 30
drivers/acpi/utils.c | 28
drivers/hotplug/acpiphp_glue.c | 46 -
include/linux/acpi.h | 28
154 files changed, 6552 insertions(+), 6744 deletions(-)
through these ChangeSets:
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/09 1.935)
ACPI: Update version string to 20030109
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/08 1.933)
ACPI: Eliminate spawning of thread from timer callback. Use
schedule_work for
all cases. Thanks to Ingo Oeser, Andrew Morton, and Pavel Machek
for their
wisdom.
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/08 1.932)
cpufreq-ACPI: no longer use CPUFREQ_ALL_CPUS (Dominik Brodowski)
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/07 1.889.4.4)
ACPI: Express state of lid in words, not a number
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/07 1.889.4.3)
ACPI: Make button functions static (Pavel Machek)
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/07 1.889.4.2)
ACPI: Expose lid state to userspace (Zdenek OGAR Skalak)
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/07 1.838.136.19)
ACPI: Remove typedefs in favor of using "struct" and "union"
explicitly
<agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org> (03/01/03 1.838.136.17)
ACPI: Use printk instead of pr_debug (Randy Dunlap)
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Larry McVoy @ 2003-01-09 23:19 UTC (permalink / raw)
To: Richard Stallman; +Cc: billh, mark, lm, linux-kernel, paul, riel
In-Reply-To: <E18WlrH-0000NO-00@fencepost.gnu.org>
On Thu, Jan 09, 2003 at 06:13:07PM -0500, Richard Stallman wrote:
> There is no such thing as an open source community.
Poof! And millions of people disappear at the bidding of the
One True God, Richard Stallman.
Not.
> The GNU system, with Linux added, had a great deal of success, but
Please remember that Linux is a trademark of Linus Torvalds and your
inclusion of "Linux" in "GNU/Linux" is covered by trademark law. Have
you cleared that use with Linus?
> attributing that success entirely to Linux is a misinterpretation of
> the events.
>
> Why do so many people misinterpret the events this way?
Maybe because their belief is a lot more valid than your belief?
Oh, since I have your attention, when are you going to issue a
press release officially renaming Hurd to Linux/Hurd?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: 2.5.55: local symbols in net/ipv6/af_inet6.o
From: Anders Gustafsson @ 2003-01-09 23:18 UTC (permalink / raw)
To: Niels den Otter; +Cc: linux-kernel, davem
In-Reply-To: <20030109091025.GW31387@surly.surfnet.nl>
On Thu, Jan 09, 2003 at 10:10:26AM +0100, Niels den Otter wrote:
> The reference_discarded.pl script says following:
> pangsit:/usr/src/linux/net> perl ~otter/reference_discarded.pl
> Finding objects, 245 objects, ignoring 0 module(s)
> Finding conglomerates, ignoring 11 conglomerate(s)
> Scanning objects
> Error: ./ipv6/af_inet6.o .init.text refers to 000003e4 R_386_PC32 .exit.text
> Done
>
> I tried both gcc-2.95 & gcc-3.2.2 .
This patch shoul fix it, the problem is that cleanup_ipv6_mibs can't be
__exit as it's called on ipv6_init's errorpath.
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===================================================================
ChangeSet@1.901, 2003-01-10 00:10:38+01:00, andersg@0x63.nu
cleanup_ipv6_mibs can't be __exit, it's called on ipv6_init's errorpath.
af_inet6.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
--- a/net/ipv6/af_inet6.c Fri Jan 10 00:11:57 2003
+++ b/net/ipv6/af_inet6.c Fri Jan 10 00:11:57 2003
@@ -684,7 +684,7 @@
}
-static void __exit cleanup_ipv6_mibs(void)
+static void cleanup_ipv6_mibs(void)
{
kfree_percpu(ipv6_statistics[0]);
kfree_percpu(ipv6_statistics[1]);
===================================================================
This BitKeeper patch contains the following changesets:
1.901
## Wrapped with gzip_uu ##
begin 664 bkpatch11850
M'XL(`+T!'CX``\V446O;,!#'GZ-/<="';G2Q[V1%L0P9V=JQC0T6,OH<9%MI
M3&PYV$K:@3_\%">T6]NUK.QALL>]_'3[H_.H'+UC3)0-O<-.T5.X%/=>N2
M`=[(*+!;/Y_7M9^'J[HRX5$5KDUC31FFZS`MZVOF53/MLA7L_&HRH""ZS;@?
M&Y,,YA\^7GY]-V=L,H'SE;97YKMQ,)DP5S<[7>;M5+M56=O`-=JVE7$ZR.JJ
MNY5V')'[9T3C"$>R(XEBW&64$VE!)D<N8BG8$6]ZA/_]_P@)%>=<HNI\3))=
M``4*"3`*D4)"0$P(DR@^0TH0X5XY.",8(GL/_Q;ZG&60E4;;[691;'9R415I
M"YFVIPY2`XN%N2G<&RC<Z3Y;EB:'VD*O+&R?-4U3-QL/$[`OP)6BF,WNCID-
M_W(PAAK9VV>V:8T+]Q"A7GH.XV20_;IA-5(=$<:\DZ-4"JX5C7(AXTC=/]8_
M53KT*R(?=()$%/7N>43\O(]>S,K6A2\T+6Q0I-53I?:P8T)2@G>"HQKWYB+U
MP%OXA+?H?_?6H0W?8-A<]Z_WRNRQCKS`<A<R'@.QSX=/Z[0K,MC51?Z0_]4^
;_?KNTLE6)ENWVVJ"8IF))5?L)Q<IQX;5!```
`
end
^ permalink raw reply
* Re: [PATCH] 2.4.20 IDE for 2.4.21-pre3
From: Michael Madore @ 2003-01-09 23:16 UTC (permalink / raw)
To: Tomas Szepe; +Cc: linux-kernel
In-Reply-To: <20030108182112.GQ823@louise.pinerecords.com>
Tomas Szepe wrote:
>>[mmadore@aslab.com]
>>
>>I get the following oops when running 2.4.21-pre3 +
>>2.4.21-pre3-2420ide-1. The oops occurred after running the Cerberus
>>stress test for about 5 hours. The machine uses an ASUS A7N8X single
>>AMD Athlon XP motherboard with the Nvidia nforce2 chipset. I had to
>>pass ide0=ata66 ide1=ata66 to the kernel in order to use DMA.
>>
>>
>
>Michael,
>
>are you able to reproduce this oops with vanilla 2.4.20?
>
>
>
Actually, we put some different memory in the machine and now it seems
stable.
Mike
^ permalink raw reply
* Re: NFS as a Cluster File System.
From: Brian Tinsley @ 2003-01-09 23:09 UTC (permalink / raw)
To: Lars Marowsky-Bree; +Cc: Lorn Kay, nfs, linux-ha
In-Reply-To: <20030109215019.GN2437@marowsky-bree.de>
Lars Marowsky-Bree wrote:
>On 2003-01-09T19:39:50,
> Lorn Kay <lorn_kay@hotmail.com> said:
>
>>Is NFS a viable CFS? (I'm cross posting this due to a discussion on the the linux-ha list recently.)
>>
>>
>NFS might be a viable system for making content available in a cluster, given a highly available NFS sever (not that easy to do right, actually) and provided that the bandwidth and latency is good enough for you; file locking might also be a problem.
>
There are numerous threads in the NFS mailing list archives (and
probably in the NFS HOWTO - it's been quite a while since I've read it)
on how to set up a HA NFS cluster. Yes, there are quite a few pitfalls
to watch for and some applications may not behave well in this
configuration, but it's definitely achievable.
>However, it is NOT a "CFS", which people commonly use to refer to a filesystem which is distributed and usually shares the same storage system connected to all nodes.
>
Yes, good clarification.
-------------------------------------------------------
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: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-09 23:14 UTC (permalink / raw)
To: Vlad@Vlad.geekizoid.com; +Cc: linux-kernel
In-Reply-To: <010101c2b786$794d87a0$0200a8c0@wsl3>
Do you actually buy your own bullshit here? If so, that's sad. I used to
respect you.
One wonders what it is you thought I had done, when you respected me
for it ;-).
I'd like to see you put your money where your mouth is
I've dedicated my life to free software since 1984, and have been
working for the cause more than full time, all these 19 years. I
think that counts as "putting my money where my mouth is" for the
movement.
If it doesn't, then you have set a standard so high that perhaps
nobody in the world qualifies.
- PROVE
that GNU (not just people who have release GPL'd software) contributed most
of the work to say Slackware, or Debian, or Red Hat.
Let's be careful. I don't say that the GNU software packages were
most of the early GNU/Linux system. They were, however, the largest
contribution of any single project. Probably they still are.
GNU, the system we were developing, was most of the early GNU/Linux
system in 1992. GNU in 1992 included non-GNU packages such as X11,
and TeX.
If we look at the GNU packages alone rather than the GNU system as a
whole, they were a large fraction of the early GNU/Linux system. The
specific data point I have comes from Adam Richter, who maintained an
early distro. In 1995, he counted up the code and found that GNU
packages added up to 28% of his distro. Linux, the kernel, was 3% of
that distro.
I would expect that both GNU code and Linux make up smaller fractions
of current GNU/Linux distros, because so many other programs have been
added over the years. It's a good thing that so many free programs
have been developed, and that so many people have contributed, but
this doesn't change the system's history. It started out as the
combination of GNU and Linux.
^ permalink raw reply
* 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
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.