* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Zwane Mwaikambo @ 2002-12-14 0:18 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Dave Jones, Petr Konecny, linux-kernel
In-Reply-To: <200212131846.gBDIk527008838@turing-police.cc.vt.edu>
On Fri, 13 Dec 2002 Valdis.Kletnieks@vt.edu wrote:
> On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
>
> > It's my understanding that pci_enable_device() *must* be called
> > before we fiddle with dev->resource, dev->irq and the like.
>
> OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> onboard ROM*.
Hmm i just saw this thread, which card is the non working one?;
The computer is still running 2.5.50
02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: CNet Technology Inc: Unknown device 401a
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 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1c00 [size=128]
Region 1: Memory at 10800000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 10400000 [size=256K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
# PCMCIA/CardBus support
CONFIG_PCMCIA=y
CONFIG_PCMCIA_XIRCOM=y
# CONFIG_PCMCIA_XIRTULIP is not set
# PCMCIA network device support
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_XIRC2PS is not set
--
function.linuxpower.ca
^ permalink raw reply
* Not able to compile modutils-2.4.21-7.src.rpm
From: Paolo Ciarrocchi @ 2002-12-14 0:09 UTC (permalink / raw)
To: adam, rusty; +Cc: linux-kernel
Hi Rusty and Adam,
I send you again this bug report.
[root@frodo module-init-tools-0.9.3]# rpm --rebuild /mnt/nt/linux/kernel/modules/modutils-2.4.21-7.src.rpm
gcc -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -o modinfo modinfo.o ../obj/libobj.a ../util/libutil.a
gcc -static -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -o insmod.static insmod.o rmmod.o modprobe.o lsmod.o ksyms.o kallsyms.o ../obj/libobj.a ../util/libutil.a
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make[1]: *** [insmod.static] Error 1
make[1]: Leaving directory `/usr/src/RPM/BUILD/modutils-2.4.21/insmod'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.76637 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.76637 (%build)
[root@frodo module-init-tools-0.9.3]# ld -v
GNU ld version 2.12.90.0.15 20020717
Do you need further information ?
Ciao,
Paolo
--
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr
Powered by Outblaze
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 0:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131347240.10159-100000@home.transmeta.com>
> James,
> the fbcon update seems to have broken the plain VGA console. I get a page
> fault at vgacon_scroll+0x144, the call sequence seems to be:
>
> vt_console_print+0x203
> set_cursor+0x78
> vgacon_cursor+x0xb5
> scrup+0x122
Calling scrup is out of place. It is only called by lf() and csi_M() in
the vt.c. lf() is used in vt_console_print but it is called before
set_cursor(). Also vgacon_cursor doesn't call vgacon_scroll. It can call
vgacon_scrolldelta. Now scrup does call vgacon_scroll. It looks like The
code jumped from the middle of vt_console_print to scrup. Do you get the
same error all the time? Also do you have Preemptible Kernel turned on?
> vgacon_scroll+0x144
>
> I don't know what triggers it, since it seems to happen pretty randomly.
>
> Linus
>
>
^ permalink raw reply
* [LARTC] Re: Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:55 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Setting standard arguments
From: axel @ 2002-12-13 23:52 UTC (permalink / raw)
To: whitnl73; +Cc: linux-newbie
In-Reply-To: <20021213.183853.134684296.0.whitnl73@juno.com>
Hi!
On Fri, 13 Dec 2002, whitnl73@juno.com wrote:
> On Thu, 12 Dec 2002 axel@pearbough.net wrote:
> > 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'
Thank you very much!
Best regards,
Axel
-
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
* [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
* 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
* 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
* 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: [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
* 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: 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
* [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: 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
* 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
* 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
* 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
* [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
* 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
* 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: 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
* 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: 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: 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: 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
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.