* Re: [patch] 2.6.1-mm3 acpi frees free irq0
From: Len Brown @ 2004-01-26 20:30 UTC (permalink / raw)
To: Jes Sorensen
Cc: Andrew Morton, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ACPI Developers, Jesse Barnes
In-Reply-To: <16390.43574.867869.286685-4mDQ13Tdud8Jw5R7aSpS0dP8p4LwMBBS@public.gmane.org>
Accepted.
thanks,
-Len
On Thu, 2004-01-15 at 09:56, Jes Sorensen wrote:
> Hi,
>
> There is a bug in the ACPI code found in 2.6.1-mm3 where if it can't
> find the interrupt source for the ACPI System Control Interrupt Handler,
> it end up trying to free irq 0.
>
> Included patch fixes the problem.
>
> Cheers,
> Jes
>
> --- linux-2.6.1-mm3/drivers/acpi/osl.c~ Wed Jan 14 05:00:25 2004
> +++ linux-2.6.1-mm3/drivers/acpi/osl.c Thu Jan 15 06:43:28 2004
> @@ -257,13 +257,13 @@
> return AE_OK;
> }
> #endif
> - acpi_irq_irq = irq;
> acpi_irq_handler = handler;
> acpi_irq_context = context;
> if (request_irq(irq, acpi_irq, SA_SHIRQ, "acpi", acpi_irq)) {
> printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
> return AE_NOT_ACQUIRED;
> }
> + acpi_irq_irq = irq;
>
> return AE_OK;
> }
> @@ -271,12 +271,13 @@
> acpi_status
> acpi_os_remove_interrupt_handler(u32 irq, OSD_HANDLER handler)
> {
> - if (acpi_irq_handler) {
> + if (irq) {
> #if defined(CONFIG_IA64) || defined(CONFIG_PCI_USE_VECTOR)
> irq = acpi_irq_to_vector(irq);
> #endif
> free_irq(irq, acpi_irq);
> acpi_irq_handler = NULL;
> + acpi_irq_irq = 0;
> }
>
> return AE_OK;
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* FIX (was Re: Demonstration code on how to trigger tcp6_sock leak)
From: David S. Miller @ 2004-01-26 20:30 UTC (permalink / raw)
To: erik; +Cc: netdev, acme, yoshfuji
In-Reply-To: <20040124131307.GB2666@bender.home.hensema.net>
Ok, I've figured out the bug. Arnaldo only fixed one of the
two incorrect calls to sk_add_node() which should both be
__sk_add_node().
Erik give this a spin.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1520 -> 1.1521
# net/ipv6/tcp_ipv6.c 1.76 -> 1.77
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/01/26 davem@nuts.ninka.net 1.1521
# [IPV6]: Fix TCP socket leak, do not grab socket reference when adding to main hashes.
# --------------------------------------------
#
diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Mon Jan 26 12:34:20 2004
+++ b/net/ipv6/tcp_ipv6.c Mon Jan 26 12:34:20 2004
@@ -485,7 +485,7 @@
unique:
BUG_TRAP(sk_unhashed(sk));
- sk_add_node(sk, &head->chain);
+ __sk_add_node(sk, &head->chain);
sk->sk_hashent = hash;
sock_prot_inc_use(sk->sk_prot);
write_unlock_bh(&head->lock);
^ permalink raw reply
* Re: [patch] 2.6.1-mm3 acpi frees free irq0
From: Len Brown @ 2004-01-26 20:30 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Andrew Morton, linux-kernel, ACPI Developers, Jesse Barnes
In-Reply-To: <16390.43574.867869.286685@gargle.gargle.HOWL>
Accepted.
thanks,
-Len
On Thu, 2004-01-15 at 09:56, Jes Sorensen wrote:
> Hi,
>
> There is a bug in the ACPI code found in 2.6.1-mm3 where if it can't
> find the interrupt source for the ACPI System Control Interrupt Handler,
> it end up trying to free irq 0.
>
> Included patch fixes the problem.
>
> Cheers,
> Jes
>
> --- linux-2.6.1-mm3/drivers/acpi/osl.c~ Wed Jan 14 05:00:25 2004
> +++ linux-2.6.1-mm3/drivers/acpi/osl.c Thu Jan 15 06:43:28 2004
> @@ -257,13 +257,13 @@
> return AE_OK;
> }
> #endif
> - acpi_irq_irq = irq;
> acpi_irq_handler = handler;
> acpi_irq_context = context;
> if (request_irq(irq, acpi_irq, SA_SHIRQ, "acpi", acpi_irq)) {
> printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
> return AE_NOT_ACQUIRED;
> }
> + acpi_irq_irq = irq;
>
> return AE_OK;
> }
> @@ -271,12 +271,13 @@
> acpi_status
> acpi_os_remove_interrupt_handler(u32 irq, OSD_HANDLER handler)
> {
> - if (acpi_irq_handler) {
> + if (irq) {
> #if defined(CONFIG_IA64) || defined(CONFIG_PCI_USE_VECTOR)
> irq = acpi_irq_to_vector(irq);
> #endif
> free_irq(irq, acpi_irq);
> acpi_irq_handler = NULL;
> + acpi_irq_irq = 0;
> }
>
> return AE_OK;
^ permalink raw reply
* Re: [parisc-linux] semid64_ds compiled on a 32-bit system has wrong expected size for sem_ctime
From: Carlos O'Donell @ 2004-01-26 20:34 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <20040126194400.GI5351@baldric.uwo.ca>
On Mon, Jan 26, 2004 at 02:44:00PM -0500, Carlos O'Donell wrote:
> > struct semid64_ds {
> > struct ipc64_perm sem_perm; /* permissions .. see ipc.h */
> > #ifndef __LP64__
> > unsigned int __pad1;
> > #endif
> > __kernel_time_t sem_otime; /* last semop time */
> > #ifndef __LP64__
> > unsigned int __pad2;
> > #endif
> > __kernel_time_t sem_ctime; /* last change time */
> > unsigned int sem_nsems; /* no. of semaphores in array */
> > unsigned int __unused1;
> > unsigned int __unused2;
> > };
>
> Our 32-bit userspace will see different values for this depending on
> running a 32-bit kernel or 64-bit. That last sem_ctime should probably
> have a padding so our 32-bit userspace sees the right thing all the
> time.
Sorry, I got confused with sem_perm, __pad2 is the padding for ctime,
thanks for pointing that out Matthew. Changing the base posix type for
32-bit builds to "long" fixes all the compiler complaints.
False alarm :)
c.
^ permalink raw reply
* Re: 2.6.2-rc1-mm3
From: Tom Rini @ 2004-01-26 20:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
In-Reply-To: <20040124180022.14fe495e.akpm@osdl.org>
On Sat, Jan 24, 2004 at 06:00:22PM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm3/
>
> - 2.6.2-rc1-mm3's allyesconfig now successfully builds with current gcc-3.5
> CVS. However allyesconfig doesn't link because of symbol clashes in IRDA.
>
> - Various random fixes.
I sent this against -mm1, and no one commented on it, so I'm resending.
>From Tom Rini <trini@kernel.crashing.org>
Switch PPC32 over to drivers/Kconfig
arch/ppc/Kconfig | 41 +----------------------------------------
1 files changed, 1 insertion(+), 40 deletions(-)
--- 1.47/arch/ppc/Kconfig Mon Jan 19 16:38:06 2004
+++ edited/arch/ppc/Kconfig Thu Jan 22 13:47:15 2004
@@ -989,8 +989,6 @@
source "drivers/pcmcia/Kconfig"
-source "drivers/parport/Kconfig"
-
endmenu
menu "Advanced setup"
@@ -1088,36 +1086,7 @@
depends on ADVANCED_OPTIONS && 8xx
endmenu
-source "drivers/base/Kconfig"
-
-source "drivers/mtd/Kconfig"
-
-source "drivers/pnp/Kconfig"
-
-source "drivers/block/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "drivers/ide/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/message/fusion/Kconfig"
-
-source "drivers/ieee1394/Kconfig"
-
-source "drivers/message/i2o/Kconfig"
-
-source "net/Kconfig"
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/video/Kconfig"
-
-source "drivers/cdrom/Kconfig"
-
-source "drivers/input/Kconfig"
-
+source "drivers/Kconfig"
menu "Macintosh device drivers"
@@ -1253,14 +1222,8 @@
endmenu
-source "drivers/char/Kconfig"
-
-source "drivers/media/Kconfig"
-
source "fs/Kconfig"
-source "sound/Kconfig"
-
source "arch/ppc/8xx_io/Kconfig"
source "arch/ppc/8260_io/Kconfig"
@@ -1284,8 +1247,6 @@
default y
endmenu
-
-source "drivers/usb/Kconfig"
source "lib/Kconfig"
--
Tom Rini
http://gate.crashing.org/~trini/
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* Re: 2.6.2-rc1-mm3
From: Tom Rini @ 2004-01-26 20:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
In-Reply-To: <20040124180022.14fe495e.akpm@osdl.org>
On Sat, Jan 24, 2004 at 06:00:22PM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm3/
>
> - 2.6.2-rc1-mm3's allyesconfig now successfully builds with current gcc-3.5
> CVS. However allyesconfig doesn't link because of symbol clashes in IRDA.
>
> - Various random fixes.
I sent this against -mm1, and no one commented on it, so I'm resending.
>From Tom Rini <trini@kernel.crashing.org>
Switch PPC32 over to drivers/Kconfig
arch/ppc/Kconfig | 41 +----------------------------------------
1 files changed, 1 insertion(+), 40 deletions(-)
--- 1.47/arch/ppc/Kconfig Mon Jan 19 16:38:06 2004
+++ edited/arch/ppc/Kconfig Thu Jan 22 13:47:15 2004
@@ -989,8 +989,6 @@
source "drivers/pcmcia/Kconfig"
-source "drivers/parport/Kconfig"
-
endmenu
menu "Advanced setup"
@@ -1088,36 +1086,7 @@
depends on ADVANCED_OPTIONS && 8xx
endmenu
-source "drivers/base/Kconfig"
-
-source "drivers/mtd/Kconfig"
-
-source "drivers/pnp/Kconfig"
-
-source "drivers/block/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "drivers/ide/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/message/fusion/Kconfig"
-
-source "drivers/ieee1394/Kconfig"
-
-source "drivers/message/i2o/Kconfig"
-
-source "net/Kconfig"
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/video/Kconfig"
-
-source "drivers/cdrom/Kconfig"
-
-source "drivers/input/Kconfig"
-
+source "drivers/Kconfig"
menu "Macintosh device drivers"
@@ -1253,14 +1222,8 @@
endmenu
-source "drivers/char/Kconfig"
-
-source "drivers/media/Kconfig"
-
source "fs/Kconfig"
-source "sound/Kconfig"
-
source "arch/ppc/8xx_io/Kconfig"
source "arch/ppc/8260_io/Kconfig"
@@ -1284,8 +1247,6 @@
default y
endmenu
-
-source "drivers/usb/Kconfig"
source "lib/Kconfig"
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: 2.2 kernel and ext3 filesystems
From: Andrew Morton @ 2004-01-26 20:41 UTC (permalink / raw)
To: campbell; +Cc: linux-kernel
In-Reply-To: <20040126145633.GA26983@helium.inexs.com>
Chuck Campbell <campbell@accelinc.com> wrote:
>
> On Fri, Jan 23, 2004 at 09:58:48PM -0800, Andrew Morton wrote:
> > Chuck Campbell <campbell@accelinc.com> wrote:
> > >
> > > Was the ext3 filesystem ever back ported to the 2.2 kernel series?
> >
> > It was written for 2.2, and then forward-ported.
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/sct/ext3/v2.2/
>
> Interesting. I looked at the system running 2.2, and there are no ext3
> options in the running config file. It may have been later than 2.2.22...
ext3 was originally written for 2.2 but was never merged into the
mainstream kernel. That happened in 2.4.15.
^ permalink raw reply
* 2.6 sis900 (and tlan?) multicast bug
From: Joseph Fannin @ 2004-01-26 20:42 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
"Craig A. Huegen" <huegen@pentics.com> wrote:
> In the same vein as:
> http://seclists.org/lists/linux-kernel/2003/Oct/5794.html
> ...there is a bug in the SiS900 driver in 2.6.1 which prevents multicast
> MAC filtering from working properly. This breaks IPv6.
I'm seeing this problem too. My sis900 interface can't get an
IPv6 address unless promiscious or allmulti mode is set, since it
doesn't get responses on ip6-allrouters.
Please note that I am not subscribed to netdev, so a CC on any
responses would be appreciated.
> Patch attached (same one as from the 2.4 post from Oct 28) that made
> IPv6 work for me again.
From the original post, referring to the change this reverts:
>> This will not work for bit_nr larger than 16 and hence the failure.
>> Reverting to use set_bit causes multicast to be handled properly.
> --- linux/drivers/net/sis900.c.old 2004-01-17 03:56:53.893211412 -0600
> +++ linux/drivers/net/sis900.c 2004-01-17 03:57:02.785567615 -0600
> @@ -2091,9 +2091,8 @@
> rx_mode = RFAAB;
> for (i = 0, mclist = net_dev->mc_list; mclist && i < net_dev->mc_count;
> i++, mclist = mclist->next) {
> - unsigned int bit_nr =
> - sis900_mcast_bitnr(mclist->dmi_addr, revision);
> - mc_filter[bit_nr >> 4] |= (1 << bit_nr);
> + set_bit(sis900_mcast_bitnr(mclist->dmi_addr, revision),
> + mc_filter);
> }
> }
This fix didn't go into 2.4 either, so presumably something is wrong
with it (perhaps we're moving away from set_bit)? I am over my head
here really, but I don't want to just set allmulti mode and forget
about this bug.
I'm seeing the same behavior with my Thunderlan interfaces and
the tlan driver -- setting allmulti or promiscious mode fixes it
(while other boxes here with 3c509 and 3c556 cards work fine with the
same configuration.) I wonder, now that USAGI is in the stable
kernel, how many multicast bugs like this will turn up?
If anyone has any ideas where in tlan.c to begin looking, I'd be
glad to hear them; I'm not completely technically inept :-).
--
Joseph Fannin
jhf@rivenstone.net
"I think I said something eloquent, like 'Fuck.'" -- Rusty Russell.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Boot problem with 2.6.2-rc2
From: Ralf Hildebrandt @ 2004-01-26 20:44 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040126144947.GD6769@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> Hi!
> On my Toshiba Sattelite Pro 6100 I cannot boot 2.6.2-rc2. Right now
> I'm using 2.6.1-mm4, which works like a charm.
>
> Booting 2.6.2-rc2 just gives me a black screen with absoulutely no
> output and no activity.
neither
initcall_debug
nor
nmi_watchdog=1
or
nmi_watchdog=2 doesn't alter anything when used as append options when
booting.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916
Referat V a - Kommunikationsnetze - AIM. ralfpostfix
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Tom Rini @ 2004-01-26 20:46 UTC (permalink / raw)
To: George Anzinger
Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <4011B07F.5060409@mvista.com>
On Fri, Jan 23, 2004 at 03:38:39PM -0800, George Anzinger wrote:
> Tom Rini wrote:
> >On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
> >[snip]
> >
> >>First up:
> >>We need to call flush_instruction_cache() on a 'c' or 's' command.
> >>arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------
> >>1 files changed, 6 insertions(+), 13 deletions(-)
> >
> >
> >On tpo of this patch, there's the following:
> >Put back some code to figure out what signal we're dealing with.
> >
> > arch/ppc/kernel/ppc-stub.c | 63
> > ++++++++++++++++++++++++++++++++++++++++++---
> > 1 files changed, 60 insertions(+), 3 deletions(-)
> >--- 1.15/arch/ppc/kernel/ppc-stub.c Thu Jan 22 10:53:06 2004
> >+++ edited/arch/ppc/kernel/ppc-stub.c Fri Jan 23 15:43:10 2004
> >@@ -3,6 +3,7 @@
> > *
> > * PowerPC-specific bits to work with the common KGDB stub.
> > *
> >+ * 1998 (c) Michael AK Tesch (tesch@cs.wisc.edu)
> > * 2003 (c) TimeSys Corporation
> > * 2004 (c) MontaVista Software, Inc.
> > * This file is licensed under the terms of the GNU General Public License
> >@@ -19,13 +20,69 @@
> > #include <asm/processor.h>
> > #include <asm/machdep.h>
> >
> >+/* Convert the hardware trap type code to a unix signal number. */
> >+/*
> >+ * This table contains the mapping between PowerPC hardware trap types,
> >and
> >+ * signals, which are primarily what GDB understands.
> >+ */
> >+static struct hard_trap_info
> >+{
> >+ unsigned int tt; /* Trap type code for powerpc */
> >+ unsigned char signo; /* Signal that we map this trap into
> >*/
> >+} hard_trap_info[] = {
> >+#if defined(CONFIG_40x)
> >+ { 0x100, SIGINT }, /* critical input interrupt */
> >+ { 0x200, SIGSEGV }, /* machine check */
> >+ { 0x300, SIGSEGV }, /* data storage */
> >+ { 0x400, SIGBUS }, /* instruction storage */
> >+ { 0x500, SIGINT }, /* interrupt */
> >+ { 0x600, SIGBUS }, /* alignment */
> >+ { 0x700, SIGILL }, /* program */
> >+ { 0x800, SIGILL }, /* reserved */
> >+ { 0x900, SIGILL }, /* reserved */
> >+ { 0xa00, SIGILL }, /* reserved */
> >+ { 0xb00, SIGILL }, /* reserved */
> >+ { 0xc00, SIGCHLD }, /* syscall */
> >+ { 0xd00, SIGILL }, /* reserved */
> >+ { 0xe00, SIGILL }, /* reserved */
> >+ { 0xf00, SIGILL }, /* reserved */
> >+ { 0x2000, SIGTRAP}, /* debug */
> >+#else
> >+ { 0x200, SIGSEGV }, /* machine check */
> >+ { 0x300, SIGSEGV }, /* address error (store) */
> >+ { 0x400, SIGBUS }, /* instruction bus error */
> >+ { 0x500, SIGINT }, /* interrupt */
> >+ { 0x600, SIGBUS }, /* alingment */
> >+ { 0x700, SIGTRAP }, /* breakpoint trap */
> >+ { 0x800, SIGFPE }, /* fpu unavail */
> >+ { 0x900, SIGALRM }, /* decrementer */
> >+ { 0xa00, SIGILL }, /* reserved */
> >+ { 0xb00, SIGILL }, /* reserved */
> >+ { 0xc00, SIGCHLD }, /* syscall */
> >+ { 0xd00, SIGTRAP }, /* single-step/watch */
> >+ { 0xe00, SIGFPE }, /* fp assist */
> >+#endif
> >+ { 0, 0} /* Must be last */
> >+};
> >+
> >+static int computeSignal(unsigned int tt)
> >+{
> >+ struct hard_trap_info *ht;
> >+
> >+ for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
> >+ if (ht->tt == tt)
> >+ return ht->signo;
> >+
> >+ return SIGHUP; /* default for things we don't know about */
> >+}
> >+
> > /*
> > * Routines
> > */
> > static void
> > kgdb_debugger(struct pt_regs *regs)
> > {
> >- (*linux_debug_hook) (0, 0, 0, regs);
> >+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
> > return;
> > }
> >
> >@@ -52,14 +109,14 @@
> > int
> > kgdb_iabr_match(struct pt_regs *regs)
> > {
> >- (*linux_debug_hook) (0, 0, 0, regs);
> >+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
> > return 1;
> > }
> >
> > int
> > kgdb_dabr_match(struct pt_regs *regs)
> > {
> >- (*linux_debug_hook) (0, 0, 0, regs);
> >+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
> > return 1;
> > }
> >
> >
> >Now, not being as well versed in all of the debugging infos that can be
> >passed around, it sounds like this patch could be dropped in the future
> >for a cleaner method using some of the dwarf2 bits being talked about.
> >But I don't know, and clarification and pointers (if so) to how to do
> >this would be appreciated.
>
> I am not sure what this buys you. I don't think dwarf2 will help here.
OK.
> There is a real danger of passing signal info back to gdb as it will want
> to try to deliver the signal which is a non-compute in most kgdbs in the
> field. I did put code in the mm-kgdb to do just this, but usually the
> arrival of such a signal (other than SIGTRAP) is the end of the kernel.
> All that is left is to read the tea leaves.
The gdb I've been testing this with knows better than to try and send a
singal back, so that's not a worry. The motivation behind doing this
however is along the lines of "if it ain't broke, don't remove it". The
original stub was getting all of this information correctly, so why stop
doing it?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: New linux box
From: Ken Moffat @ 2004-01-26 20:56 UTC (permalink / raw)
To: Theo. Sean Schulze; +Cc: linux-newbie
In-Reply-To: <20040126195306.GA20068@teamfinders.org>
On Mon, 26 Jan 2004, Theo. Sean Schulze wrote:
> Ken,
>
> Are you referring to one the VIA Mini-ITX boards with the C3s or EPIA-M's installed? I have one of those, and from the reading I have been doing, it seems I am going to have quite a time of it configuring it under Slackware. VIA distributes binary drivers for their C3/EPIA-M boards, but the modules are built for a limited number of distros running stock kernels. They do have drivers that are distro independent, but I understand that they require a good bit of configuration to get working.
>
> If I weren't too worried about speed and wanted a small quiet box, I think I'd go more for one of the small form factor (SFF) boards and cases, such as Shuttle or Biostar. Right now, I am resisting the temptation to get a Shuttle SN45G to build as a firewall or PVR (if I get too frustrated with the VIA EPIA-M). Doesn't have the onboard video, so you can add a dependable video card of your own.
>
> If your experience with the C3 has been different though, let me know. I want to set this VIA board up as a PVR. Other than early, not-really-serious attempts to install the VIA video drivers, I haven't started messing with the VIA-specific parts of it yet. Still trying to get Freevo or MythTV to run on a Slackware distro.
>
> Cheers,
> Sean
>
(Sean, please can you fix your line length ?)
Did I say I've used one ? I'm just going by reviews and comments on
other lists, and the experience of people I respect. I'm thinking about
getting one eventually to replace my firewall, so I haven't given any
consideration to drivers for fancy stuff - but the original question was
about a machine for doing basic stuff. If anybody is minded to try one
of these, it's probably worth looking in the mailing lists for your
favourite distro to see if anything shows up.
I haven't used SFF stuff either, but all the reviews I've read suggest
they're significantly noisier than C3s (I'm thinking of the lower-speed
fanless C3 processors here), need full-size power supplies (more noise),
and are a standard (overspecified for many things) processor in a box
with limited potential for upgrading.
Ken
--
Bring back the PIII :)
-
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: [patch] remove null-ifiers
From: Len Brown @ 2004-01-26 20:58 UTC (permalink / raw)
To: Jes Sorensen; +Cc: ACPI Developers
In-Reply-To: <E1AgkrW-00080w-00-uLT3q8aHQDsX9StFTm9pZA@public.gmane.org>
Accepted.
thanks,
-Len
On Wed, 2004-01-14 at 08:15, Jes Sorensen wrote:
> Hi,
>
> The included patch removes a number of NULL-ilizers from the ACPI code
> resulting in variables being put in the data segment instead of the bss
> segment.
>
> Patch is relative to Andrew's 2.6.1-mm3 patch.
>
> Cheers,
> Jes
>
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/ac.c linux-2.6.1-mm3/drivers/acpi/ac.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/ac.c Wed Dec 17 18:58:47 2003
> +++ linux-2.6.1-mm3/drivers/acpi/ac.c Wed Jan 14 04:55:10 2004
> @@ -108,7 +108,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_ac_dir = NULL;
> +struct proc_dir_entry *acpi_ac_dir;
>
> int acpi_ac_seq_show(struct seq_file *seq, void *offset)
> {
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/asus_acpi.c linux-2.6.1-mm3/drivers/acpi/asus_acpi.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/asus_acpi.c Wed Dec 17 18:58:39 2003
> +++ linux-2.6.1-mm3/drivers/acpi/asus_acpi.c Wed Jan 14 05:00:01 2004
> @@ -73,8 +73,8 @@
> MODULE_LICENSE("GPL");
>
>
> -static uid_t asus_uid = 0;
> -static gid_t asus_gid = 0;
> +static uid_t asus_uid;
> +static gid_t asus_gid;
> MODULE_PARM(asus_uid, "i");
> MODULE_PARM_DESC(uid, "UID for entries in /proc/acpi/asus.\n");
> MODULE_PARM(asus_gid, "i");
> @@ -192,14 +192,14 @@
> };
>
> /* procdir we use */
> -static struct proc_dir_entry *asus_proc_dir = NULL;
> +static struct proc_dir_entry *asus_proc_dir;
>
> /*
> * This header is made available to allow proper configuration given model,
> * revision number , ... this info cannot go in struct asus_hotk because it is
> * available before the hotk
> */
> -static struct acpi_table_header *asus_info = NULL;
> +static struct acpi_table_header *asus_info;
>
> /*
> * The hotkey driver declaration
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/battery.c linux-2.6.1-mm3/drivers/acpi/battery.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/battery.c Wed Dec 17 18:59:17 2003
> +++ linux-2.6.1-mm3/drivers/acpi/battery.c Wed Jan 14 04:56:10 2004
> @@ -340,7 +340,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_battery_dir = NULL;
> +struct proc_dir_entry *acpi_battery_dir;
>
> static int
> acpi_battery_read_info (
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/button.c linux-2.6.1-mm3/drivers/acpi/button.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/button.c Wed Dec 17 18:58:06 2003
> +++ linux-2.6.1-mm3/drivers/acpi/button.c Wed Jan 14 04:56:39 2004
> @@ -107,7 +107,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -static struct proc_dir_entry *acpi_button_dir = NULL;
> +static struct proc_dir_entry *acpi_button_dir;
>
> static int acpi_button_info_seq_show(struct seq_file *seq, void *offset)
> {
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/ec.c linux-2.6.1-mm3/drivers/acpi/ec.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/ec.c Wed Dec 17 18:58:56 2003
> +++ linux-2.6.1-mm3/drivers/acpi/ec.c Wed Jan 14 04:57:01 2004
> @@ -475,7 +475,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_ec_dir = NULL;
> +struct proc_dir_entry *acpi_ec_dir;
>
>
> static int
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/fan.c linux-2.6.1-mm3/drivers/acpi/fan.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/fan.c Wed Dec 17 18:58:07 2003
> +++ linux-2.6.1-mm3/drivers/acpi/fan.c Wed Jan 14 04:57:17 2004
> @@ -71,7 +71,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_fan_dir = NULL;
> +struct proc_dir_entry *acpi_fan_dir;
>
>
> static int
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/osl.c linux-2.6.1-mm3/drivers/acpi/osl.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/osl.c Wed Jan 14 02:59:49 2004
> +++ linux-2.6.1-mm3/drivers/acpi/osl.c Wed Jan 14 05:00:25 2004
> @@ -59,13 +59,13 @@
> #ifdef ENABLE_DEBUGGER
> #include <linux/kdb.h>
> /* stuff for debugger support */
> -int acpi_in_debugger = 0;
> +int acpi_in_debugger;
> extern char line_buf[80];
> #endif /*ENABLE_DEBUGGER*/
>
> -static int acpi_irq_irq = 0;
> -static OSD_HANDLER acpi_irq_handler = NULL;
> -static void *acpi_irq_context = NULL;
> +static int acpi_irq_irq;
> +static OSD_HANDLER acpi_irq_handler;
> +static void *acpi_irq_context;
>
> acpi_status
> acpi_os_initialize(void)
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/power.c linux-2.6.1-mm3/drivers/acpi/power.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/power.c Wed Dec 17 18:58:56 2003
> +++ linux-2.6.1-mm3/drivers/acpi/power.c Wed Jan 14 04:58:13 2004
> @@ -387,7 +387,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_power_dir = NULL;
> +struct proc_dir_entry *acpi_power_dir;
>
> static int acpi_power_seq_show(struct seq_file *seq, void *offset)
> {
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/processor.c linux-2.6.1-mm3/drivers/acpi/processor.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/processor.c Wed Dec 17 18:59:05 2003
> +++ linux-2.6.1-mm3/drivers/acpi/processor.c Wed Jan 14 04:58:27 2004
> @@ -138,7 +138,7 @@
>
> static struct acpi_processor *processors[NR_CPUS];
> static struct acpi_processor_errata errata;
> -static void (*pm_idle_save)(void) = NULL;
> +static void (*pm_idle_save)(void);
>
>
> /* --------------------------------------------------------------------------
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/thermal.c linux-2.6.1-mm3/drivers/acpi/thermal.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/thermal.c Wed Jan 14 02:59:49 2004
> +++ linux-2.6.1-mm3/drivers/acpi/thermal.c Wed Jan 14 04:59:18 2004
> @@ -74,7 +74,7 @@
> MODULE_DESCRIPTION(ACPI_THERMAL_DRIVER_NAME);
> MODULE_LICENSE("GPL");
>
> -static int tzp = 0;
> +static int tzp;
> MODULE_PARM(tzp, "i");
> MODULE_PARM_DESC(tzp, "Thermal zone polling frequency, in 1/10 seconds.\n");
>
> @@ -766,7 +766,7 @@
> FS Interface (/proc)
> -------------------------------------------------------------------------- */
>
> -struct proc_dir_entry *acpi_thermal_dir = NULL;
> +struct proc_dir_entry *acpi_thermal_dir;
>
> static int acpi_thermal_state_seq_show(struct seq_file *seq, void *offset)
> {
> diff -urN -X /usr/people/jes/exclude-linux orig/linux-2.6.1-mm3-boot/drivers/acpi/toshiba_acpi.c linux-2.6.1-mm3/drivers/acpi/toshiba_acpi.c
> --- orig/linux-2.6.1-mm3-boot/drivers/acpi/toshiba_acpi.c Wed Dec 17 18:58:07 2003
> +++ linux-2.6.1-mm3/drivers/acpi/toshiba_acpi.c Wed Jan 14 04:59:33 2004
> @@ -215,7 +215,7 @@
> return status;
> }
>
> -static struct proc_dir_entry* toshiba_proc_dir = NULL;
> +static struct proc_dir_entry* toshiba_proc_dir;
> static int force_fan;
> static int last_key_event;
> static int key_event_valid;
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [patch] 2.6.2-rc2: link error with IrDA drivers
From: Adrian Bunk @ 2004-01-26 20:58 UTC (permalink / raw)
To: Jean Tourrilhes; +Cc: Kernel Mailing List, jgarzik, linux-net
In-Reply-To: <Pine.LNX.4.58.0401251844440.32583@home.osdl.org>
On Sun, Jan 25, 2004 at 06:48:24PM -0800, Linus Torvalds wrote:
>...
> Summary of changes from v2.6.2-rc1 to v2.6.2-rc2
> ============================================
>...
> Jean Tourrilhes:
> o [IRDA]: Update dongle api
> o [IRDA]: Update actisys-sir driver
> o [IRDA]: Update esr-sir driver
> o [IRDA]: Update tekram-sir driver
> o [IRDA]: Add litelink-sir driver
> o [IRDA]: Add act200l-sir driver
> o [IRDA]: Add girbil-sir driver
> o [IRDA]: Add ma600-sir driver
> o [IRDA]: Add mcp2120-sir driver
> o [IRDA]: Add old_belkin-sir driver
> o [IRDA]: Kconfig changes to enable new drivers into the build, from
> Martin Diehl
>...
This change causes the following compile error when trying to compile
an old plus a new version of one driver statically into the kernel:
<-- snip -->
...
LD drivers/net/irda/built-in.o
drivers/net/irda/girbil-sir.o(.init.text+0x0): In function `girbil_init':
: multiple definition of `girbil_init'
drivers/net/irda/girbil.o(.init.text+0x0): first defined here
drivers/net/irda/girbil-sir.o(.exit.text+0x0): In function `girbil_cleanup':
: multiple definition of `girbil_cleanup'
drivers/net/irda/girbil.o(.exit.text+0x0): first defined here
drivers/net/irda/old_belkin-sir.o(.init.text+0x0): In function `old_belkin_init':
: multiple definition of `old_belkin_init'
drivers/net/irda/old_belkin.o(.init.text+0x0): first defined here
drivers/net/irda/old_belkin-sir.o(.exit.text+0x0): In function
`old_belkin_cleanup':
: multiple definition of `old_belkin_cleanup'
drivers/net/irda/old_belkin.o(.exit.text+0x0): first defined here
drivers/net/irda/mcp2120-sir.o(.init.text+0x0): In function `mcp2120_init':
: multiple definition of `mcp2120_init'
drivers/net/irda/mcp2120.o(.init.text+0x0): first defined here
drivers/net/irda/mcp2120-sir.o(.exit.text+0x0): In function `mcp2120_cleanup':
: multiple definition of `mcp2120_cleanup'
drivers/net/irda/mcp2120.o(.exit.text+0x0): first defined here
drivers/net/irda/act200l-sir.o(.init.text+0x0): In function `act200l_init':
: multiple definition of `act200l_init'
drivers/net/irda/act200l.o(.init.text+0x0): first defined here
drivers/net/irda/act200l-sir.o(.exit.text+0x0): In function `act200l_cleanup':
: multiple definition of `act200l_cleanup'
drivers/net/irda/act200l.o(.exit.text+0x0): first defined here
make[3]: *** [drivers/net/irda/built-in.o] Error 1
<-- snip -->
The patch below fixes this issue by disallowing building an old driver
if the new driver was included staticallly.
Please apply
Adrian
--- linux-2.6.2-rc2-full/drivers/net/irda/Kconfig.old 2004-01-26 19:40:41.000000000 +0100
+++ linux-2.6.2-rc2-full/drivers/net/irda/Kconfig 2004-01-26 19:46:43.000000000 +0100
@@ -201,7 +201,7 @@
config GIRBIL_DONGLE_OLD
tristate "Greenwich GIrBIL dongle"
- depends on DONGLE_OLD && IRDA
+ depends on DONGLE_OLD && IRDA && GIRBIL_DONGLE!=y
help
Say Y here if you want to build support for the Greenwich GIrBIL
dongle. To compile it as a module, choose M here. The Greenwich
@@ -223,7 +223,7 @@
config MCP2120_DONGLE_OLD
tristate "Microchip MCP2120"
- depends on DONGLE_OLD && IRDA
+ depends on DONGLE_OLD && IRDA && MCP2120_DONGLE!=y
help
Say Y here if you want to build support for the Microchip MCP2120
dongle. To compile it as a module, choose M here. The MCP2120 dongle
@@ -237,7 +237,7 @@
config OLD_BELKIN_DONGLE_OLD
tristate "Old Belkin dongle"
- depends on DONGLE_OLD && IRDA
+ depends on DONGLE_OLD && IRDA && OLD_BELKIN_DONGLE!=y
help
Say Y here if you want to build support for the Adaptec Airport 1000
and 2000 dongles. To compile it as a module, choose M here: the module
@@ -246,7 +246,7 @@
config ACT200L_DONGLE_OLD
tristate "ACTiSYS IR-200L dongle (EXPERIMENTAL)"
- depends on DONGLE_OLD && EXPERIMENTAL && IRDA
+ depends on DONGLE_OLD && EXPERIMENTAL && IRDA && ACT200L_DONGLE!=y
help
Say Y here if you want to build support for the ACTiSYS IR-200L
dongle. To compile it as a module, choose M here. The ACTiSYS
^ permalink raw reply
* Re: [2.4 patch] fix via-ircc.c .text.exit error
From: Adrian Bunk @ 2004-01-26 21:01 UTC (permalink / raw)
To: jt; +Cc: Marcelo Tosatti, irda-users, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040126192836.GA17134@bougret.hpl.hp.com>
On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
>
> Thanks you Adrian. Yes, I must confess that I never test
> non-modular build (because it doesn't work).
>...
Are you saying it might compile statically, but it won't work?
In this case, what about disallowing building it statically in the
Config.in?
> Jean
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Encrypted Filesystem
From: Felipe Alfaro Solana @ 2004-01-26 21:04 UTC (permalink / raw)
To: Mark Borgerding; +Cc: Michael A Halcrow, Linux Kernel Mailinglist
In-Reply-To: <40156546.1050809@borgerding.net>
On Mon, 2004-01-26 at 20:06, Mark Borgerding wrote:
> Have you given any thought to journalling? fscking? Can directory
> contents be encrypted? If so, what does the dir look like to others
> (e.g. backup utils)
>
> Per-file signatures will severely affect random access performance.
> Changing 1 byte in a 1 GB file would require the whole thing to be reread.
What about calculating signatures on a per-block basis instead?
^ permalink raw reply
* Re: New linux box
From: caszonyi @ 2004-01-26 21:08 UTC (permalink / raw)
To: S. Barret Dolph; +Cc: linux-newbie
In-Reply-To: <200401262213.43388.wheds8@ms66.hinet.net>
On Mon, 26 Jan 2004, S. Barret Dolph wrote:
> Well, my problems have much to do with hardware and it is time to get a new
> box. My old box ran for 6 years with Mandrake and never crashed. (X-windows
> crashed when setting up Matrox 450 though.) My question is what hardware is
> good to avoid. I only use my computer for work, no games, but I am on it at
> least 6 hours or more a day. I care mostly about stability and don't really
> care too much about speed. So more to the point are any of you aware of
> hardware that is a nightmare to install. Or a site which can help.
>
If you want stability don't use the latest and greatest hardware (Video
card and motherboard chipset).
It is ussually good to avoid Nvidia because they have usually binary only
drivers and they are not stable.
> Cordially,
> S. Barret Dolph
> Taipei Taiwan
> -
Calin
--
"A mouse is a device used to point at
the xterm you want to type in".
Kim Alm on a.s.r.
-
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: [Bluez-devel] Device specific pins
From: Marcel Holtmann @ 2004-01-26 21:10 UTC (permalink / raw)
To: Dave Henriksen; +Cc: BlueZ Mailing List
In-Reply-To: <1075153448.2906.2.camel@linux.local>
Hi Dave,
> Just wondering if there is any way to have pins that vary depending upon
> what device you are connecting to. Currently, I just use
> /etb/bluetooth/givepin to supply a pin, but this pin must be the same
> for every device that my Linux laptop connects to.
this is a planned future for the new security manager which also
includes one-time PIN codes.
For the current version you must do it by yourself in a pin-helper
script. The BD_ADDR of the remote device is one of the parameters.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: [patch] 2.6.2-rc2: link error with IrDA drivers
From: David S. Miller @ 2004-01-26 20:57 UTC (permalink / raw)
To: bunk; +Cc: jt, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040126205829.GF513@fs.tum.de>
From: Adrian Bunk <bunk@fs.tum.de>
Date: Mon, 26 Jan 2004 21:58:29 +0100
This change causes the following compile error when trying to compile
an old plus a new version of one driver statically into the kernel:
That's not the right fix, just mark these init routines static.
I'll do that, thanks for the report.
^ permalink raw reply
* gkrellm reports cpu temp*10! linux-athlon kernel=2.6.2-rc1-mm2
From: Gene Heskett @ 2004-01-26 21:12 UTC (permalink / raw)
To: linux-kernel
Hi all;
I just rebooted 2 days ago to 2.6.2-rc1-mm2, and I just now noticed
that gkrellm is reporting my cpu at 680C. Thats about 10x what its
running at, still warm at 68C, but functional for 2 years now. I
didn't have this error under 2.6.1-rc2-mm4.
Any idea what patch to back out? And where to get it?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* MAX_PORTS for ftp modules
From: Nick Pasich @ 2004-01-26 21:14 UTC (permalink / raw)
To: netfilter-devel
Hi,
I've exhausted the MAX_PORTS limit of 8 for ftp using my own port id.
I'm wondering if there are any repercussions in upping the limit to say,
16 in the following modules.
ip_conntrack_ftp.c: #define MAX_PORTS 8
ip_conntrack_irc.c: #define MAX_PORTS 8
ip_conntrack_tftp.c: #define MAX_PORTS 8
ip_nat_ftp.c: #define MAX_PORTS 8
ip_nat_irc.c: #define MAX_PORTS 8
ip_nat_tftp.c: #define MAX_PORTS 8
I noticed that ipfwadm_core.c has "IP_FW_MAX_PORTS" which is defined in
ipfwadm_core.h as 10.
*********************************************************************************************************
linux/include/linux/netfilter_ipv4/ipfwadm_core.h:#define IP_FW_MAX_PORTS 10 /* A reasonable maximum */
*********************************************************************************************************
So what modules need to be changed and what kind of trouble am I going to
get into????
I'm not subscribed to the newsletter, so please respond to me directly.
Thanks,
---( Nick Pasich )---
^ permalink raw reply
* Re: [2.4 patch] fix via-ircc.c .text.exit error
From: David S. Miller @ 2004-01-26 21:02 UTC (permalink / raw)
To: bunk; +Cc: jt, marcelo.tosatti, irda-users, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040126210126.GG513@fs.tum.de>
From: Adrian Bunk <bunk@fs.tum.de>
Date: Mon, 26 Jan 2004 22:01:26 +0100
On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
> Thanks you Adrian. Yes, I must confess that I never test
> non-modular build (because it doesn't work).
Are you saying it might compile statically, but it won't work?
It won't link because many IRDA drivers erroneously don't
mark their module_{init,exit}() routines static, thus
symbols conflict.
I'm fixing that now.
^ permalink raw reply
* Re: [patch] 2.6.2-rc2: link error with IrDA drivers
From: Jean Tourrilhes @ 2004-01-26 21:16 UTC (permalink / raw)
To: David S. Miller; +Cc: bunk, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040126.125713.39171691.davem@redhat.com>
On Mon, Jan 26, 2004 at 12:57:13PM -0800, David S. Miller wrote:
> From: Adrian Bunk <bunk@fs.tum.de>
> Date: Mon, 26 Jan 2004 21:58:29 +0100
>
> This change causes the following compile error when trying to compile
> an old plus a new version of one driver statically into the kernel:
>
> That's not the right fix, just mark these init routines static.
>
> I'll do that, thanks for the report.
I've just sent the following patch to Andrew (following his
bug report), and I think it's slightly better and safer. Sorry I
forgot to cc you.
Jean
---------------------------------------------------------
diff -u -p linux/drivers/net/irda.d6b/act200l-sir.c linux/drivers/net/irda/act200l-sir.c
--- linux/drivers/net/irda.d6b/act200l-sir.c Thu Jan 22 16:43:35 2004
+++ linux/drivers/net/irda/act200l-sir.c Mon Jan 26 09:42:08 2004
@@ -93,12 +93,12 @@ static struct dongle_driver act200l = {
.set_speed = act200l_change_speed,
};
-int __init act200l_init(void)
+int __init act200l_sir_init(void)
{
return irda_register_dongle(&act200l);
}
-void __exit act200l_cleanup(void)
+void __exit act200l_sir_cleanup(void)
{
irda_unregister_dongle(&act200l);
}
@@ -254,5 +254,5 @@ MODULE_DESCRIPTION("ACTiSYS ACT-IR200L d
MODULE_LICENSE("GPL");
MODULE_ALIAS("irda-dongle-10"); /* IRDA_ACT200L_DONGLE */
-module_init(act200l_init);
-module_exit(act200l_cleanup);
+module_init(act200l_sir_init);
+module_exit(act200l_sir_cleanup);
diff -u -p linux/drivers/net/irda.d6b/girbil-sir.c linux/drivers/net/irda/girbil-sir.c
--- linux/drivers/net/irda.d6b/girbil-sir.c Thu Jan 22 16:43:39 2004
+++ linux/drivers/net/irda/girbil-sir.c Mon Jan 26 09:39:51 2004
@@ -72,12 +72,12 @@ static struct dongle_driver girbil = {
.set_speed = girbil_change_speed,
};
-int __init girbil_init(void)
+int __init girbil_sir_init(void)
{
return irda_register_dongle(&girbil);
}
-void __exit girbil_cleanup(void)
+void __exit girbil_sir_cleanup(void)
{
irda_unregister_dongle(&girbil);
}
@@ -254,5 +254,5 @@ MODULE_DESCRIPTION("Greenwich GIrBIL don
MODULE_LICENSE("GPL");
MODULE_ALIAS("irda-dongle-4"); /* IRDA_GIRBIL_DONGLE */
-module_init(girbil_init);
-module_exit(girbil_cleanup);
+module_init(girbil_sir_init);
+module_exit(girbil_sir_cleanup);
diff -u -p linux/drivers/net/irda.d6b/mcp2120-sir.c linux/drivers/net/irda/mcp2120-sir.c
--- linux/drivers/net/irda.d6b/mcp2120-sir.c Thu Jan 22 16:43:49 2004
+++ linux/drivers/net/irda/mcp2120-sir.c Mon Jan 26 09:41:41 2004
@@ -49,12 +49,12 @@ static struct dongle_driver mcp2120 = {
.set_speed = mcp2120_change_speed,
};
-int __init mcp2120_init(void)
+int __init mcp2120_sir_init(void)
{
return irda_register_dongle(&mcp2120);
}
-void __exit mcp2120_cleanup(void)
+void __exit mcp2120_sir_cleanup(void)
{
irda_unregister_dongle(&mcp2120);
}
@@ -226,5 +226,5 @@ MODULE_DESCRIPTION("Microchip MCP2120");
MODULE_LICENSE("GPL");
MODULE_ALIAS("irda-dongle-9"); /* IRDA_MCP2120_DONGLE */
-module_init(mcp2120_init);
-module_exit(mcp2120_cleanup);
+module_init(mcp2120_sir_init);
+module_exit(mcp2120_sir_cleanup);
diff -u -p linux/drivers/net/irda.d6b/old_belkin-sir.c linux/drivers/net/irda/old_belkin-sir.c
--- linux/drivers/net/irda.d6b/old_belkin-sir.c Thu Jan 22 16:43:52 2004
+++ linux/drivers/net/irda/old_belkin-sir.c Mon Jan 26 09:41:06 2004
@@ -78,12 +78,12 @@ static struct dongle_driver old_belkin =
.set_speed = old_belkin_change_speed,
};
-int __init old_belkin_init(void)
+int __init old_belkin_sir_init(void)
{
return irda_register_dongle(&old_belkin);
}
-void __exit old_belkin_cleanup(void)
+void __exit old_belkin_sir_cleanup(void)
{
irda_unregister_dongle(&old_belkin);
}
@@ -152,5 +152,5 @@ MODULE_DESCRIPTION("Belkin (old) SmartBe
MODULE_LICENSE("GPL");
MODULE_ALIAS("irda-dongle-7"); /* IRDA_OLD_BELKIN_DONGLE */
-module_init(old_belkin_init);
-module_exit(old_belkin_cleanup);
+module_init(old_belkin_sir_init);
+module_exit(old_belkin_sir_cleanup);
^ permalink raw reply
* r8169, 2.6.2-rc2, Sager 4780 laptop
From: bhartin @ 2004-01-26 21:19 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2898 bytes --]
(This was meant for author of the patches located at
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1/, who states to CC
the netdev list in regards to help with these patches. Unfortunately, the
author only stated to CC this list, but didn't include his own email.)
I've been looking through your patches as a source for help with my new
laptop. It's a Sager 4780, which uses an RTL-8169 on board. It is an
internal PCI version.
Under kernel 2.4.22, this NIC works perfectly.
Under 2.6.1 and 2.6.2-rc2, I have the following situation.
When I scp a file onto the laptop across the NIC, I get about
4.5Mbyte/sec, and once it reaches about 13MByte transferred, the NIC
ceases to function. No oops messages, no errors. You can't ping in or
out of the interface any longer.
When you scp a file from the laptop to elsewhere, it transfers at about
700kbyte/sec, and once it reaches a little over 6MByte, the entire system
locks up, hard.
This has been done on two completely different networks with varying
hardware, as to rule out anything related to such.
I have tried your 2.6.2-rc1 patches against 2.6.2-rc2 (they apply
cleanly). The driver behaves the same as before.
When I apply your 2.6.1 patches against 2.6.1, I get varying responses.
I tried a few combinations (following your order as listed). The most
notable effect of any of them is the r8169-init-one.patch. When I apply
that, insmod or modprobe lock up when inserting the module. They are
unkillable processes at that point. I even tried applying all the patches
except that one and the ethtool patch (it won't apply cleanly without the
init-one patch applied). When I did this, I started getting messages
about "eth0: Too much work at interrupt!" Once this occured, I rebooted
back into a stable 2.4.22 kernel. The NIC wasn't responding. I even
tried booting into WinXP, but the NIC still wouldn't respond. I was
finally forced to remove the battery from the laptop (not meant to be a
user task, as it is under a screwed-down cover). Once this was done, it
finally cleared the NIC properly and allowed me to continue.
I attempted a similar run with the 2.6.2-rc1 patches, cutting out the last
patch on the list one-by-one.
Attached is a tar.gz containing the outputs you request in your README,
plus 'lspci -v' output and my .config for the kernel. This data was
collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1
patches, manually doing a 'modprobe r8169' once booted up. The system is
running a P4 with HT enabled, with an SMP kernel.
I'm not at all familiar with kernel debugging, but I should be able to
carry out any tasks needed, given some minor instructions.
Please CC replies to my email address, as I'm not part of this mailing
list.
Thanks,
Bradley Hartin - bhartin@straus-frank.com
Communications and Network Administrator
Straus-Frank Company
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 14383 bytes --]
^ permalink raw reply
* Re: kernel BUG under 2.6.1-mm5
From: Jim Faulkner @ 2004-01-26 21:22 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <200401261827.50169.arvidjaar@mail.ru>
On Mon, 26 Jan 2004, Andrey Borzenkov wrote:
> On Thursday 22 January 2004 01:48, Andrew Morton wrote:
> > Jim Faulkner <jfaulkne@ccs.neu.edu> wrote:
> > > Hello,
> > >
> > > I am seeing some scary looking kernel bug entries in my dmesg under
> > > 2.6.1-mm5.
> > > ...
> > >
> > > kernel BUG at fs/dcache.c:760!
> > > invalid operand: 0000 [#1]
> > > PREEMPT SMP
> > > CPU: 0
> > > EIP: 0060:[<c0179627>] Not tainted VLI
> > > EFLAGS: 00010287
> > > EIP is at d_instantiate+0x17/0x90
> > > eax: f7baf200 ebx: c1b8bac0 ecx: 000021a4 edx: 00000000
> > > esi: f7a4f868 edi: f7baf200 ebp: f7a4f840 esp: f7a79e3c
> > > ds: 007b es: 007b ss: 0068
> > > Process hotplug (pid: 24, threadinfo=f7a78000 task=c1b06d00)
> > > Stack: 00000000 f7a992e4 c1b8bac0 c1b35940 f7a78000 f7a4f840 c01ad6de
> > > f7a4f840
> > > f7baf200 f7a4f840 f7a41e1c c1bbeb40 00000000 c1b06d00 c011f5b0
> > > 00000000
> > > 00000000 f7a96d00 c1b06d00 c011bb7d 00000000 c1b06d00 c011f5b0
> > > 00000000
> > > Call Trace:
> > > [<c01ad6de>] devfs_d_revalidate_wait+0xbe/0x1b0
> > > [<c011f5b0>] default_wake_function+0x0/0x20
> > > [<c011bb7d>] do_page_fault+0x32d/0x512
> > > [<c011f5b0>] default_wake_function+0x0/0x20
> > > [<c016e868>] do_lookup+0x68/0xb0
> > > [<c016ede8>] link_path_walk+0x538/0xa30
> > > [<c016fd03>] open_namei+0x83/0x420
> > > [<c011b850>] do_page_fault+0x0/0x512
> > > [<c040d4cb>] error_code+0x2f/0x38
> > > [<c015e61e>] filp_open+0x3e/0x70
> > > [<c015eb9b>] sys_open+0x5b/0x90
> > > [<c040c992>] sysenter_past_esp+0x43/0x65
> >
> > hmm. There was a patch in that area which I have subsequently dropped
> > because it was really fixing devfs problems in the wrong place.
> >
> hmm ...
>
> > Perhaps Andrey can ask you to test a subsequent patch if he takes another
> > look at this.
>
> please try this one. This basically does the same inside of devfs. It passed
> usual sanity checks here; I cannot reproduce oops you have (do you have SMP
> system?)
>
> I appreciate if someone with more intimate knowledge of fs/namei.c comments if
> conditions in devfs_d_revalidate_wait make sense.
>
> -andrey
>
Yes, I have an SMP system.
Your patch works! I applied it to 2.6.2-rc1-mm1 (which is the last -mm
version that doesn't kernel panic on me because of an unrelated bug), and
the "kernel BUG" warning has gone away.
thanks!
Jim Faulkner
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: George Anzinger @ 2004-01-26 21:27 UTC (permalink / raw)
To: Tom Rini; +Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <20040126204631.GB32525@stop.crashing.org>
Tom Rini wrote:
> On Fri, Jan 23, 2004 at 03:38:39PM -0800, George Anzinger wrote:
>
>>Tom Rini wrote:
>>
>>>On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
>>>[snip]
>>>
>>>
>>>>First up:
>>>>We need to call flush_instruction_cache() on a 'c' or 's' command.
>>>>arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------
>>>>1 files changed, 6 insertions(+), 13 deletions(-)
>>>
>>>
>>>On tpo of this patch, there's the following:
>>>Put back some code to figure out what signal we're dealing with.
>>>
>>>arch/ppc/kernel/ppc-stub.c | 63
>>>++++++++++++++++++++++++++++++++++++++++++---
>>>1 files changed, 60 insertions(+), 3 deletions(-)
>>>--- 1.15/arch/ppc/kernel/ppc-stub.c Thu Jan 22 10:53:06 2004
>>>+++ edited/arch/ppc/kernel/ppc-stub.c Fri Jan 23 15:43:10 2004
>>>@@ -3,6 +3,7 @@
>>> *
>>> * PowerPC-specific bits to work with the common KGDB stub.
>>> *
>>>+ * 1998 (c) Michael AK Tesch (tesch@cs.wisc.edu)
>>> * 2003 (c) TimeSys Corporation
>>> * 2004 (c) MontaVista Software, Inc.
>>> * This file is licensed under the terms of the GNU General Public License
>>>@@ -19,13 +20,69 @@
>>>#include <asm/processor.h>
>>>#include <asm/machdep.h>
>>>
>>>+/* Convert the hardware trap type code to a unix signal number. */
>>>+/*
>>>+ * This table contains the mapping between PowerPC hardware trap types,
>>>and
>>>+ * signals, which are primarily what GDB understands.
>>>+ */
>>>+static struct hard_trap_info
>>>+{
>>>+ unsigned int tt; /* Trap type code for powerpc */
>>>+ unsigned char signo; /* Signal that we map this trap into
>>>*/
>>>+} hard_trap_info[] = {
>>>+#if defined(CONFIG_40x)
>>>+ { 0x100, SIGINT }, /* critical input interrupt */
>>>+ { 0x200, SIGSEGV }, /* machine check */
>>>+ { 0x300, SIGSEGV }, /* data storage */
>>>+ { 0x400, SIGBUS }, /* instruction storage */
>>>+ { 0x500, SIGINT }, /* interrupt */
>>>+ { 0x600, SIGBUS }, /* alignment */
>>>+ { 0x700, SIGILL }, /* program */
>>>+ { 0x800, SIGILL }, /* reserved */
>>>+ { 0x900, SIGILL }, /* reserved */
>>>+ { 0xa00, SIGILL }, /* reserved */
>>>+ { 0xb00, SIGILL }, /* reserved */
>>>+ { 0xc00, SIGCHLD }, /* syscall */
>>>+ { 0xd00, SIGILL }, /* reserved */
>>>+ { 0xe00, SIGILL }, /* reserved */
>>>+ { 0xf00, SIGILL }, /* reserved */
>>>+ { 0x2000, SIGTRAP}, /* debug */
>>>+#else
>>>+ { 0x200, SIGSEGV }, /* machine check */
>>>+ { 0x300, SIGSEGV }, /* address error (store) */
>>>+ { 0x400, SIGBUS }, /* instruction bus error */
>>>+ { 0x500, SIGINT }, /* interrupt */
>>>+ { 0x600, SIGBUS }, /* alingment */
>>>+ { 0x700, SIGTRAP }, /* breakpoint trap */
>>>+ { 0x800, SIGFPE }, /* fpu unavail */
>>>+ { 0x900, SIGALRM }, /* decrementer */
>>>+ { 0xa00, SIGILL }, /* reserved */
>>>+ { 0xb00, SIGILL }, /* reserved */
>>>+ { 0xc00, SIGCHLD }, /* syscall */
>>>+ { 0xd00, SIGTRAP }, /* single-step/watch */
>>>+ { 0xe00, SIGFPE }, /* fp assist */
>>>+#endif
>>>+ { 0, 0} /* Must be last */
>>>+};
>>>+
>>>+static int computeSignal(unsigned int tt)
>>>+{
>>>+ struct hard_trap_info *ht;
>>>+
>>>+ for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
>>>+ if (ht->tt == tt)
>>>+ return ht->signo;
>>>+
>>>+ return SIGHUP; /* default for things we don't know about */
>>>+}
>>>+
>>>/*
>>> * Routines
>>> */
>>>static void
>>>kgdb_debugger(struct pt_regs *regs)
>>>{
>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>> return;
>>>}
>>>
>>>@@ -52,14 +109,14 @@
>>>int
>>>kgdb_iabr_match(struct pt_regs *regs)
>>>{
>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>> return 1;
>>>}
>>>
>>>int
>>>kgdb_dabr_match(struct pt_regs *regs)
>>>{
>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>> return 1;
>>>}
>>>
>>>
>>>Now, not being as well versed in all of the debugging infos that can be
>>>passed around, it sounds like this patch could be dropped in the future
>>>for a cleaner method using some of the dwarf2 bits being talked about.
>>>But I don't know, and clarification and pointers (if so) to how to do
>>>this would be appreciated.
>>
>>I am not sure what this buys you. I don't think dwarf2 will help here.
>
>
> OK.
>
>
>>There is a real danger of passing signal info back to gdb as it will want
>>to try to deliver the signal which is a non-compute in most kgdbs in the
>>field. I did put code in the mm-kgdb to do just this, but usually the
>>arrival of such a signal (other than SIGTRAP) is the end of the kernel.
>>All that is left is to read the tea leaves.
>
>
> The gdb I've been testing this with knows better than to try and send a
> singal back, so that's not a worry. The motivation behind doing this
> however is along the lines of "if it ain't broke, don't remove it". The
> original stub was getting all of this information correctly, so why stop
> doing it?
>
OK, but I still don't like losing the return address. Tell me again, why do you
need three different functions all doing the same thing?
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
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.