Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 19 Feb 2005, Linus Torvalds wrote:
>
> Does a patch like this (instead of your version) work for you? It removes
> the Intel quirk entirely, and replaces it with the "if there's no
> resource, use the parent resource as the default fallback" code.
Here's a very very slightly changed patch. The only addition is to make
the extra line of
b->resource[2] = _resource;
which makes the root PCI device have "iomem_resource" for both it's
prefetchable and non-prefetchable resource. That's damn subtle, but it
means that it the non-prefetchable one is overridden by a half-transparent
setup like I have, then in order to see a prefetchable area at all, you
want that root iomem_resource to "shine through" the transparent
prefetchable region.
Andrew, I think this should be tested in -mm. I think it will fix Stevens
laptop, and the more I think about it, the more convinced I am that is it
the RightThing to do.. But it could easily break something subtle.
Linus
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 16:42:41 -08:00
+++ edited/arch/i386/pci/fixup.c2005-02-19 22:21:42 -08:00
@@ -197,23 +197,6 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0,
pci_fixup_via_northbridge_bug);
/*
- * For some reasons Intel decided that certain parts of their
- * 815, 845 and some other chipsets must look like PCI-to-PCI bridges
- * while they are obviously not. The 82801 family (AA, AB, BAM/CAM,
- * BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according
- * to Intel terminology. These devices do forward all addresses from
- * system to PCI bus no matter what are their window settings, so they are
- * "transparent" (or subtractive decoding) from programmers point of view.
- */
-static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
-{
- if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
- dev->transparent = 1;
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
pci_fixup_transparent_bridge);
-
-/*
* Fixup for C1 Halt Disconnect problem on nForce2 systems.
*
* From information provided by "Allen Martin" <[EMAIL PROTECTED]>:
= drivers/pci/probe.c 1.78 vs edited =
--- 1.78/drivers/pci/probe.c2005-02-02 22:42:24 -08:00
+++ edited/drivers/pci/probe.c 2005-02-19 22:44:24 -08:00
@@ -241,17 +241,20 @@
if (!dev) /* It's a host bus, nothing to read */
return;
+ /*
+* We default to the parent resources, and override them only
+* if this device has its own range defined.
+*/
+ for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
+ child->resource[i] = child->parent->resource[i];
+
if (dev->transparent) {
printk(KERN_INFO "PCI: Transparent bridge - %s\n",
pci_name(dev));
- for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
- child->resource[i] = child->parent->resource[i];
return;
}
- for(i=0; i<3; i++)
- child->resource[i] = >resource[PCI_BRIDGE_RESOURCES+i];
-
- res = child->resource[0];
+ /* Resource 0 - IO ports */
+ res = >resource[PCI_BRIDGE_RESOURCES+0];
pci_read_config_byte(dev, PCI_IO_BASE, _base_lo);
pci_read_config_byte(dev, PCI_IO_LIMIT, _limit_lo);
base = (io_base_lo & PCI_IO_RANGE_MASK) << 8;
@@ -269,9 +272,11 @@
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) |
IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
+ child->resource[0] = res;
}
- res = child->resource[1];
+ /* Resource 1 - nonprefetchable memory resource */
+ res = >resource[PCI_BRIDGE_RESOURCES+1];
pci_read_config_word(dev, PCI_MEMORY_BASE, _base_lo);
pci_read_config_word(dev, PCI_MEMORY_LIMIT, _limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
@@ -280,9 +285,11 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) |
IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xf;
+ child->resource[1] = res;
}
- res = child->resource[2];
+ /* Resource 2 - prefetchable memory resource */
+ res = >resource[PCI_BRIDGE_RESOURCES+2];
pci_read_config_word(dev, PCI_PREF_MEMORY_BASE, _base_lo);
pci_read_config_word(dev, PCI_PREF_MEMORY_LIMIT, _limit_lo);
base = (mem_base_lo & PCI_PREF_RANGE_MASK) << 16;
@@ -314,6 +321,7 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) |
IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xf;
+ child->resource[2] = res;
}
}
@@ -912,6 +920,7 @@
b->number = b->secondary = bus;
b->resource[0] =
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 19 Feb 2005, Steven Rostedt wrote:
>
> + /* the 2448 bridge is not transparent */
> + dev->device != 0x2448)
Btw, I've got a laptop with the exact same bridge chip PCI ID (well, mine
is "rev 83", while yours claims to be "rev 81"), and mine definitely _is_
transparent.
On my machine, "lspci -vvn -s 0:1e.0" gives:
I/O behind bridge: f000-0fff
Memory behind bridge: 9000-901f
Prefetchable memory behind bridge: fff0-000f
ie the IO and prefetchable memory ranges have actually been _disabled_
(that is, if we actually care about the PCI specs), yet it definitely
forwards them.
It looks to me like the Intel bridges have this magic behaviour where if
you disable a range, it turns into a subtractive decode.
Now, that's not hard to handle, and in fact, making the PCI bridge
handling in Linux match that kind of behaviour actually simplifies some
code.
Does a patch like this (instead of your version) work for you? It removes
the Intel quirk entirely, and replaces it with the "if there's no
resource, use the parent resource as the default fallback" code.
This seems to work on my laptop, which has the "transparent" case
(actually, it's "interesting" on my laptop, since it's only
half-transparent after this change: the non-prefetchable range is now put
in the 0x9000 area).
Does it work for the non-transparent case too? It should, but..
Damn. I think this might be the right thing to do, but I also suspect it's
not worth doing for 2.6.11, if only because it needs more testing. In
particular, the partial transparency case is a bit unnerving.
Linus
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 16:42:41 -08:00
+++ edited/arch/i386/pci/fixup.c2005-02-19 22:21:42 -08:00
@@ -197,23 +197,6 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8367_0,
pci_fixup_via_northbridge_bug);
/*
- * For some reasons Intel decided that certain parts of their
- * 815, 845 and some other chipsets must look like PCI-to-PCI bridges
- * while they are obviously not. The 82801 family (AA, AB, BAM/CAM,
- * BA/CA/DB and E) PCI bridges are actually HUB-to-PCI ones, according
- * to Intel terminology. These devices do forward all addresses from
- * system to PCI bus no matter what are their window settings, so they are
- * "transparent" (or subtractive decoding) from programmers point of view.
- */
-static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
-{
- if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
- dev->transparent = 1;
-}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
pci_fixup_transparent_bridge);
-
-/*
* Fixup for C1 Halt Disconnect problem on nForce2 systems.
*
* From information provided by "Allen Martin" <[EMAIL PROTECTED]>:
= drivers/pci/probe.c 1.78 vs edited =
--- 1.78/drivers/pci/probe.c2005-02-02 22:42:24 -08:00
+++ edited/drivers/pci/probe.c 2005-02-19 22:16:33 -08:00
@@ -241,17 +241,20 @@
if (!dev) /* It's a host bus, nothing to read */
return;
+ /*
+* We default to the parent resources, and override them only
+* if this device has its own range defined.
+*/
+ for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
+ child->resource[i] = child->parent->resource[i];
+
if (dev->transparent) {
printk(KERN_INFO "PCI: Transparent bridge - %s\n",
pci_name(dev));
- for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
- child->resource[i] = child->parent->resource[i];
return;
}
- for(i=0; i<3; i++)
- child->resource[i] = >resource[PCI_BRIDGE_RESOURCES+i];
-
- res = child->resource[0];
+ /* Resource 0 - IO ports */
+ res = >resource[PCI_BRIDGE_RESOURCES+0];
pci_read_config_byte(dev, PCI_IO_BASE, _base_lo);
pci_read_config_byte(dev, PCI_IO_LIMIT, _limit_lo);
base = (io_base_lo & PCI_IO_RANGE_MASK) << 8;
@@ -269,9 +272,11 @@
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) |
IORESOURCE_IO;
res->start = base;
res->end = limit + 0xfff;
+ child->resource[0] = res;
}
- res = child->resource[1];
+ /* Resource 1 - nonprefetchable memory resource */
+ res = >resource[PCI_BRIDGE_RESOURCES+1];
pci_read_config_word(dev, PCI_MEMORY_BASE, _base_lo);
pci_read_config_word(dev, PCI_MEMORY_LIMIT, _limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
@@ -280,9 +285,11 @@
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) |
IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xf;
+ child->resource[1] = res;
}
- res =
Re: Getting the page size of currently running kernel
On Saturday 19 February 2005 19:28, Roland Dreier wrote: > I'm not sure exactly how to call it from perl, but from C one can use > sysconf(3) like: > > page_size = sysconf(_SC_PAGESIZE); > > (one can also use getpagesize(2) to do exactly the same thing) And I was going nuts looking all over /proc and /sys for it. :) _SC_PAGESIZE is a part of Perl's POSIX module. Thanks Roland and Jan. - Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 19 Feb 2005, Steven Rostedt wrote: > > On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote: > > > I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the > > > > static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev) > > > > thing, and try to disable it. Maybe that rule is wrong, and triggers much > > too often? > > > > Linus, > > Thank you very much! That was it. The following patch made everything > look good. Ok. I've fired off an email to some Intel people asking what the real rules are wrt Intel PCI-PCI bridges. It may be that it's not that particular chip, but some generic rule (like "all Intel bridges act like they are subtractive decode _except_ if they actually have the IO start/stop ranges set" or something like that). If anybody on the list can figure the Intel bridge decoding rules out, please holler.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 2005-02-19 at 18:10 -0800, Linus Torvalds wrote:
> I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the
>
> static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
>
> thing, and try to disable it. Maybe that rule is wrong, and triggers much
> too often?
>
Linus,
Thank you very much! That was it. The following patch made everything
look good.
--- arch/i386/pci/fixup.c.orig 2005-02-19 22:22:29.622416639 -0500
+++ arch/i386/pci/fixup.c 2005-02-19 22:20:39.562713691 -0500
@@ -208,7 +208,9 @@
static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev)
{
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
- (dev->device & 0xff00) == 0x2400)
+ (dev->device & 0xff00) == 0x2400 &&
+ /* the 2448 bridge is not transparent */
+ dev->device != 0x2448)
dev->transparent = 1;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
pci_fixup_transparent_bridge);
PCMCIA cards now show up. Although I still have yet to get one of mine
working, but that's because of the card and not the bridge. Now I need
to start downloading drivers for my card. But at least the kernel now
sees them!
Thanks again,
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting the page size of currently running kernel
Scott> Is there any way to get a running kernel to tell you the Scott> size of its pages? Why: I'm writing a quick Perl hack to Scott> monitor the memory usage of the TCP stack over time. Easy Scott> enough: /proc/net/sockstat gives the current value of Scott> tcp_memory_allocated. But how do I convert this into Scott> bytes? I don't want to hard code PAGE_SIZE into my Perl Scott> script, complete with a lookup table for 4K vs. 8K Scott> architectures! Am I missing something obvious here? I'm not sure exactly how to call it from perl, but from C one can use sysconf(3) like: page_size = sysconf(_SC_PAGESIZE); (one can also use getpagesize(2) to do exactly the same thing) - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting the page size of currently running kernel
On Sunday 20 February 2005 05:01, Scott Bronson wrote: > Is there any way to get a running kernel to tell you the size of its pages? > > Why: I'm writing a quick Perl hack to monitor the memory usage of the TCP > stack over time. Easy enough: /proc/net/sockstat gives the current value of > tcp_memory_allocated. But how do I convert this into bytes? I don't want to > hard code PAGE_SIZE into my Perl script, complete with a lookup table for 4K > vs. 8K architectures! Am I missing something obvious here? Can you call functions in glibc through perl? If so, then getpagesize(2) is what you're looking for. Can you do raw syscalls in perl, if so, you could get the same info that way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated list of unused kernel exports posted
On Sat, 2005-02-19 at 22:14 +0100, Arjan van de Ven wrote: > +try_acquire_console_sem This is used by radeonfb and aty128fb at least... though only on ppc for now... It could be used later in fbdev's for "optisation". Basically, a trylock semantic on the console semaphore, allows you to try to do something right away (irq time), but defer if not possible. I use it in some low level PowerMac PM code. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Getting the page size of currently running kernel
Is there any way to get a running kernel to tell you the size of its pages? Why: I'm writing a quick Perl hack to monitor the memory usage of the TCP stack over time. Easy enough: /proc/net/sockstat gives the current value of tcp_memory_allocated. But how do I convert this into bytes? I don't want to hard code PAGE_SIZE into my Perl script, complete with a lookup table for 4K vs. 8K architectures! Am I missing something obvious here? Thanks, - Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption on 2.6.10-rc4-bk7
On Sat, Feb 19, 2005 at 02:41:47PM -0800, Andrew Morton wrote:
> Dave Jones <[EMAIL PROTECTED]> wrote:
> >
> > (This has actually been there for a while, but I only
> > noticed it in dmesg this morning).
> > During boot on a dual em64t I see ..
> >
> > scsi2 : ata_piix
> > isa bounce pool size: 16 pages
> > slab error in cache_free_debugcheck(): cache `size-2048': double free, or
> > memory outside object was overwritten
> >
> > Call Trace:{cache_free_debugcheck+392}
> > {kfree+234}
> >{:libata:ata_pci_init_one+937}
> > {pci_bus_read_config_word+122}
> >{:ata_piix:piix_init_one+498}
> > {pci_device_probe+134}
> >{driver_probe_device+77}
> > {driver_attach+75}
> >{bus_add_driver+169}
> > {pci_register_driver+131}
> >{:ata_piix:piix_init+16}
> > {sys_init_module+344}
> >{system_call+126}
> > 81011e49f4a0: redzone 1: 0x5a2cf071, redzone 2: 0x5a2cf071.
> >
>
> It's plain to see how ata_pci_init_one() will free `probe_ent' twice. Jeff
> wanna fix that up please? A naive fix would be
I'll take a look at it tomorrow when I get back home; it's not that
simple, as if you look through BK history, you'll see an almost reverse
patch applied, to fix another double-kfree (author: zaitcev).
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/typhoon: make a firmware image static
On Sat, 2005-02-19 at 09:43 +0100, Adrian Bunk wrote: > This patch makes a nedlessly global firmware image static. Doh! ACK. -- David Dillow <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
Helge Hafting wrote: No problem with the remote server, it does not depend on the local boot process. The mail program connects directly to the remote server, all you need is the network and it comes up so fast, it will come up way before X in a parallel boot. Depends on the implementation and what's required for network connectivity to the remote server. When I said that I was talking about the method that Lee Revell talked about, where he said "We should start X and initialize the display and get the login prompt up there ASAP, and let the system acquire the DHCP lease and start sendmail and apache and get the date from the NTP server *in the background while I am logging in*. It's not rocket science". Obviously, if the network is started synchronously it won't matter. Helge Hafting Jim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 19 Feb 2005, Steven Rostedt wrote: > > Here's the scoop: > > cat /proc/iomem: Ok. This one does not show device 00:1e.0 _at_all_. It had: I/O behind bridge: 3000-6fff Memory behind bridge: c200-cfff Prefetchable memory behind bridge: f000-f7ff and it just doesn't show. It shows some of the devices that are behind that bridge, though, and it should PCI Bus #01. Why not #02? Looks like we must have decided that that PCI bus is transparent. But we have the PCI device hierarchy right: > /sys/devices/pci:00/:00:1e.0/:02:00.0: > /sys/devices/pci:00/:00:1e.0/:02:01.0: > /sys/devices/pci:00/:00:1e.0/:02:01.1: > /sys/devices/pci:00/:00:1e.0/:02:02.0: Oh, and your dmesg does show: PCI: Transparent bridge - :00:1e.0 so that explains it. We believe that 0:1e.0 is transparent. Maybe we're even right. We do have a few quirky bridges that are marked transparent. I didn't think yours was one of them, though. I _think_ it's the code in arch/i386/pci/fixup.c that does this. See the static void __devinit pci_fixup_transparent_bridge(struct pci_dev *dev) thing, and try to disable it. Maybe that rule is wrong, and triggers much too often? Or maybe it really _is_ a transparent bridge after all, and the problem is somewhere else. Disabling the pci_fixup_transparent_bridge logic is a good thing to try first, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 2005-02-19 at 16:59 -0800, Linus Torvalds wrote: > The parent bridge has IO port mappings at 3000-6fff, and IO memory > mappings at c200-cfff and f000-f7ff. The cardbus stuff > _should_ all be behind those regions, but instead they are at 3fefb000 and > 4000-40fff000 (memory-mapped) and 4000-4cff (IO mapped). > Damn, I should have noticed that too, but I was so convinced that the PCMCIA was broken (since that's usually what is) that I didn't look elsewhere. > So something is seriously broken. > > That's a PCI layer brokenness, btw, not a PCMCIA brokenness. > > Can you enable debugging in arch/i386/pci/pci.h and post the whole bootup > dmesg. Also, can you show what /proc/iomem looks like, and what > ls -R /sys/devices/pci* > Here's the scoop: cat /proc/iomem: -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000cfbff : Video ROM 000d-000d17ff : Adapter ROM 000d1800-000d27ff : Adapter ROM 000e-000e : Extension ROM 000f-000f : System ROM 0010-0f6e : System RAM 0010-00300976 : Kernel code 00300977-003d72ff : Kernel data 0f6f-0f6f : reserved 0f70-3fee : System RAM 3fef-3fef7fff : ACPI Tables 3fef8000-3fef9fff : ACPI Non-volatile Storage 3fefa000-3fefa3ff : :00:1f.1 3fefb000-3fefbfff : :02:01.0 3fefb000-3fefbfff : yenta_socket 3fefc000-3fefcfff : :02:01.1 3fefc000-3fefcfff : yenta_socket 3ff0-3fff : reserved 4000-403f : PCI CardBus #03 4040-407f : PCI CardBus #03 4080-40bf : PCI CardBus #07 40c0-40ff : PCI CardBus #07 c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c100-c1ff : PCI Bus #01 c100-c1ff : :01:00.0 c100-c1ff : nvidia c200-c200 : :02:00.0 c200-c200 : tg3 c201-c201 : :02:02.0 c201-c201 : ath d000-dfff : :00:00.0 e000-efff : PCI Bus #01 e000-efff : :01:00.0 e000-e7ff : vesafb fec0-fec0 : reserved fee0-fee00fff : reserved ff80- : reserved cat /proc/ioports -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03bc-03be : parport0 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 1000-107f : :00:1f.0 1000-107f : motherboard 1000-1003 : PM1a_EVT_BLK 1004-1005 : PM1a_CNT_BLK 1008-100b : PM_TMR 1010-1015 : ACPI CPU throttle 1020-1020 : PM2_CNT_BLK 1028-102f : GPE0_BLK 1180-11bf : :00:1f.0 1180-11bf : motherboard 1800-181f : :00:1d.0 1800-181f : uhci_hcd 1820-183f : :00:1d.1 1820-183f : uhci_hcd 1840-185f : :00:1d.2 1840-185f : uhci_hcd 1860-186f : :00:1f.1 1880-189f : :00:1f.3 1880-188f : i801-smbus 18c0-18ff : :00:1f.5 18c0-18ff : Intel 82801DB-ICH4 1c00-1cff : :00:1f.5 1c00-1cff : Intel 82801DB-ICH4 2000-207f : :00:1f.6 2000-207f : Intel 82801DB-ICH4 Modem 2400-24ff : :00:1f.6 2400-24ff : Intel 82801DB-ICH4 Modem 4000-40ff : PCI CardBus #03 4400-44ff : PCI CardBus #03 4800-48ff : PCI CardBus #07 4c00-4cff : PCI CardBus #07 === ls -R /sys/devices/pci* /sys/devices/pci:00/: :00:00.0 :00:00.1 :00:00.3 :00:01.0 :00:1d.0 :00:1d.1 :00:1d.2 :00:1d.7 :00:1e.0 :00:1f.0 :00:1f.1 :00:1f.3 :00:1f.5 :00:1f.6 detach_state power /sys/devices/pci:00/:00:00.0: class config detach_state device driver irq local_cpus power resource subsystem_device subsystem_vendor vendor /sys/devices/pci:00/:00:00.0/power: state /sys/devices/pci:00/:00:00.1: class config detach_state device irq local_cpus power resource subsystem_device subsystem_vendor vendor /sys/devices/pci:00/:00:00.1/power: state /sys/devices/pci:00/:00:00.3: class config detach_state device irq local_cpus power resource subsystem_device subsystem_vendor vendor /sys/devices/pci:00/:00:00.3/power: state /sys/devices/pci:00/:00:01.0: :01:00.0 class config detach_state device irq local_cpus power resource subsystem_device subsystem_vendor vendor /sys/devices/pci:00/:00:01.0/:01:00.0: class config detach_state device driver irq local_cpus power resource rom subsystem_device subsystem_vendor vendor /sys/devices/pci:00/:00:01.0/:01:00.0/power: state /sys/devices/pci:00/:00:01.0/power: state /sys/devices/pci:00/:00:1d.0: class config detach_state device driver irq local_cpus pools power resource
Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
On Sat, 19 Feb 2005, Steven Rostedt wrote: > > :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 > [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Bus: primary=00, secondary=02, subordinate=08, sec-latency=168 > I/O behind bridge: 3000-6fff > Memory behind bridge: c200-cfff > Prefetchable memory behind bridge: f000-f7ff > BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- This is the bridge that your cardbus controller is behind: > :02:01.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus > Controller (rev 01) > Subsystem: IBM ThinkPad T30/T40 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 168, Cache Line Size: 0x20 (128 bytes) > Interrupt: pin A routed to IRQ 177 > Region 0: Memory at 3fefb000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 > Memory window 0: 4000-403ff000 (prefetchable) > Memory window 1: 4040-407ff000 > I/O window 0: 4000-40ff > I/O window 1: 4400-44ff > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+ > 16-bit legacy interface ports at 0001 > > :02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus > Controller (rev 01) > Subsystem: IBM ThinkPad T30/T40 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 168, Cache Line Size: 0x20 (128 bytes) > Interrupt: pin B routed to IRQ 185 > Region 0: Memory at 3fefc000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 > Memory window 0: 4080-40bff000 (prefetchable) > Memory window 1: 40c0-40fff000 > I/O window 0: 4800-48ff > I/O window 1: 4c00-4cff > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+ > 16-bit legacy interface ports at 0001 And quite frankly, their "Region 0:" things look broken: the bridge is a "Normal decode" bridge, which means that anything behind that bridge should only map things _within_ the IO windows of the bridge, ie all IO mappings on the cardbus bridge should be inside the IO mappings of the parent bridge. But they aren't. Now, your interrupts are a bit insane too, but they may actually be correct for all I know. The Yenta code will just decide that interrupts can't be working, since when it tries to trigger an interrupt it won't come in: but that is quite possibly not due to broken interrupts, but because the whole controller IO-MEM region has been mapped at the wrong place, so the controller simply never _sees_ our writes. The parent bridge has IO port mappings at 3000-6fff, and IO memory mappings at c200-cfff and f000-f7ff. The cardbus stuff _should_ all be behind those regions, but instead they are at 3fefb000 and 4000-40fff000 (memory-mapped) and 4000-4cff (IO mapped). So something is seriously broken. That's a PCI layer brokenness, btw, not a PCMCIA brokenness. Can you enable debugging in arch/i386/pci/pci.h and post the whole bootup dmesg. Also, can you show what /proc/iomem looks like, and what ls -R /sys/devices/pci* says (that cardbus controller should be properly nested _inside_ that PCI bridge, dammit!). Greg, any ideas? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]
Sorry for the repost, but I figured I might get the attention of someone that has an IBM Thinkpad G41 with the updated subject. -- Hi everyone, I've been banging my head on this one a couple of days with no luck. I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't get the PCMCIA working at all. I've tried turning off hyperthreading, I've tried with and without preempt, I've even added pci=noacpi. I've added Len's ACPI patches, but nothing works. Here's lspci -vvv: :00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Subsystem: IBM: Unknown device 0579 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: IBM: Unknown device 057a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- [ ... USB controllers snipped out ... ] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 :02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Subsystem: IBM ThinkPad T30/T40 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 The above is probably more than anyone needs, but if I should show the whole listing (USB, Audio and all), just let me know and I can post all of it too. And here's the dmesg: Linux Kernel Card Services options: [pci] [cardbus] [pm] ACPI: PCI interrupt :02:01.0[A] -> GSI 20 (level, low) -> IRQ 177 Yenta: CardBus bridge found at :02:01.0 [1014:0512] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:01.0, mfunc 0x01001c22, devctl 0x64 Yenta TI: socket :02:01.0 probing PCI interrupt failed, trying to fix Yenta TI: socket :02:01.0 no PCI interrupts. Fish. Please report. Yenta: ISA IRQ mask 0x, PCI irq 0 Socket status: ACPI: PCI interrupt :02:01.1[B] -> GSI 21 (level, low) -> IRQ 185 Yenta: CardBus bridge found at :02:01.1 [1014:0512] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:01.1, mfunc 0x01001c22, devctl 0x64 Yenta TI: socket :02:01.1 probing PCI interrupt failed, trying to fix Yenta TI: socket :02:01.1 no PCI interrupts. Fish. Please report. Yenta: ISA IRQ mask 0x, PCI irq 0 Socket status: 4410080c (the above is from kernel.org 2.6.10 with Len's ACPI patches). I've tried this with Debian stock kernels: 2.4.27-1-386, 2.6.8-2-686, 2.6.9-1-686, 2.6.10-1-686-smp I've also tried kernel.org kernels with 2.6.9, 2.6.10 and 2.6.11-rc3-mm2. As I've mentioned, I've added Len's ACPI patches to 2.6.10 and still nothing works. I've tried disable_clkrun but still nothing. I've found a couple of other patches on the net and nothing works. I've tried debugging this but PCMCIA is not my strong spot, so all I can tell you is that the interrupt never comes in when Yenta probes it. Does anyone else out there have a IBM Thinkpad G41 and have this working? Or, do you have it and it is not working. I get no power to the PCMCIA card slots, so they are basically useless now. Any ideas would be appreciated. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
hi, sorry, the host had poor advertisement. I opened a SF project and am waiting for its validation. In the meantimes, I changed host, this one has no ad: http://slvn.free.fr/kernelanalyzer/index.php I'm going to put more explanation on the site too. sylvain On Sat, 19 Feb 2005 19:17:18 -0500, Lee Revell <[EMAIL PROTECTED]> wrote: > On Sat, 2005-02-19 at 16:04 -0800, Randy.Dunlap wrote: > > > > > > For some reason all i ever get to see is the front page.. Any link just > > > leads to an empty page like this [screenshot]: > > > > That's also what I saw with firefox, but konqueror worked OK. > > > > I saw it at first with Firefox but then when I tried again it worked. > > > > http://affenbande.org/~tapas/kernelanalyzer_web.png > > > > > > I second lee's idea to move the project to sf.net or berlios. > > > > This wasn't my idea but it's a good one. > > Lee > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated list of unused kernel exports posted
bio_map_user bio_unmap_user Used by Oracle's GPL ASMLib driver. dcache_readdir simple_commit_write simple_getattr simple_link simple_prepare_write simple_readpage simple_rename simple_sync_file Used By OCFS2. Joel -- Life's Little Instruction Book #198 "Feed a stranger's expired parking meter." Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
On Sat, 2005-02-19 at 16:04 -0800, Randy.Dunlap wrote: > > > > For some reason all i ever get to see is the front page.. Any link just > > leads to an empty page like this [screenshot]: > > That's also what I saw with firefox, but konqueror worked OK. > I saw it at first with Firefox but then when I tried again it worked. > > http://affenbande.org/~tapas/kernelanalyzer_web.png > > > > I second lee's idea to move the project to sf.net or berlios. > This wasn't my idea but it's a good one. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
On Sat, 2005-02-19 at 15:45 -0500, Lee Revell wrote: > I have not tried "data=journal". As previously stated "data=writeback" > works perfectly - I ran JACK overnight while stressing the fs and did > not get one xrun. "data=journal" has the same good performance as "data=writeback". Only the ordered data mode is affected. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bootsplash for 2.6.11-rc4
Hi! > > > Just in case someone is interested, this is bootsplash for 2.6.11-rc4, > > > taken from suse kernel. I'll probably try to modify it to work with > > > radeonfb. > > > > > > Any ideas why bootsplash needs to hack into vesafb? It only uses > > > vesafb_ops to test against them before some kind of free... > > > > It doesn't really need vesafb for anything. Back in the days of 2.6.7 > > I used to release a version of bootsplash that had the dep. on vesafb > > removed. It worked fine with at least some other fb drivers. > > > > You might also want to save yourself some work and try out an > > alternative solution called fbsplash [1], which I designed after I got > > tired of fixing bootsplash and which I actively maintain. Fbsplash > > provides virtually the same functionality, and it has as much code as > > possible moved into userspace (no more JPEG decoders in the kernel). > > > > [1] http://dev.gentoo.org/~spock/projects/gensplash/current/ > > Pavel, I agree with Michal, take a look at this version of the code > instead of the version that you posted. It's a _whole_ lot more sane, > and possibly even mergable. Yes, I agree, almost anything is more sane than code I posted :-(. My only requirement is that it works with radeonfb and similar low-level drivers (so that I can get suspend-to-ram to work) and that it gets past our branding people... > Michal, any thoughts on submitting it for inclusion? It seems pretty > stable now. How many distros do use some variant of bootsplash? SuSE does, from above url I guess gentoo does, too... Does RedHat do something similar? [Or do they just set log-level to very high giving them clean look?] What about Debian? If most distros do some kind of splash screen, anyway, it would make sense to merge one "good" version... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
Florian Schmidt wrote: On Sat, 19 Feb 2005 02:33:00 +0100 sylvanino b <[EMAIL PROTECTED]> wrote: Hi, Sorry, it's meant to run on linux. Actually, patch provided is for linux 2.6.9 + kdb 4.4 I have uploaded a new tarball and updated the webpage. should be ok, Sylvain For some reason all i ever get to see is the front page.. Any link just leads to an empty page like this [screenshot]: That's also what I saw with firefox, but konqueror worked OK. http://affenbande.org/~tapas/kernelanalyzer_web.png I second lee's idea to move the project to sf.net or berlios. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated list of unused kernel exports posted
On Sat, Feb 19, 2005 at 10:14:33PM +0100, Arjan van de Ven wrote: > +get_sb_pseudo Used by Oracle's GPL ASMLib driver, and I think by some OCFS2 stuff as well. Joel -- "If you are ever in doubt as to whether or not to kiss a pretty girl, give her the benefit of the doubt" -Thomas Carlyle Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
On Sat, 19 Feb 2005 02:33:00 +0100 sylvanino b <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry, it's meant to run on linux. > Actually, patch provided is for linux 2.6.9 + kdb 4.4 > > > I have uploaded a new tarball and updated the webpage. > should be ok, > > Sylvain For some reason all i ever get to see is the front page.. Any link just leads to an empty page like this [screenshot]: http://affenbande.org/~tapas/kernelanalyzer_web.png I second lee's idea to move the project to sf.net or berlios. flo -- Palimm Palimm! http://affenbande.org/~tapas/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: Workaround memory corruption accel problem
Hi !
A conflict between X and radeonfb can cause system memory corruption
when switching console from X (note that this is not realted to the
recent radeonfb patches, the problem has been there forever as far as I
can tell).
This patch works around it in radeonfb by making sure the "offsets"
register that driver the memory mapping of the accel engine are always
properly set before every accel op. A better fix should be done in fbcon
ultimately.
Please apply to 2.6.11
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/drivers/video/aty/radeon_accel.c
===
--- linux-work.orig/drivers/video/aty/radeon_accel.c2005-01-24
17:09:44.0 +1100
+++ linux-work/drivers/video/aty/radeon_accel.c 2005-02-20 10:41:37.0
+1100
@@ -4,6 +4,41 @@
* "ACCEL_MMIO" ifdef branches in XFree86
* --dte
*/
+
+static void radeon_fixup_offset(struct radeonfb_info *rinfo)
+{
+ u32 local_base;
+
+ /* *** Ugly workaround *** */
+ /*
+* On some platforms, the video memory is mapped at 0 in radeon chip
space
+* (like PPCs) by the firmware. X will always move it up so that it's
seen
+* by the chip to be at the same address as the PCI BAR.
+* That means that when switching back from X, there is a mismatch
between
+* the offsets programmed into the engine. This means that potentially,
+* accel operations done before radeonfb has a chance to re-init the
engine
+* will have incorrect offsets, and potentially trash system memory !
+*
+* The correct fix is for fbcon to never call any accel op before the
engine
+* has properly been re-initialized (by a call to set_var), but this is
a
+* complex fix. This workaround in the meantime, called before every
accel
+* operation, makes sure the offsets are in sync.
+*/
+
+ radeon_fifo_wait (1);
+ local_base = INREG(MC_FB_LOCATION) << 16;
+ if (local_base == rinfo->fb_local_base)
+ return;
+
+ rinfo->fb_local_base = local_base;
+
+ radeon_fifo_wait (3);
+ OUTREG(DEFAULT_PITCH_OFFSET, (rinfo->pitch << 0x16) |
+(rinfo->fb_local_base >> 10));
+ OUTREG(DST_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base
>> 10));
+ OUTREG(SRC_PITCH_OFFSET, (rinfo->pitch << 0x16) | (rinfo->fb_local_base
>> 10));
+}
+
static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo,
const struct fb_fillrect *region)
{
@@ -38,6 +73,8 @@
return;
}
+ radeon_fixup_offset(rinfo);
+
vxres = info->var.xres_virtual;
vyres = info->var.yres_virtual;
@@ -105,6 +142,8 @@
return;
}
+ radeon_fixup_offset(rinfo);
+
vxres = info->var.xres_virtual;
vyres = info->var.yres_virtual;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Current bk on ppc32: kernel text corruption
On Fri, 2005-02-18 at 18:09 +1100, Benjamin Herrenschmidt wrote: > Ok, we may not be over with memory corruption bugs yet. ppc64 now seem > stable running LTP overnight, but my laptop has a page of kernel .text > replaced with zero's as soon as I launch X (and just X, no need to launc > the whole desktop environment). > > I suspect remap_pfn_range() but I haven't checked yet. Ok, I found it. It's a bug that was there forever it seems, where radeonfb accel ops may corrupt kernel memory (via bus master from the radeon chip) when switching back from X, due to X remapping some areas of the card vs. fbcon calling some radeonfb accel ops before radeonfb has a chance to re-initialize the chip (when switching back from X). I'm cooking a workaround patch for 2.6.11, will be ready as soon as I have tested. Proper fix is to make sure fbcon never calls any fbdev accel op before the chip has been properly restored (by a set_var call), but that is beyond the scope of 2.6.11 I suppose... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Symlink /sys/class/block to /sys/block
Greg,
Following the discussion in [1], the attached patch creates /sys/class/block
as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.
Please cc: me on any replies - I'm not subscribed to the mailing list.
[1] http://marc.theaimsgroup.com/?m=110506536315986
Regards,
Malcolm
Signed-off-by: Malcolm Rowe <[EMAIL PROTECTED]>
diff -ur linux-2.6.11-rc4-bk7/drivers/base/class.c
linux-2.6.11-rc4-bk7-diff/drivers/base/class.c
--- linux-2.6.11-rc4-bk7/drivers/base/class.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/base/class.c 2005-02-19
21:38:31.0 +
@@ -69,7 +69,7 @@
};
/* Hotplug events for classes go to the class_obj subsys */
-static decl_subsys(class, _class, NULL);
+decl_subsys(class, _class, NULL);
int class_create_file(struct class * cls, const struct class_attribute *
attr)
diff -ur linux-2.6.11-rc4-bk7/drivers/block/genhd.c
linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c
--- linux-2.6.11-rc4-bk7/drivers/block/genhd.c 2005-02-19 21:34:31.0
+
+++ linux-2.6.11-rc4-bk7-diff/drivers/block/genhd.c 2005-02-19
22:01:56.0 +
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#define MAX_PROBE_HASH 255 /* random */
@@ -300,11 +301,24 @@
return NULL;
}
+extern struct subsystem class_subsys;
+
static int __init genhd_device_init(void)
{
bdev_map = kobj_map_init(base_probe, _subsys);
blk_dev_init();
- subsystem_register(_subsys);
+ if (!subsystem_register(_subsys)) {
+ /*
+ * /sys/block should really live under /sys/class, but for
+ * the moment, we can only have class devices, not
+ * sub-classes-devices. Until we can move /sys/block into
+ * the right place, create a symlink from /sys/class/block to
+ * /sys/block, so that userspace doesn't need to know about
+ * the difference.
+ */
+ sysfs_create_link(_subsys.kset.kobj,
+ _subsys.kset.kobj, "block");
+ }
return 0;
}
@@ -406,6 +420,7 @@
static void disk_release(struct kobject * kobj)
{
struct gendisk *disk = to_disk(kobj);
+ sysfs_remove_link(_subsys.kset.kobj, "block");
kfree(disk->random);
kfree(disk->part);
free_disk_stats(disk);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bootsplash for 2.6.11-rc4
On Sat, Feb 19, 2005 at 02:14:34AM +0100, Michal Januszewski wrote: > On Fri, Feb 18, 2005 at 05:52:54PM +0100, Pavel Machek wrote: > > Hi, > > > Just in case someone is interested, this is bootsplash for 2.6.11-rc4, > > taken from suse kernel. I'll probably try to modify it to work with > > radeonfb. > > > > Any ideas why bootsplash needs to hack into vesafb? It only uses > > vesafb_ops to test against them before some kind of free... > > It doesn't really need vesafb for anything. Back in the days of 2.6.7 > I used to release a version of bootsplash that had the dep. on vesafb > removed. It worked fine with at least some other fb drivers. > > You might also want to save yourself some work and try out an > alternative solution called fbsplash [1], which I designed after I got > tired of fixing bootsplash and which I actively maintain. Fbsplash > provides virtually the same functionality, and it has as much code as > possible moved into userspace (no more JPEG decoders in the kernel). > > [1] http://dev.gentoo.org/~spock/projects/gensplash/current/ Pavel, I agree with Michal, take a look at this version of the code instead of the version that you posted. It's a _whole_ lot more sane, and possibly even mergable. Michal, any thoughts on submitting it for inclusion? It seems pretty stable now. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
On Sat, Feb 19, 2005 at 11:36:05AM -0800, David Brownell wrote: > > Those allocations could be from _using_ a dma pool ... but they're > not from just creating one! > > The cost of creating the dma_pool is the cost of one small kmalloc() > plus (the expensive part) the /sys/devices/.../pools sysfs attribute > is created along with the first pool. (Use that instead of slabinfo > for those pool allocations.) That's why the normal spot to create and > destroy dma pools is in driver probe() and remove() methods. OK, then I misread drivers/base/pool.c and my objection to the patch is unfounded. > If you want to allocate gobs of other stuff at the same time, that's > your choice ... but it'd be a separate issue. Cost to create a > dma_pool is significantly less than PAGE_SIZE, and there's no good > reason to allocate or destroy those pools anywhere near an IRQ context. I agree. raw1394 does far too much with irqs disabled, and moving this stuff to probe() will fix part of that problem. Jody > > - Dave > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
On Sat, Feb 19, 2005 at 12:56:25AM -0500, Jim Crilly wrote: > Helge Hafting wrote: > > > > > >Well, this will depend on your email server (pop? imap? other?) > >being up. Is it local on your machine, or external? Either way, > >being able to launch an email client (or some "new mail" notification > >app) shouldn't be a problem. It will simply not notice new mail until > >the mail service comes up - but it won't fail. It'll be as if the > >mail arrived a little later. > > Sure it can fail, when you start it up it'll most likely fail to login to > the mail server, whether it's local or not, if certain services aren't > already started. If you're using local direct access via maildir or mbox, > that'll work fine but most people access remote server for their mail. > No problem with the remote server, it does not depend on the local boot process. The mail program connects directly to the remote server, all you need is the network and it comes up so fast, it will come up way before X in a parallel boot. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab corruption on 2.6.10-rc4-bk7
Dave Jones <[EMAIL PROTECTED]> wrote:
>
> (This has actually been there for a while, but I only
> noticed it in dmesg this morning).
> During boot on a dual em64t I see ..
>
> scsi2 : ata_piix
> isa bounce pool size: 16 pages
> slab error in cache_free_debugcheck(): cache `size-2048': double free, or
> memory outside object was overwritten
>
> Call Trace:{cache_free_debugcheck+392}
> {kfree+234}
>{:libata:ata_pci_init_one+937}
> {pci_bus_read_config_word+122}
>{:ata_piix:piix_init_one+498}
> {pci_device_probe+134}
>{driver_probe_device+77}
> {driver_attach+75}
>{bus_add_driver+169}
> {pci_register_driver+131}
>{:ata_piix:piix_init+16}
> {sys_init_module+344}
>{system_call+126}
> 81011e49f4a0: redzone 1: 0x5a2cf071, redzone 2: 0x5a2cf071.
>
It's plain to see how ata_pci_init_one() will free `probe_ent' twice. Jeff
wanna fix that up please? A naive fix would be
--- 25/drivers/scsi/libata-core.c~a 2005-02-19 14:41:08.0 -0800
+++ 25-akpm/drivers/scsi/libata-core.c 2005-02-19 14:41:24.0 -0800
@@ -3743,8 +3743,6 @@ int ata_pci_init_one (struct pci_dev *pd
if (legacy_mode) {
if (legacy_mode & (1 << 0))
ata_device_add(probe_ent);
- else
- kfree(probe_ent);
if (legacy_mode & (1 << 1))
ata_device_add(probe_ent2);
else
_
>
>
> SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
> Slab corruption: start=81011e49f4a8, len=2048
> Redzone: 0x170fc2a5/0x170fc2a5.
> Last user: [](load_module+0x180c/0x1a00)
> 000: 38 e0 35 80 ff ff ff ff b8 f9 49 1e 01 81 ff ff
> 010: e0 f4 49 1e 01 81 ff ff 80 e7 08 88 ff ff ff ff
> 020: 24 01 00 00 5a 5a 5a 5a 10 0b 15 80 ff ff ff ff
> 030: 00 00 00 00 00 00 00 00 2e 74 65 78 74 00 5a 5a
> 040: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
> 050: 5a 5a 5a 5a 5a 5a 5a 5a 00 e0 07 88 ff ff ff ff
> Prev obj: start=81011e49ec90, len=2048
> Redzone: 0x170fc2a5/0x170fc2a5.
> Last user: [](ata_probe_ent_alloc+0x29/0xc0 [libata])
> 000: 90 ec 49 1e 01 81 ff ff 90 ec 49 1e 01 81 ff ff
> 010: 80 8e 26 08 00 81 ff ff 60 24 07 88 ff ff ff ff
> slab error in cache_alloc_debugcheck_after(): cache `size-2048': double free,
> or memory outside object was overwritten
>
> Call Trace:{alloc_skb+81}
> {cache_alloc_debugcheck_after+186}
>{__kmalloc+216} {alloc_skb+81}
>{send_uevent+84}
> {kobject_hotplug+592}
>{kobject_add+349}
> {class_device_add+135}
>{class_simple_device_add+317}
> {__wake_up+67}
>{init_dev+1197} {vcs_make_devfs+43}
>{con_open+158} {tty_open+574}
>{selinux_file_alloc_security+42}
>{chrdev_open+393}
> {selinux_file_alloc_security+42}
>{dentry_open+246} {filp_open+62}
>{get_unused_fd+219} {sys_open+76}
>{system_call+126}
> 81011e49f4a0: redzone 1: 0x170fc2a5, redzone 2: 0x170fc2a5.
> SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
>
Last user: ata_probe_ent_alloc(). Hopefully that's the same bug.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove unnecessary addition operations from usb/core/hub.c
On Sat, Feb 19, 2005 at 07:03:27PM +, Telemaque Ndizihiwe wrote: > This Patch removes unnecessary addition operations from > usb/core/hub.c in kernel 2.6.10. > > usb_disable_endpoint(udev, 0 + USB_DIR_IN); //replaced by > usb_disable_endpoint(udev, USB_DIR_IN); > > usb_disable_endpoint(udev, 0 + USB_DIR_OUT); //replaced by > usb_disable_endpoint(udev, USB_DIR_OUT); > > > Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]> No, I'll say to leave these "0 +" in the code. It doesn't hurt anything (the compiler takes care of it in preprocessing) and it instantly tells you exactly what the code is really doing (disabling endpoint 0). Without the 0 in there, you would have to take a bit to think about which endpoint is actually being disabled. So, sorry, I'm not going to apply this. Oh, and next time, please CC: the linux usb maintainer, and the linux-usb-devel mailing list when you post USB patches. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c.h: Fix another gcc 4.0 compile failure
On Sat, Feb 19, 2005 at 08:58:48AM -0800, Mickey Stein wrote:
> From: Mickey Stein
> Versions: linux-2.6.11-rc4-bk7, gcc4 (GCC) 4.0.0 20050217 (latest fc
> rawhide from 19Feb DL)
>
> gcc4 cvs seems to dislike "include/linux/i2c.h file":
>
> Error msg: include/linux/i2c.h:{55,194} error: array type has
> incomplete element type
>
> A. Daplas has recently done a workaround for this on another header
> file. A thread discussing this
> can be found by following the link below:
>
> http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
>
> The patch changes the array declaration from "struct x y[]" format to
> "struct x *y".
> I realize its only a workaround, but the gcc guys seem to be aware of
> this.
> ** Note: I'm a noob at this, so feel free to make chopped liver out of
> this if its incorrect.
> patch below is also attached since I'm not sure formatting survives
> the cut
The patch looks sane, but before I apply it, care to also fix up all of
the function pointers that are affected by this patch? Also the
i2c_transfer() function itself should be changed (not just the header
file.)
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.10: irq 12 nobody cared!
On Feb 17 2005, Linus Torvalds wrote: > Does the box still work? It may well be that once all drivers have had a > chance to initialize their hardware properly, the problem is just gone, > and that the interim reports about not being able to handle the irq are > just temporary noise. I started seeing a similar message (irq 10: nobody cared!) right after I've bought a (IDE) DVD recorder and decided to rearrange my drives so that each one would not interfere with the others. An excerpt of the messages that I get with kernel 2.6.10-rc4 is the following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Linux version 2.6.11-rc4-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8)) #1 Sun Feb 13 15:23:03 BRST 2005 (...) ACPI: RSDP (v000 ASUS ) @ 0x000f6a90 ACPI: RSDT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec000 ACPI: FADT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec080 ACPI: BOOT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec040 ACPI: DSDT (v001 ASUS A7V 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 (...) ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] (...) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot :00:04.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci:00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: HL-DT-ST DVDRAM GSA-4160B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 PDC20265: IDE controller at PCI slot :00:11.0 PCI: :00:11.0 has unsupported PM cap regs version (1) ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0x93/0xbd [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] probe_hwif+0x2da/0x366 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x88 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0x93/0xbd [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] ide_config_drive_speed+0x168/0x30d [] pdc202xx_tune_chipset+0x38c/0x396 [] probe_hwif+0x324/0x366 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x88 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0x93/0xbd [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] ide_config_drive_speed+0x168/0x30d [] pdc202xx_tune_chipset+0x38c/0x396 [] config_chipset_for_dma+0x216/0x227 []
slab corruption on 2.6.10-rc4-bk7
(This has actually been there for a while, but I only
noticed it in dmesg this morning).
During boot on a dual em64t I see ..
scsi2 : ata_piix
isa bounce pool size: 16 pages
slab error in cache_free_debugcheck(): cache `size-2048': double free, or
memory outside object was overwritten
Call Trace:{cache_free_debugcheck+392}
{kfree+234}
{:libata:ata_pci_init_one+937}
{pci_bus_read_config_word+122}
{:ata_piix:piix_init_one+498}
{pci_device_probe+134}
{driver_probe_device+77}
{driver_attach+75}
{bus_add_driver+169}
{pci_register_driver+131}
{:ata_piix:piix_init+16}
{sys_init_module+344}
{system_call+126}
81011e49f4a0: redzone 1: 0x5a2cf071, redzone 2: 0x5a2cf071.
and..
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
Slab corruption: start=81011e49f4a8, len=2048
Redzone: 0x170fc2a5/0x170fc2a5.
Last user: [](load_module+0x180c/0x1a00)
000: 38 e0 35 80 ff ff ff ff b8 f9 49 1e 01 81 ff ff
010: e0 f4 49 1e 01 81 ff ff 80 e7 08 88 ff ff ff ff
020: 24 01 00 00 5a 5a 5a 5a 10 0b 15 80 ff ff ff ff
030: 00 00 00 00 00 00 00 00 2e 74 65 78 74 00 5a 5a
040: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
050: 5a 5a 5a 5a 5a 5a 5a 5a 00 e0 07 88 ff ff ff ff
Prev obj: start=81011e49ec90, len=2048
Redzone: 0x170fc2a5/0x170fc2a5.
Last user: [](ata_probe_ent_alloc+0x29/0xc0 [libata])
000: 90 ec 49 1e 01 81 ff ff 90 ec 49 1e 01 81 ff ff
010: 80 8e 26 08 00 81 ff ff 60 24 07 88 ff ff ff ff
slab error in cache_alloc_debugcheck_after(): cache `size-2048': double free,
or memory outside object was overwritten
Call Trace:{alloc_skb+81}
{cache_alloc_debugcheck_after+186}
{__kmalloc+216} {alloc_skb+81}
{send_uevent+84}
{kobject_hotplug+592}
{kobject_add+349}
{class_device_add+135}
{class_simple_device_add+317}
{__wake_up+67}
{init_dev+1197} {vcs_make_devfs+43}
{con_open+158} {tty_open+574}
{selinux_file_alloc_security+42}
{chrdev_open+393}
{selinux_file_alloc_security+42}
{dentry_open+246} {filp_open+62}
{get_unused_fd+219} {sys_open+76}
{system_call+126}
81011e49f4a0: redzone 1: 0x170fc2a5, redzone 2: 0x170fc2a5.
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
This box got new hardware just before xmas, and a >24hr run of memtest86
so I can probably rule out bad memory.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Yenta TI: ... no PCI interrupts. Fish. Please report.
Hi everyone, I've been banging my head on this one a couple of days with no luck. I have a IBM Thinkpad G41 with a pentium4M with Hyperthreading. I can't get the PCMCIA working at all. I've tried turning off hyperthreading, I've tried with and without preempt, I've even added pci=noacpi. I've added Len's ACPI patches, but nothing works. Here's lspci -vvv: :00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Subsystem: IBM: Unknown device 0579 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: IBM: Unknown device 057a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- [ ... USB controllers snipped out ... ] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 :02:01.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) Subsystem: IBM ThinkPad T30/T40 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 The above is probably more than anyone needs, but if I should show the whole listing (USB, Audio and all), just let me know and I can post all of it too. And here's the dmesg: Linux Kernel Card Services options: [pci] [cardbus] [pm] ACPI: PCI interrupt :02:01.0[A] -> GSI 20 (level, low) -> IRQ 177 Yenta: CardBus bridge found at :02:01.0 [1014:0512] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:01.0, mfunc 0x01001c22, devctl 0x64 Yenta TI: socket :02:01.0 probing PCI interrupt failed, trying to fix Yenta TI: socket :02:01.0 no PCI interrupts. Fish. Please report. Yenta: ISA IRQ mask 0x, PCI irq 0 Socket status: ACPI: PCI interrupt :02:01.1[B] -> GSI 21 (level, low) -> IRQ 185 Yenta: CardBus bridge found at :02:01.1 [1014:0512] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:01.1, mfunc 0x01001c22, devctl 0x64 Yenta TI: socket :02:01.1 probing PCI interrupt failed, trying to fix Yenta TI: socket :02:01.1 no PCI interrupts. Fish. Please report. Yenta: ISA IRQ mask 0x, PCI irq 0 Socket status: 4410080c (the above is from kernel.org 2.6.10 with Len's ACPI patches). I've tried this with Debian stock kernels: 2.4.27-1-386, 2.6.8-2-686, 2.6.9-1-686, 2.6.10-1-686-smp I've also tried kernel.org kernels with 2.6.9, 2.6.10 and 2.6.11-rc3-mm2. As I've mentioned, I've added Len's ACPI patches to 2.6.10 and still nothing works. I've tried disable_clkrun but still nothing. I've found a couple of other patches on the net and nothing works. I've tried debugging this but PCMCIA is not my strong spot, so all I can tell you is that the interrupt never comes in when Yenta probes it. Does anyone else out there have a IBM Thinkpad G41 and have this working? Or, do you have it and it is not working. I get no power to the PCMCIA card slots, so they are basically useless now. Any ideas would be appreciated. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated list of unused kernel exports posted
On Sat, Feb 19, 2005 at 10:14:33PM +0100, Arjan van de Ven wrote: >... > The following symbols are added to this list since the last posted list; > some of these will be of the "emerging functionality" type, others will > be now-redundant and should be investigated for removal; after all each > exported symbol uses easily over a hundred bytes of unswappable kernel > memory for every linux user out there. > > +++ unused.new 2005-02-19 21:27:59.556557390 +0100 > +alloc_chrdev_region Used on s390: drivers/s390/char/vmlogrdr.c drivers/s390/char/tape_char.c >... > +backlight_device_register > +backlight_device_unregister Used on the Sharp Zaurus: drivers/video/backlight/corgi_bl.c >... > +cpufreq_get Used on ARM: drivers/pcmcia/sa11xx_base.c But ist seems to be wrong that it gets exported twice on ARM. >... > +nr_free_pages In -mm, it's used by reiser4. > +nr_pagecache Used on s390: arch/s390/appldata/appldata_mem.c >... > +pccard_static_ops Used on ARM and m32r: drivers/pcmcia/m32r_pcc.c drivers/pcmcia/soc_common.c drivers/pcmcia/m32r_cfc.c drivers/pcmcia/hd64465_ss.c >... > +platform_get_irq_byname Used on ppc: drivers/net/gianfar.c > +platform_get_resource_byname Used on ARM, m32r and ppc: drivers/net/smc91x.c >... > +totalram_pages In -mm, it's used by reiser4. >... > +try_acquire_console_sem It's used in -mm: drivers/video/aty/radeon_pm.c >... > +wait_for_completion_interruptible >... > +wait_for_completion_timeout Both are used in -mm: drivers/i2c/i2c-core.c 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updated list of unused kernel exports posted
On Sat, 2005-02-19 at 22:14 +0100, Arjan van de Ven wrote: > Hi, > > an updated list of currently unused-on-i386 kernel exports is now posted Russell asked me to clarify this: symbols on this list may well be used on other architectures than i386; before sending patches to remove them please use grep to make sure it's really globally unused... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
updated list of unused kernel exports posted
Hi, an updated list of currently unused-on-i386 kernel exports is now posted at http://www.kernel.org/pub/linux/kernel/people/arjan/unused based on 2.6.11-rc4-bk7. Note 1) the URL of the location has changed; the previous URL led to several vendors of binary modules to contact my employer in the hope to pressure to get certain symbols off that list. This list has nothing to do with my employer and as such I decided to move it to a more neutral URL to not cause that incorrect burden. Note 2) this list contains all unused symbols regardless of merit; it contains pure bloating symbols but also symbols for emerging new functionality not fully merged and generic library helpers. The following symbols are added to this list since the last posted list; some of these will be of the "emerging functionality" type, others will be now-redundant and should be investigated for removal; after all each exported symbol uses easily over a hundred bytes of unswappable kernel memory for every linux user out there. +++ unused.new 2005-02-19 21:27:59.556557390 +0100 +alloc_chrdev_region +attribute_container_add_attrs +attribute_container_add_class_device +attribute_container_add_class_device_adapter +attribute_container_class_device_del +attribute_container_classdev_to_container +attribute_container_device_trigger +attribute_container_remove_attrs +attribute_container_remove_device +attribute_container_trigger +backlight_device_register +backlight_device_unregister +class_device_create_bin_file +class_device_remove_bin_file +cpufreq_get +cpufreq_parse_governor +debugfs_create_bool +debugfs_create_u16 +debugfs_create_u32 +debugfs_create_u8 +device_for_each_child +fb_create_modedb +fb_get_monitor_limits +get_sb_pseudo +hugetlb_total_pages +ib_find_cached_gid +kernel_subsys +lcd_device_register +lcd_device_unregister +mt352_read +nr_free_pages +nr_pagecache +nr_swap_pages +pccard_static_ops +phys_proc_id +platform_get_irq_byname +platform_get_resource_byname +__scsi_print_sense +scsi_sense_desc_find +slab_reclaim_pages +sysctl_overcommit_memory +sysctl_overcommit_ratio +totalram_pages +total_swap_pages +try_acquire_console_sem +tveeprom_dump +usb_bus_init +vm_acct_memory +vm_committed_space +w1_search_devices +wait_for_completion_interruptible +wait_for_completion_interruptible_timeout +wait_for_completion_timeout - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
On Saturday 19 February 2005 12:50 pm, Parag Warudkar wrote: > On Saturday 19 February 2005 02:36 pm, David Brownell wrote: > > The cost of creating the dma_pool is the cost of one small kmalloc() > > plus (the expensive part) the /sys/devices/.../pools sysfs attribute > > is created along with the first pool. (Use that instead of slabinfo > > for those pool allocations.) That's why the normal spot to create and > > destroy dma pools is in driver probe() and remove() methods. > > What's the format of /sys/devices/.../pools (Name of pool, ? ? ? ?) ? Can > the > memory consumption be derived from it? See what drivers/base/dmapool.c tells you; yes that consumption can be derived from the pool statistics. > Here is what the ohci pools look during data read (Kino->Capture) and after > closing Kino - > > During Kino Capture > [EMAIL PROTECTED] pci:00]# cat ./:00:0a.0/:02:00.0/pools > poolinfo - 0.1 > ohci1394 rcv prg 16 256 16 1 --> This one is in question > ohci1394 trm prg 32 64 64 1 > ohci1394 trm prg 32 64 64 1 > ohci1394 rcv prg4 256 16 1 > ohci1394 rcv prg4 256 16 1 I suggest you get rid of the spaces in those names, to make it easier to use things like "awk" to massage those numbers. The "ohci1394" is implied by the fact that no other driver could be bound to that device, for example. In this case, other than the fact that you've created multiple pools with the same names (!), that line translates to 16 blocks in use out of 256 available, 16 bytes per block, just one page. I suspect that on some systems it should be bumping up the minimum block size to match the CPU cacheline size. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cfq: depth 4 reached, tagging now on
Starting around 2.6.11-rc4 I get this printk during the boot process after kjournald starts, and again if I stress the filesystem. cfq: depth 4 reached, tagging now on Is this printk intentional? I am sure users will wonder about it, especially because (presumably) cfq turns tagging off at some point in between, and doesn't say anything about it. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Hi! > > I believe power and suspend keys should definitely go through > > input. I'm not that sure about battery... Lid is somewhere in > > between... > > > > I think we need a generic way of delivering system status changes to > userspace. Something like acpid but bigger than that, something not Yes, we need something like that. But IMNSHO, it should not handle power button. We already have perfectly good way of handling power button through input. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Hi! > > > The question is how to unify it. > > > > > > Using power.c to simply pass power/sleep keys to the ACPI event pipe > > > could get the input subsystem out of the loop at least. Maybe we could > > > even pass sound keys to it. > > > > I do not think passing sound keys through acpi is good idea. acpid > > does not know how to handle them, and X already know how to get them > > from input subsystem. > > What X? I am not saying that sound events should go through acpid, but > why bringing X here? One may not even run X... True, but X is big "existing user", thats why I mentioned it. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Dynamically allocated pageflags.
Hi! > In Suspend2, I need the functional equivalent of pageflags, but don't > need them when Suspend isn't running. One of the outcomes of the last > submission of Suspend2 for review was that I changed the format in which > that data is stored, creating something I call dynamically allocated > pageflags. > > It's a simple idea: we tie together a bunch of order zero allocated > pages using a kmalloc'd list of poiinters to those pages, and store the Will not using linklist for this make some algorithms O(n^2), hidden in the macros so that user does not realize it? -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
On Saturday 19 February 2005 02:36 pm, David Brownell wrote: > The cost of creating the dma_pool is the cost of one small kmalloc() > plus (the expensive part) the /sys/devices/.../pools sysfs attribute > is created along with the first pool. (Use that instead of slabinfo > for those pool allocations.) That's why the normal spot to create and > destroy dma pools is in driver probe() and remove() methods. What's the format of /sys/devices/.../pools (Name of pool, ? ? ? ?) ? Can the memory consumption be derived from it? Here is what the ohci pools look during data read (Kino->Capture) and after closing Kino - During Kino Capture [EMAIL PROTECTED] pci:00]# cat ./:00:0a.0/:02:00.0/pools poolinfo - 0.1 ohci1394 rcv prg 16 256 16 1 --> This one is in question ohci1394 trm prg 32 64 64 1 ohci1394 trm prg 32 64 64 1 ohci1394 rcv prg4 256 16 1 ohci1394 rcv prg4 256 16 1 After Closing Kino [EMAIL PROTECTED] pci:00]# cat ./:00:0a.0/:02:00.0/pools poolinfo - 0.1 ohci1394 trm prg 32 64 64 1 ohci1394 trm prg 32 64 64 1 ohci1394 rcv prg4 256 16 1 ohci1394 rcv prg4 256 16 1 Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel8x0: no sound in 2.6.11 rc3 & 4 (fine with 2.6.10)
Please cc: alsa-devel when reporting ALSA issues. Lee On Sat, 2005-02-19 at 13:11 +0100, [EMAIL PROTECTED] wrote: > Hello > > I have read a post in lkml.org that states that the problem experienced in > rc3 has gone (1). That is not the case for me. > > My audio device is > > :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) > Subsystem: IBM: Unknown device 0554 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin B routed to IRQ 11 > Region 0: I/O ports at 1c00 [size=256] > Region 1: I/O ports at 18c0 [size=64] > Region 2: Memory at d0100c00 (32-bit, non-prefetchable) [size=512] > Region 3: Memory at d0100800 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > In 2.6.10 and in 2.6.11-rc3 & 4 the clock is set to 48khz. > > eg: > > intel8x0_measure_ac97_clock: measured 49502 usecs > intel8x0: clocking to 48000 > > It uses an Analog Devices AD1981B > > I have put a tar file of the /proc/asound directory of 2.6.10 and 2.6.11-rc4 > in > > http://pusa.uv.es/~ulisses/asound-intel8x0/ > > the tar files were done while playing pcm audio, (not being eard in rc4). > > I have found that I had to Mute __both__ "Headphone Jack Sense" and > "Line Jack Sense" in order to ear the audio in rc4. > > Please let me know if you need further info or you want a tester > > All this is on a IBM Thinkpad R51 - Type 2887 -AVG > > (tot toc: IBM, we're buying your laptops too) > > Thanks in advance > > Ulisses > > (1) http://lkml.org/lkml/2005/2/18/93 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-kernel, Get a new home
Homeowners - do you have less-than-perfect credit* We'll quickly match you up with the B.EST provider based on YOUR NEEDS. Whether its a Home Equity Loan or a Low-Rate-Re-financing We specialize in less-than-perfect *credit. We'll help you get the YES! you deserve. http://www.nocturnull.com/save.asp Future reference options: http://www.nocturnull.com/gone.asp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Investment Capital
Re: Investment Capital. Your contact has been gotten from after a search for a person whom we can jointly invest Trust in and also solicit a Honourable partnership with. I represent a client and my client has interest to do business relative to investments in your country in areas related to agriculture or any business of your choice, to initiate a proper and structured relationship: Please let me know what your response will be to an offer to receive the investment funds : 1. The said fund amounts to Ten Million Pounds sterling. 2.The said fund will be transferred to you in same state. 3.The fund is intended to be invested through your agency in the purchase of facilities and assets, for the said purposes within your country. 4. This transaction will result in you being paid a commission of 10% off the investment capital and another 10% of after annual tax income. 5.The fund owners desire absolute confidentiality and professionalism in the handling of this matter as the people involved are top government officials. Please respond urgently and if you do not intend to help, i will respect your privacy and stop contacting you. Sincerely. Solicitor. Frank West NB: Please reply to: [EMAIL PROTECTED] __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hotplug blacklist and video devices
Jon Smirl wrote: I didn't say make framebuffer depend on DRM, you can still unload DRM before suspend. It's the other way around DRM needs framebuffer. Only if you want to see the output, surely? I have an application which doesn't need a framebuffer (or more strictly, scan-out), but does use DRM. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
> > Jody - Is the 200K waste for sure or do you want me to verify it by some > > means? ( Reason I am asking is firstly, Dave Brownell was quite sure it > > wasn't that costly and secondly, I am hoping it isn't.. ;) > > I'm not sure, but I looked through the code and it seems to allocate: > - 16 buffers of 2x PAGE_SIZE (= 131072 on i386) > - 16 buffers of PAGE_SIZE (= 65536 on i386) > - various other smaller structures. > > I'm not sure how to actually _measure_ how much memory this is using. > slabinfo isn't useful, at least on my system, because the 1394 > allocations get lost in the noise of other activity. Those allocations could be from _using_ a dma pool ... but they're not from just creating one! The cost of creating the dma_pool is the cost of one small kmalloc() plus (the expensive part) the /sys/devices/.../pools sysfs attribute is created along with the first pool. (Use that instead of slabinfo for those pool allocations.) That's why the normal spot to create and destroy dma pools is in driver probe() and remove() methods. If you want to allocate gobs of other stuff at the same time, that's your choice ... but it'd be a separate issue. Cost to create a dma_pool is significantly less than PAGE_SIZE, and there's no good reason to allocate or destroy those pools anywhere near an IRQ context. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cciss CSMI via sysfs for 2.6
On Wed, Feb 16, 2005 at 10:45:12AM -0600, [EMAIL PROTECTED] wrote:
> +static ssize_t cciss_phyinfo_show(struct device *dev, char *buf)
> +{
> + ctlr_info_t *h = dev->driver_data;
> + unsigned long flags;
> + CommandList_struct *c;
> + CSMI_SAS_PHY_INFO_BUFFER iocommand;
> + CSMI_SAS_IDENTIFY p;
> + u64bit temp64;
> + DECLARE_COMPLETION(wait);
> +
> + printk(KERN_WARNING "cciss: into cciss_phyinfo_show\n");
> + memset(, 0, sizeof(CSMI_SAS_PHY_INFO_BUFFER));
> + memset(, 0, sizeof(CSMI_SAS_IDENTIFY));
> +
> + /* allocate and fill in the command */
> + if ((c = cmd_alloc(h, 0)) == NULL)
> + return -ENOMEM;
> +
> + iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
> + c->cmd_type = CMD_IOCTL_PEND;
> + c->Header.ReplyQueue = 0;
> +
> + //Do we send the whole buffer?
> + if (iocommand.IoctlHeader.Length > 0){
This test will always be true, no?
> + c->Header.SGList = 1;
> + c->Header.SGTotal = 1;
> + } else {
> + c->Header.SGList = 0;
> + c->Header.SGTotal = 0;
> + }
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove unnecessary addition operations from usb/core/hub.c
This Patch removes unnecessary addition operations from
usb/core/hub.c in kernel 2.6.10.
usb_disable_endpoint(udev, 0 + USB_DIR_IN); //replaced by
usb_disable_endpoint(udev, USB_DIR_IN);
usb_disable_endpoint(udev, 0 + USB_DIR_OUT); //replaced by
usb_disable_endpoint(udev, USB_DIR_OUT);
Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]>
--- linux-2.6.10/drivers/usb/core/hub.c.orig2005-02-19
12:26:28.682067480 +
+++ linux-2.6.10/drivers/usb/core/hub.c 2005-02-19 12:38:55.059600848
+
@@ -2044,8 +2044,8 @@ static int hub_set_address(struct usb_de
int m = udev->epmaxpacketin[0];
usb_set_device_state(udev, USB_STATE_ADDRESS);
- usb_disable_endpoint(udev, 0 + USB_DIR_IN);
- usb_disable_endpoint(udev, 0 + USB_DIR_OUT);
+ usb_disable_endpoint(udev, USB_DIR_IN);
+ usb_disable_endpoint(udev, USB_DIR_OUT);
udev->epmaxpacketin[0] = udev->epmaxpacketout[0] = m;
}
return retval;
@@ -2244,8 +2244,8 @@ hub_port_init (struct usb_device *hdev,
i = udev->descriptor.bMaxPacketSize0;
if (udev->epmaxpacketin[0] != i) {
dev_dbg(>dev, "ep0 maxpacket = %d\n", i);
- usb_disable_endpoint(udev, 0 + USB_DIR_IN);
- usb_disable_endpoint(udev, 0 + USB_DIR_OUT);
+ usb_disable_endpoint(udev, USB_DIR_IN);
+ usb_disable_endpoint(udev, USB_DIR_OUT);
udev->epmaxpacketin[0] = udev->epmaxpacketout[0] = i;
}
@@ -2508,8 +2508,8 @@ static void hub_port_connect_change(stru
loop:
hub_port_disable(hdev, port);
- usb_disable_endpoint(udev, 0 + USB_DIR_IN);
- usb_disable_endpoint(udev, 0 + USB_DIR_OUT);
+ usb_disable_endpoint(udev, USB_DIR_IN);
+ usb_disable_endpoint(udev, USB_DIR_OUT);
release_address(udev);
usb_put_dev(udev);
if (status == -ENOTCONN)
@@ -2893,8 +2893,8 @@ int usb_reset_device(struct usb_device *
/* ep0 maxpacket size may change; let the HCD know about it.
* Other endpoints will be handled by re-enumeration. */
- usb_disable_endpoint(udev, 0 + USB_DIR_IN);
- usb_disable_endpoint(udev, 0 + USB_DIR_OUT);
+ usb_disable_endpoint(udev, USB_DIR_IN);
+ usb_disable_endpoint(udev, USB_DIR_OUT);
ret = hub_port_init(parent, udev, port, i);
if (ret >= 0)
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IDE patch to fix Promise 202xx_new
I was having lots of DMA problems with a Promise 20269 PCI IDE controller under 2.6.11-rc4, which made it pretty useless. I found the following patch from almost two years ago, which when applied resolved the problems: http://www.cs.helsinki.fi/linux/linux-kernel/2003-19/1192.html Is there a reason I'm unaware of why this never made it into the main kernel tree? I've not noticed any ill-effects of applying the patch to 2.6.11-rc4. Thanks, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pdirops: tmpfs patch
Index: linux-2.6.10/mm/shmem.c
===
--- linux-2.6.10.orig/mm/shmem.c2005-01-28 19:32:16.0 +0300
+++ linux-2.6.10/mm/shmem.c 2005-02-19 20:05:32.642599576 +0300
@@ -1849,7 +1849,7 @@
#endif
};
-static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t
*gid, unsigned long *blocks, unsigned long *inodes)
+static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t
*gid, unsigned long *blocks, unsigned long *inodes, struct super_block *sb)
{
char *this_char, *value, *rest;
@@ -1858,6 +1858,9 @@
continue;
if ((value = strchr(this_char,'=')) != NULL) {
*value++ = 0;
+ } else if (!strcmp(this_char,"pdirops")) {
+ sb->s_flags |= S_PDIROPS;
+ continue;
} else {
printk(KERN_ERR
"tmpfs: No value for mount option '%s'\n",
@@ -1928,7 +1931,7 @@
max_blocks = sbinfo->max_blocks;
max_inodes = sbinfo->max_inodes;
}
- if (shmem_parse_options(data, NULL, NULL, NULL, _blocks,
_inodes))
+ if (shmem_parse_options(data, NULL, NULL, NULL, _blocks,
_inodes, sb))
return -EINVAL;
/* Keep it simple: disallow limited <-> unlimited remount */
if ((max_blocks || max_inodes) == !sbinfo)
@@ -1978,7 +1981,7 @@
inodes = blocks;
if (shmem_parse_options(data, ,
- , , , ))
+ , , , , sb))
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pdirops: vfs patch
fs/inode.c |1
fs/namei.c | 66 ++---
include/linux/fs.h | 11
3 files changed, 54 insertions(+), 24 deletions(-)
Index: linux-2.6.10/fs/namei.c
===
--- linux-2.6.10.orig/fs/namei.c2005-01-28 19:32:13.0 +0300
+++ linux-2.6.10/fs/namei.c 2005-02-19 20:40:05.763437304 +0300
@@ -104,6 +104,28 @@
* any extra contention...
*/
+static inline struct semaphore * lock_sem(struct inode *dir, struct qstr *name)
+{
+ if (IS_PDIROPS(dir)) {
+ struct super_block *sb;
+ /* name->hash expected to be already calculated */
+ sb = dir->i_sb;
+ BUG_ON(sb->s_pdirops_sems == NULL);
+ return sb->s_pdirops_sems + name->hash % sb->s_pdirops_size;
+ }
+ return >i_sem;
+}
+
+static inline void lock_dir(struct inode *dir, struct qstr *name)
+{
+ down(lock_sem(dir, name));
+}
+
+static inline void unlock_dir(struct inode *dir, struct qstr *name)
+{
+ up(lock_sem(dir, name));
+}
+
/* In order to reduce some races, while at the same time doing additional
* checking and hopefully speeding things up, we copy filenames to the
* kernel data space before using them..
@@ -380,7 +402,7 @@
struct dentry * result;
struct inode *dir = parent->d_inode;
- down(>i_sem);
+ lock_dir(dir, name);
/*
* First re-do the cached lookup just in case it was created
* while we waited for the directory semaphore..
@@ -406,7 +428,7 @@
else
result = dentry;
}
- up(>i_sem);
+ unlock_dir(dir, name);
return result;
}
@@ -414,7 +436,7 @@
* Uhhuh! Nasty case: the cache was re-populated while
* we waited on the semaphore. Need to revalidate.
*/
- up(>i_sem);
+ unlock_dir(dir, name);
if (result->d_op && result->d_op->d_revalidate) {
if (!result->d_op->d_revalidate(result, nd) &&
!d_invalidate(result)) {
dput(result);
@@ -1182,12 +1204,26 @@
/*
* p1 and p2 should be directories on the same fs.
*/
-struct dentry *lock_rename(struct dentry *p1, struct dentry *p2)
+struct dentry *lock_rename(struct dentry *p1, struct qstr *n1,
+ struct dentry *p2, struct qstr *n2)
{
struct dentry *p;
if (p1 == p2) {
- down(>d_inode->i_sem);
+ if (IS_PDIROPS(p1->d_inode)) {
+ unsigned int h1, h2;
+ h1 = n1->hash % p1->d_inode->i_sb->s_pdirops_size;
+ h2 = n2->hash % p2->d_inode->i_sb->s_pdirops_size;
+ if (h1 < h2) {
+ lock_dir(p1->d_inode, n1);
+ lock_dir(p2->d_inode, n2);
+ } else if (h1 > h2) {
+ lock_dir(p2->d_inode, n2);
+ lock_dir(p1->d_inode, n1);
+ } else
+ lock_dir(p1->d_inode, n1);
+ } else
+ down(>d_inode->i_sem);
return NULL;
}
@@ -1195,31 +1231,35 @@
for (p = p1; p->d_parent != p; p = p->d_parent) {
if (p->d_parent == p2) {
- down(>d_inode->i_sem);
- down(>d_inode->i_sem);
+ lock_dir(p2->d_inode, n2);
+ lock_dir(p1->d_inode, n1);
return p;
}
}
for (p = p2; p->d_parent != p; p = p->d_parent) {
if (p->d_parent == p1) {
- down(>d_inode->i_sem);
- down(>d_inode->i_sem);
+ lock_dir(p1->d_inode, n1);
+ lock_dir(p2->d_inode, n2);
return p;
}
}
- down(>d_inode->i_sem);
- down(>d_inode->i_sem);
+ lock_dir(p1->d_inode, n1);
+ lock_dir(p2->d_inode, n2);
return NULL;
}
-void unlock_rename(struct dentry *p1, struct dentry *p2)
+void unlock_rename(struct dentry *p1, struct qstr *n1,
+ struct dentry *p2, struct qstr *n2)
{
- up(>d_inode->i_sem);
+ unlock_dir(p1->d_inode, n1);
if (p1 != p2) {
- up(>d_inode->i_sem);
+ unlock_dir(p2->d_inode, n2);
up(>d_inode->i_sb->s_vfs_rename_sem);
+ } else if (IS_PDIROPS(p1->d_inode) &&
+ n1->hash != n2->hash) {
+ unlock_dir(p2->d_inode, n2);
}
}
@@ -1386,13 +1426,13 @@
dir = nd->dentry;
nd->flags &= ~LOOKUP_PARENT;
- down(>d_inode->i_sem);
+ lock_dir(dir->d_inode, >last);
[RFC] parallel directory operations
Good day Al and all could you review couple patches that implement $subj for vfs and tmpfs. In short the idea is that we can protect operations taking semaphore related for set of names. definitely, protection at vfs layer isn't enough and filesystem will need to protect their own structures by itself, but in some cases vfs patch is enough. for example, tmpfs. during some loads one can see quite high load in /tmp. being mounted as tmpfs on big smp, we can get high contention on i_sem. probably someone could try more-less real load? I wrote simple program that spawn few processes, then chdir to the given directory, then loops creating and unlinking file. The test box is dual PIII-1GHz: run 1: 2 processes create/unlink file on regular tmpfs [EMAIL PROTECTED] root]# mount -t tmpfs none /test [EMAIL PROTECTED] root]# (cd /test; time /root/crunl ./f 100 2) #1998: 100 iterations, create/unlink ./f-0-1998 #1999: 100 iterations, create/unlink ./f-1-1999 #384: done #384: done wait for completion ... OK real0m36.224s user0m0.823s sys 0m47.994s run 2: 2 processes create/unlink file on tmpfs + pdirops [EMAIL PROTECTED] root]# mount -t tmpfs -o pdirops none /test [EMAIL PROTECTED] root]# (cd /test; time /root/crunl ./f 100 2) #1992: 100 iterations, create/unlink ./f-0-1992 #1993: 100 iterations, create/unlink ./f-1-1993 #384: done #384: done wait for completion ... OK real0m15.108s user0m0.592s sys 0m29.406s run 3: 1 process creates/unlinks file on regular tmpfs [EMAIL PROTECTED] root]# mount -t tmpfs none /test [EMAIL PROTECTED] root]# (cd /test; time /root/crunl ./f 100 1) #2004: 100 iterations, create/unlink ./f-0-2004 #384: done wait for completion ... OK real0m11.950s user0m0.262s sys 0m7.465s run 4: 1 process creates/unlinks file on tmpf + pdirops [EMAIL PROTECTED] root]# mount -t tmpfs -o pdirops none /test [EMAIL PROTECTED] root]# (cd /test; time /root/crunl ./f 100 1) #2009: 100 iterations, create/unlink ./f-0-2009 #384: done wait for completion ... OK real0m8.047s user0m0.243s sys 0m7.646s 2 processes creating/unlinking on regular tmpfs cause ~200K context switches: procs memory swap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 0 0 1005760 6616 1092800 0 0 1007 215095 1 64 35 2 0 0 0 1005760 6616 1092800 0 0 1007 213580 1 67 32 2 0 0 0 1005760 6616 1092800 0 0 1007 214445 1 63 36 2 0 0 0 1005760 6616 1092800 0 0 1007 216250 1 63 36 2 processes creating/unlinking on tmpfs + pdirops cause ~44 context switches: procs memory swap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 1 0 1001824 6632 1091200 0 0 100841 2 98 0 2 0 2 0 1002144 6632 1091200 0 0 100845 2 98 0 2 0 2 0 1001632 6632 1091200 0 0 100747 2 98 0 the next benchmark is rename. two processes generate random name, create file, generate new name, rename created file in new name and unlink: run 5: regular tmpfs [EMAIL PROTECTED] root]# mount -t tmpfs none /test [EMAIL PROTECTED] root]# (cd /test; time /root/rndrename ./f 100 2) #2036: 100 iterations #2037: 100 iterations wait for completion ... OK real1m22.381s user0m10.254s sys 1m50.214s run 6: tmpfs + pdirops [EMAIL PROTECTED] root]# mount -t tmpfs -o pdirops none /test [EMAIL PROTECTED] root]# (cd /test; time /root/rndrename ./f 100 2) #2044: 100 iterations #2045: 100 iterations wait for completion ... OK real0m39.403s user0m9.411s sys 1m8.626s thanks, Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
Well , In other computer with one fresh Core 3 installation, try set a prodvd.key on xcdroast, Fedora Core 3, doesn't had set hdc=ide-scsi , so I think that the recorder of dvds has worked in mode hdc=ide-cd, and stopped to function and to read any type of cd or dvd. So is it possible that ide-cd had, damage my dvdrecorder ? Well dvdrecorder doesn't had work very well all the time, even in Windows, and stops after one firmware upgrade but I hadn't much luck. Happily it is in the warranty. -- On Thu, 2005-02-17 at 02:27 +, Sergio Monteiro Basto wrote: with hdc=scsi haldeamon doesn't recognize cdwriter. but with hdc=ide-scsi (was the original from kernel 2.4) haldaamon reconize my cdwriter ! So this message of this subject just make me wast my time and lose my patience. ( because I forgot to enable haldaemon before to try understand the message ) Still don't understand if I should or not change to ide-cd on my FC3, if not please remove the message, if yes rewrite it please . thanks for your precious time. On Tue, 2005-02-15 at 20:36 +, Sergio Monteiro Basto wrote: > Well the problem for the common users is the haldeamon doesn't recognize > automatically /dev/scd0 and /etc/fstab don't have any entry about it. > > So with hdc=scsi, how I read cds on hdc ? > > thanks, > > Note: I am using last updates of FC3, after upgrade from FC1. > > > On Tue, 2005-02-15 at 17:02 +, Alan Cox wrote: > > On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote: > > > It means: don't use the ide-scsi driver. Support for it is > > > lagging (not well-maintained) because it's really not needed for > > > burning CDs. Just use the ide-cd driver (module) and > > > specify the CD burner device as /dev/hdX. > > > > This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is > > vastly inferior to ide-scsi. The ide-scsi layer knows about proper error > > reporting, end of media and other things that ide-cd does not. > > > > The -ac ide-cd knows some of the stuff that ide-cd needs to and works > > with various drive/disk combinations the base code doesn't but ide-scsi > > still handles CD's better. > > > > Alan > > -- Sérgio M.B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote: > The linux-2.5 tree right now (I'm re-doing the conversion, and am up to > October of last year, so far) is at 141M, if you don't count the pristine > cache or working directory. That's already compressed, so you don't get > any extra bonuses. Darcs stores with each changeset both the old and new > versions of each hunk, which gives you some redundancy, and probably > accounts for the factor of two greater size than CVS. This gives a bit of > redundancy, which can be helpful in cases of repository corruption. Double size of the compressed backup is about the same as SVM with fsfs (not tested on l-k tree but in something much smaller). Why not to simply checksum instead of having data redundancy? Knowing when something is corrupted is a great feature, but doing raid1 without the user asking for it, is a worthless overhead. The same is true for arch of course, last time I checked they were using the default -U 3 format instead of -U 0. > I presume you're referring to a local checkout? That is already done using > hard links by darcs--only of course the working directory has to actually > be copied over, since there are editors out there that aren't friendly to > hard-linked files. arch allows to hardlink the copy too (optionally) and it's up to you to use the right switch in the editor (Davide had a LD_PRELOAD to do a copy-on-write since the kernel doesn't provide the feature). > And here's where darcs really falls down. To track the history of a single > file it has to read the contents of every changeset since the creation of > that file, which will take forever (well, not quite... but close). Indeed, and as I mentioned this is the *major* feature as far as I'm concerned (and frankly the only one I really care about and that helps a lot to track changes in the tree and understand why the code evolved). Note that cvsps works great for this, it's very efficient as well (not remotely comparable to arch at least, even if arch provided a tool equivalent to cvsps), the only problem is that CVS is out of sync... > I hope to someday (when more pressing issues are dealt with) add a per-file > cache indicating which patches affect which files, which should largely > address this problem, although it won't help at all with files that are > touched by most of the changesets, and won't be optimimal in any case. :( Wouldn't using the CVS format help an order of magnitude here? With CVS/SCCS format you can extract all the patchsets that affected a single file in a extremely efficient manner, memory utilization will be extremely low too (like in cvsps indeed). You'll only have to lookup the "global changeset file", and then open the few ,v files that are affected and extract their patchsets. cvsps does this optimally already. The only difference is that what cvsps is a "readonly" cache, while with a real SCM it would be a global file that control all the changesets in an atomic way. Infact *that* global file could be a bsddb too, I don't care about how the changset file is being encoded, all I care is that the data is a ,v file or SCCS file so cvsps won't have to read >2 files every time I ask that question, which is currently unavoidable with both darcs and arch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.29-pre1 OOPS early in boot with Intel ICH5 SATA controller
On Sat, 19 Feb 2005 12:33:32 -0500, Jeff Garzik <[EMAIL PROTECTED]> said: >>> Is it possible for you to enable the following two #ifdefs in >>> include/linux/libata.h, and send me the output? >> >>> #define ATA_DEBUG /* debugging output */ #define ATA_VERBOSE_DEBUG >>> /* yet more debugging output */ >> >> >> (Hand transcribed - E) >> >> ksymoops output below. > Can you confirm that this is fixed in 2.4.30-pre1? Sorry - I worked around the problem by setting the BIOS to "Native Mode", and the boxes that were showing the problem (Supermicro X6DA8) have now been shipped out to customers, where I can no longer do any debugging on them. -- Alan J. Wylie http://www.wylie.me.uk/ "Perfection [in design] is achieved not when there is nothing left to add, but rather when there is nothing left to take away." -- Antoine de Saint-Exupery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil data corruption
PALFFY Daniel wrote:
Hi,
I'm trying to set up a machine with a si3112a controller (lspci: 1095:3112
(rev 01) Subsystem: 1095:6112, cheap PCI card) and a ST3200822AS Rev:
3.01 disk and I see continuous silent data corruption while reading the
disk. Writing seems to be ok. I have 2.6.10-ac1 built with conservative
options (UP, no PREEMPT, 8k stack, no regparm). After seeing problems I
tried to blacklist my drive to do MOD15, but it didn't help.
Finally I did
unsigned long long i = 0;
while (write(1, , sizeof(i)) != -1) i++;
to the only primary partition while running sata_sil. Reading it back with
unsigned long long i=0, j;
while (read(0, , sizeof(i)) == sizeof(i)) {
if (j != i) fprintf(stderr, "diff at %llx: read: %llx\n", i, j);
i++;
}
gives similar results, but always different:
diff at 5efff: read: 5ef24
diff at 7: read: 7ff08
diff at 8: read: 8ff51
diff at 97fff: read: 97f00
diff at a: read: aff00
diff at b: read: bffac
diff at d: read: dff00
diff at efffe: read: eff00
diff at e: read: eff00
diff at fffbf: read: f
and so on.
Reading back the same data with the ide siimage driver worked for at least
500MB without corrupted data, but dma doesn't work with that driver, this
is logged on about the first read attempt:
hde: dma_intr: bad DMA status (dma_stat=76)
hde: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hde: DMA disabled
ide2: reset phy, status=0x0113, siimage_reset
ide2: reset: success
The machine is an old Compaq Prosignia 200, with a p2 300 and
:00:00.0 Host bridge: Intel Corp. 440FX - 82441FX PMC [Natoma] (rev 02)
chipset. Relevant parts from dmesg:
sata_sil:
libata version 1.10 loaded.
sata_sil version 0.8
ata1: SATA max UDMA/100 cmd 0xC886A080 ctl 0xC886A08A bmdma 0xC886A000 irq 10
ata2: SATA max UDMA/100 cmd 0xC886A0C0 ctl 0xC886A0CA bmdma 0xC886A008 irq 10
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
ata1(0): applying Seagate errata fix
ata1: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata2: no device found (phy stat )
scsi2 : sata_sil
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
siimage:
SiI3112 Serial ATA: IDE controller at PCI slot :00:0a.0
SiI3112 Serial ATA: chipset revision 1
SiI3112 Serial ATA: 100% native mode on irq 10
ide2: MMIO-DMA , BIOS settings: hde:DMA, hdf:DMA
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: ST3200822AS, ATA DISK drive
hde: applying pessimistic Seagate errata fix
ide2 at 0xc886a080-0xc886a087,0xc886a08a on irq 10
hde: max request size: 7KiB
hde: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63
hde: cache flushes supported
hde:<3>hde: dma_intr: bad DMA status (dma_stat=76)
hde: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hde1
Probing IDE interface ide3...
hdg: no response (status = 0xfe)
hde: dma_intr: bad DMA status (dma_stat=76)
hde: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
Don't use --two-- drivers for the same hardware.
Can you re-test with siimage disabled?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.29-pre1 OOPS early in boot with Intel ICH5 SATA controller
Alan J. Wylie wrote: On Mon, 13 Dec 2004 06:09:26 -0500, Jeff Garzik <[EMAIL PROTECTED]> said: Is it possible for you to enable the following two #ifdefs in include/linux/libata.h, and send me the output? #define ATA_DEBUG/* debugging output */ #define ATA_VERBOSE_DEBUG/* yet more debugging output */ (Hand transcribed - E) ksymoops output below. Can you confirm that this is fixed in 2.4.30-pre1? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts
it looks like yaird does use pivot_root. however pivot_root and initramfs cause a kernel crash (once you unmount /initrd in the real system). use run-init from klibc instead and you are fine. Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote: > But anyway the only thing I care about is that you import all dozen > thousands changesets of the 2.5 kernel into it, and you show it's > manageable with <1G of ram and that the backup size is not very far from > the 75M of CVS. The linux-2.5 tree right now (I'm re-doing the conversion, and am up to October of last year, so far) is at 141M, if you don't count the pristine cache or working directory. That's already compressed, so you don't get any extra bonuses. Darcs stores with each changeset both the old and new versions of each hunk, which gives you some redundancy, and probably accounts for the factor of two greater size than CVS. This gives a bit of redundancy, which can be helpful in cases of repository corruption. > I read in the webpage of the darcs kernel repository that they had to > add RAM serveral times to avoid running out of memory. They needed more > than 1G IIRC, and that was enough for me to lose interest into it. > You're right I blamed the functional approach and so I felt it was going > to be a mess to fix the ram utilization, but as someone else pointed > out, perhaps it's darcs to blame and not haskell. I don't know. Darcs' RAM use has indeed already improved somewhat... I'm not exactly sure how much. I'm not quite sure how to measure peak virtual memory usage, and most of the time darcs' memory use while doing the linux kernel conversion is under a couple of hundred megabytes. There are indeed trickinesses involved in making sure garbage gets collected in a timely manner when coding in a lazy language like haskell. > On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote: > > Thats all up to how the versioning system is written. Darcs developers > > are working in a checkpoint system to allow you to just grab the newest > > stuff, Correction: we already have a checkpoint system. The work in progress is making commands that examine the history fail gracefully when that history isn't present. > This is already available with arch. In fact I suggested myself how to > improve it with hardlinks so that a checkout will take a few seconds no > matter the size of the tree. I presume you're referring to a local checkout? That is already done using hard links by darcs--only of course the working directory has to actually be copied over, since there are editors out there that aren't friendly to hard-linked files. > > and automatically grab anything else you need, instead of just grabbing > > everything. In the case of the darcs linux repo, no one wants to > > download 600 megs or so of changes. > > If you use arch/darcs as a patch-download tool, then that's fine ... > The major reason a versioning system is useful to me is to track all > changesets that touched a single file since the start of 2.5 to the > head. So I can't get away by downloading the last dozen patches and > caching the previous tree (which is perfectly doable with arch for ages > and with hardlinks as well). And here's where darcs really falls down. To track the history of a single file it has to read the contents of every changeset since the creation of that file, which will take forever (well, not quite... but close). I hope to someday (when more pressing issues are dealt with) add a per-file cache indicating which patches affect which files, which should largely address this problem, although it won't help at all with files that are touched by most of the changesets, and won't be optimimal in any case. :( -- David Roundy http://www.darcs.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] libata-dev queue updated
Andre Tomt wrote: Jeff Garzik wrote: Patch URL, BK URL, and changelog attached. Recent changes: * New sata_qstor driver. * Turn on ATAPI by default. * Change a couple unconditional use-the-hardware function calls to be callbacks instead. Should have been this way originally. * Most of C/H/S support. * Fix bugs in ADMA driver. * Support PCI MSI in AHCI driver. * Support ATAPI in AHCI driver. * Improve ATA passthru (a.k.a. SMART) support How is the Marvell driver coming along? Did it stall? :-) Yeah, it's stalled... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c.h: Fix another gcc 4.0 compile failure
From: Mickey Stein
Versions: linux-2.6.11-rc4-bk7, gcc4 (GCC) 4.0.0 20050217 (latest fc
rawhide from 19Feb DL)
gcc4 cvs seems to dislike "include/linux/i2c.h file":
Error msg: include/linux/i2c.h:{55,194} error: array type has
incomplete element type
A. Daplas has recently done a workaround for this on another header
file. A thread discussing this
can be found by following the link below:
http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the array declaration from "struct x y[]" format to
"struct x *y".
I realize its only a workaround, but the gcc guys seem to be aware of
this.
** Note: I'm a noob at this, so feel free to make chopped liver out of
this if its incorrect.
patch below is also attached since I'm not sure formatting survives
the cut
Signed-off-by: Mickey Stein <[EMAIL PROTECTED]>
---
--- include/linux/i2c.h.sav 2005-02-19 07:02:52.0 -0800
+++ include/linux/i2c.h 2005-02-19 07:26:22.0 -0800
@@ -55,7 +55,7 @@
/* Transfer num messages.
*/
-extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg
msg[],int num)
;
+extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg
*msg,int num);
/*
* Some adapter types (i.e. PCF 8584 based ones) may support slave
behaviuor.
@@ -194,7 +194,7 @@
to NULL. If an adapter algorithm can do SMBus access, set
smbus_xfer. If set to NULL, the SMBus protocol is simulated
using common I2C messages */
- int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[],
+ int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs,
int num);
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
--- include/linux/i2c.h.sav 2005-02-19 07:02:52.0 -0800
+++ include/linux/i2c.h 2005-02-19 07:26:22.0 -0800
@@ -55,7 +55,7 @@
/* Transfer num messages.
*/
-extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int
num);
+extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,int num);
/*
* Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor.
@@ -194,7 +194,7 @@
to NULL. If an adapter algorithm can do SMBus access, set
smbus_xfer. If set to NULL, the SMBus protocol is simulated
using common I2C messages */
- int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[],
+ int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs,
int num);
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
Re: [SATA] libata-dev queue updated
Jeff Garzik wrote: Patch URL, BK URL, and changelog attached. Recent changes: * New sata_qstor driver. * Turn on ATAPI by default. * Change a couple unconditional use-the-hardware function calls to be callbacks instead. Should have been this way originally. * Most of C/H/S support. * Fix bugs in ADMA driver. * Support PCI MSI in AHCI driver. * Support ATAPI in AHCI driver. * Improve ATA passthru (a.k.a. SMART) support How is the Marvell driver coming along? Did it stall? :-) The propetiary source driver works, but its not like its universally available (I had to grab it from a different vendor..), "guaranteed" to work with future kernels, have a usable license, and so on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: workqueue - process context
Roland Dreier wrote: Rene> I have no idea about the module refcounting stuff. Is there Rene> a chance that create_workqueue() could increase a reference Rene> somewhere so that the module wouldn't be allowed to unload Rene> untill after a destroy_workqueue()? There's no point to doing this, since it's adding complexity to try and avoid a very obvious and easy to find bug. Other types of resource leaks are harder to find, but a module not destroying a workqueue is going to be trivial to spot and fix. Yes, fair enough. Thank you. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hotplug blacklist and video devices
On Sat, 2005-02-19 at 10:56 -0500, Jon Smirl wrote: > I didn't say make framebuffer depend on DRM, you can still unload DRM > before suspend. It's the other way around DRM needs framebuffer. > Suspend/resume are part of this. In the current model there is no way > for the DRM driver to see the suspend/resume events. I haven't tried > it but I suspect a suspend/resume with DRM running has a bad outcome > right now. Right. But for most machines, it's not possible to successfully resume if an accelerated framebuffer driver is loaded. Until that's fixed, tying DRM functionality to the framebuffer will make it impractical to use DRM on laptops. That's a regression from the current situation. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote: > In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By > using it's super magical method, it represents how code is written and how it > changes (patch theory at its best). You can clearly see the direction code is > going, where it came from, and how it relates to other patches. I don't know anything about darcs, I was only talking about arch. I failed to compile darcs after trying for a while, so I give it up, I'll try again eventually. But anyway the only thing I care about is that you import all dozen thousands changesets of the 2.5 kernel into it, and you show it's manageable with <1G of ram and that the backup size is not very far from the 75M of CVS. I read in the webpage of the darcs kernel repository that they had to add RAM serveral times to avoid running out of memory. They needed more than 1G IIRC, and that was enough for me to lose interest into it. You're right I blamed the functional approach and so I felt it was going to be a mess to fix the ram utilization, but as someone else pointed out, perhaps it's darcs to blame and not haskell. I don't know. To me backup size matters too and for example I'm quite happy the fsfs backend of SVN generates very small backups compared to bsddb. > Sure, you can do this with RCS/SCCS style versioning, but whats the point? It > is inefficient, and backwards. It is saved in a compact format, and I don't think it'll run slower since if it's in cache it'll be fast and if it's I/O dominaed the more compact it is, the faster it will be, having a compact size both for the repository and for the backup, is more important to me. In theory one could write a backup tool that extracts the thing and rewrite a special backup-backend that is as space efficient as CVS and that can compress as well as CVS, but this won't help the working copy. > Thats all up to how the versioning system is written. Darcs developers are > working in a checkpoint system to allow you to just grab the newest stuff, This is already available with arch. Infact I suggested myself how to improve it with hardlinks so that a checkout will take a few seconds no matter the size of the tree. > and automatically grab anything else you need, instead of just grabbing > everything. In the case of the darcs linux repo, no one wants to download 600 > megs or so of changes. If you use arch/darcs as a patch-download tool, then that's fine as you say and you can already do that with arch (that in this part seems already a lot more advanced and it's written in C btw). Most people just checking out the kernel with arch (or darcs) would never need to download 600Megs of changes, but I need to download them all. The major reason a versioning system is useful to me is to track all changesets that touched a single file since the start of 2.5 to the head. So I can't get away by downloading the last dozen patches and caching the previous tree (which is perfectly doable with arch for ages and with hardlinks as well). > It may not even be space efficient. Code ultimately is just code, and changes > ultimately are changes. RCS isn't magical, and its far from it. Infact, the The way RCS stores the stuff compresses great. In that is "magical". I guess SCCS is the same. fsfs isn't bad either though, and infact I'd never use bsddb and I'd only use fsfs with SVN. > The darcs repo which has the entire history since at least the start of 2.4 > (iirc anyways) to *now* is around 600 to 700. > My suggestion is to convert _all_ dozen thousand changesets to darcs, and > then > compare the size with CVS. And no, darcs doesn't eat that much memory for the What is the above 600/700 number then? I thought that was the conversion of all dozen thousand changesets of linux-2.5 CVS to darcs. > amount of work its doing. (And yes, they are working on that). I'll stay tuned. To me the only argument for not using a "magic" format like CVS or SCCS that is space efficient and compresses efficiently, is if you claim it's going to be a lot slower at checkouts (but infact applying some dozen thousand patchsets to run a checkout is going to be slower than CVS/SCCS). I know it's so much simpler to keep each patchset in a different file like arch is already doing, but that's not the best on-disk format IMHO. Note that some year ago I had the opposite idea, i.e. at some point I got convinced it was so much better to keep each patch separated from each other like you're advocating above, until I figured out how big the thing grows and how little space efficient it is, and how much I/O it forces me to do, how much disk it wastes in the backup and how slow it is as well to checkout dozen thousand patchsets. For smaller projects without dozen thousand changesets, the patch per file looks fine instead. For big projects IMHO being space efficient is much more important. - To unsubscribe from this list: send the line "unsubscribe
Re: Should kirqd work on HT?
Pallipadi, Venkatesh wrote: You are right. Kernel balancer doesn't move around the irqs, unless it has too many interrupts. The logic is moving around interrupts all the time will not be good on caches. So, there is a threshold above which the balancer start moving things around. You should see them moving around if you do 'ping -f' or a big 'dd' from the disk. If kirqd is moving NIC interrupts, it's broken. (and another reason why irqbalanced is preferable) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
Hello, > Hm, maybe you will have to implement some PCI add-on IDE controller, > AFAIR Silicon Image 680 datasheet is publicly available now. I just talked with a coworker who has experience with the above card. He told me that this IDE controller (hardware) has havy problems if you have havy load on both channels. (Blue screens in windows and DMA errors in Linux). He also told me that everything works fine if you use one channel in PIO mode and that there are workarounds in the linux kernel to circumvent the upcomming problems under havy load. Is that true or just nonsense? However it is worth to look at them. Thanks for the pointer! :-) Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: workqueue - process context
Rene> I have no idea about the module refcounting stuff. Is there Rene> a chance that create_workqueue() could increase a reference Rene> somewhere so that the module wouldn't be allowed to unload Rene> untill after a destroy_workqueue()? There's no point to doing this, since it's adding complexity to try and avoid a very obvious and easy to find bug. Other types of resource leaks are harder to find, but a module not destroying a workqueue is going to be trivial to spot and fix. (There are technical issues as well -- if create_workqueue() increments the module reference count, then you would never be able to unload the module if the destroy_workqueue() was in the module_exit function, because you can never even start to unload a module with a non-zero ref count). - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hotplug blacklist and video devices
On Sat, 19 Feb 2005 12:29:13 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > Jon Smirl <[EMAIL PROTECTED]> wrote: > > > For example I'm looking at making changes to DRM such that DRM will > > require the corresponding framebuffer driver to be loaded. If you back > > up further this is part of fixing X so that it won't mess with the > > hardware from user space. Mode setting would come from the framebuffer > > driver instead of the X 2D XAA driver. > > Please don't until all the framebuffer drivers are able to deal with > suspend and resume (which will also require some mechanism to switch > backlights back on). Currently, it's far easier to restore some amount > of state on a standard VGA or VESA mode. There's no real support for > doing so with most accelerated framebuffers. I didn't say make framebuffer depend on DRM, you can still unload DRM before suspend. It's the other way around DRM needs framebuffer. Suspend/resume are part of this. In the current model there is no way for the DRM driver to see the suspend/resume events. I haven't tried it but I suspect a suspend/resume with DRM running has a bad outcome right now. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/smc-mca.c: cleanups
> > > This comment is applicable to similar changes, also. Use 'const' > > > whenever possible. > > > > does that even have meaning in C? In C++ it does, but afaik in C it > > doesn't. > > Yes it does. Often the variables declared this way will go into the text > section which is marked read-only. true. Doesn't mean too much for the kernel right now (in kernel space not a lot of memory is really read only) though. > I've used this technique in a few very > small programs to reduce their size (I could strip off both their bss and > data sections to save space). Also, I believe that the compiler is able > to optimize code using consts, but this is pure speculation, I've not > verified it. Afaik that's the main difference between C and C++; in C you can still change "const" variables... in C++ thats illegal (at least that's what I remember and google seems to support somewhat ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/smc-mca.c: cleanups
On Sat, Feb 19, 2005 at 10:09:00AM +0100, Arjan van de Ven wrote: > On Sat, 2005-02-19 at 03:41 -0500, Jeff Garzik wrote: > > Adrian Bunk wrote: > > > This patch contains the following cleanups: > > > - make a needlessly global function static > > > - make three needlessly global structs static > > > > > > Since after moving the now-static stucts to smc-mca.c the file smc-mca.h > > > was empty except for two #define's, I've also killed the rest of > > > smc-mca.h . > > > > It looks like the structs should be 'static const', not just 'static'. > > > > This comment is applicable to similar changes, also. Use 'const' > > whenever possible. > > does that even have meaning in C? In C++ it does, but afaik in C it > doesn't. Yes it does. Often the variables declared this way will go into the text section which is marked read-only. I've used this technique in a few very small programs to reduce their size (I could strip off both their bss and data sections to save space). Also, I believe that the compiler is able to optimize code using consts, but this is pure speculation, I've not verified it. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc3-mm2: SMB: BUG: atomic counter underflow
I found the following in my logs: <-- snip --> Feb 19 15:46:05 r063144 kernel: smb_get_length: Invalid NBT packet, code=86 Feb 19 15:46:35 r063144 kernel: smb_add_request: request [d5242d40, mid=50934] timed out! Feb 19 15:46:35 r063144 kernel: BUG: atomic counter underflow at: Feb 19 15:46:35 r063144 kernel: [] smb_rput+0x51/0x60 Feb 19 15:46:35 r063144 kernel: [] smb_proc_readX+0xe8/0x100 Feb 19 15:46:35 r063144 kernel: [] smb_readpage_sync+0x92/0x110 Feb 19 15:46:35 r063144 kernel: [] smb_readpage+0x17/0x60 Feb 19 15:46:35 r063144 kernel: [] read_pages+0xec/0x170 Feb 19 15:46:35 r063144 kernel: [] __do_page_cache_readahead+0xee/0x100 Feb 19 15:46:35 r063144 kernel: [] blockable_page_cache_readahead+0x40/0x60 Feb 19 15:46:35 r063144 kernel: [] page_cache_readahead+0x20b/0x280 Feb 19 15:46:35 r063144 kernel: [] do_generic_mapping_read+0x3fe/0x720 Feb 19 15:46:35 r063144 kernel: [] __generic_file_aio_read+0x185/0x200 Feb 19 15:46:35 r063144 kernel: [] file_read_actor+0x0/0xf0 Feb 19 15:46:35 r063144 kernel: [] generic_file_read+0x9c/0xc0 Feb 19 15:46:35 r063144 kernel: [] autoremove_wake_function+0x0/0x50 Feb 19 15:46:35 r063144 kernel: [] do_sigaction+0x131/0x1b0 Feb 19 15:46:35 r063144 kernel: [] smb_file_read+0x3f/0xa0 Feb 19 15:46:35 r063144 kernel: [] sys_rt_sigaction+0x78/0xb0 Feb 19 15:46:35 r063144 kernel: [] sys_select+0x36d/0x480 Feb 19 15:46:35 r063144 kernel: [] vfs_read+0x126/0x130 Feb 19 15:46:35 r063144 kernel: [] sys_read+0x41/0x70 Feb 19 15:46:35 r063144 kernel: [] sysenter_past_esp+0x52/0x75 <-- snip --> This was during a time with multiple active smb connections with heavy read traffic (approx. 0,8 MByte/s altogether). 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] drivers/pci/: possible cleanups
On Sat, Feb 19, 2005 at 12:54:19AM +0100, Adrian Bunk wrote: > - remove the following unused functions: > - pci.c: pci_find_ext_capability The pcie bridge driver ought to be using this. I haven't submitted that cleanup patch yet. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible leak in kernel 2.6.10-ac12
On Saturday 19 February 2005 07:37 am, Pedro Venda wrote: > biovec-1 1989252 1989478 16 226 1 : tunables 120 60 > 0 : slabdata 8803 8803 0 bio 1989270 1989271 64 > 61 1 : tunables 120 60 0 : slabdata 32611 32611 0 You have bio leak. Similar one was fixed in -rc4. Did you already try using the md fix http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/md/[EMAIL PROTECTED] And http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fpatch-2.6.10.bz2;z=4918 ? If not, is it possible for you to either port these fixes to -ac12 or use -rc4 and then report slabinfo after couple of days? Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: workqueue - process context
Roland Dreier wrote: Not destroying its workqueue is a bug in the module just like any other resource leak. It's analogous to a module allocating some memory with kmalloc() and not calling kfree() when it's unloaded. Except though that with kmalloc() it's indeed just a leak while in this case things might blow up violently if run_workqueue() later accesses a workqueue_struct (or work_struct) which is already gone as part of the modules' datasection, for example. That's to say, if I'm reading this right... I have no idea about the module refcounting stuff. Is there a chance that create_workqueue() could increase a reference somewhere so that the module wouldn't be allowed to unload untill after a destroy_workqueue()? Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c
On Sad, 2005-02-19 at 05:20, Jeff Garzik wrote: > > It means that padto has improved a lot (or the underlying allocators). > > It also still means the patch makes the code slower and introduces > > changes that have no benefit into the kernel, so while its good to see > > its not relevant its still a pointless change. > > So the verdict is to revert? Not sure. The old code is known to work and a fraction faster, the new code makes the driver use the same logic as the others. Having seen the numbers from Paul I personally don't care either way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
On Sat, 19 Feb 2005 14:26:07 +0100, Thomas Glanzmann <[EMAIL PROTECTED]> wrote: > Hello Bartlomiej, > > > In IDE you have 2 devices per port and usually 2 ports per PCI device. > > There are some controller cards with 4 ports but they don't have public > > available documentation etc. I really wonder what are you trying to > > achieve and why just can't you use more than 1 "virtual" PIIX crontoller. > > we implemented the PIIX controller as part of an Intel Southbridge > 82371AB[1] Chip so I didn't thought that it was also available as > seperate PCI Device. Do you have any pointers to products or better > sepcification of this products? Nope. > If this is the case that would be the best solution for our problem. Hm, maybe you will have to implement some PCI add-on IDE controller, AFAIR Silicon Image 680 datasheet is publicly available now. Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
Hello, to clear things up. We implemented the PIIX IDE controller as part of the Intel Southbridge 82371AB which is part of the South bridge and a *onboard* chip. This chip has only two IDE channels AFAIK. The best thing would be if there is a PCI card or another chipset which has a PIIX IDE controller with more channels. Otherwise I look for another easy to implement IDE Bus Master capable chip with 2 channels which I can implement as PCI Card to use more of the card to get more DMA capable IDE channels in the virtual machine. Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sysfs, PCI-devices and power management
Hi, I don't know if this is the "right place(TM)" to ask about this, and if it isn't, I apologize. But the fact is that I haven't found any help from anywhere else and I can't learn enough without asking. So, the situation is like this: I am using a laptop and want to minimize the power consumption by shutting down unneeded components. Under windozer a program called Battery Doubler does the same by for example shutting down not-needed PCI devices. I too, tried to shut down certain devices by doing "echo 3 > /sys/devices/pci*/*0a*/power/state", but that didn't work. state was still a zero. So, I then echoed a "3" to detach_state and removed the module, after which */power/state was 3. Now, I then tried again changing it with no luck. Echoing a 1 to detach_state, modprobing and rmmoding the module did the trick, but I still can't get it back to state 0. Also, I read from the kernel documentations that echoing something to power/state should work, without toying around with the modules, but apparently that is b0rked. So, is there any way to fix this? Or, could someone do a simple C-program for changing the state of the devices? I don't know enough about PCI or programming under Linux, so my experiments with pci_set_power_state didn't work out quite the way they were supposed to =/ Also, the kernel in question is 2.6.10, though this hasn't worked with any other version either. I am not a regular reader in here, so please be kind and answer directly to me. -WareKala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Should kirqd work on HT?
You are right. Kernel balancer doesn't move around the irqs, unless it has too many interrupts. The logic is moving around interrupts all the time will not be good on caches. So, there is a threshold above which the balancer start moving things around. You should see them moving around if you do 'ping -f' or a big 'dd' from the disk. Thanks, Venki >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Nigel >Cunningham >Sent: Saturday, February 19, 2005 1:02 AM >To: [EMAIL PROTECTED] >Cc: Linux Kernel Mailing List >Subject: Re: Should kirqd work on HT? > >Hi. > >On Sat, 2005-02-19 at 17:44, Kwijibo wrote: >> My guess is that irqbalance is not running. > >No. It is. > >USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND >root 301 0.0 0.0 00 ?SW 16:52 0:00 [kirqd] > >The debugging info reports that it doesn't think it's worth doing the >balancing. > >Regards, > >Nigel >-- >Nigel Cunningham >Software Engineer, Canberra, Australia >http://www.cyclades.com > >Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 > >- >To unsubscribe from this list: send the line "unsubscribe >linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
Hello Bartlomiej, > In IDE you have 2 devices per port and usually 2 ports per PCI device. > There are some controller cards with 4 ports but they don't have public > available documentation etc. I really wonder what are you trying to > achieve and why just can't you use more than 1 "virtual" PIIX crontoller. we implemented the PIIX controller as part of an Intel Southbridge 82371AB[1] Chip so I didn't thought that it was also available as seperate PCI Device. Do you have any pointers to products or better sepcification of this products? If this is the case that would be the best solution for our problem. [1] Intel(R) 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4) Datasheet http://www.intel.com/design/intarch/datashts/290562.htm ftp://download.intel.com/design/intarch/datashts/29056201.pdf Greetings, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
On Sat, Feb 19, 2005 at 01:54:41PM +0100, Kenan Esau wrote: > > > But this return code is _very_ unusual. 0xfc means 'basic assurance test > > > failure' and should be reported only as a response to the 0xff command. > > > > Kenan, can you check whether the 0xfc response is there even if you > > don't do the setres 7 command before this one? > > Yes OK -- I will check. But as far as I know the 0xfe-answer from the > touchscreen means: "Please resend the last command". In theory, it should mean that even with the PS/2 spec. But it only works so in the other direction - when the PC doesn't get the bytes right. The devices use this error code for any problem, and this of course would lead to infinite loops if the system did always resend. > And 0xfc means: > "Error I didn't get that". Why wouldn't it? > I also checked my original standalone-driver: Because of this behaviour > I always retried the last command 3 times if the responce from the > device was 0xfe or 0xfc. And did it actually help? Did the touchscreen ever respond with a 0xfa "ACK, OK" response to these commands? -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
Am Donnerstag, den 17.02.2005, 20:42 +0100 schrieb Vojtech Pavlik: > On Thu, Feb 17, 2005 at 04:04:55PM +0100, Vojtech Pavlik wrote: > > > > drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489009] > > > drivers/input/serio/i8042.c: 07 -> i8042 (parameter) [78489009] > > > drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12) [78489014] > > > > Ok, this is a regular 'I don't know what you mean' response from the > > pad. > > > > > drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489014] > > > drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [78489014] > > > drivers/input/serio/i8042.c: fc <- i8042 (interrupt, aux, 12) [78489018] > > > > But this return code is _very_ unusual. 0xfc means 'basic assurance test > > failure' and should be reported only as a response to the 0xff command. > > Kenan, can you check whether the 0xfc response is there even if you > don't do the setres 7 command before this one? Yes OK -- I will check. But as far as I know the 0xfe-answer from the touchscreen means: "Please resend the last command". And 0xfc means: "Error I didn't get that". I also checked my original standalone-driver: Because of this behaviour I always retried the last command 3 times if the responce from the device was 0xfe or 0xfc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible leak in kernel 2.6.10-ac12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Parag Warudkar wrote: | On Wednesday 16 February 2005 06:28 pm, Pedro Venda wrote: | |>Having upgraded most of them to 2.6.10-ac12, one of them showed a linear |>growth of used memory over the last 7 days, after the first 2.6.10-ac12 |>boot. It came to a point that it started swapping and the swap usage too |>started to grow linearly. | | | cat /proc/slabinfo please. I am also seeing similar symptoms (although that is | with 2.6.11-rc4 there is a possibility of a common bug) here and I seem to | have linearly growing size-64 in slabinfo. | hi I've read the leak thread above possibly about this bug... AFAI read, there isn't really a conclusion about this leak, right? here goes the /proc/slabinfo for 2 days uptime: admin proc # uptime ~ 12:29:18 up 2 days, 14:23, 2 users, load average: 0.29, 0.38, 0.24 admin proc # cat slabinfo slabinfo - version: 2.1 # name : tunables : slabdata ip_conntrack_expect 0 0128 311 : tunables 120 600 : slabdata 0 0 0 ip_conntrack 230820384 101 : tunables 54 270 : slabdata 82 82 0 xfrm6_tunnel_spi 0 0 64 611 : tunables 120 600 : slabdata 0 0 0 fib6_nodes 8119 32 1191 : tunables 120 600 : slabdata 1 1 0 ip6_dst_cache 6 15256 151 : tunables 120 600 : slabdata 1 1 0 ndisc_cache1 15256 151 : tunables 120 600 : slabdata 1 1 0 rawv6_sock 3 664061 : tunables 54 270 : slabdata 1 1 0 udpv6_sock 6 664061 : tunables 54 270 : slabdata 1 1 0 tcpv6_sock10 14 115272 : tunables 24 120 : slabdata 2 2 0 unix_sock371620384 101 : tunables 54 270 : slabdata 62 62 0 tcp_tw_bucket 31 31128 311 : tunables 120 600 : slabdata 1 1 0 tcp_bind_bucket 81226 16 2261 : tunables 120 600 : slabdata 1 1 0 tcp_open_request 16 31128 311 : tunables 120 600 : slabdata 1 1 0 inet_peer_cache3 61 64 611 : tunables 120 600 : slabdata 1 1 0 secpath_cache 0 0128 311 : tunables 120 600 : slabdata 0 0 0 xfrm_dst_cache 0 0256 151 : tunables 120 600 : slabdata 0 0 0 ip_fib_alias 10226 16 2261 : tunables 120 600 : slabdata 1 1 0 ip_fib_hash 10119 32 1191 : tunables 120 600 : slabdata 1 1 0 ip_dst_cache 193285256 151 : tunables 120 600 : slabdata 19 19 0 arp_cache 3 31128 311 : tunables 120 600 : slabdata 1 1 0 raw_sock 2 751271 : tunables 54 270 : slabdata 1 1 0 udp_sock 14 1451271 : tunables 54 270 : slabdata 2 2 0 tcp_sock 21 52 102441 : tunables 54 270 : slabdata 13 13 0 flow_cache 0 0128 311 : tunables 120 600 : slabdata 0 0 0 cfq_ioc_pool 0 0 24 1561 : tunables 120 600 : slabdata 0 0 0 cfq_pool 0 0104 381 : tunables 120 600 : slabdata 0 0 0 crq_pool 0 0 52 751 : tunables 120 600 : slabdata 0 0 0 deadline_drq 0 0 48 811 : tunables 120 600 : slabdata 0 0 0 as_arq 135260 60 651 : tunables 120 600 : slabdata 4 4 0 mqueue_inode_cache 1 751271 : tunables 54 270 : slabdata 1 1 0 udf_inode_cache0 0348 111 : tunables 54 270 : slabdata 0 0 0 ntfs_big_inode_cache 0 051271 : tunables 54 270 : slabdata 0 0 0 ntfs_inode_cache 0 0156 251 : tunables 120 600 : slabdata 0 0 0 ntfs_name_cache0 051281 : tunables 54 270 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 32 1191 : tunables 120 600 : slabdata 0 0 0 ntfs_index_ctx_cache 0 0 64 611 : tunables 120 600 : slabdata 0 0 0 devfsd_event 0 0 20 1851 : tunables 120 600 : slabdata 0 0 0 isofs_inode_cache 0
idr_remove
http://marc.theaimsgroup.com/?l=linux-kernel=109838483518162=2
I am getting messages "idr_remove called for id=0 which is not allocated" when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case by installing a new kernel package on a SE Debian system. The
above URL references Jim Houston's message with the patch to add this
warning.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Jan 17 13:45:43 lyta kernel: audit(1105929943.164:0): avc: denied { search }
for pid=30322 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117]
sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.347:0): avc: denied { search }
for pid=30322 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.425:0): avc: denied { search }
for pid=30328 exe=/usr/bin/stat name=run dev=dm-2 ino=597921
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:var_run_t
tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.486:0): avc: denied { search }
for pid=30328 exe=/usr/bin/stat name=run dev=dm-2 ino=597921
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:var_run_t
tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.563:0): avc: denied { search }
for pid=30333 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117]
sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.713:0): avc: denied { search }
for pid=30333 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.785:0): avc: denied { search }
for pid=30337 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117]
sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.902:0): avc: denied { search }
for pid=30337 exe=/bin/bash name=/ dev=devpts ino=1
scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t
tclass=dir
Jan 17 13:45:44 lyta kernel: audit(1105929943.967:0): avc: denied { search }
for
Re: Hotplug blacklist and video devices
Jon Smirl <[EMAIL PROTECTED]> wrote: > For example I'm looking at making changes to DRM such that DRM will > require the corresponding framebuffer driver to be loaded. If you back > up further this is part of fixing X so that it won't mess with the > hardware from user space. Mode setting would come from the framebuffer > driver instead of the X 2D XAA driver. Please don't until all the framebuffer drivers are able to deal with suspend and resume (which will also require some mechanism to switch backlights back on). Currently, it's far easier to restore some amount of state on a standard VGA or VESA mode. There's no real support for doing so with most accelerated framebuffers. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
intel8x0: no sound in 2.6.11 rc3 & 4 (fine with 2.6.10)
Hello I have read a post in lkml.org that states that the problem experienced in rc3 has gone (1). That is not the case for me. My audio device is :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Subsystem: IBM: Unknown device 0554 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://pusa.uv.es/~ulisses/asound-intel8x0/ the tar files were done while playing pcm audio, (not being eard in rc4). I have found that I had to Mute __both__ "Headphone Jack Sense" and "Line Jack Sense" in order to ear the audio in rc4. Please let me know if you need further info or you want a tester All this is on a IBM Thinkpad R51 - Type 2887 -AVG (tot toc: IBM, we're buying your laptops too) Thanks in advance Ulisses (1) http://lkml.org/lkml/2005/2/18/93 -- Debian GNU/Linux: a dream come true - "Computers are useless. They can only give answers."Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should kirqd work on HT?
On Sat, 2005-02-19 at 21:58 +1100, Nigel Cunningham wrote: > Hi again. > > Didn't realise it was going to take nothing to install, so I've done it. > IRQs are running on cpu 1 now. Is there some documentation somewhere? > I'm wondering whether I can compile kirqd out. with irqbalance running yes you can compile kirqd out.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
Hi, On Sat, 19 Feb 2005 11:24:10 +0100, Thomas Glanzmann <[EMAIL PROTECTED]> wrote: > Hello, > we just implemented the Intel PIIX DMA Bus Master capable IDE Controller > in FAUmachine. This improved the IO access to virtual IDE Devices using > DMA as transport mechanism a lot. > > But with the current simulation it is only possible to access 4 devices > via DMA. > > Because of that I am looking for a good documented PCI IDE Controller > Card to provide DMA access to more than 4 devices with public available > documentation. Any pointers? In IDE you have 2 devices per port and usually 2 ports per PCI device. There are some controller cards with 4 ports but they don't have public available documentation etc. I really wonder what are you trying to achieve and why just can't you use more than 1 "virtual" PIIX crontoller. Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should kirqd work on HT?
Hi again. Didn't realise it was going to take nothing to install, so I've done it. IRQs are running on cpu 1 now. Is there some documentation somewhere? I'm wondering whether I can compile kirqd out. Thanks and regards, Nigel On Sat, 2005-02-19 at 20:36, Arjan van de Ven wrote: > On Sat, 2005-02-19 at 20:07 +1100, Nigel Cunningham wrote: > > Hi Jeff. > > > > On Sat, 2005-02-19 at 17:52, Jeff Garzik wrote: > > > Nigel Cunningham wrote: > > > What are the results of running irqbalanced? > > > > You mean the debugging output? I can reenable it and record the results > > if that's what you mean. > > no Jeff meant > http://people.redhat.com/arjanv/irqbalance/ > that app most likely > -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should kirqd work on HT?
Hi, On Sat, 2005-02-19 at 20:36, Arjan van de Ven wrote: > On Sat, 2005-02-19 at 20:07 +1100, Nigel Cunningham wrote: > > Hi Jeff. > > > > On Sat, 2005-02-19 at 17:52, Jeff Garzik wrote: > > > Nigel Cunningham wrote: > > > What are the results of running irqbalanced? > > > > You mean the debugging output? I can reenable it and record the results > > if that's what you mean. > > no Jeff meant > http://people.redhat.com/arjanv/irqbalance/ > that app most likely Oh... Ok. Never heard of it before. I'll download it now, but I'm about to go to bed now so the answer will be a while. Thanks for the reply. Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FAUmachine: Looking for a good documented DMA bus master capable PCI IDE Controller card
Hello, we just implemented the Intel PIIX DMA Bus Master capable IDE Controller in FAUmachine. This improved the IO access to virtual IDE Devices using DMA as transport mechanism a lot. But with the current simulation it is only possible to access 4 devices via DMA. Because of that I am looking for a good documented PCI IDE Controller Card to provide DMA access to more than 4 devices with public available documentation. Any pointers? Please CC me because I am currently not subscribed to linux-kernel. Thomas -- Thomas Glanzmann ++49 (0) 9131 85-27574 Department of Computer Science III Martensstrasse 3 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://www3.informatik.uni-erlangen.de/Research/FAUmachine/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, February 19, 2005 4:10 am, Patrick McFarland said: > On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote: >> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote: >> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM. >> >> The advantage it will provide is that it'll be compact and a backup will >> compress at best too. Small compressed tarballs compress very badly >> instead, it wouldn't be even comparable. Once the thing is very compact >> it has a better chance to fit in cache, and if it fits in cache >> extracting diffs from each file will be very fast. Once it'll be compact >> the cost of a changeset will be diminished allowing it to scale better >> too. > > In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. > By > using it's super magical method, it represents how code is written and how > it > changes (patch theory at its best). You can clearly see the direction code > is > going, where it came from, and how it relates to other patches. > > Sure, you can do this with RCS/SCCS style versioning, but whats the point? > It > is inefficient, and backwards. > >> Now it's true new disks are bigger, but they're not much faster, so if >> the size of the repository is much larger, it'll be much slower to >> checkout if it doesn't fit in cache. And if it's smaller it has better >> chances of fitting in cache too. > > Thats all up to how the versioning system is written. Darcs developers are > working in a checkpoint system to allow you to just grab the newest stuff, > and automatically grab anything else you need, instead of just grabbing > everything. In the case of the darcs linux repo, no one wants to download > 600 > megs or so of changes. > >> The thing is, RCS seems a space efficient format for storing patches, >> and it's efficient at extracting them too (plus it's textual so it's not >> going to get lost info even if something goes wrong). > > It may not even be space efficient. Code ultimately is just code, and > changes > ultimately are changes. RCS isn't magical, and its far from it. Infact, > the > format darcs uses probably stores more code in less space, but don't quote > me > on that. > >> The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed. > > The darcs repo which has the entire history since at least the start of > 2.4 > (iirc anyways) to *now* is around 600 to 700. > >> My suggestion is to convert _all_ dozen thousand changesets to arch or >> SVN and then compare the size with CVS (also the compressed size is >> interesting for backups IMHO). Unfortunately I know nothing about darcs >> yet (except it eats quite some memory ;) > > My suggestion is to convert _all_ dozen thousand changesets to darcs, and > then > compare the size with CVS. And no, darcs doesn't eat that much memory for > the > amount of work its doing. (And yes, they are working on that). > > The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks, > lets > switch to SVN or Arch!" thing everyone else in the known universe is > doing. > BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the > same > goes for SVN vs Arch vs Darcs). > > (Start Generic BK Thread On LKML Rant) > > Dear Everyone, > > I think if Linus is happy with BK, he should stick with it. His opinion > ultimately trumps all of ours because he does all the hard maintainership > work, and we don't. The only guy that gets to bitch about how much a > versioning system sucks is the maintainer of a project (unless its CVS, > then > all bets are off). > > Linus has so far indicated that he likes BK, so the kernel hacking > community > will be stuck using that for awhile. However, that doesn't stop the > license > kiddies from coming out of the woodwork and mindlessly quoting the bad > parts > of the BK license (which, yes, its non-free, but at this point, who gives > a > shit). > > IMO, yes, a non-free versioning system for the crown jewel of the FLOSS > community is a little... odd, but it was LInus's choice, and we now have > to > respect it/deal with it. > > Now, I did say above (in this thread) that darcs would be really awesome > for > kernel hacking, especially since it's inherent support for multiple > branches[1] and the ability to send changes from each other around easily > would come in handy; however, darcs was not mature at the time of Linus's > decision (and many say it is still not mature enough), so if Linus had > actually chosen darcs, I (and other people here) would be now flaming him > for > choosing a versioning system that wasn't mature. > > Similarly, if he had chosen arch, everyone would have flamed him for > choosing > a hard to use tool. With svn, he would have met flamage by the hands of it > being too much like cvs and not supporting arch/darcs style branch > syncing. > And if he stayed with cvs, he would have been roasted over an open fire > for > sticking with an out of date, useless, insane tool. > > And if he chose
Re: I wrote a kernel tool for monitoring / web page
sylvanino b wrote: Hi, I wrote a kernel tool for my personnal usage which goal is to keep a record of recent task preemptions and interruptions that appears under linux. Although the record is short (a few minutes only), It can help to analyse scheduling algorithm efficiency and also driver timing issues. The user can access data from user-space, through proc filesystem and analyze it with a graphics tool. Then, since it's also availlable within KDB, it can give clues and help for debugging. So far, the tool is not a big deal, but not trivial either. When It is running, the tool doesn't overload the system. And when it is not running, it's just transparent. I did a webpage for it, you can check it out at: http://membres.lycos.fr/kernelanalyzer/ If you have any comment/critics, don't hesitate to share it Thanks, Sylvain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Lycos is not the right place for such a good project, request hosting at sf.net or developer.berlios.de. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should kirqd work on HT?
On Sat, 2005-02-19 at 20:02 +1100, Nigel Cunningham wrote: > Hi. > > On Sat, 2005-02-19 at 17:44, Kwijibo wrote: > > My guess is that irqbalance is not running. > > No. It is. > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 301 0.0 0.0 00 ?SW 16:52 0:00 [kirqd] > > The debugging info reports that it doesn't think it's worth doing the > balancing. I guess the question was about the userspace irqbalance - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should kirqd work on HT?
On Sat, 2005-02-19 at 20:07 +1100, Nigel Cunningham wrote: > Hi Jeff. > > On Sat, 2005-02-19 at 17:52, Jeff Garzik wrote: > > Nigel Cunningham wrote: > > What are the results of running irqbalanced? > > You mean the debugging output? I can reenable it and record the results > if that's what you mean. no Jeff meant http://people.redhat.com/arjanv/irqbalance/ that app most likely - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
