* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Benjamin Herrenschmidt @ 2003-01-09 17:52 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Linus Torvalds, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030109204626.A2007@jurassic.park.msu.ru>
On Thu, 2003-01-09 at 18:46, Ivan Kokshaysky wrote:
> There is no need for changes to arch-specific code, as everything
> is hidden in pci_scan_bus(). However, it's possible to use
> pci_scan_bus_parented() and pci_probe_resources() directly,
> because some arch-specific fixups between these two might
> be useful.
>
> Note: on powermacs, if the I/O ASIC is behind PCI-PCI bridge, the
> bridge device probably should be marked as "skip_probe" as well.
Good.
Yes, On these, I'll skip the pci<->pci bridge in cases there is one on
the path too, this will add some nasty logic to the pmac pci code, but
that's ok as long as that crap doesn't leak out of
arch/ppc/platforms/pmac_*
Ben.
^ permalink raw reply
* Re: APIC with SIS
From: Alan Cox @ 2003-01-09 18:44 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Justin Cormack, Linux Kernel Mailing List
In-Reply-To: <20030109184222.71dff627.skraw@ithnet.com>
On Thu, 2003-01-09 at 17:42, Stephan von Krawczynski wrote:
> > It looks like I managed to set something to turn shared interrupts off
> > too (because initially I was getting the shared int hang). Cant look in
> > the BIOS right now...
>
> You don't have to, just look at cat /proc/interrupts to see if some are shared ...
SiS APIC is not supported in 2.4. That it happens to work on your board with
ACPI is I suspect mostly luck
^ permalink raw reply
* Rage128 as secondary adapter
From: Jon Smirl @ 2003-01-09 17:47 UTC (permalink / raw)
To: fbdev
I'm working on aty128fb to make it support a Rage128
as a secondary adapter. It needs a few new minor
changes to do this.
My main problem is that secondary adapters are not
initialized at boot. I have a program (vbios.vm86)
that will initialize the R128, but instead I would
like to do it when the driver loads. vbios.vm86 goes
through a complicated process in real mode of
emulating the system boot ROM (same thing X does).
Can someone with access to the Rage128 documentation
tell me how to do this from protected mode? I have the
ROM mapped so the code can get to constants stored in
the ROM. What I need is a piece of C code equal to
what the ROM initialization does minus the part about
Int10 vector setup.
The programmers at ATI probably have a piece of code
available to do this since ATI's Windows driver can do
it. I've tried emailing and signing up as a developer
without response.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [patch 2.5] 2-pass PCI probing, i386 USB quirk
From: Ivan Kokshaysky @ 2003-01-09 17:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Grant Grundler, Paul Mackerras, Benjamin Herrenschmidt,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301070942440.1913-100000@home.transmeta.com>
Untested, but it might work. Perhaps this needs to be chip specific (VIA?).
Ivan.
--- 2.5.55/arch/i386/pci/fixup.c Thu Jan 9 07:04:19 2003
+++ linux/arch/i386/pci/fixup.c Thu Jan 9 15:10:34 2003
@@ -187,6 +187,24 @@ static void __devinit pci_fixup_transpar
dev->transparent = 1;
}
+/*
+ * On certain systems with legacy USB support, the USB controller does
+ * access the system memory while we boot, so disconnecting the host
+ * bridge (along with system memory) from PCI bus during the PCI window
+ * sizing causes immediate crash.
+ * To avoid this, clear the MASTER bit before we start probing the BARs.
+ */
+static void __devinit pci_fixup_usb_dma(struct pci_dev *dev)
+{
+ u16 cmd;
+
+ if ((dev->class >> 8) == PCI_CLASS_SERIAL_USB) {
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ pci_write_config_word(dev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MASTER);
+ }
+}
+
struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82451NX, pci_fixup_i450nx },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx },
@@ -205,5 +223,6 @@ struct pci_fixup pcibios_fixups[] = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0, pci_fixup_via_northbridge_bug },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_NCR, PCI_DEVICE_ID_NCR_53C810, pci_fixup_ncr53c810 },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_fixup_transparent_bridge },
+ { PCI_FIXUP_EARLY, PCI_ANY_ID, PCI_ANY_ID, pci_fixup_usb_dma },
{ 0 }
};
^ permalink raw reply
* Re: What's in a name?
From: Jesse Pollard @ 2003-01-09 17:48 UTC (permalink / raw)
To: root, vlad; +Cc: 'John Alvord', linux-kernel, rms
In-Reply-To: <Pine.LNX.3.95.1030109110746.10873A-100000@chaos.analogic.com>
On Thursday 09 January 2003 10:11 am, Richard B. Johnson wrote:
> On Thu, 9 Jan 2003, Vlad@Vlad.geekizoid.com wrote:
> > And in that same period, look at Linux, and then look at Hurd. Hurd even
> > has the advantage of using giant chunks of Linux code, but it still is
> > basically useless.
> >
> > Why should Linux be refered to as GNU/Linux because of tools, and yet
> > Hurd doesn't give credit where credit is due? RMS has done more to hurt
> > GNU with his current stance on the matter than Microsoft ever could.
> > He's getting annoying, too.
> >
> > Regards,
> > Scott
>
> Damn. This is getting tried and it doesn't seem to "go away".
>
> Anybody remember this Copyright notice?? Most ALL of the
> early Linux Distributions contained programs with this
> notice:
>
> /*
> * Copyright (c) 1983 Regents of the University of California.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms are permitted
> * provided that the above copyright notice and this paragraph are
> * duplicated in all such forms and that any documentation,
> * advertising materials, and other materials related to such
> * distribution and use acknowledge that the software was developed
> * by the University of California, Berkeley. The name of the
> * University may not be used to endorse or promote products derived
> * from this software without specific prior written permission.
> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
> * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
> * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> */
>
> #ifndef lint
> char copyright[] =
> "@(#) Copyright (c) 1983 Regents of the University of California.\n\
> All rights reserved.\n";
> #endif /* not lint */
>
>
> ...however. Something happened so that this code was lifted
> "whole cloth" into some later distributions that contained
> the GNU License notice. By some unknown mystery, the embeded
> copyright notice was eliminated as well. However, much of the
> code remained the same. In some little-used programs, all the
> code, including the bug, remained the same.
>
> If I had anything to do with so-called GNU, I'd keep my mouth
> shut so this wholesale appropriation of intellectual property
> was not investigated.
>
> Here is an early distribution of Linux:
>
> Script started on Thu Jan 9 10:55:02 2003
> # cd /usr/bin
> # strings * | grep Regents
> @(#) Copyright (c) 1980 Regents of the University of California.
> @(#) Copyright (c) 1980 The Regents of the University of California.
[snip]
> @(#) Copyright (c) 1991 The Regents of the University of California.
> # cd /sbin
> # strings * | grep Regents
> strings: control: No such file or directory
> strings: discard: No such file or directory
> The Regents of the University of California. All rights reserved.
> The Regents of the University of California. All rights reserved.
> The Regents of the University of California. All rights reserved.
> The Regents of the University of California. All rights reserved.
> strings: server: No such file or directory
> The Regents of the University of California. All rights reserved.
> strings: sysinit: No such file or directory
> # exit
> Script done on Thu Jan 9 10:57:53 2003
>
>
> So much for the absolute bullshit that GNU started Linux and that
> there is somehow a GNU/Linux. Most all of the early distributions
> used programs ported from BSD. The Linux-BSD emulation was so good,
> thanks to Linus and others, that most programs needed to only be
> recompiled.
>
> That, ladies and gentlemen, is the true history of the "Linux Operating
> System" with all of the components that RMS insists are his, actually
> coming from the University of California, Berkeley.
>
> Don't be bambozzled by the persons who will re-write history to glorify
> their accomplishments. Saying something over-and-over again doesn't
> make it true. Facts stand alone. They only need to be noted. Bullshit
> needs repeating.
I seem to remember that there was also a request from the University of
California to remove that code too. That was when they started charging
for the BSD distribution, and before the NetBSD got out, which also
had to rewrite/replace the code. Guess what got used...
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
^ permalink raw reply
* [patch 2.5] 2-pass PCI probing, hotplug changes
From: Ivan Kokshaysky @ 2003-01-09 17:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Grant Grundler, Paul Mackerras, Benjamin Herrenschmidt,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301070942440.1913-100000@home.transmeta.com>
As the hotplug drivers use low-level probing functions
(pci_do_scan_bus and pci_scan_bridge), they have to
use the phase #2 routine directly.
Ivan.
diff -urpN 2.5.55/drivers/hotplug/acpiphp_glue.c linux/drivers/hotplug/acpiphp_glue.c
--- 2.5.55/drivers/hotplug/acpiphp_glue.c Thu Jan 9 07:03:59 2003
+++ linux/drivers/hotplug/acpiphp_glue.c Thu Jan 9 15:33:29 2003
@@ -947,6 +947,7 @@ static int enable_device (struct acpiphp
pci_read_config_byte(dev, PCI_SECONDARY_BUS, &bus);
child = (struct pci_bus*) pci_add_new_bus(dev->bus, dev, bus);
pci_do_scan_bus(child);
+ pci_probe_resources(child);
}
/* associate pci_dev to our representation */
diff -urpN 2.5.55/drivers/hotplug/cpci_hotplug_pci.c linux/drivers/hotplug/cpci_hotplug_pci.c
--- 2.5.55/drivers/hotplug/cpci_hotplug_pci.c Thu Jan 9 07:04:17 2003
+++ linux/drivers/hotplug/cpci_hotplug_pci.c Thu Jan 9 15:59:12 2003
@@ -395,6 +395,7 @@ static int cpci_configure_bridge(struct
/* Scan behind bridge */
n = pci_scan_bridge(bus, dev, max, 2);
child = pci_find_bus(max + 1);
+ pci_probe_resources(child);
#ifdef CONFIG_PROC_FS
pci_proc_attach_bus(child);
#endif
diff -urpN 2.5.55/drivers/hotplug/cpqphp_pci.c linux/drivers/hotplug/cpqphp_pci.c
--- 2.5.55/drivers/hotplug/cpqphp_pci.c Thu Jan 9 07:04:25 2003
+++ linux/drivers/hotplug/cpqphp_pci.c Thu Jan 9 15:34:07 2003
@@ -284,7 +284,7 @@ int cpqhp_configure_device (struct contr
pci_read_config_byte(func->pci_dev, PCI_SECONDARY_BUS, &bus);
child = (struct pci_bus*) pci_add_new_bus(func->pci_dev->bus, (func->pci_dev), bus);
pci_do_scan_bus(child);
-
+ pci_probe_resources(child);
}
temp = func->pci_dev;
diff -urpN 2.5.55/drivers/hotplug/ibmphp_core.c linux/drivers/hotplug/ibmphp_core.c
--- 2.5.55/drivers/hotplug/ibmphp_core.c Thu Jan 9 07:04:28 2003
+++ linux/drivers/hotplug/ibmphp_core.c Thu Jan 9 15:38:25 2003
@@ -1071,6 +1071,7 @@ static int ibm_configure_device (struct
pci_read_config_byte (func->dev, PCI_SECONDARY_BUS, &bus);
child = (struct pci_bus *) pci_add_new_bus (func->dev->bus, (func->dev), bus);
pci_do_scan_bus (child);
+ pci_probe_resources (child);
}
temp = func->dev;
^ permalink raw reply
* Re: Re: Some ALSA documents on line
From: Patrick Shirkey @ 2003-01-09 17:40 UTC (permalink / raw)
Cc: Takashi Iwai, alsa-devel
In-Reply-To: <3E1DA93E.2070602@boosthardware.com>
I have made the changes to the docs page.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [patch 2.5] 2-pass PCI probing, generic part
From: Ivan Kokshaysky @ 2003-01-09 17:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Grant Grundler, Paul Mackerras, Benjamin Herrenschmidt,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301070942440.1913-100000@home.transmeta.com>
As discussed, this patch splits PCI probing into 2 phases.
1. Do the full bus enumeration, collect identification info for
all devices, call early fixup routines. At this stage we
can solve two kinds of problems:
- turn off devices generating PCI traffic, so we'll be
safe in the phase 2 (USB DMA case);
- allow alternative probing methods for devices that
cannot be safely probed by generic code (powermac I/O ASIC).
2. Sizing the BARs. Now it's possible to disable the device
being probed, which should fix ia64 case. Note that we
don't need to keep the device disabled when sizing ROM
base register, as we probe with ROM-enable bit cleared.
There is no need for changes to arch-specific code, as everything
is hidden in pci_scan_bus(). However, it's possible to use
pci_scan_bus_parented() and pci_probe_resources() directly,
because some arch-specific fixups between these two might
be useful.
Note: on powermacs, if the I/O ASIC is behind PCI-PCI bridge, the
bridge device probably should be marked as "skip_probe" as well.
Ivan.
diff -urpN 2.5.55/drivers/pci/probe.c linux/drivers/pci/probe.c
--- 2.5.55/drivers/pci/probe.c Thu Jan 9 07:04:19 2003
+++ linux/drivers/pci/probe.c Thu Jan 9 13:47:47 2003
@@ -47,8 +47,17 @@ static void pci_read_bases(struct pci_de
{
unsigned int pos, reg, next;
u32 l, sz;
+ u16 cmd;
struct resource *res;
+ if (dev->skip_probe)
+ return;
+
+ /* Disable I/O & memory decoding while we size the BARs. */
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ pci_write_config_word(dev, PCI_COMMAND,
+ cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
+
for(pos=0; pos<howmany; pos = next) {
next = pos+1;
res = &dev->resource[pos];
@@ -96,6 +105,9 @@ static void pci_read_bases(struct pci_de
#endif
}
}
+
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+
if (rom) {
dev->rom_base_reg = rom;
res = &dev->resource[PCI_ROM_RESOURCE];
@@ -342,7 +354,7 @@ static void pci_read_irq(struct pci_dev
* @dev: the device structure to fill
*
* Initialize the device structure with information about the device's
- * vendor,class,memory and IO-space addresses,IRQ lines etc.
+ * vendor, memory and IO-space addresses, IRQ lines etc.
* Called at initialisation of the PCI subsystem and by CardBus services.
* Returns 0 on success and -1 if unknown type of device (not normal, bridge
* or CardBus).
@@ -351,14 +363,9 @@ int pci_setup_device(struct pci_dev * de
{
u32 class;
- sprintf(dev->slot_name, "%02x:%02x.%d", dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
- sprintf(dev->dev.name, "PCI device %04x:%04x", dev->vendor, dev->device);
INIT_LIST_HEAD(&dev->pools);
- pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
- class >>= 8; /* upper 3 bytes */
- dev->class = class;
- class >>= 8;
+ class = dev->class >> 8;
DBG("Found %02x:%02x [%04x/%04x] %06x %02x\n", dev->bus->number, dev->devfn, dev->vendor, dev->device, class, dev->hdr_type);
@@ -410,8 +417,8 @@ int pci_setup_device(struct pci_dev * de
}
/*
- * Read the config data for a PCI device, sanity-check it
- * and fill in the dev structure...
+ * Read the config data for a PCI device and fill in
+ * the dev structure...
*/
struct pci_dev * __devinit pci_scan_device(struct pci_dev *temp)
{
@@ -433,18 +440,23 @@ struct pci_dev * __devinit pci_scan_devi
dev->vendor = l & 0xffff;
dev->device = (l >> 16) & 0xffff;
+ pci_read_config_dword(dev, PCI_CLASS_REVISION, &l);
+ dev->class = l >> 8; /* upper 3 bytes */
+
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
dev->dma_mask = 0xffffffff;
- if (pci_setup_device(dev) < 0) {
- kfree(dev);
- return NULL;
- }
pci_name_device(dev);
+ sprintf(dev->slot_name, "%02x:%02x.%d",
+ dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+
+ /* Early fixups, before probing the BARs */
+ pci_fixup_device(PCI_FIXUP_EARLY, dev);
+
/* now put in global tree */
- strcpy(dev->dev.bus_id,dev->slot_name);
+ strcpy(dev->dev.bus_id, dev->slot_name);
dev->dev.dma_mask = &dev->dma_mask;
device_register(&dev->dev);
@@ -480,13 +492,12 @@ struct pci_dev * __devinit pci_scan_slot
* the per-bus list of devices and add the /proc entry.
*/
pci_insert_device (dev, bus);
-
- /* Fix up broken headers */
- pci_fixup_device(PCI_FIXUP_HEADER, dev);
}
return first_dev;
}
+/* First phase of device discovery. Build the bus tree, collect header types,
+ class codes, device and vendor IDs. Perform early fixups. */
unsigned int __devinit pci_do_scan_bus(struct pci_bus *bus)
{
unsigned int devfn, max, pass;
@@ -510,11 +521,8 @@ unsigned int __devinit pci_do_scan_bus(s
}
/*
- * After performing arch-dependent fixup of the bus, look behind
- * all PCI-to-PCI bridges on this bus.
+ * Look behind all PCI-to-PCI bridges on this bus.
*/
- DBG("Fixups for bus %02x\n", bus->number);
- pcibios_fixup_bus(bus);
for (pass=0; pass < 2; pass++)
for (ln=bus->devices.next; ln != &bus->devices; ln=ln->next) {
dev = pci_dev_b(ln);
@@ -545,6 +553,38 @@ int __devinit pci_bus_exists(const struc
return 0;
}
+/* Second phase of device discovery. Probe the BARs, fill in the rest
+ of pci_dev structure, perform device and bus fixups. */
+void __devinit pci_probe_resources(struct pci_bus *bus)
+{
+ struct list_head *ln;
+
+ if (!bus)
+ return;
+
+ for (ln = bus->devices.next; ln != &bus->devices; ln = ln->next) {
+ struct pci_dev *dev = pci_dev_b(ln);
+
+ if (pci_setup_device(dev) < 0) {
+ pci_remove_device(dev);
+ kfree(dev);
+ }
+
+ /* Fix up broken headers */
+ pci_fixup_device(PCI_FIXUP_HEADER, dev);
+ }
+
+ /*
+ * After performing arch-dependent fixup of the bus, look behind
+ * all PCI-to-PCI bridges on this bus.
+ */
+ DBG("Fixups for bus %02x\n", bus->number);
+ pcibios_fixup_bus(bus);
+
+ for (ln = bus->children.next; ln != &bus->children; ln = ln->next)
+ pci_probe_resources(pci_bus_b(ln));
+}
+
struct pci_bus * __devinit pci_alloc_primary_bus_parented(struct device *parent, int bus)
{
struct pci_bus *b;
@@ -600,4 +640,5 @@ EXPORT_SYMBOL(pci_do_scan_bus);
EXPORT_SYMBOL(pci_scan_slot);
EXPORT_SYMBOL(pci_scan_bus);
EXPORT_SYMBOL(pci_scan_bridge);
+EXPORT_SYMBOL(pci_probe_resources);
#endif
diff -urpN 2.5.55/include/linux/pci.h linux/include/linux/pci.h
--- 2.5.55/include/linux/pci.h Thu Jan 9 07:04:13 2003
+++ linux/include/linux/pci.h Thu Jan 9 13:40:32 2003
@@ -412,7 +412,8 @@ struct pci_dev {
char slot_name[8]; /* slot name */
/* These fields are used by common fixups */
- unsigned int transparent:1; /* Transparent PCI bridge */
+ unsigned int transparent:1, /* Transparent PCI bridge */
+ skip_probe:1; /* Don't probe the BARs */
};
#define pci_dev_g(n) list_entry(n, struct pci_dev, global_list)
@@ -544,11 +545,14 @@ void pcibios_fixup_pbus_ranges(struct pc
/* Generic PCI functions used internally */
+void pci_probe_resources(struct pci_bus *bus);
int pci_bus_exists(const struct list_head *list, int nr);
struct pci_bus *pci_scan_bus_parented(struct device *parent, int bus, struct pci_ops *ops, void *sysdata);
static inline struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata)
{
- return pci_scan_bus_parented(NULL, bus, ops, sysdata);
+ struct pci_bus *pbus = pci_scan_bus_parented(NULL, bus, ops, sysdata);
+ pci_probe_resources(pbus);
+ return pbus;
}
struct pci_bus *pci_alloc_primary_bus_parented(struct device * parent, int bus);
static inline struct pci_bus *pci_alloc_primary_bus(int bus)
@@ -809,8 +813,11 @@ struct pci_fixup {
extern struct pci_fixup pcibios_fixups[];
-#define PCI_FIXUP_HEADER 1 /* Called immediately after reading configuration header */
-#define PCI_FIXUP_FINAL 2 /* Final phase of device fixups */
+#define PCI_FIXUP_EARLY 1 /* Called immediately after reading
+ device/vendor IDs and class code */
+#define PCI_FIXUP_HEADER 2 /* Called after reading configuration
+ header (including BARs) */
+#define PCI_FIXUP_FINAL 3 /* Final phase of device fixups */
void pci_fixup_device(int pass, struct pci_dev *dev);
^ permalink raw reply
* Re: APIC with SIS
From: Stephan von Krawczynski @ 2003-01-09 17:42 UTC (permalink / raw)
To: Justin Cormack; +Cc: linux-kernel
In-Reply-To: <1042131701.25527.8.camel@lotte>
On 09 Jan 2003 17:01:36 +0000
Justin Cormack <justin@street-vision.com> wrote:
> On Thu, 2003-01-09 at 16:59, Stephan von Krawczynski wrote:
>
> > Unfortunately it is not. Shared interrupts do _not_ work with APIC disabled.
> > They _only_ work with APIC enabled in BIOS _and_ APIC support patch from sf.
> > I tested every other combination and none did work.
>
> It looks like I managed to set something to turn shared interrupts off
> too (because initially I was getting the shared int hang). Cant look in
> the BIOS right now...
You don't have to, just look at cat /proc/interrupts to see if some are shared ...
--
Regards,
Stephan
^ permalink raw reply
* SGI INDY and RedHat
From: Carlos Vieira @ 2003-01-09 17:29 UTC (permalink / raw)
To: linux-mips
Hi,
I have an SGI Indy with R5000 MIPS processor
and with IRIX OS.
I want to make this machine a DNS Server with
RedHat for MIPS processor.
How can i install RedHat in this machine without
using IRIX that is installed.
Netboot at machine boot time is a good option (using bootp server
for downloading kernel and then get the rest of the
OS installation)?
Thanks in advance
Carlos
^ permalink raw reply
* Re: MB without keyboard controller / USB-only keyboard ?
From: Stephan von Krawczynski @ 2003-01-09 17:39 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <1042134121.27796.20.camel@irongate.swansea.linux.org.uk>
On 09 Jan 2003 17:42:01 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 2003-01-09 at 10:42, Stephan von Krawczynski wrote:
> > Hello all,
> >
> > how do I work with a mb that contains no keyboard controller, but has only
> > USB for keyboard and mouse?
> > While booting the kernel I get:
> >
> > pc_keyb: controller jammed (0xFF)
>
> Does your BIOS do keyboard emulation ?
It is Compaq EVO D510. It has merely nothing of interest in the BIOS (no
keyboard emu). As far as I remember it contains an I845 chipset.
--
Regards,
Stephan
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Chris Wood @ 2003-01-09 17:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3E1A16C5.87EDE35A@digeo.com>
Andrew Morton wrote:
> Chris Wood wrote:
>
>>Due to kswapd problems in Redhat's 2.4.9 kernel, I have had to upgrade
>>to the 2.4.20 kernel with the IBM Summit Patches for our IBM x440.
>>...
>>16480 total 0.0138
>> 6383 .text.lock.swap 110.0517
>> 4689 .text.lock.vmscan 28.2470
>> 4486 shrink_cache 4.6729
>> 168 rw_swap_page_base 0.6176
>> 124 prune_icache 0.5167
>
>
> With six gigs of memory, it looks like the VM has gone nuts
> trying to locate some reclaimable lowmem.
>
> Suggest you send the contents of /proc/meminfo and /proc/slabinfo,
> captured during a period of misbehaviour.
The server ran fine for 3 days, so it took a bit to get this info.
Is there a list of which patches I can apply if I don't want to apply
the entire 2.4.20aa1? I'm nervous about breaking other things, but may
give it a try anyway.
Thanks for the help!
Here is a /proc/meminfo when it is running fine:
total: used: free: shared: buffers: cached:
Mem: 6356955136 6035910656 321044480 0 206626816 5301600256
Swap: 2146529280 41652224 2104877056
MemTotal: 6207964 kB
MemFree: 313520 kB
MemShared: 0 kB
Buffers: 201784 kB
Cached: 5171716 kB
SwapCached: 5628 kB
Active: 3667492 kB
Inactive: 1912544 kB
HighTotal: 5373660 kB
HighFree: 203952 kB
LowTotal: 834304 kB
LowFree: 109568 kB
SwapTotal: 2096220 kB
SwapFree: 2055544 kB
Here is a /proc/meminfo when it is having problems:
total: used: free: shared: buffers: cached:
Mem: 6356955136 6337114112 19841024 0 369520640 5160353792
Swap: 2146529280 96501760 2050027520
MemTotal: 6207964 kB
MemFree: 19376 kB
MemShared: 0 kB
Buffers: 360860 kB
Cached: 5023300 kB
SwapCached: 16108 kB
Active: 2551264 kB
Inactive: 3291804 kB
HighTotal: 5373660 kB
HighFree: 15404 kB
LowTotal: 834304 kB
LowFree: 3972 kB
SwapTotal: 2096220 kB
SwapFree: 2001980 kB
Here is a /proc/slabinfo when it is fine:
slabinfo - version: 1.1 (SMP)
kmem_cache 64 64 244 4 4 1 : 252 126
ip_fib_hash 14 224 32 2 2 1 : 252 126
ip_conntrack 0 0 384 0 0 1 : 124 62
urb_priv 0 0 64 0 0 1 : 252 126
journal_head 1141 5929 48 33 77 1 : 252 126
revoke_table 7 250 12 1 1 1 : 252 126
revoke_record 448 448 32 4 4 1 : 252 126
clip_arp_cache 0 0 128 0 0 1 : 252 126
ip_mrt_cache 0 0 128 0 0 1 : 252 126
tcp_tw_bucket 384 510 128 13 17 1 : 252 126
tcp_bind_bucket 442 1008 32 9 9 1 : 252 126
tcp_open_request 570 570 128 19 19 1 : 252 126
inet_peer_cache 232 232 64 4 4 1 : 252 126
ip_dst_cache 807 1185 256 79 79 1 : 252 126
arp_cache 354 480 128 16 16 1 : 252 126
blkdev_requests 768 810 128 27 27 1 : 252 126
dnotify_cache 500 664 20 4 4 1 : 252 126
file_lock_cache 1157 2120 96 53 53 1 : 252 126
fasync_cache 565 600 16 3 3 1 : 252 126
uid_cache 419 448 32 4 4 1 : 252 126
skbuff_head_cache 780 1410 256 65 94 1 : 252 126
sock 426 1671 1280 288 557 1 : 60 30
sigqueue 725 725 132 25 25 1 : 252 126
kiobuf 0 0 64 0 0 1 : 252 126
cdev_cache 703 870 64 15 15 1 : 252 126
bdev_cache 9 116 64 2 2 1 : 252 126
mnt_cache 18 116 64 2 2 1 : 252 126
inode_cache 50995 50995 512 7285 7285 1 : 124 62
dentry_cache 71760 71760 128 2392 2392 1 : 252 126
dquot 0 0 128 0 0 1 : 252 126
filp 52314 52380 128 1746 1746 1 : 252 126
names_cache 28 28 4096 28 28 1 : 60 30
buffer_head 1342242 1486740 128 49558 49558 1 : 252 126
mm_struct 701 2355 256 155 157 1 : 252 126
vm_area_struct 11887 58530 128 1793 1951 1 : 252 126
fs_cache 831 2378 64 41 41 1 : 252 126
files_cache 597 2184 512 246 312 1 : 124 62
signal_act 501 2112 1408 168 192 4 : 60 30
pae_pgd 699 2378 64 41 41 1 : 252 126
size-131072(DMA) 0 0 131072 0 0 32 : 0 0
size-131072 0 0 131072 0 0 32 : 0 0
size-65536(DMA) 0 0 65536 0 0 16 : 0 0
size-65536 0 0 65536 0 0 16 : 0 0
size-32768(DMA) 0 0 32768 0 0 8 : 0 0
size-32768 1 5 32768 1 5 8 : 0 0
size-16384(DMA) 0 0 16384 0 0 4 : 0 0
size-16384 5 12 16384 5 12 4 : 0 0
size-8192(DMA) 0 0 8192 0 0 2 : 0 0
size-8192 5 7 8192 5 7 2 : 0 0
size-4096(DMA) 0 0 4096 0 0 1 : 60 30
size-4096 437 1127 4096 437 1127 1 : 60 30
size-2048(DMA) 0 0 2048 0 0 1 : 60 30
size-2048 314 434 2048 170 217 1 : 60 30
size-1024(DMA) 0 0 1024 0 0 1 : 124 62
size-1024 567 1464 1024 240 366 1 : 124 62
size-512(DMA) 0 0 512 0 0 1 : 124 62
size-512 906 968 512 120 121 1 : 124 62
size-256(DMA) 0 0 256 0 0 1 : 252 126
size-256 8724 8850 256 583 590 1 : 252 126
size-128(DMA) 2 60 128 2 2 1 : 252 126
size-128 3198 3450 128 114 115 1 : 252 126
size-64(DMA) 0 0 128 0 0 1 : 252 126
size-64 3486 4050 128 135 135 1 : 252 126
size-32(DMA) 34 116 64 2 2 1 : 252 126
size-32 22446 22446 64 387 387 1 : 252 126
Here is a /proc/slabinfo when it is having problems:
slabinfo - version: 1.1 (SMP)
kmem_cache 64 64 244 4 4 1 : 252 126
ip_fib_hash 14 224 32 2 2 1 : 252 126
ip_conntrack 0 0 384 0 0 1 : 124 62
urb_priv 0 0 64 0 0 1 : 252 126
journal_head 1660 3773 48 49 49 1 : 252 126
revoke_table 7 250 12 1 1 1 : 252 126
revoke_record 0 0 32 0 0 1 : 252 126
clip_arp_cache 0 0 128 0 0 1 : 252 126
ip_mrt_cache 0 0 128 0 0 1 : 252 126
tcp_tw_bucket 148 150 128 5 5 1 : 252 126
tcp_bind_bucket 696 896 32 8 8 1 : 252 126
tcp_open_request 120 120 128 4 4 1 : 252 126
inet_peer_cache 107 232 64 4 4 1 : 252 126
ip_dst_cache 960 960 256 64 64 1 : 252 126
arp_cache 232 360 128 12 12 1 : 252 126
blkdev_requests 768 810 128 27 27 1 : 252 126
dnotify_cache 238 332 20 2 2 1 : 252 126
file_lock_cache 1776 2040 96 51 51 1 : 252 126
fasync_cache 273 400 16 2 2 1 : 252 126
uid_cache 501 560 32 5 5 1 : 252 126
skbuff_head_cache 685 1020 256 68 68 1 : 252 126
sock 1095 1095 1280 365 365 1 : 60 30
sigqueue 203 203 132 7 7 1 : 252 126
kiobuf 0 0 64 0 0 1 : 252 126
cdev_cache 725 754 64 13 13 1 : 252 126
bdev_cache 9 116 64 2 2 1 : 252 126
mnt_cache 18 116 64 2 2 1 : 252 126
inode_cache 13808 20755 512 2965 2965 1 : 124 62
dentry_cache 5976 14070 128 469 469 1 : 252 126
dquot 0 0 128 0 0 1 : 252 126
filp 52314 52380 128 1746 1746 1 : 252 126
names_cache 8 8 4096 8 8 1 : 60 30
buffer_head 1335952 1470150 128 49005 49005 1 : 252 126
mm_struct 1620 1620 256 108 108 1 : 252 126
vm_area_struct 39180 39180 128 1306 1306 1 : 252 126
fs_cache 1815 1972 64 34 34 1 : 252 126
files_cache 1477 1477 512 211 211 1 : 124 62
signal_act 1430 1430 1408 130 130 4 : 60 30
pae_pgd 1798 1798 64 31 31 1 : 252 126
size-131072(DMA) 0 0 131072 0 0 32 : 0 0
size-131072 0 0 131072 0 0 32 : 0 0
size-65536(DMA) 0 0 65536 0 0 16 : 0 0
size-65536 0 0 65536 0 0 16 : 0 0
size-32768(DMA) 0 0 32768 0 0 8 : 0 0
size-32768 1 1 32768 1 1 8 : 0 0
size-16384(DMA) 0 0 16384 0 0 4 : 0 0
size-16384 5 5 16384 5 5 4 : 0 0
size-8192(DMA) 0 0 8192 0 0 2 : 0 0
size-8192 5 5 8192 5 5 2 : 0 0
size-4096(DMA) 0 0 4096 0 0 1 : 60 30
size-4096 981 1011 4096 981 1011 1 : 60 30
size-2048(DMA) 0 0 2048 0 0 1 : 60 30
size-2048 312 342 2048 167 171 1 : 60 30
size-1024(DMA) 0 0 1024 0 0 1 : 124 62
size-1024 1080 1080 1024 270 270 1 : 124 62
size-512(DMA) 0 0 512 0 0 1 : 124 62
size-512 832 832 512 104 104 1 : 124 62
size-256(DMA) 0 0 256 0 0 1 : 252 126
size-256 8550 8550 256 570 570 1 : 252 126
size-128(DMA) 2 60 128 2 2 1 : 252 126
size-128 2850 2850 128 95 95 1 : 252 126
size-64(DMA) 0 0 128 0 0 1 : 252 126
size-64 2591 4200 128 140 140 1 : 252 126
size-32(DMA) 34 116 64 2 2 1 : 252 126
size-32 2536 7134 64 123 123 1 : 252 126
>
> Then please apply
> http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.20aa1.bz2
> and send a report on the outcome.
^ permalink raw reply
* [linux-lvm] lvremove
From: Ross S. @ 2003-01-09 17:23 UTC (permalink / raw)
To: linux-lvm
Has anyone had this problem?
I went to remove a vserver, after stopping it, and I could not unmount
it. The error received was 'device is busy'. I verified the vserver
was stopped, I was not in the vserver's cwd, and (through lsof) there
were no processes being used for the vserver or calling it. Has anyone
else experienced this problem? And if so, is anyone aware of a solution
(other than reboot with modified fstab)?
- Ross S.
^ permalink raw reply
* Re: [PATCH] PATCH: IPMI driver
From: Alan Cox @ 2003-01-09 18:12 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030109172229.GA27288@codemonkey.org.uk>
On Thu, 2003-01-09 at 17:22, Dave Jones wrote:
> On Thu, Jan 09, 2003 at 06:06:34PM +0000, Alan Cox wrote:
>
> > Arghhh I was told Linus accepted it, and my tree indexer found "IPMI" so
> > decided it was present too. (Only the i2c definitions apparently).
>
> Shouldn't cause any problems in 2.4 anyways should it ?
> After all, its 'just another driver'.
>
> > Oh well, it should be in 2.5
>
> Added to the queue of bits from the 2.4 changesets list that I'm
> intending to push to Linus soon.
Pull the 2.5 port from openipmi.sourceforge.net saves you doing the port
yourself.
^ permalink raw reply
* Re: [PATCH] PATCH: IPMI driver
From: Dave Jones @ 2003-01-09 17:22 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042135594.27796.37.camel@irongate.swansea.linux.org.uk>
On Thu, Jan 09, 2003 at 06:06:34PM +0000, Alan Cox wrote:
> Arghhh I was told Linus accepted it, and my tree indexer found "IPMI" so
> decided it was present too. (Only the i2c definitions apparently).
Shouldn't cause any problems in 2.4 anyways should it ?
After all, its 'just another driver'.
> Oh well, it should be in 2.5
Added to the queue of bits from the 2.4 changesets list that I'm
intending to push to Linus soon.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [PATCH] PATCH: IPMI driver
From: Alan Cox @ 2003-01-09 18:06 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030109164407.GA26195@codemonkey.org.uk>
On Thu, 2003-01-09 at 16:44, Dave Jones wrote:
>
> Either I'm blind, or none of those files exist in Linus' tree
> looking at current bitkeeper snapshot.
Arghhh I was told Linus accepted it, and my tree indexer found "IPMI" so
decided it was present too. (Only the i2c definitions apparently). Oh
well, it should be in 2.5
^ permalink raw reply
* [PATCH]: rpc_debug mode causes an oops
From: Chuck Lever @ 2003-01-09 17:07 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Linux NFS List
hi trond-
this patch fixes a bug introduced by the recent rpc_procinfo change.
when entering debug mode, one of the debug printk's in sched.c expects
tk_msg.rpc_proc to be non-NULL, but now it can be NULL in certain
legitimate cases.
the rpc_qname cleanup below removes redundant code.
apply against 2.5.55.
net/sunrpc/sched.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -Naurp 00-stock/net/sunrpc/sched.c 01-debug-oops/net/sunrpc/sched.c
--- 00-stock/net/sunrpc/sched.c Wed Jan 8 23:04:15 2003
+++ 01-debug-oops/net/sunrpc/sched.c Thu Jan 9 10:55:36 2003
@@ -1123,11 +1123,12 @@ void rpc_show_tasks(void)
"-rpcwait -action- --exit--\n");
alltask_for_each(t, le, &all_tasks)
printk("%05d %04d %04x %06d %8p %6d %8p %08ld %8s %8p %8p\n",
- t->tk_pid, t->tk_msg.rpc_proc->p_proc,
+ t->tk_pid,
+ (t->tk_msg.rpc_proc ? t->tk_msg.rpc_proc->p_proc : -1),
t->tk_flags, t->tk_status,
t->tk_client, t->tk_client->cl_prog,
t->tk_rqstp, t->tk_timeout,
- t->tk_rpcwait ? rpc_qname(t->tk_rpcwait) : " <NULL> ",
+ rpc_qname(t->tk_rpcwait),
t->tk_action, t->tk_exit);
spin_unlock(&rpc_sched_lock);
}
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [OT] cross-compiler problem
From: Krishnakumar. R @ 2003-01-09 15:31 UTC (permalink / raw)
To: Indukumar Ilangovan; +Cc: linux-mips
In-Reply-To: <040b01c2b7f2$56ff0f40$a78b4d0a@apac.cisco.com>
Hi,
Have you changed the /usr/src/linux/include/asm
link to point to the asm-mips.
IMHO you should do it.
Hope it helps
Regards
KK
On Thursday 09 January 2003 08:48 pm, you wrote:
> Hi All,
>
> I tried to build cross compiler on Red Hat Linux
> Kernel 2.4.2-2 on an i686.
> I use binutils-2.13, gcc-3.2, glibc-2.2.5,
> glibc-2.2.5-mips-build-gmon.diff, glibc-linuxthreads.tar.gz.
> I followed the instructions from
> http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt
>
> I installed binutils without any problems.
>
> While compiling glibc2.2.5 I get the following error.
>
> ../sysdeps/unix/syscall.S: Assembler messages:
> ../sysdeps/unix/syscall.S:28: Error: absolute expression required `li'
> make[2]: *** [/home/iilangov/crossGCC/mips/mips-glibc/misc/syscall.o] Error
> 1
> make[2]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5/misc'
> make[1]: *** [misc/subdir_lib] Error 2
> make[1]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5'
> make: *** [all] Error 2
>
> I have "asm/unistd.h" in the include path, still this problem is happening.
> Do you guys have any clue ?
>
> Thanks in Advance !
> Indu
>
>
> ----- Original Message -----
> From: "Alexandre Oliva" <aoliva@redhat.com>
> To: "Khantharat Anekboon" <dfos1@hotmail.com>
> Cc: <crossgcc@sources.redhat.com>
> Sent: Saturday, December 28, 2002 12:22 PM
> Subject: Re: cross-compiler problem
>
> | On Dec 28, 2002, "Khantharat Anekboon" <dfos1@hotmail.com> wrote:
> | > ../sysdeps/unix/syscall.S:28: Error: absolute expression required 'li'
> |
> | Looks like you're missing the kernel headers where the syscall numbers
> | are defined. (.../include/asm/unistd.h)
> |
> | --
> | Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> | Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
> | CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
> | Free Software Evangelist Professional serial bug killer
> |
> | ------
> | Want more information? See the CrossGCC FAQ,
>
> http://www.objsw.com/CrossGCC/
>
> | Want to unsubscribe? Send a note to
>
> crossgcc-unsubscribe@sources.redhat.com
>
> ********************************************************
> Indukumar Ilangovan
> HCL-Cisco Offshore development center,
> 49-50, Nelson Manickam Road, Chennai - 600029 , India .
> TEL: +91-44-2374 1939 x 2215 FAX: +91-44-3741038
> Email :iilangov@cisco.com
^ permalink raw reply
* Re: NAPI and tg3
From: Robert Olsson @ 2003-01-09 17:21 UTC (permalink / raw)
To: David S. Miller
Cc: Steffen Persvold, Alan Cox, Robert Olsson, Jeff Garzik,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0301080059060.1128-100000@sp-laptop.isdn.scali.no>
Before it's get forgotten...
Cheers.
--ro
--- NAPI_HOWTO.txt.orig 2002-12-24 06:20:31.000000000 +0100
+++ NAPI_HOWTO.txt 2003-01-09 13:25:30.000000000 +0100
@@ -721,6 +721,23 @@
+
+APPENDIX 3: Scheduling issues.
+==============================
+As seen NAPI moves processing to softirq level. Linux uses the ksoftirqd as the
+general solution to schedule softirq's to run before next interrupt and by putting
+them under scheduler control. Also this prevents consecutive softirq's from
+monopolize the CPU. This also have the effect that the priority of ksoftirq needs
+to be considered when running very CPU-intensive applications and networking to
+get the proper balance of softirq/user balance. Increasing ksoftirq priority to 0
+(eventually more) is reported cure problems with low network performance at high
+CPU load.
+
+Most used processes in a GIGE router:
+USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
+root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0)
+root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated
+
--------------------------------------------------------------------
relevant sites:
^ permalink raw reply
* VIA8233/8235 testers wanted
From: Takashi Iwai @ 2003-01-09 17:01 UTC (permalink / raw)
To: alsa-devel; +Cc: alsa-user
Hi,
if someone has VIA8233, VIA8233A, VIA8233C or VIA8235 chipset, could
you help the testing of the new driver?
the new driver code is found at
http://www.alsa-project.org/~iwai/via82xx.c
(sorry, no links from the index page)
and replace it with alsa-kernel/pci/via82xx.c.
also, get
http://www.alsa-project.org/~iwai/VIA8233.conf
http://www.alsa-project.org/~iwai/VIA8233A.conf
and put them into /usr/share/alsa/cards directory.
the new driver can (hopefully) play multiple streams simultaneously on
VIA8233, VIA8233C and VIA8235, but NOT on VIA8233A.
also, if you have an SPDIF i/o, please check whether ac3dec works on
it. you might need to set up the mixer (IEC958 related stuffs)
preoprly beforehand.
TIA.
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [Linux-ia64] Re: disabling nics using boot options.
From: Bill Nottingham @ 2003-01-09 17:01 UTC (permalink / raw)
To: linux-ia64
Roy Dragseth (Roy.Dragseth@cc.uit.no) said:
> Further investigation shows that if I connect the Gbit interface to a 10Mbs
> hub everything works ok, e.g. using the ksdevice=eth2 boot option works as
> expected.
>
> I have narrowed this down to the following problem: When the init process
> tries to configure the eth2 with dhcp it fail, but if I logon as root and run
>
> /etc/init.d/network start
>
> everything works ok. Subsequent reboots also works ok because now the
> information is cached in /etc/dhcpc/. If I remove the cached info the
> problem turn up again.
So, it works post-install, but not in the installer? Hm. The dhcp client
code is different in the two cases, but not in a way that should
significantly affect this case.
Bill
^ permalink raw reply
* Re: a little help request (OT)
From: Haines Brown @ 2003-01-09 16:57 UTC (permalink / raw)
To: wd0fpc; +Cc: linux-hams
In-Reply-To: <Pine.LNX.4.50.0301090621490.32755-100000@yossarian.aniota.net>
Terry, thanks!
Haines
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: Oleg Drokin @ 2003-01-09 16:56 UTC (permalink / raw)
To: Russell Coker; +Cc: ReiserFS, Rik van Riel
In-Reply-To: <200301091431.54451.russell@coker.com.au>
Hello!
On Thu, Jan 09, 2003 at 02:31:54PM +0100, Russell Coker wrote:
> I have a server with 4G of RAM running ReiserFS for everything that matters.
> It has 2G of swap space free, but so far I have not seen swap usage go above
> 1.6M (so in normal use I could turn off swap entirely and expect not to see
> much difference).
> When it's under really heavy load (when I have a maintenance task involving a
> "find /" and there are lots of POP/IMAP clients hitting the server as well as
> mail delivery) and the load average gets to about 40, the "kswapd" kernel
> thread starts using excessive CPU time. It will stay on ~4% but have spikes
> of up to 45%!!! This is a two-processor machine so 45% CPU reported by top
> means 90% of a single CPU I guess. 90% of a 1.8GHz P4 CPU is a lot of CPU
> and I think that something is wrong.
Sounds exactly like yesterday/todays topic on lkml.
You have highmem box, during heavy IO all of the lowmempages are
occupied with bounce buffers and bh's.
Kernel needs more low memory and tries to free some with no much success though.
Known non-reiserfs related problem. Not easy to fix unfortunatelly.
Relevant lkml topic was "2.4.20, .text.lock.swap cpu usage? (ibm x440)"
Mail from Andrew Morton with msgid <3E1A16C5.87EDE35A@digeo.com>
He recommended to try http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.20aa1.bz2
"and send a report on the outcome"
Bye,
Oleg
^ permalink raw reply
* Re: Help! AMD Config Advice
From: Jörn Engel @ 2003-01-09 17:26 UTC (permalink / raw)
To: Frank R Callaghan; +Cc: LinuxMTD
In-Reply-To: <200301091146.13337.f.callaghan@ieee.org>
On Thu, 9 January 2003 11:46:13 -0500, Frank R Callaghan wrote:
> Subject: Help! AMD Config Advice
>
> Is there no solution to this question ?
> am I asking the wronge group ?
> is it so stupid it does not deserve a responce ?
It had the correct subject to be ignored. ;)
> I am looking to use an AMD flash chip on my pc104 card
> to store some non-volatile data, the chip is a 2MB part AMD29F016,
> the BIOS is in the top 128KB of the first mega-byte(do not want to
> overwrite).
>
> After setting up the kernel with MDT I get
> cat /proc/mtd
> dev: size erasesize name
> mtd0: 00200000 00010000 "Physically mapped flash"
>
> ok but I only need the second 1MB - is there some way to
> prevent the first meg being mapped/used ?
Maybe, but you have already tried the obvious. And it is a very odd
request, that you have too _much_ storage.
My first guess is that physmap calls up the cfi probing. cfi tells the
kernel about a 2MiB-Chip and that is what the kernel uses. Whether
this is correct behaviour or not, I don't want to decide.
> also I'm looking to use jffs2 as the file system - maybe I can partion it
> to only use the second meg ???
This would be the easiest. Easiest is to copy physmap.c and hardcode
the partitioning, as is already done dozens of time. Not pretty, but
simple.
Jörn
--
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
^ permalink raw reply
* Re: small fix for nforce ide chipset driver in 2.5.54
From: Alan Cox @ 2003-01-09 17:49 UTC (permalink / raw)
To: James Curbo; +Cc: Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <20030109065642.GA6251@carthage>
On Thu, 2003-01-09 at 06:56, James Curbo wrote:
> Well, I thought this deal was over but apparently not. My 2.5.54 kernel
> is still working fine, but when I compiled 2.4.20-ac2, it didn't pick up
> my Nforce2 IDE. On a whim I checked include/linux/pci_ids.h and it has a
> different PCI ID for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE, namely 0x01bc.
> (lspci -v reports 0x0065 here). Perhaps 0x01bc is the nforce1 ide
> chipset and 0x0065 is the nforce2 ide chipset?
2.4.21pre3-ac2 should support the Nforce and Nforce2. Its not the final driver
for 2.4 or 2.5 (there is a much nicer merged AMD/Nvidia one) but it will wait
until after 2.4.21 before I merge it.
^ 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.