* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: Maciej W. Rozycki @ 2003-01-08 21:22 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <CACAEBD1F1C@vcnet.vc.cvut.cz>
On Wed, 8 Jan 2003, Petr Vandrovec wrote:
> > > 1. which device is at port address 0xCFB?
> >
> > Hopefully none.
>
> Actually I'm not sure. This code is here since at least 2.0.28,
> and during googling I even found code for direct PCI access
> (http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
> which sets lowest bit at 0xCFB to 1 before doing PCI config
> accesses and reset it back to original value afterward.
>
> So I believe that there were some chipsets (probably in 486&PCI times)
> which did conf1/conf2 accesses depending on value of this bit.
> Unfortunately I was not able to confirm this - almost nobody provides
> northbridge datasheets from '94 era, even Intel does not provide them
> (f.e. Neptune) anymore :-(
Fortunately that's not true. Grab the relevant docs from:
'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
config space using conf2 accesses.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: Mike Anderson @ 2003-01-08 21:13 UTC (permalink / raw)
To: Luben Tuikov; +Cc: linux-scsi
In-Reply-To: <3E1C60D5.2070805@splentec.com>
Luben Tuikov [luben@splentec.com] wrote:
> >I'm arguing for a linked list of structs that hold the minimum data we
> >need to use them as a path - much like a scsi_device with the redundant
> >fields removed (and if needed it can also point to the actual
> >scsi_device). And then plugging this data (or a pointer) into a scsi_cmnd
> >for use by the LLDD.
>
> This may be an easier approach, but a scsi_cmnd stands for SCSI command.
>
but struct scsi_device currently stands for more than the LLDD
scsi_device. It stands for a block request queue, scsi mid data, and
scsi host device data.
While in the short term struct scsi_device already exists and appears to
be the right next progression to use. Future progression of abstraction
should look at some separation of the LLDD nexus device data and the
other struct scsi_device data. Maybe in the future part of struct scsi_device
will be a nexus handle given to the mid layer by the LLDD to represent
its object which will be plugged into the scsi_cmnd.
> Its a good thing to have multipathing represented as an ADT (abstract
> data type). Say something like a linked list of structs with
> cost/weight member and a pointer to an actual low-level device (the
> infrastructure
> will be more involved since multipathing will need to be notified
> when a device goes away, but read further...). Now this ADT may be embeded
> into a block device and char device structs -- i.e. highest hierarchy.
> (The assumption is that there won't be a device which will present
> a char and block interface at the same time.)
>
> Now since this ADT is embeded into the block/char device, we do get
> notification when it goes away. So this should be ok.
>
> The effect is that when write(fd, buf, count) is done, somewhere along
> the way *before* the actual physical device (ide,scsi,etc) is referenced
> multipathing has already been accomplished. This preserves as much as
> possible
> the current infrastructure of the kernel.
>
> So when a low-level device (LLD) says that it cannot satisfy the request,
> you *may* try another path.
>
> In effect a low-level device *as seen from the multipath code* is the tuple
> (PATH, DEVICE), and this is where a request is sent, i.e. to the tuple
> (PATH, DEVICE). Where for each PATH, there can be exactly one DEVICE, since
> a PATH describes a device (or access to it), but the opposite is not
> necessarily
> true. I.e. for each DEVICE there can be zero/one to many PATHs.
>
> >As long as we have an interface (function or macro), I'm not strongly
> >opposed to the above. We can keep the scsi_allocate_device (in dire need
> >of a new name), and just have it allocate and init (or not) any fields as
> >needed, so there is only one place to change the init of the allocated
> >scsi_cmnd.
>
> The SCSI Core has a well-defined funtion. I'm not so sure that we
> should muck it up with other well-defined functions, like multipathing.
>
I would counter that moving device and transport knowledge into the
upper level might also muck up that level.
While it is not difficult to link paths together inside an object it
becomes more difficult to make good decisions on how to use the paths
beyond simple fail-over. There are device and platform specific
characteristics that effect performance and error policy. These
personalities exist in multipath OS core support in AIX, MS, and
DYNIX/ptx and vendor specific multi-path support drivers available for
most OS's. While the implementation is unique to the OS environment the
need for path personalities is common.
These type of issues are touched on in the mid-multipath document.
> It is *inevitable* that multipathing will be moved up into the
> generic device char and block structs; sooner or later.
The inevitable hopefully will wait until we get a few more versions of
the mid-level patch out and discuss code specific pro / cons of mid vs
upper layer implementations.
-andmike
--
Michael Anderson
andmike@us.ibm.com
^ permalink raw reply
* Re: [BUG - HRT patch] nanosleep returns 0 on failure
From: george anzinger @ 2003-01-08 20:14 UTC (permalink / raw)
To: Fleischer, Julie N; +Cc: high-res-timers-discourse, linux-kernel
In-Reply-To: <D9223EB959A5D511A98F00508B68C20C17F1C724@orsmsx108.jf.intel.com>
"Fleischer, Julie N" wrote:
>
> > george anzinger wrote:
> > If you don't mind, I will add your test code to my
> > clock_nanosleep test code so this does not creep back in.
>
> Sure. It's all GPL. The 6-1.c test case (attached below) probably has the
> best test because it does multiple values, some < 0, some >= 1000 million.
>
> One other thing I forgot to write in my previous report is that
> clock_nanosleep() appeared to behave as expected, just nanosleep() showed
> the issue of returning 0 on failure.
Yes, I found the problem. Thanks for the code and the heads
up.
-g
>
> Thanks.
> - Julie
>
> ----
> test 6-1.c
> /*
> * Copyright (c) 2002, Intel Corporation. All rights reserved.
> * Created by: julie.n.fleischer REMOVE-THIS AT intel DOT com
> * This file is licensed under the GPL license. For the full content
> * of this license, see the COPYING file at the top level of this
> * source tree.
>
> * Test that nanosleep() sets errno to EINVAL if rqtp contained a
> * nanosecond value < 0 or >= 1,000 million
> */
> #include <stdio.h>
> #include <time.h>
> #include <errno.h>
>
> #define PTS_PASS 0
> #define PTS_FAIL 1
> #define PTS_UNRESOLVED 2
>
> #define NUMTESTS 7
>
> int main(int argc, char *argv[])
> {
> struct timespec tssleepfor, tsstorage;
> int sleepnsec[NUMTESTS] = {-1, -5, -1000000000, 1000000000,
> 1000000001, 2000000000, 2000000000 };
> int i;
> int failure = 0;
>
> tssleepfor.tv_sec=0;
>
> for (i=0; i<NUMTESTS;i++) {
> tssleepfor.tv_nsec=sleepnsec[i];
> printf("sleep %d\n", sleepnsec[i]);
> if (nanosleep(&tssleepfor, &tsstorage) == -1) {
> if (EINVAL != errno) {
> printf("errno != EINVAL\n");
> failure = 1;
> }
> } else {
> printf("nanosleep() did not return -1 on
> failure\n");
> return PTS_UNRESOLVED;
> }
> }
>
> if (failure) {
> printf("At least one test FAILED\n");
> return PTS_FAIL;
> } else {
> printf("All tests PASSED\n");
> return PTS_PASS;
> }
> }
> **These views are not necessarily those of my employer.**
> -
> 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/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: 3CR990 question (Nearly unrelated to iSCSI)
From: David Dillow @ 2003-01-08 21:14 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200301081950.h08JoTr15738@buggy.badula.org>
Ion Badulescu wrote:
> Actually, the 3Com driver I cleaned up does not have support for the
> hardware crypto chip. Maybe the other driver you were referring to
> supports it?
Yes, and no. It doesn't support it in the version I sent to Jeff. I do
have code that uses it, and a kludge to use it under 2.4. As for 2.5, I
hope to work to get it supported with the IPSEC code properly.
I do support the other offloading it will do -- VLAN, Checksum, and TCP
segmentation.
> > I hope we will see it appear in a kernel RSN
>
> Indeed. :) That damn legalese in 3Com's license...
And government work! I've got the paperwork in progress, should be RSN
as Jeff said. Word is no later than next Wednesday, though I'm pushing
for Friday.
I've got the firmware under a BSD style license that will work for us,
and the driver is completely GPL.
Dave Dillow
dillowd@y12.doe.gov
^ permalink raw reply
* 2.5.54 and 2.5.52 keep failing on make modules_install
From: Rowan Reid @ 2003-01-08 21:13 UTC (permalink / raw)
To: Linux Kernel Mailing List
I keep getting errors simular to that listed below when I run make
modules_install. This happens for 2.5.52, and 2.5.54.
depmod: *** Unresolved symbols in
/lib/modules/2.5.54/kernel/net/netlink/netlink_dev.ko
This problem does not exist on 2.5.50. My only problem is when using
the 2.5.50 kernel I get the following error on boot. After some research
I understood there is a bug or something in 2.5.50. can someone give me
some direction. My reason for trying to use the 2.5 kernel is to
incorperate the IPSEC features of that kernel.
Kernel panic on boot. Error below. It's a 2.5.50 kernel reiserfs
using initrd SuSE8.0
QM_MODULES not implimented
UDF-fs: No partition found
Rowan Reid
Job Captain,
Systems Administrator
STUDIO 3 ARCHITECTS
909 982 1717
^ permalink raw reply
* Re: [RFC][PATCH] allow bigger PAGE_OFFSET with PAE
From: Dave Hansen @ 2003-01-08 21:04 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Linux Kernel Mailing List, linux-mm
In-Reply-To: <20030107233713.GB23814@holomorphy.com>
William Lee Irwin III wrote:
> On Tue, Jan 07, 2003 at 12:06:38PM -0800, Dave Hansen wrote:
>
>>Also, this gets the kernel's pagetables right, but neglects
>>userspace's for now. pgd_alloc() needs to be fixed to allocate
>>another PMD, if the split isn't PMD-alighed.
>
> Um, that should be automatic when USER_PTRS_PER_PGD is increased.
Nope, you need a little bit more. pgd_alloc() relies on its memcpy()
to provide the kernel mappings. After the last user PMD is allocated,
you still need to copy the kernel-shared part of it in.
--
Dave Hansen
haveblue@us.ibm.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* RE: Gigabit/SMP performance problem
From: Feldman, Scott @ 2003-01-08 21:12 UTC (permalink / raw)
To: Jon Fraser, linux-kernel, Avery Fay
> If you happen to turn on vlans, I be curious about your
> results. Our chipsets produced cisco ISL frames instead of
> 802.1q frames. Intel admitted the chipset would do it, but
> 'shouldn't be doing that...'
This problem has been fixed in tot 2.4 and 2.5. The VLANs were not
being restored after ifup.
-scott
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Adam Belay @ 2003-01-08 16:09 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: Zwane Mwaikambo, Jaroslav Kysela, linux-kernel
In-Reply-To: <Pine.BSF.4.05.10301081959130.88742-100000@wildrose.miee.ru>
On Wed, Jan 08, 2003 at 08:20:13PM +0300, Ruslan U. Zakirov wrote:
> Hello Adam and All.
> Here is patch to sb16.c that makes it posible to compile and use this
> driver under 2.5.54-vanilla.
> It working for me as module and built in kernel, but it's need testing.
> Ruslan.
Hi Ruslan,
I haven't had a chance to test this yet but everything does look ok. I
think it will be ready once the below function is completed. Jaroslav,
any comments? Also, if anyone has a built in wavetable, as previously
mentioned by Zwane, I'd like to hear how this patch works for you. This
patch makes full use of pnp card services, which is prefered for cards
that have several closely related devices, and it would be great to
further test those code paths.
Thanks,
Adam
>
> -#endif /* __ISAPNP__ */
> +static void snd_sb16_isapnp_remove(struct pnp_card * card)
> +{
> + /*FIX ME*/
> +}
> +
>
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: Linus Torvalds @ 2003-01-08 21:03 UTC (permalink / raw)
To: John Levon; +Cc: linux-kernel, davem
In-Reply-To: <20030108205220.GB35912@compsoc.man.ac.uk>
On Wed, 8 Jan 2003, John Levon wrote:
> On Wed, Jan 08, 2003 at 12:28:23PM -0800, Linus Torvalds wrote:
>
> > doesn't change suddenly on the machine, there's no point at all in doing
> > something like this and exporting it through proc, when the information is
> > perfectly available in other ways
>
> What other ways ? Dave M reasonably argued it wasn't part of the
> architecture's ABI, so did not have a place in the headers.
You should certainly see it in "uname -a" output, for example.
> > or could even be a user program config file option.
>
> Eww.
And it's less disgusting than adding a kernel hack for it?
Trust me, kernel stuff is for stuff that _cannot_ be gotten in user space,
not for random hacks.
> It's not silly, it's a necessity on architectures like pa-risc, sparc64,
> ppc64, etc. where pointers are 32 bit in userspace. OProfile simply
> cannot work at all on such systems without being able to figure out the
> units of the oprofile kernel buffer.
So?
The same is true of kernel modules - 32-bit kernel modules do not work at
all when the kernel is 64-bit.
Compile oprofile for the proper architecture if you do it yourself, and
complain to the vendor if the vendor is stupid enough to supply a 32-bit
oprofile with a 64-bit kernel.
There is _no_ excuse to bloat the kernel for user mistakes.
Linus
^ permalink raw reply
* Re: Honest does not pay here ...
From: Philip Dodd @ 2003-01-08 20:59 UTC (permalink / raw)
To: Hell.Surfers; +Cc: linux-kernel
In-Reply-To: <03db80127070813DTVMAIL12@smtp.cwctv.net>
> 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.
^ permalink raw reply
* Re: [ACPI] RE: kacpidpc needs to die
From: Pavel Machek @ 2003-01-08 20:58 UTC (permalink / raw)
To: Grover, Andrew; +Cc: kernel list, ACPI mailing list
In-Reply-To: <F760B14C9561B941B89469F59BA3A84725A10E-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
Hi!
> > safe, anyway],
> > > kacpidpc needs to die. Andrew, are you going to kill it or
> > should I do
> > > it?
> >
> > I can kill it...let me just verify with you --
> > acpi_os_queue_for_execution has a two block switch statement, just use
> > the first block (the case that uses schedule_work) and delete
> > the rest,
> > yes?
>
> Oops, and combine acpi_os_schedule_exec and acpi_os_queue_exec, so that
> we call dpc->function() from the original thread. Anything else?
I don't see anything else, this looks okay.
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: [RFC][PATCH] allow bigger PAGE_OFFSET with PAE
From: Dave Hansen @ 2003-01-08 21:04 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Linux Kernel Mailing List, linux-mm
In-Reply-To: <20030107233713.GB23814@holomorphy.com>
William Lee Irwin III wrote:
> On Tue, Jan 07, 2003 at 12:06:38PM -0800, Dave Hansen wrote:
>
>>Also, this gets the kernel's pagetables right, but neglects
>>userspace's for now. pgd_alloc() needs to be fixed to allocate
>>another PMD, if the split isn't PMD-alighed.
>
> Um, that should be automatic when USER_PTRS_PER_PGD is increased.
Nope, you need a little bit more. pgd_alloc() relies on its memcpy()
to provide the kernel mappings. After the last user PMD is allocated,
you still need to copy the kernel-shared part of it in.
--
Dave Hansen
haveblue@us.ibm.com
^ permalink raw reply
* Re: PIC programming question
From: Nuno Miguel Fernandes Sucena Almeida @ 2003-01-08 20:54 UTC (permalink / raw)
To: Phil; +Cc: linux-hams
In-Reply-To: <200301062005.06383.phil@spiderweb.com.au>
On Tue, Jan 07, 2003 at 02:30:56PM +1000, Phil wrote:
| An Internet search didn't reveal very many programmers for Linux. One
|interesting project is called ponyprog2000. The hardware is more complex than
check the two simple schematics at:
http://www.finitesite.com/d3jsys/
73,
Nuno
--
^ permalink raw reply
* RE: 16 NANDS
From: Marc Neiger @ 2003-01-08 21:23 UTC (permalink / raw)
To: tglx, manningc2, 'linux-mtd@lists.infradead.org'
Hi Thomas,
> I have the framework ready to support different buswidths.
It's dangerous talking to you, guys, one gets easily caught in the maelstrom
;-)
I'll gladly put my share back into the GPLd world, however my timeframe for
the current project is very tight; everything, board, embedded linux and
application should be working in less than 2 months.....
Moreover, although I, and my colleagues, are experienced programmers, both
in embedded and win32, I booted my first Linux about 6 weeks ago....
The project shall be using a customly developped board using AMD Alchemy
AU1000 (MIPS4Kc) processor. The board is planned to support both 8 and
16bits NAND flash, an EPLD shall, among other task, take care of data bus
bits reordering (8 and 16 bits NANDS are pin out compatible except for the
bit order). After reading some msg on this list, we already doubt about the
ease of mounting a root JFFS2 filesystem.
I'll have a look at the framework, then if I have some "time" and I feel
comfortable with your code, I'll try to finish it, and we'll test it on our
first board version. Otherwise, and it seems more likely, after the project
is delivered and we have some experience on Linux, including kernel
development since we are to write a driver for this very specific hardware,
I'll get more seriously hands on the code but without having a very short
deadline in front of me.
I already do much non computer related volunteer work and can not afford to
take on my "free" time anymore.
Cheers,
Marc Neiger
^ permalink raw reply
* Re: [ACPI] RE: kacpidpc needs to die
From: Pavel Machek @ 2003-01-08 20:58 UTC (permalink / raw)
To: Grover, Andrew; +Cc: kernel list, ACPI mailing list
In-Reply-To: <F760B14C9561B941B89469F59BA3A84725A10E@orsmsx401.jf.intel.com>
Hi!
> > safe, anyway],
> > > kacpidpc needs to die. Andrew, are you going to kill it or
> > should I do
> > > it?
> >
> > I can kill it...let me just verify with you --
> > acpi_os_queue_for_execution has a two block switch statement, just use
> > the first block (the case that uses schedule_work) and delete
> > the rest,
> > yes?
>
> Oops, and combine acpi_os_schedule_exec and acpi_os_queue_exec, so that
> we call dpc->function() from the original thread. Anything else?
I don't see anything else, this looks okay.
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: [PATCH] Embed __this_module in module itself.
From: Sam Ravnborg @ 2003-01-08 20:56 UTC (permalink / raw)
To: Miles Bader; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <buoadid1pxl.fsf@mcspd15.ucom.lsi.nec.co.jp>
On Tue, Jan 07, 2003 at 02:36:54PM +0900, Miles Bader wrote:
> Miles Bader <miles@lsi.nec.co.jp> writes:
> > When I try to build modules using 2.5.54, the resulting .ko files lack
> > the .gnu.linkonce.* sections, which causes the kernel module loader to
> > fail on them -- those sections _are_ present in the .o files, but the
> > linker apparently removes them!
>
> Ok, I found out why this is happening -- the v850 default linker
> scripts, for whatever reason, merge any section called `.gnu.linker.t*'
> with .text.
ld per default uses a default linker-scripts as you note.
Could another solution be to provide a fixed linker script, used for all
invocations of ld?
LDFLAGS += -T arch/v850/v850.lds
Not knowing much about v850, I wonder why you do not need to set the -m
option. Most other architectures do this.
Sam
^ permalink raw reply
* RE: [BUG - HRT patch] nanosleep returns 0 on failure
From: Fleischer, Julie N @ 2003-01-08 20:53 UTC (permalink / raw)
To: 'george anzinger', Fleischer, Julie N
Cc: high-res-timers-discourse, linux-kernel
> george anzinger wrote:
> If you don't mind, I will add your test code to my
> clock_nanosleep test code so this does not creep back in.
Sure. It's all GPL. The 6-1.c test case (attached below) probably has the
best test because it does multiple values, some < 0, some >= 1000 million.
One other thing I forgot to write in my previous report is that
clock_nanosleep() appeared to behave as expected, just nanosleep() showed
the issue of returning 0 on failure.
Thanks.
- Julie
----
test 6-1.c
/*
* Copyright (c) 2002, Intel Corporation. All rights reserved.
* Created by: julie.n.fleischer REMOVE-THIS AT intel DOT com
* This file is licensed under the GPL license. For the full content
* of this license, see the COPYING file at the top level of this
* source tree.
* Test that nanosleep() sets errno to EINVAL if rqtp contained a
* nanosecond value < 0 or >= 1,000 million
*/
#include <stdio.h>
#include <time.h>
#include <errno.h>
#define PTS_PASS 0
#define PTS_FAIL 1
#define PTS_UNRESOLVED 2
#define NUMTESTS 7
int main(int argc, char *argv[])
{
struct timespec tssleepfor, tsstorage;
int sleepnsec[NUMTESTS] = {-1, -5, -1000000000, 1000000000,
1000000001, 2000000000, 2000000000 };
int i;
int failure = 0;
tssleepfor.tv_sec=0;
for (i=0; i<NUMTESTS;i++) {
tssleepfor.tv_nsec=sleepnsec[i];
printf("sleep %d\n", sleepnsec[i]);
if (nanosleep(&tssleepfor, &tsstorage) == -1) {
if (EINVAL != errno) {
printf("errno != EINVAL\n");
failure = 1;
}
} else {
printf("nanosleep() did not return -1 on
failure\n");
return PTS_UNRESOLVED;
}
}
if (failure) {
printf("At least one test FAILED\n");
return PTS_FAIL;
} else {
printf("All tests PASSED\n");
return PTS_PASS;
}
}
**These views are not necessarily those of my employer.**
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Jon Portnoy @ 2003-01-08 20:53 UTC (permalink / raw)
To: Giacomo A. Catenazzi; +Cc: rms, linux-kernel
In-Reply-To: <3E1C3D87.7030605@debian.org>
[cc list trimmed, it was getting a little excessive]
On Wed, 8 Jan 2003, Giacomo A. Catenazzi wrote:
>
>
> Richard Stallman wrote:
> > Great. So not only is there no legal need to cite GNU in the Linux
> > name, there is no ethical obligation either.
> >
> > When you take part of my statement, stretch it, interpret it based on
> > assumptions you know I disagree with, and present the result as
> > something I said, that doesn't prove anything. It is childish.
> >
> > There is no ethical obligation to mention secondary contributions
> > incorporated in a large project. There ethical obligation is to cite
> > the main developer. In the GNU/Linux system, the GNU Project is the
> > principal contributor; the system is more GNU than anything else,
> > and we started it.
>
> GNU is not so important in new system. I take gcc and glibc as to be
> outside the GNU project. (they have now the GNU mark only for GNU
> convenience, IMHO) I use "GNU/Linux" only to make more explicit the
> "copyleft" ideas, but surelly not because of the GNU tools.
>
> If you insist with such arguments, you risk that someone will rewrite
> the basic GNU tools outside the GNU project (emacs is not an OS main tool,
> gcc and glibc are de facto outside GNU) (bash will remain GNU ?)
>
> ciao
> giacomo
>
>
> RMS: maybe you can reply me privatly about some more explication of your mail,
> so less OT mail, and privately maybe I can understand more about GNU/Linux flames.
>
Nearly all of your base system except the kernel is GNU. Primarily,
fileutils, sh-utils, and findutils come to mind. These could be replaced,
in which case it would no longer be GNU/Linux. As long as your standard
base system tools (chown, cp, dir, dd, df, du, ls, ln, mkdir, mv, rm,
rmdir, touch, chmod, id, kill, whoami, chroot, who, date, echo,
pwd, uname, and many others) are GNU, it's really GNU/Linux.
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: John Levon @ 2003-01-08 20:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, davem
In-Reply-To: <Pine.LNX.4.44.0301081222430.5369-100000@home.transmeta.com>
On Wed, Jan 08, 2003 at 12:28:23PM -0800, Linus Torvalds wrote:
> doesn't change suddenly on the machine, there's no point at all in doing
> something like this and exporting it through proc, when the information is
> perfectly available in other ways
What other ways ? Dave M reasonably argued it wasn't part of the
architecture's ABI, so did not have a place in the headers.
> or could even be a user program config file option.
Eww.
> Quite frankly, just compile oprofile for the architecture and be done with
> it. Or add a command line option. Don't add stupid bloat to the kernel
> because somebody is silly enough to care about a 32-bit oprofile working
> with a 64-bit kernel.
It's not silly, it's a necessity on architectures like pa-risc, sparc64,
ppc64, etc. where pointers are 32 bit in userspace. OProfile simply
cannot work at all on such systems without being able to figure out the
units of the oprofile kernel buffer.
We could force the oprofile kernel buffer to always be u64s but that
just eats unnecessary space and time on x86.
So, what solution do you suggest instead ?
regards
john
--
"CUT IT OUT FACEHEAD"
- jeffk
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: Petr Vandrovec @ 2003-01-08 20:49 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
On 8 Jan 03 at 10:52, H. Peter Anvin wrote:
>
> > 1. which device is at port address 0xCFB?
>
> Hopefully none.
Actually I'm not sure. This code is here since at least 2.0.28,
and during googling I even found code for direct PCI access
(http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
which sets lowest bit at 0xCFB to 1 before doing PCI config
accesses and reset it back to original value afterward.
So I believe that there were some chipsets (probably in 486&PCI times)
which did conf1/conf2 accesses depending on value of this bit.
Unfortunately I was not able to confirm this - almost nobody provides
northbridge datasheets from '94 era, even Intel does not provide them
(f.e. Neptune) anymore :-(
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply
* Re: how to configure iptables / syslog to log to separate file
From: Chris Shepherd @ 2003-01-08 20:37 UTC (permalink / raw)
To: Randall J. Parr; +Cc: netfilter
In-Reply-To: <3E1C89D7.7000706@TemporalArts.com>
Quoting "Randall J. Parr" <RParr@TemporalArts.COM>:
> Can I, and if so how can I, configure iptables (esp using GuardDog which
> I use to configure iptables) and/or syslog (ie /etc/syslog.conf, ...) so
> that my firewall messages are logged into a file other than
> /var/log/messages?
>
> I have searched, looked at tutorial, etc. and found this question asked
> many times but without ever finding a decent answer.
>
> If it just can not be done, could someone who knows this please state so?
Configure Syslog to log a certain log-level to an alternate file, and then just
use "-j LOG --log-level <level>". ie: if you wanted it to log as a notice,
just setup Syslog to log notices to another file, and drop in a line that reads
like:
iptables -A LOGGING_TABLE -j LOG --log-level notice --log-prefix="NF: "
I'm not too up on Syslog myself, so you should read the docs for that, but I do
believe it is possible to log specific log-levels to an alternate file.
--
Chris Shepherd
-------------------------------------------------
This email may contain confidential information. Use of any such information
is strictly prohibited without express written consent of the sender
^ permalink raw reply
* Re: [Pcihpd-discuss] Re:[BUG] cpci patch for kernel 2.4.19 bug
From: Rusty Lynch @ 2003-01-08 20:44 UTC (permalink / raw)
To: Scott Murray, Rusty Lynch; +Cc: greg, harold.yang, linux-kernel, pcihpd-discuss
In-Reply-To: <Pine.LNX.4.44.0301081453520.15466-100000@rancor.yyz.somanetworks.com>
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
From: "Scott Murray" <scottm@somanetworks.com>
> On Wed, 8 Jan 2003, Rusty Lynch wrote:
>
> > From: "Yang, Harold" <harold.yang@intel.com>
> > >
> > > Hi, Scott & Greg:
> > >
> > > I have applied the cpci patch for kernel 2.4.19, and test it
> > > thoroughly on ZT5084 platform. Two bugs are found:
> > >
> > > 1. In my ZT5084, the driver can't correctly detect the cPCI
> > > Hot Swap bridge device. Two DEC21154 exist on ZT5084,
> > > however, only one is the right bridge. The driver can't
> > > distinguish them correctly.
> >
> > I just got a couple of ZT5541 peripheral master boards
> > and can finally see what happens when an enumerable board
> > is plugged into a ZT5084 chassis using a ZT5550 system master
> > board.
> >
> > As of yet I have only tried a 2.5.54 kernel, but I see the
> > same problems along with some other wacky behavior that I
> > am trying to isolate.
> >
> > Now about the multiple DEC21154 devices ==> on my ZT5550 that
> > is in system master mode, the first DEC21154 device is a bridge
> > for the slots to the left of the system slots, and the second
> > DEC21154 is a bridge for the right of the system slots.
>
> Okay, that's what I originally wanted to determine from the lspci
> output I requested when Harold mentioned this problem at the end
> of November.
>
I am attaching output for:
1. lspci -vvv
2. cat /proc/ioports
3. cat /proc/iomem
For a ZT5550 running as system master in the second system slot
of a ZT5084 chassis that has two ZT5541 (peripherial master) boards
plugged in (one to the left of the sytem slots and the other to
the right of the system slots.)
> > So if I boot the system master (I'll talk about problems with
> > hotswaping in another email) with a peripheral board plugged
> > into one of the slots on the right of the master using the
> > current 2.5.54 kernel then I run into problems the first time
> > cpci_hotplug_core.c::check_slots() runs because it only looks
> > at the first bus when trying to find the card that caused the
> > #ENUM.
>
> I assume by problems you mean that the cPCI event thread gets
> shut down (which is what I'd expect), or do you mean something more
> severe?
>
The event thread shutsdown with the
"cannot find ENUM# source, shutting down" error message. That's all.
> > The following patch will register each of the cpci busses instead
> > of just the first one detected.
>
> Your patch is better than Harold's hack, but I'm probably going to
> try and think of some other alternative, as the while loop idea
> doesn't handle the possibility of someone having a 21154 bridge
> on a PMC card or actually as a bridge on a cPCI card. The original
> code doesn't really handle that possiblity either, so I'll need to
> cook up something better anyway.
>
> > NOTE: I'm a little worried that the right way to do this is to
> > properly initialize the RSS bits, or at least see how the
> > chassis is configured via the RSS bits to determine which
> > cpci bus to register. The ZT5084 doesn't have near as many
> > configurations as newer designs like the ZT5088.
> [snip]
>
> I will investigate reading the active bus(es) out of the HC, as I've
> gotten the documentation for the HC from Performance Tech, I was just
> too busy before Christmas to dig into it then. I'll try and have
> something that attempts to handle your ZT5084 chassis done in a few
> days.
>
> Scott
[-- Attachment #2: lspci_system_master.txt --]
[-- Type: text/plain, Size: 7070 bytes --]
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: <available only to root>
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f5000000-f5ffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+
00:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 165 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1080 [size=128]
Region 1: Memory at f4001000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
00:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 165 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1400 [size=128]
Region 1: Memory at f4001400 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at 14a0 [size=16]
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at 1060 [size=32]
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
00:08.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Bus: primary=00, secondary=02, subordinate=02, sec-latency=68
I/O behind bridge: 00002000-00002fff
Memory behind bridge: f6000000-f61fffff
Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
00:0b.0 Class ff00: Ziatech Corporation: Unknown device 5550 (rev 03)
Subsystem: Ziatech Corporation: Unknown device 5550
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1480 [size=32]
Region 1: Memory at f4000000 (32-bit, non-prefetchable) [size=4K]
00:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Bus: primary=00, secondary=03, subordinate=03, sec-latency=68
I/O behind bridge: 00003000-00003fff
Memory behind bridge: f6200000-f63fffff
Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: <available only to root>
01:00.0 VGA compatible controller: Chips and Technologies F69000 HiQVideo (rev 64) (prog-if 00 [VGA])
Subsystem: Chips and Technologies F69000 HiQVideo
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled] [size=256K]
02:0d.0 Bridge: Digital Equipment Corporation DECchip 21554 (rev 01)
Subsystem: Ziatech Corporation: Unknown device 5541
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f6101000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 2400 [size=256]
Region 2: I/O ports at 2000 [size=256]
Region 3: Memory at f6000000 (32-bit, non-prefetchable) [size=1M]
Region 4: Memory at f6100000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
03:0a.0 Bridge: Digital Equipment Corporation DECchip 21554 (rev 01)
Subsystem: Ziatech Corporation: Unknown device 5541
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f6301000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3400 [size=256]
Region 2: I/O ports at 3000 [size=256]
Region 3: Memory at f6200000 (32-bit, non-prefetchable) [size=1M]
Region 4: Memory at f6300000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
[-- Attachment #3: proc_iomem.txt --]
[-- Type: text/plain, Size: 1221 bytes --]
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c9800-000c9fff : Extension ROM
000ca000-000ca7ff : Extension ROM
000f0000-000fffff : System ROM
00100000-0fffffff : System RAM
00100000-002fda29 : Kernel code
002fda2a-003c7d67 : Kernel data
f4000000-f4000fff : PCI device 1138:5550 (Ziatech Corporation)
f4000000-f4000fff : cpcihp_zt5550
f4001000-f40013ff : Digital Equipment Co DECchip 21142/43
f4001000-f40013ff : tulip
f4001400-f40017ff : Digital Equipment Co DECchip 21142/43 (#2)
f4001400-f40017ff : tulip
f5000000-f5ffffff : PCI Bus #01
f5000000-f5ffffff : Chips and Technologi F69000 HiQVideo
f6000000-f61fffff : PCI Bus #02
f6000000-f60fffff : Digital Equipment Co DECchip 21554
f6100000-f6100fff : Digital Equipment Co DECchip 21554
f6101000-f6101fff : Digital Equipment Co DECchip 21554
f6200000-f63fffff : PCI Bus #03
f6200000-f62fffff : Digital Equipment Co DECchip 21554 (#2)
f6300000-f6300fff : Digital Equipment Co DECchip 21554 (#2)
f6301000-f6301fff : Digital Equipment Co DECchip 21554 (#2)
f8000000-fbffffff : Intel Corp. 440BX/ZX/DX - 82443B
fffc0000-ffffffff : reserved
[-- Attachment #4: proc_ioports.txt --]
[-- Type: text/plain, Size: 1018 bytes --]
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00e1-00e1 : #ENUM hotswap signal register
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-103f : Intel Corp. 82371AB/EB/MB PIIX4
1040-105f : Intel Corp. 82371AB/EB/MB PIIX4
1060-107f : Intel Corp. 82371AB/EB/MB PIIX4
1080-10ff : Digital Equipment Co DECchip 21142/43
1080-10ff : tulip
1400-147f : Digital Equipment Co DECchip 21142/43 (#2)
1400-147f : tulip
1480-149f : PCI device 1138:5550 (Ziatech Corporation)
14a0-14af : Intel Corp. 82371AB/EB/MB PIIX4
2000-2fff : PCI Bus #02
2000-20ff : Digital Equipment Co DECchip 21554
2400-24ff : Digital Equipment Co DECchip 21554
3000-3fff : PCI Bus #03
3000-30ff : Digital Equipment Co DECchip 21554 (#2)
3400-34ff : Digital Equipment Co DECchip 21554 (#2)
^ permalink raw reply
* Re: [PATCH][TRIVIAL] menuconfig color sanityExpires:
From: H. Peter Anvin @ 2003-01-08 20:43 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.3.96.1030108095857.21895A-100000@gatekeeper.tmr.com>
Followup to: <Pine.LNX.3.96.1030108095857.21895A-100000@gatekeeper.tmr.com>
By author: Bill Davidsen <davidsen@tmr.com>
In newsgroup: linux.dev.kernel
>
> Man, did you look at this on a console? That is uglier than a hedgehog's
> asshole! Good idea, poor implementation. Please retry, the default colors
> are not as bad on an xterm as the new colors on a console. And with small
> memory machines I sure don't build kernels using X!
>
Also, whatever color set is chosen: make sure it works on a
512-character font console, which doesn't have the high-intensity
colors.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* ksymoops and 64 bit mips
From: Gilad Benjamini @ 2003-01-08 20:15 UTC (permalink / raw)
To: linux-mips
I tried using ksymoops to analyze an oops on my 64 bit SMP mips kernel.
I am running ksymoops on x86 platform.
Initially I got a lot of garbage.
Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and
-t elf32-little reduced
the amount of garbage, but still all the output shown
was "No symbol available".
Any additional things I should do ?
TIA
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: H. Peter Anvin @ 2003-01-08 20:40 UTC (permalink / raw)
To: Nakajima, Jun; +Cc: linux-kernel
In-Reply-To: <3014AAAC8E0930438FD38EBF6DCEB5647D0D1C@fmsmsx407.fm.intel.com>
Nakajima, Jun wrote:
>
> Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
> We do not encourage use of byte accesses as it will not be supported in future platforms.
>
The PCI standard is quite explicit: byte accesses are permitted to the
data window (0xCFC) and not permitted to the address window (0xCF8).
Accepting byte accesses to the address window, or not supporting byte
accesses to the data window, *will* result in breakage (I can attest to
this fact quite well.)
-hpa
^ 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.