* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-13 22:53 UTC (permalink / raw)
To: Terje Eggestad
Cc: Ville Herva, J.A. Magallon, Mark Mielke, linux-kernel, Dave Jones
In-Reply-To: <1039816682.10496.13.camel@eggis1>
Terje Eggestad wrote:
> I haven't tried the vsyscall patch, but there was a sysenter patch
> floating around that I tried. It reduced the syscall overhead with 1/3
> to 1/4, but I never tried it on P4.
>
> FYI: Just note that I say overhead, which I assume to be the time it
> take to do someting like getpid(), write(-1,...), select(-1, ...) (etc
> that is immediatlely returned with -EINVAL by the kernel).
> Since the kernel do execute a quite afew instructions beside the
> int/iret sysenter/sysexit, it's an assumption that the int 80 is the
> culprit.
>
IRET in particular is a very slow instruction.
As far as I know, though, the SYSENTER patch didn't deal with several of
the corner cases introduced by the generally weird SYSENTER instruction
(such as the fact that V86 tasks can execute it despite the fact there
is in general no way to resume execution of the V86 task afterwards.)
In practice this means that vsyscalls is pretty much the only sensible
way to do this. Also note that INT 80h will need to be supported
indefinitely.
Personally, I wonder if it's worth the trouble, when x86-64 takes care
of the issue anyway :)
-hpa
^ permalink raw reply
* Re: [parisc-linux] gcc-snapshot (3.3) and linux-2.4.20-pa13
From: John David Anglin @ 2002-12-13 22:46 UTC (permalink / raw)
To: M. Grabert; +Cc: parisc-linux
In-Reply-To: <Pine.LNX.4.44.0212132231260.18468-100000@sal.ucc.ie>
> ====
> Changes since 1.46: +1 -1 lines
> Diff to previous 1.46
>
> 2.5.47-pa8: remove reference to $$mulU millicode function for gcc 3.3
> =====
The routine doesn't exist.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Custom Override for DSDT?
From: Matthew Tippett @ 2002-12-13 22:47 UTC (permalink / raw)
To: Grover, Andrew
Cc: 'Craig Whitmore', Matthew Tippett, chbm-tNiY1ywYjSU,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD04C7A597-OU+JdkIUtvd9zuciVAfUoVDQ4js95KgL@public.gmane.org>
Getting back to the original question, would it make sense to support a
way of overriding a dsdt to allow a broken BIOS that the manufacturer
won't fix be usable?
This still keeps standards based ACPI compliance but with the nice twist
that we don't have to rely entirely on the manufacturer for the BIOS
to work.
Regards,
Matthew
Grover, Andrew wrote:
>>From: Craig Whitmore [mailto:lennon-q3Ck4f9/EBK9koe0gwxAeg@public.gmane.org]
>>
>>>>distributed in windows drivers.
>>>
>>>Continuing with this thread, would it make sense to be ACPI
>>
>>compliant
>>
>>>but allow 'custom' dsdts to be passed to the acpi subsystem to allow
>>>users to work around less than perfect implementations from
>>>manufacturers.
>>>
>>
>>Just 1 question. What do the manufacturer's say when you tell
>>them they have
>>a "broken" dsdt? Do they normally fix it? or give some excuse
>>in a reason
>>why they won't fix it?
>
>
> It varies. BIOS bugs exposed by Linux may be prioritized lower due to
> Linux's market position in laptops. They also may not get attention if they
> are on end-of-lifed machines, or rolled into a BIOS update only when enough
> other bugs are fixed to justify a new BIOS's validation and release. (We may
> *say* to them it is a trivial fix, but the only way to know if it breaks
> Windows is for them to test it!)
>
> There also isn't always a clear way to report BIOS bugs from end users.
>
> On the upside, the things we're seeing are almost always obviously wrong and
> easy to fix - it's just getting them to make the trivial change.
>
> Regards -- Andy
>
>
> -------------------------------------------------------
> 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/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
-------------------------------------------------------
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/
^ permalink raw reply
* ACPI Licensing Change - timeframe
From: Grover, Andrew @ 2002-12-13 22:49 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
Just FYI...
We have preliminary approval from legal, but we need to hammer out a few
details with them. Hopefully you should see this happen in January of next
year.
Regards -- Andy
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
-------------------------------------------------------
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/
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Matti Aarnio @ 2002-12-13 22:58 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: Andrew McGregor, Bogdan Costescu, David S. Miller, dlstevens,
matti.aarnio, alan, stefano.andreani.ap, linux-kernel, linux-net
In-Reply-To: <3DFA21C5.867C6320@us.ibm.com>
On Fri, Dec 13, 2002 at 10:07:01AM -0800, Nivedita Singhvi wrote:
> Andrew McGregor wrote:
> > In a closed network, why not have SOCK_STREAM map to something faster than
> > TCP anyway? That is, if I connect(address matching localnet), SOCK_STREAM
> > maps to (eg) SCTP. That would be a far more dramatic performance hack!
> >
> > Andrew
>
> Not that simple. SCTP (if that is what Matti was referring to) is
> a SOCK_STREAM socket, with a protocol of IPPROTO_SCTP. I'm just
> getting done implementing a testsuite against the SCTP API.
Most likely that is what I did mean.
Things in IETF do on occasion change names, or I don't always
remember all characters in (E)TLA-acronyms I use rarely...
...
> But dont expect SCTP to be the surreptitious underlying layer
> carrying TCP traffic, if thats an expectation that anyone has :)
At least I didn't expect that, don't know of others.
It all depends on application coders, if users will be able
to use arbitrary network protocols -- say any SOCK_STREAM
protocol supported now, and in future by system kernel.
Ever heard of "TLI" ?
> Solving this problem without application involvement is a
> more limited scenario..
Yes, but sufficiently important to occasionally.
Doing things like this mapping might make limited sense
via routing table lookups.
> thanks,
> Nivedita
/Matti Aarnio
^ permalink raw reply
* Re: Setting standard arguments
From: whitnl73 @ 2002-12-13 22:51 UTC (permalink / raw)
To: axel; +Cc: linux-newbie
In-Reply-To: <20021212161921.GA10853@neon.pearbough.net>
On Thu, 12 Dec 2002 axel@pearbough.net wrote:
> Hi,
>
> I have an Slackware installation and I'm using checkinstall to create and
> install slackware packages from sources.
> Now there are some options I use checkinstall with that I'd like
> checkinstall always to use.
> For example I call "checkinstall" and "checkinstall -S --nodoc --gzman
> --install=yes" shall be executed.
> Can this be done somehow with tcsh?
alias checkinstall='checkinstall -S --nodoc --gzman --install=yes'
would be one way. put it in your shell startup file /etc/csh.cshrc
or ~/.tcshrc or so. it won't take effect until the next shell startup
or you source the file you put it in.
>
> Thank you for your help,
> Axel Siebenwirth
> -
Lawson
--
---oops---
________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
-
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: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Doug Ledford @ 2002-12-13 22:52 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-scsi
In-Reply-To: <20021213215113.A16528@infradead.org>
On Fri, Dec 13, 2002 at 09:51:13PM +0000, Christoph Hellwig wrote:
> On Fri, Dec 13, 2002 at 04:23:52PM -0500, Doug Ledford wrote:
> > Hmmm...what's the failure mode here?
>
> It complains that it can't reserve the mem regions but still continues to
> setup, download sequencer code, and even register scsi3ff.
Hmmm...are you loading mine or Justin's driver first? Mine should bail,
not continue, when it can't reserve the requested region.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* Re: 2.5.50-mm2
From: Christoph Hellwig @ 2002-12-13 22:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
In-Reply-To: <3DF453C8.18B24E66@digeo.com>
On Mon, Dec 09, 2002 at 12:26:48AM -0800, Andrew Morton wrote:
> +remove-PF_SYNC.patch
>
> remove the current->flags:PF_SYNC abomination. Adds a `sync' arg to
> all writepage implementations to tell them whether they are being
> called for memory cleansing or for data integrity.
Any chance you could pass down a struct writeback_control instead of
just the sync flag? XFS always used ->writepage similar to the
->vm_writeback in older kernel releases because writing out more
than one page of delalloc space is really needed to be efficient and
this would allow us to get a few more hints about the VM's intentions.
--
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: Custom Override for DSDT?
From: Grover, Andrew @ 2002-12-13 22:59 UTC (permalink / raw)
To: 'Matthew Tippett'
Cc: 'Craig Whitmore', chbm-tNiY1ywYjSU,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> From: Matthew Tippett [mailto:matthew-+XluyfkzffvQT0dZR+AlfA@public.gmane.org]
> Getting back to the original question, would it make sense to
> support a
> way of overriding a dsdt to allow a broken BIOS that the manufacturer
> won't fix be usable?
>
> This still keeps standards based ACPI compliance but with the
> nice twist
> that we don't have to rely entirely on the manufacturer for
> the BIOS
> to work.
We have this. Old documentation of the procedure is at
http://developer.intel.com/technology/iapc/acpi/bios_override.htm .
There is a new, easier way to do it, that various people have documented.
(Ducrot, perhaps?) We will be updating that URL with the new method at some
point, too.
It's good for debugging, or you highly motivated people, but obviously not
for a general solution.
Regards -- Andy
-------------------------------------------------------
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/
^ permalink raw reply
* Re: massive compile failures w/ 2.5.51 on RH8.0
From: Randy.Dunlap @ 2002-12-13 23:05 UTC (permalink / raw)
To: Dave Jones; +Cc: Rod Van Meter, linux-kernel
In-Reply-To: <20021213122017.GC31187@suse.de>
On Fri, 13 Dec 2002, Dave Jones wrote:
| On Thu, Dec 12, 2002 at 09:42:39PM -0800, Randy.Dunlap wrote:
|
| > and some of these may have patches available for them on lkml.
| > I know that intermezzo does, from Peter Braam, with a small
| > follow-up by me, so it's fixable if you want it. Surely (Rod ;).
|
| >From reading bugzilla #11, it seems even with your additional
| patch intermezzo still has problems..
(I sense a subtle hint here. :)
Hi Dave,
There are just too many Linux 2.5 bugs and patches to keep track
of all of them...i.e., you might have looked at the latest in bugzilla,
but not the latest patches on lkml. I have updated bugzilla #11
with the info needed to build intermezzo in 2.5.51, either as a
loadable module or built-into-kernel.
--
~Randy
^ permalink raw reply
* ACPI releases updated (20021212)
From: Grover, Andrew @ 2002-12-13 23:11 UTC (permalink / raw)
To: acpi-devel; +Cc: kernel list
Hi all,
New versions of the ACPI patches are available from
http://sf.net/projects/acpi . Non-Linux source drops will not be available
until Dec 20, due to web publishing issues. (I can email it on request, if
you can't wait.)
(If you already downloaded the patch against 2.5.51, you may want to re-get
it. A small fix for writes to the /proc interface has been slipstreamed.)
Regards -- Andy
----------------------------------------
12 December 2002. Summary of changes for version 20021212.
1) ACPI CA Core Subsystem:
Fixed a problem where the creation of a zero-length AML Buffer
would cause a fault.
Fixed a problem where a Buffer object that pointed to a static
AML buffer (in an ACPI table) could inadvertently be deleted,
causing memory corruption.
Fixed a problem where a user buffer (passed in to the external
ACPI CA interfaces) could be overwritten if the buffer was too
small to complete the operation, causing memory corruption.
Fixed a problem in the Buffer-to-String conversion code where
a string of length one was always returned, regardless of the
size of the input Buffer object.
Removed the NATIVE_CHAR data type across the entire source due
to lack of need and lack of consistent use.
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover@intel.com
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-13 23:08 UTC (permalink / raw)
To: Doug Ledford, Christoph Hellwig; +Cc: linux-scsi
In-Reply-To: <20021213225225.GB10883@redhat.com>
> On Fri, Dec 13, 2002 at 09:51:13PM +0000, Christoph Hellwig wrote:
>> On Fri, Dec 13, 2002 at 04:23:52PM -0500, Doug Ledford wrote:
>> > Hmmm...what's the failure mode here?
>>
>> It complains that it can't reserve the mem regions but still continues to
>> setup, download sequencer code, and even register scsi3ff.
>
> Hmmm...are you loading mine or Justin's driver first? Mine should bail,
> not continue, when it can't reserve the requested region.
If the new driver is loaded second, you'll wind up with a config
space COMMAND register with both IO space and MEM space disabled.
The reason for this was to ensure that the aic7xxx controller was
not responding to a memory or I/O port already requested for a
*different device*. I wasn't thinking about a *different driver*
accessing the same device. There are other PCI api functions
that are called prior to the region check too (set powerstate, enable
device, set dma mask, etc.). I just don't know how safe you can
really make it unless the old driver uses the PCI registration API.
The new driver will fail though if *both* its memory and port addresses
cannot be mapped.
In the other load order, the driver only reserves the region type it is
using.
The other region is simply disabled in the COMMAND register. This is
probably why things are failing. One driver is using mem I/O. The other
is using PIO.
--
Justin
^ permalink raw reply
* [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-13 23:08 UTC (permalink / raw)
To: linux-mips; +Cc: jsun
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
If a machine uses i8259 as part of its interrupt routing subsystem,
it typically has two ways to figure out which i8259 interrupt has
happened.
1) through PCI interrupt ack cycle to directly read the IRQ number
2) read i8259 interrupt status registers and figure which one has
happened.
This patch adds support for those sorry boards which only have
option 2) available.
While I am here, I also promoted do_IRQ() declaration to a
header file, as it is needed by all C-level interrupt dispatching
code.
Any feedbacks?
Jun
[-- Attachment #2: junk --]
[-- Type: text/plain, Size: 1281 bytes --]
--- ./arch/mips64/kernel/i8259.c.orig Mon Aug 5 16:53:33 2002
+++ ./arch/mips64/kernel/i8259.c Fri Dec 13 14:54:09 2002
@@ -14,6 +14,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/spinlock.h>
+#include <linux/bitops.h>
#include <asm/io.h>
@@ -219,6 +220,26 @@
}
}
+asmlinkage void dispatch_i8259_irq(struct pt_regs *regs)
+{
+ int isr, irq=-1;
+
+ isr = ~(int)inb(0x20) | cached_21;
+ if (isr != -1)
+ irq = ffz (isr);
+ if (irq == 2) {
+ isr = ~(int)inb(0xa0) | cached_A1;
+ if (isr != -1)
+ irq = 8 + ffz(isr);
+ }
+ if (irq == -1) {
+ printk("We got a spurious i8259 interrupt\n");
+ atomic_inc(&irq_err_count);
+ } else {
+ do_IRQ(irq,regs);
+ }
+}
+
void __init init_8259A(int auto_eoi)
{
unsigned long flags;
diff -Nru ./include/asm-mips64/irq.h.orig ./include/asm-mips/irq.h
--- ./include/asm-mips64/irq.h.orig Fri Dec 13 10:51:25 2002
+++ ./include/asm-mips64/irq.h Fri Dec 13 14:50:46 2002
@@ -12,6 +12,7 @@
#define _ASM_IRQ_H
#include <linux/config.h>
+#include <linux/linkage.h>
#define NR_IRQS 128 /* Largest number of ints of all machines. */
@@ -36,4 +37,6 @@
extern void init_generic_irq(void);
+extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
+
#endif /* _ASM_IRQ_H */
^ permalink raw reply
* ACPI releases updated (20021212)
From: Grover, Andrew @ 2002-12-13 23:11 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A; +Cc: kernel list
Hi all,
New versions of the ACPI patches are available from
http://sf.net/projects/acpi . Non-Linux source drops will not be available
until Dec 20, due to web publishing issues. (I can email it on request, if
you can't wait.)
(If you already downloaded the patch against 2.5.51, you may want to re-get
it. A small fix for writes to the /proc interface has been slipstreamed.)
Regards -- Andy
----------------------------------------
12 December 2002. Summary of changes for version 20021212.
1) ACPI CA Core Subsystem:
Fixed a problem where the creation of a zero-length AML Buffer
would cause a fault.
Fixed a problem where a Buffer object that pointed to a static
AML buffer (in an ACPI table) could inadvertently be deleted,
causing memory corruption.
Fixed a problem where a user buffer (passed in to the external
ACPI CA interfaces) could be overwritten if the buffer was too
small to complete the operation, causing memory corruption.
Fixed a problem in the Buffer-to-String conversion code where
a string of length one was always returned, regardless of the
size of the input Buffer object.
Removed the NATIVE_CHAR data type across the entire source due
to lack of need and lack of consistent use.
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
^ permalink raw reply
* writing new BBRAM driver
From: Alex Pavloff @ 2002-12-13 23:45 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
Hi there folks. I've written the struct mtd_info functions for a 128KB
BBRAM driver for my companies new board. It's horribly simple, as most of
it is actually done by a gate array on the board, so from kernel land its
just poking ioports. Easy stuff.
Anyway, at this point, I've got that written, but I'm a little hazy as to
what I do next. Insmod the driver, and then....?
How do I get a drive to mount?
Also, what FS should I use for this BBRAM?
Thanks!
Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com
^ permalink raw reply
* Re: RE: Custom Override for DSDT?
From: Ducrot Bruno @ 2002-12-13 23:16 UTC (permalink / raw)
To: Grover, Andrew
Cc: 'Matthew Tippett', 'Craig Whitmore',
chbm-tNiY1ywYjSU, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD04C7A59A-OU+JdkIUtvd9zuciVAfUoVDQ4js95KgL@public.gmane.org>
On Fri, Dec 13, 2002 at 02:59:58PM -0800, Grover, Andrew wrote:
> > From: Matthew Tippett [mailto:matthew-+XluyfkzffvQT0dZR+AlfA@public.gmane.org]
> > Getting back to the original question, would it make sense to
> > support a
> > way of overriding a dsdt to allow a broken BIOS that the manufacturer
> > won't fix be usable?
> >
> > This still keeps standards based ACPI compliance but with the
> > nice twist
> > that we don't have to rely entirely on the manufacturer for
> > the BIOS
> > to work.
>
> We have this. Old documentation of the procedure is at
> http://developer.intel.com/technology/iapc/acpi/bios_override.htm .
>
> There is a new, easier way to do it, that various people have documented.
> (Ducrot, perhaps?) We will be updating that URL with the new method at some
http://www.poupinou.org/acpi/over.html
or
http://www.cpqlinux/acpi-howto.html
The latter should be read by almost all 'newbies' peoples that want
to override their DSDT.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
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/
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Doug Ledford @ 2002-12-13 23:20 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Christoph Hellwig, linux-scsi
In-Reply-To: <59730000.1039820896@aslan.btc.adaptec.com>
On Fri, Dec 13, 2002 at 04:08:17PM -0700, Justin T. Gibbs wrote:
> > On Fri, Dec 13, 2002 at 09:51:13PM +0000, Christoph Hellwig wrote:
> >> On Fri, Dec 13, 2002 at 04:23:52PM -0500, Doug Ledford wrote:
> >> > Hmmm...what's the failure mode here?
> >>
> >> It complains that it can't reserve the mem regions but still continues to
> >> setup, download sequencer code, and even register scsi3ff.
> >
> > Hmmm...are you loading mine or Justin's driver first? Mine should bail,
> > not continue, when it can't reserve the requested region.
>
> If the new driver is loaded second, you'll wind up with a config
> space COMMAND register with both IO space and MEM space disabled.
> The reason for this was to ensure that the aic7xxx controller was
> not responding to a memory or I/O port already requested for a
> *different device*.
Two PCI devices sharing the same I/O or Mem space either one is invalid.
If the space is allocated to the card, then it *belongs* to that card and
there should never be a conflict. So, in my driver now, I switched to
using pci_request_regions() (pretty nice helper function actually, it
grabs *all* the pci resources that are assigned to that card and fails if
it can't get all of them). That's the only thing that really made sense
to me. Now, I think the *only* thing I might do differently is to move
the pci_enable_device() call to after the pci_request_regions() since
right now the pci_enable_device() is the first thing my driver does (I
wasn't sure, but I thought you might have to call pci_enable_device() to
trigger some resource allocations so that pci_request_regions() would have
all the regions it needs to reserve properly allocated). But, that should
be fairly safe from a 2 driver standpoint (I'm making the assumption that
calling pci_enabled_device() on an already enabled and live card isn't a
problem, which I think is right but probably warrants a deeper look into
the pci subsys to be sure). It's also pretty close to identical to what I
do in the eisa/vlb case.
> I wasn't thinking about a *different driver*
> accessing the same device. There are other PCI api functions
> that are called prior to the region check too (set powerstate, enable
> device, set dma mask, etc.). I just don't know how safe you can
> really make it unless the old driver uses the PCI registration API.
> The new driver will fail though if *both* its memory and port addresses
> cannot be mapped.
I had a few things in there before the region check as well. I just moved
the region check up to the top, right after pci_enable_device().
> In the other load order, the driver only reserves the region type it is
> using.
Which I think is technically wrong IMHO. Whether you use the I/O space or
not, it's been allocated to you by the BIOS/PCI subsystem. If you can't
have control over an area allocated to you then there is a bogon hiding
somewhere in the woodpile.
> The other region is simply disabled in the COMMAND register. This is
> probably why things are failing. One driver is using mem I/O. The other
> is using PIO.
>
> --
> Justin
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* [Linux-ia64] [PATCH] efivars.c locking fixes
From: Matt Domsch @ 2002-12-13 23:31 UTC (permalink / raw)
To: linux-ia64
With thanks to Peter Chubb and his preempt work, here's a patch for
efivars.c that applies to both 2.4.x and 2.5.x to clean up the SMP
locking issues discovered there. The efivar_lock was being held
across calls to create_proc_entry(), and worse, kmalloc(). I believe
this fixes those.
This has been tested on a Big Sur on 2.5.50 and seems to work
correctly. This hasn't been tested on 2.4.20 (though it patches,
compiles and builds properly, and I expect it works fine), something
immediately after efivars_init() finishes crashes and I haven't been
able to track it down yet, though I'm pretty certain it's not
something in efivars.c.
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
--- linux-2.5-ia64/arch/ia64/kernel/efivars.c Fri Dec 13 17:22:01 2002
+++ linux-2.5-ia64-test/arch/ia64/kernel/efivars.c Fri Dec 13 10:33:51 2002
@@ -29,6 +29,9 @@
*
* Changelog:
*
+ * 10 Dec 2002 - Matt Domsch <Matt_Domsch@dell.com>
+ * fix locking per Peter Chubb's findings
+ *
* 25 Mar 2002 - Matt Domsch <Matt_Domsch@dell.com>
* move uuid_unparse() to include/asm-ia64/efi.h:efi_guid_unparse()
*
@@ -73,7 +76,7 @@ MODULE_AUTHOR("Matt Domsch <Matt_Domsch@
MODULE_DESCRIPTION("/proc interface to EFI Variables");
MODULE_LICENSE("GPL");
-#define EFIVARS_VERSION "0.05 2002-Mar-26"
+#define EFIVARS_VERSION "0.06 2002-Dec-10"
static int
efivar_read(char *page, char **start, off_t off,
@@ -106,6 +109,14 @@ typedef struct _efivar_entry_t {
struct list_head list;
} efivar_entry_t;
+/*
+ efivars_lock protects two things:
+ 1) efivar_list - adds, removals, reads, writes
+ 2) efi.[gs]et_variable() calls.
+ It must not be held when creating proc entries or calling kmalloc.
+ efi.get_next_variable() is only called from efivars_init(),
+ which is protected by the BKL, so that path is safe.
+*/
static spinlock_t efivars_lock = SPIN_LOCK_UNLOCKED;
static LIST_HEAD(efivar_list);
static struct proc_dir_entry *efi_vars_dir = NULL;
@@ -150,6 +161,7 @@ proc_calc_metrics(char *page, char **sta
* variable_name_size = number of bytes required to hold
* variable_name (not counting the NULL
* character at the end.
+ * efivars_lock is not held on entry or exit.
* Returns 1 on failure, 0 on success
*/
static int
@@ -160,10 +172,12 @@ efivar_create_proc_entry(unsigned long v
int i, short_name_size = variable_name_size /
sizeof(efi_char16_t) + 38;
- char *short_name = kmalloc(short_name_size+1,
- GFP_KERNEL);
- efivar_entry_t *new_efivar = kmalloc(sizeof(efivar_entry_t),
- GFP_KERNEL);
+ char *short_name;
+ efivar_entry_t *new_efivar;
+
+ short_name = kmalloc(short_name_size+1, GFP_KERNEL);
+ new_efivar = kmalloc(sizeof(efivar_entry_t), GFP_KERNEL);
+
if (!short_name || !new_efivar) {
if (short_name) kfree(short_name);
if (new_efivar) kfree(new_efivar);
@@ -188,19 +202,18 @@ efivar_create_proc_entry(unsigned long v
*(short_name + strlen(short_name)) = '-';
efi_guid_unparse(vendor_guid, short_name + strlen(short_name));
-
/* Create the entry in proc */
new_efivar->entry = create_proc_entry(short_name, 0600, efi_vars_dir);
kfree(short_name); short_name = NULL;
if (!new_efivar->entry) return 1;
-
new_efivar->entry->data = new_efivar;
new_efivar->entry->read_proc = efivar_read;
new_efivar->entry->write_proc = efivar_write;
+ spin_lock(&efivars_lock);
list_add(&new_efivar->list, &efivar_list);
-
+ spin_unlock(&efivars_lock);
return 0;
}
@@ -326,6 +339,8 @@ efivar_write(struct file *file, const ch
kfree(efivar);
}
+ spin_unlock(&efivars_lock);
+
/* If this is a new variable, set up the proc entry for it. */
if (!found) {
efivar_create_proc_entry(utf8_strsize(var_data->VariableName,
@@ -336,7 +351,6 @@ efivar_write(struct file *file, const ch
kfree(var_data);
MOD_DEC_USE_COUNT;
- spin_unlock(&efivars_lock);
return size;
}
@@ -351,8 +365,6 @@ efivars_init(void)
efi_char16_t *variable_name = kmalloc(1024, GFP_KERNEL);
unsigned long variable_name_size = 1024;
- spin_lock(&efivars_lock);
-
printk(KERN_INFO "EFI Variables Facility v%s\n", EFIVARS_VERSION);
/* Since efi.c happens before procfs is available,
@@ -365,8 +377,6 @@ efivars_init(void)
efi_vars_dir = proc_mkdir("vars", efi_dir);
-
-
/* Per EFI spec, the maximum storage allocated for both
the variable name and variable data is 1024 bytes.
*/
@@ -398,7 +408,6 @@ efivars_init(void)
} while (status != EFI_NOT_FOUND);
kfree(variable_name);
- spin_unlock(&efivars_lock);
return 0;
}
@@ -408,17 +417,16 @@ efivars_exit(void)
struct list_head *pos, *n;
efivar_entry_t *efivar;
- spin_lock(&efivars_lock);
-
+ spin_lock(&efivars_lock);
list_for_each_safe(pos, n, &efivar_list) {
efivar = efivar_entry(pos);
remove_proc_entry(efivar->entry->name, efi_vars_dir);
list_del(&efivar->list);
kfree(efivar);
}
- remove_proc_entry(efi_vars_dir->name, efi_dir);
spin_unlock(&efivars_lock);
+ remove_proc_entry(efi_vars_dir->name, efi_dir);
}
module_init(efivars_init);
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-13 23:32 UTC (permalink / raw)
To: Doug Ledford; +Cc: Christoph Hellwig, linux-scsi
In-Reply-To: <20021213232013.GF10883@redhat.com>
>> If the new driver is loaded second, you'll wind up with a config
>> space COMMAND register with both IO space and MEM space disabled.
>> The reason for this was to ensure that the aic7xxx controller was
>> not responding to a memory or I/O port already requested for a
>> *different device*.
>
> Two PCI devices sharing the same I/O or Mem space either one is invalid.
Sure. But I've seen BIOSes that screw this up before, especially if
you have more devices in the system then you have I/O space to map them
all. This becomes even more important in a PCI hot-plug environment.
I dont' want to reserve regions that I'm not going to use because that
resource space might be vital for some future hot-plug device. The fact
that the BIOSes allocate all regions is a holdover from when OSes were
not PCI PNP capable.
>> In the other load order, the driver only reserves the region type it is
>> using.
>
> Which I think is technically wrong IMHO. Whether you use the I/O space or
> not, it's been allocated to you by the BIOS/PCI subsystem. If you can't
> have control over an area allocated to you then there is a bogon hiding
> somewhere in the woodpile.
There are lots of PCI devices that have extra bars that a driver may or
may not choose to use. In some cases, the memory regions supported by
those bars are *huge* but only one bar need be active at a time. On some
devices it may be safe to allocate and just not use all BARs on the card,
but I don't think that it applies to all devices. I would rather the PCI
subsystem defer to the device driver to tell it which regions are required
rather than attempt to allocate them all upfront and exhaust what is
a limited pool of resources.
--
Justin
^ permalink raw reply
* Re: RE: Custom Override for DSDT?
From: Ducrot Bruno @ 2002-12-13 23:37 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021213231650.GW4327-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
>
> http://www.poupinou.org/acpi/over.html
> or
> http://www.cpqlinux/acpi-howto.html
ouch. www.cpqlinux.com of course...
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
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/
^ permalink raw reply
* Re: [Linux-ia64] [PATCH] fix /proc/.../vm_info
From: David Mosberger @ 2002-12-13 23:40 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805552@msgid-missing>
>>>>> On Fri, 13 Dec 2002 08:45:37 +0100, Christian Hildner <christian.hildner@hob.de> said:
Christian> I agree. But I would like a distinction between both UCs
Christian> like "UC (001)" and "UC (100)".
Actually, it turns out the double UC entry was just plain wrong. I
wondered about that, but got distracted before I got to double-check
it. In reality, 001 is reserved for Software Use. I changed the
table to read:
"WB", /* 000 */
"SW", /* 001 */
"010", /* 010 */
"011", /* 011 */
"UC", /* 100 */
"UCE", /* 101 */
"WC", /* 110 */
"NaTPage" /* 111 */
Thanks to Jim Hull for catching this.
--david
^ permalink raw reply
* Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:49 UTC (permalink / raw)
To: lartc, linux-kernel, kuznet
Hi,
having read an article about QoS and HTB in a German computer magazine I
wanted to implement such thing on my linux router running kernel 2.5.51.
First I patched the iproute2-020116.tar.gz package with the htb3.6_tc.diff
from http://luxik.cdi.cz/~devik/qos/htb/ and started building it. But
unfortunately it resulted in strange compile errors I do not understand.
Hope this is some help for you and I am not doing something terribly wrong.
Best regards,
Axel Siebenwirth
make[1]: Entering directory /usr/local/src/iproute2/misc'
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o ss.o ss.c
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:9: redefinition of `struct timespec'
/usr/src/linux/include/linux/time.h:15: redefinition of `struct timeval'
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:146:1: warning: "FD_SET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:89:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:147:1: warning: "FD_CLR" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:90:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:148:1: warning: "FD_ISSET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:91:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:149:1: warning: "FD_ZERO" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:92:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/sched.h:12,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/jiffies.h:11: parse error before "jiffies_64"
/usr/src/linux/include/linux/jiffies.h:11: warning: type defaults to nt'
in declaration of
iffies_64'
/usr/src/linux/include/linux/jiffies.h:11: warning: data definition has no
type
or storage class
In file included from /usr/src/linux/include/linux/sched.h:20,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/asm/mmu.h:13: field `sem' has incomplete type
/usr/src/linux/include/asm/mmu.h:15: confused by earlier errors, bailing out
make[1]: *** [ss.o] Error 1
make[1]: Leaving directory /usr/local/src/iproute2/misc'
^ permalink raw reply
* Re: new Debian packages
From: Tom @ 2002-12-13 23:42 UTC (permalink / raw)
To: selinux
In-Reply-To: <20021213223108.GA5424@lyta.coker.com.au>
On Fri, Dec 13, 2002 at 11:31:08PM +0100, Russell Coker wrote:
> I have packaged the new kernel patch and the selinux-small code and uploaded
> them to my web site and to Debian.
>
> Please make sure that you install the "selinux" and "selinux-policy-default"
> packages BEFORE booting a kernel compiled with the latest kernel patch.
I'll be testing this next week. Any new kernels from Brian that I could
give a shakedown while I'm at it? (I've hosed my test machine again.
Must remember to be more careful. Will probably write a new chapter
into my "things not to do with SELinux" paper. :) )
--
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:55 UTC (permalink / raw)
To: lartc, linux-kernel, kuznet
In-Reply-To: <20021213234959.GA31994@neon.pearbough.net>
Hi again!
On Sat, 14 Dec 2002, axel@pearbough.net wrote:
> having read an article about QoS and HTB in a German computer magazine I
> wanted to implement such thing on my linux router running kernel 2.5.51.
> First I patched the iproute2-020116.tar.gz package with the htb3.6_tc.diff
> from http://luxik.cdi.cz/~devik/qos/htb/ and started building it. But
> unfortunately it resulted in strange compile errors I do not understand.
>
> make[1]: *** [ss.o] Error 1
> make[1]: Leaving directory /usr/local/src/iproute2/misc'
There are no such problems with 2.4.20.
Axel
^ permalink raw reply
* [LARTC] Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:49 UTC (permalink / raw)
To: lartc
Hi,
having read an article about QoS and HTB in a German computer magazine I
wanted to implement such thing on my linux router running kernel 2.5.51.
First I patched the iproute2-020116.tar.gz package with the htb3.6_tc.diff
from http://luxik.cdi.cz/~devik/qos/htb/ and started building it. But
unfortunately it resulted in strange compile errors I do not understand.
Hope this is some help for you and I am not doing something terribly wrong.
Best regards,
Axel Siebenwirth
make[1]: Entering directory /usr/local/src/iproute2/misc'
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o ss.o ss.c
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:9: redefinition of `struct timespec'
/usr/src/linux/include/linux/time.h:15: redefinition of `struct timeval'
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:146:1: warning: "FD_SET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:89:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:147:1: warning: "FD_CLR" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:90:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:148:1: warning: "FD_ISSET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:91:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:149:1: warning: "FD_ZERO" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:92:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/sched.h:12,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/jiffies.h:11: parse error before "jiffies_64"
/usr/src/linux/include/linux/jiffies.h:11: warning: type defaults to nt'
in declaration of
iffies_64'
/usr/src/linux/include/linux/jiffies.h:11: warning: data definition has no
type
or storage class
In file included from /usr/src/linux/include/linux/sched.h:20,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/asm/mmu.h:13: field `sem' has incomplete type
/usr/src/linux/include/asm/mmu.h:15: confused by earlier errors, bailing out
make[1]: *** [ss.o] Error 1
make[1]: Leaving directory /usr/local/src/iproute2/misc'
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ 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.