* Re: IDE module problem
From: Keith Owens @ 2002-12-12 2:56 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Jun Sun, linux-mips
In-Reply-To: <Pine.GSO.3.96.1021211181032.22157L-100000@delta.ds2.pg.gda.pl>
On Wed, 11 Dec 2002 18:20:30 +0100 (MET),
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:
>On Wed, 11 Dec 2002, Jun Sun wrote:
>
>> > > This is because arch/mips/lib/Makefile says:
>> > >
>> > > obj-$(CONFIG_IDE) += ide-std.o ide-no.o
>> > [...]
>> > > 3) use some smart trick in Makefile so that we include those
>> > > two files only if CONFIG_IDE is 'y' or 'm'. (How?)
>> >
>> > obj-$(CONFIG_IDE_MODULE)
>>
>> This does not work. Apparently, CONFIG_IDE_MODULE is not created
>> for makefile part.
>
> Indeed -- my fault. Variables such as $(CONFIG_IDE) are four-state and
>for the module case they are simply set to "m". But then you can use
>"ifeq ($(CONFIG_IDE),m)". Another approach is to invent an additional
>variable automatically set to "y" whenever CONFIG_IDE is enabled.
obj-$(subst m,y,$(CONFIG_IDE)) += ide-std.o ide-no.o
ide-std.o ide-no.o are built in if CONFIG_IDE is m or y.
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Donald Becker @ 2002-12-12 2:42 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev
In-Reply-To: <20021211132436.GA12529@k3.hellgate.ch>
On Wed, 11 Dec 2002, Roger Luethi wrote:
> pci-skeleton (and some other net drivers) figure out the duplex setting
> like this (leaving duplex locks out here):
>
> int duplex = (lpar & 0x0100) || (lpar & 0x01C0) == 0x0040;
I'm not certain what version of pci-skeleton.c you are looking at, but
the current version is
int mii_reg5 = mdio_read(dev, np->phys[0], 5);
int negotiated = mii_reg5 & np->advertising;
int duplex = (negotiated & 0x0100) || (negotiated & 0x01C0) == 0x0040;
We are looking for the highest negotiated capability, according to the
rules described in
http://scyld.com/expert/NWay.html
You did read the reference documentation, didn't you?
I put the documentation references at the top of the driver because you
may need to read them to understand what is going on. Or was it so
unusual to have written priciples of operation that you skipped that
section?
I'll explain the cases:
(negotiated & 0x0100) 100baseTx full duplex
or
(negotiated & 0x01C0) == 0x0040 No capability above 10baseT full duplex
Note that the second check ignores 100baseT4, despite it have priority
over 10baseT-*. That was intentional to work around, "a specific issue"
with a transceiver.
> If we get past the first condition, we already know bit 8 must be 0. Why do
> we check again in the second condition?
The is no extra cost to the extra bit, and it makes it clear we are
testing for 10baseT-FDX.
(The test was originally implemented as part of a complete set of
cases. The test code needed while building a driver is more complex
than what you see in the concise final result.)
--
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
^ permalink raw reply
* Re: [Printing-architecture] Meeting on the 9th of January?
From: Norm Jacobs @ 2002-12-12 2:42 UTC (permalink / raw)
To: HEMSTREET,CHARLES (HP-Vancouver,ex1)
Cc: 'printing-architecture@freestandards.org'
In-Reply-To: <6D805D4C4567D411AF32009027B683510ECA5F89@xvan02.vcd.hp.com>
I don't have a problem with canceling the meeting for the next few
weeks, I'm sure that discussion will continue via email. I would
like to get some idea as to when we are planning our next summit.
Someone suggested that we hold it in NY at LinuxWorld (January 21-24).
If we are going to plan on having a summit then, we should decide before
the holidays so that people can attempt to make arrangements early.
-Norm
"HEMSTREET,CHARLES (HP-Vancouver,ex1)" wrote:
>
> Folks:
>
> In line with the Job Ticket folks, and the holidays, I would like to cancel
> the printing-architecture meeting for the next few weeks.
>
> Unless someone objects, let's plan on reconvening on the 9th of January.
>
> Happy Holidays,
> Charles
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@freestandards.org
> http://freestandards.org/mailman/listinfo/printing-architecture
^ permalink raw reply
* Re: Vaguely NFS related problem
From: Jeff L. Smith @ 2002-12-12 2:41 UTC (permalink / raw)
To: nfs
I should also add that I realize this an RPC problem, not and NFS
problem (hence vaguely NFS related), but this is being tickled by the
NFS server so I was hoping someone else had seen this.
Jeff
-------- Original Message --------
Subject: Re: [NFS] Vaguely NFS related problem
Date: Thu, 12 Dec 2002 13:12:34 +1100
From: Neil Brown <neilb@cse.unsw.edu.au>
To: "Jeff L. Smith" <jeff@atheros.com>
CC: nfs@lists.sourceforge.net
References: <3DF7EA94.20108@atheros.com>
On Wednesday December 11, jeff@atheros.com wrote:
> We have been running a couple of machines (PIII with Mylex Extreme 2000
> SCSI RAID, RH7.3, 2.4.18 kernel, 64 nfsd's) which only act as NFS
> fileservers. When either of these servers start getting busy, I start
> seeing a lot of the following messages:
>
> Dec 8 15:27:58 localhost kernel: RPC: Unable to allocate resbuf from
cache!
This message is not part of any 'vanilla' release kernel. It must be
a redhat-special. Ask redhat.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
--
Jeff Smith Atheros Communications, Inc.
Hardware Manager 529 Almanor Avenue
(408) 773-5257 Sunnyvale, CA 94086
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH 2.5] SGI O2 framebuffer driver
From: Ralf Baechle @ 2002-12-12 2:33 UTC (permalink / raw)
To: Alan Cox; +Cc: Vivien Chappelier, linux-mips, Ilya Volynets
In-Reply-To: <1039656676.18587.63.camel@irongate.swansea.linux.org.uk>
On Thu, Dec 12, 2002 at 01:31:16AM +0000, Alan Cox wrote:
> On Wed, 2002-12-11 at 23:41, Vivien Chappelier wrote:
> > linear framebuffer (up to 8MB with 64kB granularity). I'm then remapping
> > all those pages to one virtual region obtained from get_vm_area so that
> > 1. caching attributes can be set to cacheable write-through no WA
>
> Ick. The framebuffer can't handle cached and write barriers ?
The O2 is non-cache coherent. So with the fairly large write-back second
level caches enabled frame buffer write could potencially be delayed
indefinately but in any case quite long. Frame buffers are usually only
written to, so the cache mode "uncached accelerated" seems preferable
but only the R10000 provides this mode, so for the R5000 write-though no
write allocation is the next best solution.
Ralf
^ permalink raw reply
* strange bug rmap15a
From: Rik van Riel @ 2002-12-12 2:39 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-mm
OK, something between rmap15 and rmap15a is triggering the
following bug, where launder_page() really doesn't know
what to do with a page that:
1) has a page->count of 1
2) does not have mapping, buffers, or pte_chain set
3) is clean
mystery page c1028220, cnt 1 map 00000000, buf 00000000, ptec 00000000, dirty 0
I don't know how the pages end up in this situation, but it's
not a pretty sight and effectively kills the machine...
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
--
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: Vaguely NFS related problem
From: Jeff L. Smith @ 2002-12-12 2:37 UTC (permalink / raw)
To: Neil Brown; +Cc: nfs
In-Reply-To: <15863.61586.150820.505519@notabene.cse.unsw.edu.au>
I'm running a kernel I built from kernel.org source. I found the
message in linux-2.4.18/net/sunrpc/svcsock.c.
printk (KERN_WARNING "RPC: Unable to allocate resbuf from cache!\n");
Jeff
Neil Brown wrote:
> On Wednesday December 11, jeff@atheros.com wrote:
>
>>We have been running a couple of machines (PIII with Mylex Extreme 2000
>>SCSI RAID, RH7.3, 2.4.18 kernel, 64 nfsd's) which only act as NFS
>>fileservers. When either of these servers start getting busy, I start
>>seeing a lot of the following messages:
>>
>>Dec 8 15:27:58 localhost kernel: RPC: Unable to allocate resbuf from cache!
>
>
> This message is not part of any 'vanilla' release kernel. It must be
> a redhat-special. Ask redhat.
>
> NeilBrown
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
--
Jeff Smith Atheros Communications, Inc.
Hardware Manager 529 Almanor Avenue
(408) 773-5257 Sunnyvale, CA 94086
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [linux-lvm] vgcreate on md: vgcreate -- ERROR "pv_read(): read" reading physical volumes
From: udo @ 2002-12-12 2:16 UTC (permalink / raw)
To: linux-lvm
Hello,
I noticed my kernel has LVM 1.0.5 but my tools were
1.0.3. I built the 1.0.6 tools but they gave the same
error.
Please advise.
Thanks,
Udo
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: Vaguely NFS related problem
From: Neil Brown @ 2002-12-12 2:12 UTC (permalink / raw)
To: Jeff L. Smith; +Cc: nfs
In-Reply-To: <3DF7EA94.20108@atheros.com>
On Wednesday December 11, jeff@atheros.com wrote:
> We have been running a couple of machines (PIII with Mylex Extreme 2000
> SCSI RAID, RH7.3, 2.4.18 kernel, 64 nfsd's) which only act as NFS
> fileservers. When either of these servers start getting busy, I start
> seeing a lot of the following messages:
>
> Dec 8 15:27:58 localhost kernel: RPC: Unable to allocate resbuf from cache!
This message is not part of any 'vanilla' release kernel. It must be
a redhat-special. Ask redhat.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: How to get the IPv6 address of next hop towards destination?
From: Zheng Jianping @ 2002-12-12 2:11 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20021129.131656.766932499.yoshfuji@linux-ipv6.org>
Hi, Yoshfuji,
What's type of the address stored in primary_key[0], link-local or global?
Thanks,
Zheng
> In article <000d01c2975d$a2ad3c10$6c06a8c0@zhengjp> (at Fri, 29 Nov 2002
12:13:13 +0800), "Zheng Jianping" <zjp@iscas.ac.cn> says:
>
> > It seems that
> > u8 primary_key[0];
> > is responsible for it.
> >
> > Is it right?
>
> yes.
>
> --yoshfuji
>
>
^ permalink raw reply
* Re: capable open_port() check wrong for kmem
From: Chris Wright @ 2002-12-12 2:11 UTC (permalink / raw)
To: carbonated beverage; +Cc: linux-kernel
In-Reply-To: <20021212013849.GA24054@net-ronin.org>
* carbonated beverage (ramune@net-ronin.org) wrote:
>
> So if I want to have a generic utility that can be used by any user (and
> I'm not granting CAP_SYS_RAWIO to every process), then I can:
>
> 1) make it suid root
> 2) drop all caps other than cap_sys_rawio
>
> or
>
> 1) add the capability to the executable, assuming it worked...
this is not supported without kernel patches. in general you have to
start with full capabilities and shed the ones you don't need.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [Linux-ia64] kernel update (relative to 2.4.20)
From: Matthew Wilcox @ 2002-12-12 2:00 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590678205111@msgid-missing>
On Tue, Dec 10, 2002 at 09:44:12PM -0700, Bjorn Helgaas wrote:
> The latest ia64 kernel patch for Linux 2.4.20 is available here:
>
> ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.4/linux-2.4.20-ia64-021210.diff.gz
I've uploaded a version of the latest ACPI code as a patch against this
release to http://sourceforge.net/project/showfiles.php?group_id6832
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: kernel update (relative to 2.4.20)
From: Matthew Wilcox @ 2002-12-12 2:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-ia64-WygotPe7DYIabbyE177sbg,
acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <200212102144.13053.bjorn_helgaas-VXdhtT5mjnY@public.gmane.org>
On Tue, Dec 10, 2002 at 09:44:12PM -0700, Bjorn Helgaas wrote:
> The latest ia64 kernel patch for Linux 2.4.20 is available here:
>
> ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.4/linux-2.4.20-ia64-021210.diff.gz
I've uploaded a version of the latest ACPI code as a patch against this
release to http://sourceforge.net/project/showfiles.php?group_id=36832
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: romfs
From: Miles Bader @ 2002-12-12 2:06 UTC (permalink / raw)
To: Garst R. Reese; +Cc: linux-kernel
In-Reply-To: <3DF7CC90.99585A8C@isn.net>
"Garst R. Reese" <reese@isn.net> writes:
> Is there a current maintainer for romfs?
Try:
http://romfs.sourceforge.net
-Miles
--
Yo mama's so fat when she gets on an elevator it HAS to go down.
^ permalink raw reply
* Re: [BK PATCH] Dynamic MP_BUSSES and IRQ_SOURCES for 2.4.21-pre1
From: Matt Domsch @ 2002-12-12 2:06 UTC (permalink / raw)
To: Greg KH; +Cc: marcelo, linux-kernel
In-Reply-To: <20021212015326.GI16615@kroah.com>
> The first patch fixes a problem for machines that have more busses or
> irq sources than MAX_MP_BUSSES or MAX_IRQ_SOURCES has been set to.
> time.
Thanks Greg, indeed this is required for our PowerEdge 6600 system also,
when one adds PCI cards with PCI bridges (dual-port NICs, RAID cards,
etc).
> This patch was originally written by James Cleverdon, and has been in
> the -ac tree for quite some time. I also think Red Hat includes it in
> their main kernel, but am not sure.
Yes, Red Hat kernels > 2.4.7-10 and >= 2.4.9-e.3 include this.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
^ permalink raw reply
* Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
From: David Dawes @ 2002-12-12 1:58 UTC (permalink / raw)
To: Nicolas ASPERT
Cc: Margit Schubert-While, linux-kernel, davej, faith, dri-devel
In-Reply-To: <3DF72A91.5080804@epfl.ch>
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote:
>Margit Schubert-While wrote:
>> From drivers/char/agp/agpgart_be.c
>> 4554,4559
>> { PCI_DEVICE_ID_INTEL_845_G_0,
>> PCI_VENDOR_ID_INTEL,
>> INTEL_I845_G,
>> "Intel",
>> "i845G",
>> intel_830mp_setup },
>>
>> Surely this is wrong or ?
>> Should be "intel_845_setup", I think.
>>
>
>IIRC, the 845G is a "new" version of the 830MP chipset (it had been
>added by Abraham vd Merwe & Graeme Fisher some months ago), but acts
>basically just as the 830MP. Therefore the entry is correct.... Or maybe
>if it gets confusing adding a comment would not hurt...
No, I think it should be intel_845_setup too, since the 845G docs on
Intel's public web site show that the behaviour is like the 845 when
the on-board graphics isn't enabled. I made that change in my
locally maintained version of the agpgart driver a little while ago,
but haven't had the opportunity to test it with an external AGP card
in an 845G box yet.
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
^ permalink raw reply
* Re: [PATCH] Dynamic MP_BUSSES and IRQ_SOURCES for 2.4.21-pre1
From: Greg KH @ 2002-12-12 1:55 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
In-Reply-To: <20021212015454.GJ16615@kroah.com>
ChangeSet 1.813, 2002/12/11 17:44:54-08:00, greg@kroah.com
mpparse.c: Fix a minor code formatting issue.
diff -Nru a/arch/i386/kernel/mpparse.c b/arch/i386/kernel/mpparse.c
--- a/arch/i386/kernel/mpparse.c Wed Dec 11 17:49:48 2002
+++ b/arch/i386/kernel/mpparse.c Wed Dec 11 17:49:48 2002
@@ -234,7 +234,7 @@
if (m->mpc_apicid > MAX_APICS) {
printk("Processor #%d INVALID. (Max ID: %d).\n",
m->mpc_apicid, MAX_APICS);
- --num_processors;
+ --num_processors;
return;
}
ver = m->mpc_apicver;
^ permalink raw reply
* [PATCH] Dynamic MP_BUSSES and IRQ_SOURCES for 2.4.21-pre1
From: Greg KH @ 2002-12-12 1:54 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
In-Reply-To: <20021212015326.GI16615@kroah.com>
ChangeSet 1.812, 2002/12/11 11:53:05-08:00, greg@kroah.com
[PATCH] dynamic MAX_MP_BUSSES and MAX_IRQ_SOURCES
Here's a patch that fixes a problem for machines
that have more busses or irq sources than MAX_MP_BUSSES or
MAX_IRQ_SOURCES has been set to. This happens on some Intel Foster
machines (or whatever they are calling the processors now) when a PCI
bus expansion unit is plugged in at boot time.
Without this patch, those machines can not boot Linux.
If the machine needs more busses or interrupts, they will be dynamically
allocated at boot time. If not, the existing MAX_MP_BUSSES and
MAX_IRW_SOURCES value will be used. Once nice side effect of this patch
is when running a SMP kernel on a UP machine without a MP table, less
kernel memory is used than without the patch.
This patch was originally written by James Cleverdon.
diff -Nru a/arch/i386/kernel/mpparse.c b/arch/i386/kernel/mpparse.c
--- a/arch/i386/kernel/mpparse.c Wed Dec 11 17:49:52 2002
+++ b/arch/i386/kernel/mpparse.c Wed Dec 11 17:49:52 2002
@@ -36,18 +36,20 @@
* MP-table.
*/
int apic_version [MAX_APICS];
-int mp_bus_id_to_type [MAX_MP_BUSSES];
-int mp_bus_id_to_node [MAX_MP_BUSSES];
-int mp_bus_id_to_local [MAX_MP_BUSSES];
int quad_local_to_mp_bus_id [NR_CPUS/4][4];
-int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { [0 ... MAX_MP_BUSSES-1] = -1 };
int mp_current_pci_id;
+int *mp_bus_id_to_type;
+int *mp_bus_id_to_node;
+int *mp_bus_id_to_local;
+int *mp_bus_id_to_pci_bus;
+int max_mp_busses;
+int max_irq_sources;
/* I/O APIC entries */
struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
/* # of MP IRQ source entries */
-struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
+struct mpc_config_intsrc *mp_irqs;
/* MP IRQ source entries */
int mp_irq_entries;
@@ -313,7 +315,7 @@
m->mpc_irqtype, m->mpc_irqflag & 3,
(m->mpc_irqflag >> 2) & 3, m->mpc_srcbus,
m->mpc_srcbusirq, m->mpc_dstapic, m->mpc_dstirq);
- if (++mp_irq_entries == MAX_IRQ_SOURCES)
+ if (++mp_irq_entries == max_irq_sources)
panic("Max # of irq sources exceeded!!\n");
}
@@ -406,6 +408,9 @@
char oem[16], prod[14];
int count=sizeof(*mpc);
unsigned char *mpt=((unsigned char *)mpc)+count;
+ int num_bus = 0;
+ int num_irq = 0;
+ unsigned char *bus_data;
if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
panic("SMP mptable: bad signature [%c%c%c%c]!\n",
@@ -453,9 +458,70 @@
mpc_record = 0;
}
+ /* Pre-scan to determine the number of bus and
+ * interrupts records we have
+ */
+ while (count < mpc->mpc_length) {
+ switch (*mpt) {
+ case MP_PROCESSOR:
+ mpt += sizeof(struct mpc_config_processor);
+ count += sizeof(struct mpc_config_processor);
+ break;
+ case MP_BUS:
+ ++num_bus;
+ mpt += sizeof(struct mpc_config_bus);
+ count += sizeof(struct mpc_config_bus);
+ break;
+ case MP_INTSRC:
+ ++num_irq;
+ mpt += sizeof(struct mpc_config_intsrc);
+ count += sizeof(struct mpc_config_intsrc);
+ break;
+ case MP_IOAPIC:
+ mpt += sizeof(struct mpc_config_ioapic);
+ count += sizeof(struct mpc_config_ioapic);
+ break;
+ case MP_LINTSRC:
+ mpt += sizeof(struct mpc_config_lintsrc);
+ count += sizeof(struct mpc_config_lintsrc);
+ break;
+ default:
+ count = mpc->mpc_length;
+ break;
+ }
+ }
+ /*
+ * Paranoia: Allocate one extra of both the number of busses and number
+ * of irqs, and make sure that we have at least 4 interrupts per PCI
+ * slot. But some machines do not report very many busses, so we need
+ * to fall back on the older defaults.
+ */
+ ++num_bus;
+ max_mp_busses = max(num_bus, MAX_MP_BUSSES);
+ if (num_irq < (4 * max_mp_busses))
+ num_irq = 4 * num_bus; /* 4 intr/PCI slot */
+ ++num_irq;
+ max_irq_sources = max(num_irq, MAX_IRQ_SOURCES);
+
+ count = (max_mp_busses * sizeof(int)) * 4;
+ count += (max_irq_sources * sizeof(struct mpc_config_intsrc));
+ bus_data = alloc_bootmem(count);
+ if (!bus_data) {
+ printk(KERN_ERR "SMP mptable: out of memory!\n");
+ return 0;
+ }
+ mp_bus_id_to_type = (int *)&bus_data[0];
+ mp_bus_id_to_node = (int *)&bus_data[(max_mp_busses * sizeof(int))];
+ mp_bus_id_to_local = (int *)&bus_data[(max_mp_busses * sizeof(int)) * 2];
+ mp_bus_id_to_pci_bus = (int *)&bus_data[(max_mp_busses * sizeof(int)) * 3];
+ mp_irqs = (struct mpc_config_intsrc *)&bus_data[(max_mp_busses * sizeof(int)) * 4];
+ memset(mp_bus_id_to_pci_bus, -1, max_mp_busses);
+
/*
* Now process the configuration blocks.
*/
+ count = sizeof(*mpc);
+ mpt = ((unsigned char *)mpc)+count;
while (count < mpc->mpc_length) {
switch(*mpt) {
case MP_PROCESSOR:
diff -Nru a/include/asm-i386/io_apic.h b/include/asm-i386/io_apic.h
--- a/include/asm-i386/io_apic.h Wed Dec 11 17:49:52 2002
+++ b/include/asm-i386/io_apic.h Wed Dec 11 17:49:52 2002
@@ -97,7 +97,7 @@
extern int mp_irq_entries;
/* MP IRQ source entries */
-extern struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
+extern struct mpc_config_intsrc *mp_irqs;
/* non-0 if default (table-less) MP configuration */
extern int mpc_default_type;
diff -Nru a/include/asm-i386/mpspec.h b/include/asm-i386/mpspec.h
--- a/include/asm-i386/mpspec.h Wed Dec 11 17:49:52 2002
+++ b/include/asm-i386/mpspec.h Wed Dec 11 17:49:52 2002
@@ -198,11 +198,11 @@
MP_BUS_PCI,
MP_BUS_MCA
};
-extern int mp_bus_id_to_type [MAX_MP_BUSSES];
-extern int mp_bus_id_to_node [MAX_MP_BUSSES];
-extern int mp_bus_id_to_local [MAX_MP_BUSSES];
+extern int *mp_bus_id_to_type;
+extern int *mp_bus_id_to_node;
+extern int *mp_bus_id_to_local;
+extern int *mp_bus_id_to_pci_bus;
extern int quad_local_to_mp_bus_id [NR_CPUS/4][4];
-extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
extern unsigned int boot_cpu_physical_apicid;
extern unsigned long phys_cpu_present_map;
@@ -211,11 +211,9 @@
extern void get_smp_config (void);
extern int nr_ioapics;
extern int apic_version [MAX_APICS];
-extern int mp_bus_id_to_type [MAX_MP_BUSSES];
extern int mp_irq_entries;
-extern struct mpc_config_intsrc mp_irqs [MAX_IRQ_SOURCES];
+extern struct mpc_config_intsrc *mp_irqs;
extern int mpc_default_type;
-extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
extern int mp_current_pci_id;
extern unsigned long mp_lapic_addr;
extern int pic_mode;
^ permalink raw reply
* Vaguely NFS related problem
From: Jeff L. Smith @ 2002-12-12 1:47 UTC (permalink / raw)
To: nfs
We have been running a couple of machines (PIII with Mylex Extreme 2000
SCSI RAID, RH7.3, 2.4.18 kernel, 64 nfsd's) which only act as NFS
fileservers. When either of these servers start getting busy, I start
seeing a lot of the following messages:
Dec 8 15:27:58 localhost kernel: RPC: Unable to allocate resbuf from cache!
I does not seem to cause any problems (things keep running with no
obvious corruption) but this surly cannot be good. Is there something I
need to tune or a FAQ I could review?
Jeff
--
Jeff Smith Atheros Communications, Inc.
Hardware Manager 529 Almanor Avenue
(408) 773-5257 Sunnyvale, CA 94086
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [BK PATCH] Dynamic MP_BUSSES and IRQ_SOURCES for 2.4.21-pre1
From: Greg KH @ 2002-12-12 1:53 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
Here is a bk tree with two changesets that fix some problems with
mpparse.c.
The first patch fixes a problem for machines that have more busses or
irq sources than MAX_MP_BUSSES or MAX_IRQ_SOURCES has been set to. This
happens on some Intel Foster machines (or whatever they are calling the
processors now) when a PCI bus expansion unit is plugged in at boot
time.
Without this patch, those machines can not boot Linux.
If the machine needs more busses or interrupts, they will be dynamically
allocated at boot time. If not, the existing MAX_MP_BUSSES and
MAX_IRW_SOURCES value will be used. Once nice side effect of this patch
is when running a SMP kernel on a UP machine without a MP table, less
kernel memory is used than without the patch.
This patch was originally written by James Cleverdon, and has been in
the -ac tree for quite some time. I also think Red Hat includes it in
their main kernel, but am not sure.
There's also a minor patch to fix a formatting error in mpparse.c too.
Please pull from:
bk://linuxusb.bkbits.net/marcelo-smp-2.4
Patches will be sent as a response to this message for those who want to
see them.
thanks,
greg k-h
arch/i386/kernel/mpparse.c | 80 +++++++++++++++++++++++++++++++++++++++++----
include/asm-i386/io_apic.h | 2 -
include/asm-i386/mpspec.h | 12 ++----
3 files changed, 79 insertions(+), 15 deletions(-)
-----
ChangeSet@1.813, 2002-12-11 17:44:54-08:00, greg@kroah.com
mpparse.c: Fix a minor code formatting issue.
arch/i386/kernel/mpparse.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
------
ChangeSet@1.812, 2002-12-11 11:53:05-08:00, greg@kroah.com
[PATCH] dynamic MAX_MP_BUSSES and MAX_IRQ_SOURCES
Here's a patch that fixes a problem for machines
that have more busses or irq sources than MAX_MP_BUSSES or
MAX_IRQ_SOURCES has been set to. This happens on some Intel Foster
machines (or whatever they are calling the processors now) when a PCI
bus expansion unit is plugged in at boot time.
Without this patch, those machines can not boot Linux.
If the machine needs more busses or interrupts, they will be dynamically
allocated at boot time. If not, the existing MAX_MP_BUSSES and
MAX_IRW_SOURCES value will be used. Once nice side effect of this patch
is when running a SMP kernel on a UP machine without a MP table, less
kernel memory is used than without the patch.
This patch was originally written by James Cleverdon.
arch/i386/kernel/mpparse.c | 78 +++++++++++++++++++++++++++++++++++++++++----
include/asm-i386/io_apic.h | 2 -
include/asm-i386/mpspec.h | 12 ++----
3 files changed, 78 insertions(+), 14 deletions(-)
------
^ permalink raw reply
* [PATCH] declare and export scsi_bus_type
From: Matt Domsch @ 2002-12-12 1:46 UTC (permalink / raw)
To: linux-scsi; +Cc: mochel
Below please find a patch, written by Pat Mochel, to declare and export
scsi_bus_type. My EDD code requires this to be exported in order to walk
the list of SCSI devices to match what BIOS discovered.
Please apply.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
===== drivers/scsi/scsi.h 1.50 vs edited =====
--- 1.50/drivers/scsi/scsi.h Thu Nov 28 08:09:53 2002
+++ edited/drivers/scsi/scsi.h Thu Dec 5 19:05:27 2002
@@ -994,4 +994,6 @@
extern int scsi_sysfs_register(void);
extern void scsi_sysfs_unregister(void);
+extern struct bus_type scsi_bus_type;
+
#endif
===== drivers/scsi/scsi_sysfs.c 1.1 vs edited =====
--- 1.1/drivers/scsi/scsi_sysfs.c Thu Nov 28 12:54:06 2002
+++ edited/drivers/scsi/scsi_sysfs.c Thu Dec 5 19:06:55 2002
@@ -84,7 +84,7 @@
}
-static struct bus_type scsi_bus_type = {
+struct bus_type scsi_bus_type = {
.name = "scsi",
.match = scsi_bus_match,
};
@@ -202,3 +202,5 @@
device_remove_file(&sdev->sdev_driverfs_dev, &dev_attr_type);
device_unregister(&sdev->sdev_driverfs_dev);
}
+
+EXPORT_SYMBOL(scsi_bus_type);
^ permalink raw reply
* Re: problems with ALSA
From: dashielljt @ 2002-12-12 1:46 UTC (permalink / raw)
To: r4mz3z; +Cc: linux-newbie
In-Reply-To: <200212110750.08044.r4mz3z@yahoo.es>
Have you tried: lspci -v >lspci.log <cr> then had a look inside of
lspci.log to see if you could find your sound card? If it's a p&P sound
card only this won't work, but if it's in a pci slot it's possible lspci
-v can give you the vendor and type of card which may be enough to get
alsa going correctly. That should also provide you port info, but even
before that perhaps dmesg >dmesg.log as root and reading down that file to
see if the system even finds a sound card would be useful.
Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: capable open_port() check wrong for kmem
From: carbonated beverage @ 2002-12-12 1:38 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021211164348.A26790@figure1.int.wirex.com>
On Wed, Dec 11, 2002 at 04:43:48PM -0800, Chris Wright wrote:
[snip]
> If you have only one capability (CAP_SYS_RAWIO), you are not owner of
> /dev/kmem, you are in group kmem, and /dev/kmem is 0640, then all you will
> get is read-only access to /dev/kmem. This does not require kernel changes.
So if I want to have a generic utility that can be used by any user (and
I'm not granting CAP_SYS_RAWIO to every process), then I can:
1) make it suid root
2) drop all caps other than cap_sys_rawio
or
1) add the capability to the executable, assuming it worked...
Script started on Wed Dec 11 17:29:14 2002
UB6IB9:/home/ramune/src/hack# setcap 'cap_sys_rawio=eip' ./a.out
Failed to set capabilities on file `./a.out'
(Function not implemented)
usage: setcap [-q] (-|<caps>) <filename> [ ... (-|<capsN>) <filenameN> ]
UB6IB9:/home/ramune/src/hack# mount
/dev/hda1 on / type ext3 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
UB6IB9:/home/ramune/src/hack# uname -a
Linux UB6IB9 2.4.20 #1 Sat Nov 30 20:51:01 PST 2002 i586 unknown
UB6IB9:/home/ramune/src/hack#
Script done on Wed Dec 11 17:29:31 2002
So, what am I missing?
I just have to make it suid root if I wanna use it on 2.4.x? Or is there
a problem with my setup causing setcap to fail?
-- DN
Daniel
^ permalink raw reply
* [Printing-architecture] Meeting on the 9th of January?
From: HEMSTREET,CHARLES (HP-Vancouver,ex1) @ 2002-12-12 1:30 UTC (permalink / raw)
To: 'printing-architecture@freestandards.org'
Folks:
In line with the Job Ticket folks, and the holidays, I would like to cancel
the printing-architecture meeting for the next few weeks.
Unless someone objects, let's plan on reconvening on the 9th of January.
Happy Holidays,
Charles
^ permalink raw reply
* Re: Linux 2.4.21-pre1 IDE
From: Erik Andersen @ 2002-12-12 1:35 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
In-Reply-To: <Pine.LNX.4.50L.0212101834240.23096-100000@freak.distro.conectiva>
On Tue Dec 10, 2002 at 06:37:14PM -0200, Marcelo Tosatti wrote:
>
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
A few off things here...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller at PCI slot 00:0b.0
PDC20267: chipset revision 2
PDC20267: not 100%% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xb800-0xb807, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xb808-0xb80f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller at PCI slot 00:11.1
PCI: No IRQ known for interrupt pin A of device 00:11.1.
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xbc00-0xbc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L080AVVA07-0, ATA DISK drive
hdb: IC35L040AVER07-0, ATA DISK drive
hda: DMA disabled
^^^^^^^^^^^^^^^^^
What's up with this? For each drive in my system it claims it
has disabled DMA. But hdparm later reports that DMA is in fact
enabled. In fact, later on the kernel ever reports the drive
as being in UDMA 100 mode... I think these "DMA disabled"
messages are bogus.
blk: queue c03c4a00, I/O limit 4095Mb (mask 0xffffffff)
hdb: DMA disabled
^^^^^^^^^^^^^^^^^
blk: queue c03c4b4c, I/O limit 4095Mb (mask 0xffffffff)
hdc: PCRW804, ATAPI CD/DVD-ROM drive
hdd: Pioneer DVD-ROM ATAPIModel DVD-116 0122, ATAPI CD/DVD-ROM drive
hdc: DMA disabled
hdd: DMA disabled
^^^^^^^^^^^^^^^^^
hde: IC35L040AVER07-0, ATA DISK drive
hde: DMA disabled
^^^^^^^^^^^^^^^^^
Yet more bogus DMA disabled messages....
blk: queue c03c52d8, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x1800-0x1807,0xac02 on irq 11
hda: host protected area => 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
Now we see the funky "host protected area => 1" message. As
discussed earlier with Andre, this message should be removed from
the kernel. The message as written implies that the drive
actually has an active HPA -- which is not the case at all! All
this is doing is enumerating support for a particular drive
feature. Do we really care that the drive has Host Protected
Area feature set support? I don't care. I suppose it might be
interesting to note if there is actually an HPA in effect, but
this as is the message is just noise. If we are going to
enumerate drive capabilities, why not useful ones like the Power
Management feature set, or the Power-Up In Standby feature set...
I think we should kill the "host protected area => 1" message. If
people care about their drives supported feature set, they can
run 'hdparm -I' to find this out,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
^ 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.