Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too much these days (or, I do that in big batches).
> This lets you select hwdb support at compile time.
>
> hwdb is an efficient hardware database shipped with recent versions of udev.
> It contains among other sources pci.ids so querying hwdb rather than reading
> pci.ids directly should give the same result.
>
> Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb
> as the only source of this information, which this patch allows.
Generally, I will be glad to include hwdb support in libpci.
There is a couple of details I am concerned with:
> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ;
> then
> + HWDB=yes
> + else
> + HWDB=no
> + fi
Does this make sense? Does every version of libudev support hwdb?
> @@ -86,8 +91,58 @@ char
> *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2,
> int id3, int id4)
> {
>struct id_entry *n, *best;
> - u32 id12 = id_pair(id1, id2);
> - u32 id34 = id_pair(id3, id4);
> + u32 id12, id34;
> +
> +#ifdef PCI_HAVE_HWDB
> + if (!(flags & PCI_LOOKUP_SKIP_LOCAL))
> +{
As you wrote it, hwdb has always priority over pci.ids (unless local lookup is
disabled). As a user, I would expect that pci.ids (being a part of the pciutils)
is the primary source of data and other sources (network lookups, hwdb) are
used only if pci.ids do not match or if explicitly requested.
Have a nice fortnight
--
Martin `MJ' Mares http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Quidquid latine dictum sit, altum videtur.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 66MHz PCI
Hello! > is it possible to detect whether a device is running at 66MHz (as opposed > to 33)? PCI defines a 66MHz capable bit, but not a 66MHz enabled bit. We > have a silly device that seems to need to know what it's bus speed is, but > have no way to tell from software (that I know of). > > So, pray tell -- is there a way to figure it out? There is, but unfortunately it's host bridge specific. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ If a train station is where the train stops, what is a work station? - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Hi Jeff! > Is Martin still alive? He hasn't been active in PCI development well > over six months, maybe a year now. Ivan (alpha hacker) appeared on the > scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA > stuff, and I've added a couple driver-related things. I haven't seen > code from Martin in a long long time, and only a comment or two in > recent memory. I'm buried alive in mail, graph theory and several other projects, so I'm now happy I'm able to at least keep track of kernel development and answer some bug reports, but I hope it will get better soon. If it won't, I'll probably have to pass the maintainer's sceptre to someone less busy, but I'd rather like to avoid it as I still like the PCI world very much though it's got somewhat messy these days. > > --- linux-2.4.3-orig/include/linux/pci.hWed Apr 4 19:46:49 2001 > > +++ linux/include/linux/pci.h Sat Apr 7 20:01:51 2001 > > @@ -454,6 +454,9 @@ > > void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a >hot-plug capable driver) */ > > void (*suspend)(struct pci_dev *dev); /* Device suspended */ > > void (*resume)(struct pci_dev *dev);/* Device woken up */ > > + int multifunction_quirks; /* Quirks for PCI serial+parport >cards, > > + here multiple drivers are >allowed to register > > + for the same pci id match */ > > }; This is incredibly ugly. IMHO the right solution is to add a driver for each such multi-function device which will split the device to two virtual devices as Linus has suggested, or maybe better to add a generic driver doing such splitting for multiple similar multi-function cards. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ bug, n: A son of a glitch. - 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: No 100 HZ timer !
Hi! > Just how would you do kernel/user CPU time accounting then ? It's currently done > on every timer tick, and doing it less often would make it useless. Except for machines with very slow timers we really should account time to processes during context switch instead of sampling on timer ticks. The current values are in many situations (i.e., lots of processes or a process frequently waiting for events bound to timer) a pile of random numbers. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ We all live in a yellow subroutine... - 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.4.4.3: pci_enable/disable_device stuff
Hi! > The attached patch does two things: > > 1) Take PCI devices to D0 state before enabling them. We both think > this is the right thing to do, but there is always the crazy chance this > change will break something. So, think twice before applying, but IMHO > apply :) I'm not able to cite the PCI PM specs by heart :) ... but looks OK to me. > 2) Adds pci_disable_device. Right now is just disables busmastering. > When suspending devices, the last task that should occur is to disable > busmastering, before ceding control to ACPI. Also its a good idea in > general to disable busmastering when its not in use; it's friendlier to > the bus. OK. > When unloading drivers too, we should be more "green" about > disabling devices. Yes, but not before we're sure we can wake them up correctly. Probably also needs to handle wakeup of PCI-to-PCI bridges. > I wonder if we should disable IO and MEM decoding too, and I also like > to ack PCI_STATUS. I didn't add those things because I'm not yet sure > we want to do that unconditionally. I'd rather prefer to avoid this. It brings nothing except for possible problems. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Compatible: Gracefully accepts erroneous data from any source. - 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] Near-constant time directory index for Ext2
Hello! > Have You tried to use skiplists ? > In 93 I've coded a skiplist based directory access for Minix and it gave very > interesting performances. > Skiplists have a link-list like performance when linear scanned, and overall > good performance in insertion/seek/delete. Skip list search/insert/delete is O(log N) in average as skip lists are just a dynamic version of interval bisection. Good hashing is O(1). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Entropy isn't what it used to be. - 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] Near-constant time directory index for Ext2
Hello! > To have O(1) you've to have the number of hash entries > number of files and a > really good hasing function. No, if you enlarge the hash table twice (and re-hash everything) every time the table fills up, the load factor of the table keeps small and everything is O(1) amortized, of course if you have a good hashing function. If you are really smart and re-hash incrementally, you can get O(1) worst case complexity, but the multiplicative constant is large. > To be sincere, here is pretty daylight :) :) Martin - 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] Near-constant time directory index for Ext2
Hello! > You're right. However, for each hash table operation to be O(1) the size > of the hash table must be >> n. If we are talking about average case complexity (which is the only possibility with fixed hash function and arbitrary input keys), it suffices to have hash table size >= c*n for some constant c which gives O(1/c) cost of all operations. > I suggested at one point to use B-trees with a hash value as the key. > B-trees are extremely efficient when used on a small constant-size key. Although from asymptotic complexity standpoint hashing is much better than B-trees, I'm not sure at all what will give the best performance for reasonable directory sizes. Maybe the B-trees are really the better alternative as they are updated dynamically and the costs of successive operations are similar as opposed to hashing which is occassionally very slow due to rehashing unless you try to rehash on-line, but I don't know any algorithm for on-line rehashing with both inserts and deletes which wouldn't be awfully complex and slow (speaking of multiplicative constants, of course -- it's still O(1) per operation, but "the big Oh is really big there"). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "#define QUESTION ((bb) || !(bb))" -- Shakespeare - 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] Near-constant time directory index for Ext2
Hello! > My personal preference goes to skiplist coz it doesn't have fixed ( or growing > ) tables to handle. You've simply a stub of data togheter with FS data in each > direntry. Another problem with skip lists is that they require variable sized nodes, so you either need to keep free chunk lists and lose some space in deleted nodes kept in these lists, or you choose to shift remaining nodes which is slow and complicated as you need to keep the inter-node links right. With hashing, you can separate the control part of the structure and the actual data and shift data while leaving most of the control part intact. > And performance ( O(log2(n)) ) are the same for whatever number of entries. I don't understand this complexity estimate -- it cannot be the same for whatever number of entries as the complexity function depends on the number of entries. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms' - 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] Near-constant time directory index for Ext2
Hello! > True. Note too, though, that on a filesystem (which we are, after all, > talking about), if you assume a large linear space you have to create a > file, which means you need to multiply the cost of all random-access > operations with O(log n). One could avoid this, but it would mean designing the whole filesystem in a completely different way -- merge all directories to a single gigantic hash table and use (directory ID,file name) as a key, but we were originally talking about extending ext2, so such massive changes are out of question and your log n access argument is right. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ COBOL -- Completely Outdated, Badly Overused Language - 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] Near-constant time directory index for Ext2
Hello! > Not true. The rehashing is O(n) and it has to be performed O(log n) > times during insertion. Therefore, insertion is O(log n). Rehashing is O(n), but the "n" is the _current_ number of items, not the maximum one after all the insertions. Let's assume you start with a single-entry hash table. You rehash for the first time after inserting the first item (giving hash table of size 2), then after the second item (=> size 4), then after the fourth item (=> size 8) and so on. I.e., when you insert n items, the total cost of rehashing summed over all the insertions is at most 1 + 2 + 4 + 8 + 16 + ... + 2^k (where k=floor(log2(n))) <= 2^k+1 = O(n). That is O(1) operations per item inserted. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ MIPS: Meaningless Indicator of Processor Speed. - 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] Cleanup of PCI device reporting in IDE driver (2.4.0)
Hello! > Description: > Cleans up the reporting of PCI device numbers when they are printed out by > the PCI IDE driver. The dev->devfn value holds both the device number and > the function number, so it's nicer if they are split out and displayed > separately to the user. Better use pci_dev->slot_name, so that the formatting of slot names will be consistent with what the other drivers and the PCI subsystem itself use. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Linux hackers are funny people -- they count the time in patchlevels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI-Devices and ServerWorks chipset
Hello! > The patch below (against vanilla 2.4.0) makes Linux recognize > PCI-Devices sitting in another PCI bus than 0 (or 1). > > This was tested on a Netfinity 7100-8666 using a ServerWorks chipset. I don't have the ServerWorks chipset documentation at hand, but I think your patch is wrong -- it doesn't make any sense to scan a bus _range_. The registers 0x44 and 0x45 are probably ID's of two primary buses and the code should scan both of them, but not the space between them. Anyway, could you send me a `lspci -MH1 -vvx' and `lspci -vvxxx -s0:0', please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ System going down at 5 pm to install scheduler bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: "No IRQ known for interrupt pin A..." error message
Hello! > During boot, I get the message: > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > using pci=biosirq. Can you send me 'lspci -vvx' output, please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "System going down at 1:45 for disk crashing." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reordering pci interrupts?
Hello!
> I have a motherboard with a broken bios that is unable to set interrupts
> correctly, i.e. it initializes the devices corerctly but swaps the
> interrupts for slot1/slot3 and slot2/slot4.
>
> Now, is there a way to forcefully re-order the pci-interrupts? I do not
> have an io-apic (thus no pirq=xxx), and I tried to poke the interrupt
> values directly into /proc/bus/pic/*/*, but the kernel has it's own idea.
>
> Thanks a lot for any info (I guess I'll just patch the kernel).
Please try this patch and boot with "pci=autoirq" on the kernel command line.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"veni, vidi, nuclei deceiri - I came, I saw, I core dumped"
--- arch/i386/kernel/pci-pc.c.mjSun Nov 19 20:18:14 2000
+++ arch/i386/kernel/pci-pc.c Sun Nov 19 20:18:14 2000
@@ -1035,6 +1035,9 @@
} else if (!strncmp(str, "lastbus=", 8)) {
pcibios_last_bus = simple_strtol(str+8, NULL, 0);
return NULL;
+ } else if (!strcmp(str, "autoirq")) {
+ pci_probe |= PCI_AUTOIRQ;
+ return NULL;
}
return str;
}
--- arch/i386/kernel/pci-i386.h.mj Sun Nov 19 20:18:32 2000
+++ arch/i386/kernel/pci-i386.h Sun Nov 19 20:18:32 2000
@@ -18,6 +18,7 @@
#define PCI_NO_SORT 0x100
#define PCI_BIOS_SORT 0x200
#define PCI_NO_CHECKS 0x400
+#define PCI_AUTOIRQ 0x800
#define PCI_ASSIGN_ROMS 0x1000
#define PCI_BIOS_IRQ_SCAN 0x2000
--- arch/i386/kernel/pci-irq.c.mj Sun Nov 19 20:18:50 2000
+++ arch/i386/kernel/pci-irq.c Sun Nov 19 20:18:50 2000
@@ -487,7 +487,7 @@
* If the BIOS has set an out of range IRQ number, just ignore it.
* Also keep track of which IRQ's are already in use.
*/
- if (dev->irq >= 16) {
+ if (dev->irq >= 16 || (pci_probe & PCI_AUTOIRQ)) {
DBG("%s: ignoring bogus IRQ %d\n", dev->slot_name, dev->irq);
dev->irq = 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
Hi Andries! > All these really good people, unable to capture a simple idea. > Let me try one more time. > There is information. The information is: > "this variable needs initialization" > Now you tell me to know simple rules. OK, I know them. > But what do they tell me about my variables a and b, where > a requires initialization and b does not require it? Distinguishing between variables initialized to zero and those not requiring initialization is a good idea, but honestly, how common are static variables declared at the top level which don't require initialization? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "RAM = Rarely Adequate Memory" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: x86 PCI IRQ's were not being routed in some cases (against 2.4.0-test11pre4)
Hello! > To fix this problem, I have deleted a conditional in > pcibios_enable_irq, so that it will route the IRQ, even if it > thinks the work has already been done. Now, USB and my PCMCIA > flash cards work in that notebook computer again. Unfortunately, your fix is wrong -- it makes Linux ignore all the IRQ settings the user has set up in the BIOS and I also guess there are machines where the IRQ information in the INTERRUPT_LINE register is correct, but the BIOS tables/functions are inaccurate. First of all, please send me the 'lspci -vvx' output for the USB device and also try booting the kernel with a "pci=autoirq" option which should have exactly the same effect as your patch. > I do not have that solid of an understanding of PCI > initialization in Linux. I am still rather confused about what > routines are supposed to set up an interrupt if one is needed > and has not yet been routed for the device and which ones are supposed > to punt in case. The IRQ assignment logic is somewhat complicated to handle all the corner cases: o When we are scanning the PCI bus and we encounter a device with wrong IRQ, we ignore the IRQ information. o During the scan, if we find a device with unset IRQ, but having an interrupt pin advertised in its configuration header, we try to look at the interrupt router to see what IRQ did BIOS route the pin to. o When pci_enable_device() is called and the IRQ is still unset (and interrupt pin exists), we try to route the IRQ ourselves. > For example, there is another problem that I > am trying to fix, where the motherboard BIOS on that other computer > sets the IRQ associated with the USB controller to zero, no matter > how I program the BIOS, and pcibios_lookup_irq takes this as reason > enough to refuse to allocate and route a new IRQ. It definitely shouldn't behave so -- IRQ set to zero is always interpreted as "no IRQ assigned". Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Purchasing Windows is an Unrecoverable Application Error. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! > It is a real issue of failure in 2.2, and it would be useful if the PPC > folks want to use Ultra-ATA cards. For 2.4, making the IDE driver call pci_enable_device() and modifying the PPC PCI code to fix up whatever is needed there. For 2.2, it's probably better to leave things as they are and just ask PPC guys for adding a special fixup to their code. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Q: How to start hacking Linux? A: vi /boot/vmlinuz" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: weird PCI problems...
Hi Tigran!
Sorry for the delay, I'm now finishing up for my final exams, so I get to
answering my mail once per day if I'm lucky.
> Yes, doing it like this works:
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
> Martin, is this totally wrong? I.e. will it break the case of multiple
> peer PCI buses? Note that with the above I see absolutely all my devices,
> like this:
This fix is wrong -- the scanning of cardbus devices is done inside the cardbus
driver itself, the PCI layer should only allocate the bus. If you force the
scanning, it will work for devices present during system boot, but not if you
remove the card and insert it again.
Anyway, can you send me your /proc/ioports and /proc/iomem, please?
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"People disagree with me. I just ignore them." -- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: pci_enable_device_mask
Hi Jeff! > I didn't update all the archs, just x86.. Enjoy. This is not an > official patch submission (so Linus if you see it, don't apply...) Is there any reason for adding such a thing? I was thinking about it some months ago and it seemed to me that we always have plenty of space for all the resources. Anyway, I'd prefer selecting such options via extra fields in struct pci_dev which would the driver set before calling pci_enable_device() -- this way we can add new options later without introducing new functions. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "return(ENOTOBACCO); /* Read on an empty pipe */" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bookkeeping
Hello! > The problem I'm seeing is that at least one driver > has signed up to handle the wrong IRQ because, > when it queried that PCI config value, it went > back and got it from PCI config space rather > than from the in-kernel data structures where the > (correct) recalculated value had been stored. So, > I'm wondering if our Official Approach is to always > query the in-kernel data structures which have > been setup so nicely for us, or are we supposed > to obtain (some or all of) that sort of info from > PCI space? Or is this all just a bleeding mess? The only correct way to get the IRQ number for a given PCI card is to look to the pci_dev structure. This holds for both 2.2 and 2.4 kernels. (The main reason being that on some architectures the interrupt number doesn't fit in a single byte.) If you know of any drivers reading interrupt line information from the configuration space, please tell us and we'll fix them. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Immanuel doesn't pun, he Kant." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 PCI detection and documentation
Hello! > > Some years ago, the PCI routines have really used this strategy > > (and the obsolete help text reflects this situation), but unfortunately, > > there exist machines where the direct access detection gives bogus > > results, so it's much better to ask the BIOS first. Also, it's conceptually > > cleaner to use a well-defined BIOS interface than to probe random > > ports (well, they are random on all non-PCI machines). > > > > These are the reasons why I'd prefer keeping the current code and > > just fixing the documentation. > > AFAICS the current code does not follow this line of thought > completely, as it still probes the hw directly after asking the > BIOS, even though the BIOS might have returned valid data. > > So I propose the following patch (patch 1) that changes the code > to check the BIOS results before probing directly and changes the > documentation to reflect this. It seems you've misunderstood the code (I agree it isn't as straightforward as I would wish, but the whole PCI probing business is a bit fishy anyway). The current probing code doesn't ignore the BIOS check results at all -- the check_pcibios() function looks which direct access methods are said by the BIOS to be supported by the hardware and if there are any, we continue with probing these direct access methods. Only if they fail or the BIOS reports no known direct access methods, we fall back to using the BIOS functions. (There is a couple of good reasons for trying to avoid using BIOS to access the configuration registers -- these functions are slow and sometimes buggy.) I still think the code is correct and only the documentation needs to be updated (I'll send a patch to Linus as soon as I catch up with my mail queue). > If this is rejected for some reason, I include a patch 2 that > merely changes the Documentation/Configure.help to reflect how > the code works currently. Unfortunately, it doesn't :( Anyway, have you already tried "pci=conf1" as I've suggested in my previous mail? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Linux vs. Windows is a no-WIN situation." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Hello! > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > bang over everyone's head, without success. > > Here is his sample code for cs5530 chipset. > > Look at this and comment. I have part of the space setup to complete the > APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "MIPS: Meaningless Indicator of Processor Speed." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Hi Jeff! > First, some definitions: > downstream - away from the host processor > primary - number of the PCI bus closer to the host processor > secondary - number of the PCI bus on the downstream side of the PCI > bridge > subordinate - number of the highest-numbered bus on the downstream side > of the PCI bridge Agreed. > > > 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) > > Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 > > First bridge on bus 0. > primary == 0 - ok > secondary == 2, should be 1 (bus #1 is behind this bridge) Why? Behind this bridge, there is bus #2, not bus #1. Bus #1 is behind the PCI-to-PCI bridge 00:11.0. > subordinate == 5, should be 2 (bus #2 follows us) The bus numbers assigned by the current kernel may look strange, but they are perfectly correct according to the definition above. The PCI specs don't enforce any specific ordering of bridges on the same bus, the only requirements are that that the secondary...subordinate ranges of the bridges don't overlap and that they are in the secondary+1...subordinate range of the parent bus (which is 01...FF for the root bus). > > 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) > > Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 [...] > > 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 [...] This gives us the following assignment: 00 root bus (01-FF allowed for its sub-busses) 01 secondary PCI 02-05 first cardbus 06-09 second cardbus which doesn't break the rules. > Second, will anything break if bus numbers change on x86? There exists > pcibios_assign_all_busses() on all platforms... but only Alpha defines > it to 1. All others define it to zero. Yes, it will break on any machine with multiple primary PCI busses, because the registers assigning bus number ranges to primary busses are chipset specific. In 2.5, I'd like to rewrite the resource + bus number assignment code to be able to re-layout the busses and resources even on i386 if it detects it's safe to do so (that is there is either only one primary bus or the host bridge is known). This will be needed for proper PCI hotplug and it will also help us to get rid of some more BIOS bugs (especially on some embedded systems). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Hi! > So this is not our problem here. Anyway I guess it's time to hunt for > i8259 accesses in the kernel that lack the necessary spinlock, even when > they're not probably the cause of the problem we see here. BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "This line is umop apisdn." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd)
Hello! [Sorry for the delay, I've been ill for two weeks and now I'm trying hard to catch up with the huge pile of mail...] > I'm not certain of the details but I do know that it is legal. > To date I've only heard of it on ISA bridges, in particular the PIIXE. > It's some kind of passive listening mode as opposed to actually claiming > the bus cycles. Yes, this is called subtractive address decoding, but as far as I remember, the PCI specifications allow only one subtractive decoder in the system which is in 99% of cases the ISA bridge. Jamal, can you send me "lspci -vvxxx" results on both 2.2 and 2.4, please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Hi Alan! > If the sound card is only used some of the time or setup and then used > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it > especially on a low end box So why don't we allocate / free the DMA buffer on device open / close instead of module insert / remove? If the reason lies in problems with allocation of large chunks of contiguous memory, we're going to have exactly the same problems when autoloading the module. I think that automatic loading / unloading of modules has been a terrible hack since its first days (although back in these times a useful one) and that the era of its usefulness is over. There are zillions of problems with this mechanism, the most important ones being: o It would have to preserve _complete_ device state over module reload. For the sound card mixer settings discussed it's close to trivial, but for example consider a tape drive and the problem of preserving tape position after reload (probably including device reset causing tape rewind). And what about textures loaded to memory of a 3D video card? o For many drivers, the "device currently open" concept makes no sense. Consider a mouse driver whose only activity is to feed mouse events to an event device. The mouse driver can be unloaded in any time (either manually or perhaps automatically after the mouse gets unplugged), hence it should have a use count == zero, but even if it seems to be unused, it must not be unloaded just because of some timeout since the mouse will cease to work. o It interferes with hotplug in nasty ways. Let's have a USB host controller driver with currently no devices on its bus. It's also an example of a zero use count driver, but it also must not be unloaded as it's needed for recognizing newly plugged in devices. I don't argue whether we need or need not some kind of persistent storage for the modules (it might be a good idea when it comes to hotplug, but it should be probably taken care of by the userspace hotplug helpers), but I think that it has no chance to solve the problems with automatic unloading. We could of course attempt to circumvent the problems listed above by adding some hints to module state which will say whether it's possible to auto-unload the module or not even if it has zero use count, but it means another thing to handle in all the drivers (well, at least another thing to think of whether it's needed or not for each driver) and I think that the total effect of the autounloading mechanism (a minimum amount of memory saved) in no way outweighs the cost of implementing it right. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "A mathematician is a machine for converting coffee into theorems." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Hello Horst!
> Strange somebody from a distribution forgets _the_ most important use of
> modules: Remember old-time Slackware, with dozens of different boot
> diskettes, and the imperative to compile a kernel to your machine once you
> got it running?
But how is this related to automatic unloading of modules???
Even automatic loading is not needed for this purpose -- just make the startup
scripts load all the modules needed and you don't have to maintain complex
mappings from userspace device names to kernel drivers.
> The cases mentioned are cases where unloading (automatic or manual, doesn't
> matter) would break things. Just don't allow it, ever (IPv6 does this, for
> one example). Or fix the loading/unloading somehow. Strategies to be able
> to do so is what is being discussed here, BTW...
No, the cases mentioned are cases where automatic unloading breaks things,
but manual unloading is perfectly okay. Nobody expects you to preserve exact
hardware state and keep things working if you unload the driver manually,
but automatic unload should be perfectly transparent.
> Just force a non-zero count as long as the module is in use. Wait a
> minute... that is exactly what a non-zero count is supposed to mean!
Yes, but define "in use". Does your "in use" mean "referenced by user space
or by other drivers" (== cannot be unloaded without crashing the system)
or "unloading this module makes something cease to work"? Currently, the
use counts maintained by the drivers correspond to the first definition
which is the right definition when it comes to manual unloading, but it
gives you no clue when it comes to transparent automatic unloading.
> What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen
> discussed here isn't at all "minimal" for somebody who has to run Linux in
> 4Mb, preferably less...
> Linux came to be what it is today in large part because the PC nobody
> wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web
> server/mail server/... over in some closet, and soon nobody even remembered
> where the machine was physically. Don't kill this.
In routers dreaming the ancient dreams from the elder days of their creation,
you need all the modules loaded all the time anyway, hence automatic unloading
doesn't apply. Even better use a monolithic kernel since it saves in average
half a page per driver. (Yes, I know that current distributions don't ship with
precompiled kernels suiting your machine, but current distributions don't run
on a 4MB 386 anyway.)
Also, I'm not advocating killing compatibility with such old hardware (which
I frequently use), but I'd very much like to avoid hacking all the drivers
just to support correctly some (although sometimes useful) ill defined feature.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"ADA -- A Dumb Acronym"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
Hi! > I noticed a lot of drivers are setting the PCI_CACHE_LINE_SIZE > themselves, some to L1_CACHE_BYTES/sizeof(u32), others > to arbitrary values (4, 8, 16). > > Then I spotted that we have a routine in the PCI subsystem > (pdev_enable_device) that sets all these to L1_CACHE_BYTES/sizeof(u32) > Further digging revealed that this routine was not getting called. > > On my Athlon box, I've noticed some devices are getting their > default values set to 8 (where (I think) it should be 16 ?) > > Questions: > 1. Is there reason for the drivers to be setting this themselves >to hardcoded values ? Definitely not unless the devices are buggy and need a work-around. For PC's, we've until now relied on the BIOS setting up cache line sizes correctly. Are the "8"'s you've spotted due to drivers messing with the cache line register or do they come from the BIOS? > 2. Why is pdev_device_enable no longer used ? I haven't written this function, but I guess it's expected to be called from the architecture specific device enabling code and that some architectures have to call it, some don't. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ bug, n: A son of a glitch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
Hello Gerard! > Having to call some pdev_enable_device() to have the cache line size > configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER, > etc.. are configured prior to entering driver probe. Once upon a time, they used to be, but they no longer are. Unfortunately, there are lots of bogus devices which must be never assigned BARs nor routed interrupts. You need to call pci_enable_device() after you recognize the device as handled by your driver to get BARs and interrupts set up. Also, if your driver uses bus mastering, it should call pci_set_master(). > Why should the cache line size be deferred to some call to some obscure > mismaned thing ? See above. I'm also not joyfully jumping when I think of it, but consider it being a tax on being compatible with the rough world of buggy PCI devices. Anyway, it's still zillion times better than random drivers modifying such configuration registers in random manner, knowing nothing about the host bridge and other such stuff. (Side note: I'm not saying the method your driver uses was bad at the time it was designed, I'm only saying that it's wrong wrt. the rest of the kernel and it should be gone.) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ CChheecckk yyoouurr dduupplleexx sswwiittcchh.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cardbus pirq conflict
Hi Linus! > My tentative fix for this would be to make Linux never assign bus #1 or #2 > to a cardbus bridge, and start cardbus bridges at bus #8 or something like > that. That way we'd still catch any strangeness in the pirq table, but we > wouldn't get the message for this case which seems to be very common. Agreed. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ CChheecckk yyoouurr dduupplleexx sswwiittcchh.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
Hello! > It is the bar cookies in pci dev structure that are insane, in my opinion. > > If a driver needs BARs values, it needs actual BARs values and not some > stinking cookies. What a driver can do with BAR cookies other than using > them as band-aid for dubiously designed kernel interface. If a driver wants to know the BAR values, it can pick them up in the configuration space itself. The problem is that these values mean absolutely nothing outside the bus the device resides on. There exist zillions of translating bridges and no driver except for the driver for the particular bridge should ever assume anything about them. The values in pci_dev->resource[] are not some random cookies, they are genuine physical addresses as seen by the CPU and as accepted by ioremap(). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "People disagree with me. I just ignore them." -- Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random: really secure?
Hello! > I noticed peculiarities in the behaviour of the delta-delta-3 system for > entropy estimation in the random.c code./ When I hold right alt or control, I > get about 8 bits of entropy per repeat fro the /dev/random which is > overestimated. I think the real entropy is 0 bits because it is absolutely > deterministic when the interrupt comes. Am I right or is there any hidden > magic source of entropy in this case? It isn't _absolutely_ deterministic (see the other replies about clock skew), but I agree it isn't a reliable source of entropy. This is the reason why add_keyboard_randomness() tries not to count autorepeated keys, but unfortunately it's buggy since it doesn't work with keys producing multiple scan codes per repeat. It would be probably better to make it work with key codes instead of scan codes. > Right shift, left alt, ctrl and shift make 4 bits per repeat. Did you really test it? I bet they don't. > When I have a server where n blobk read, keyboard and mouse events occur > (everything is cached within huge amount of semiconductor RAM), the /dev/random > depends solely on the network packets. These can be manipulated and their > leading edge precisely sniffed. How precisely? Remember that at least on the ia32, you need to guess the timing down to one CPU clock cycle. > I think here exists a severe risk of compromise. Am I right? Even if you were able to predict all entropy sources, to predict the generated random numbers you would need to invert the cryptographic hash used there. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ You can't do that in horizontal mode! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BIOS problem, pro Microsoft, anti other OS
Hello! > This alert should probably be forwarded to Others, but appropriate > subTask persons in the kernel-source Maintainers list were not obvious. > > Briefly, documented below is the fact/complications that some PC BIOS > chips are now coming with a default Microsoft setting, which makes them > hostile to some functionalities of other OS. If particular under Linux, > a PCI Winmodem did NOT function with the Win98 BIOS setting, but did > fine with BIOS choice "Other OS". Possible, other PCI devices under > Linux OS might be simmilarly afflicated. > > This indicates a need for Linux install software to be equipped with a > utility to probe the BIOS and report back "Linux hostile" BIOS > settings. Today most Newbies are getting new PC boxes equipped with > WinModems. Hostile BIOS settings will block their capability to get > on-line. Unfortunately, I do not have the technical capablity to > directly contribute. Thus please forward this alert to however may be > capable and concerned with dealing with the problem. Can you check what does Linux 2.4.0-test behave, please? I know of these problems and I hope the new PCI code in 2.4.0 is able to assign the missing memory/IO resources without help of the BIOS, but unfortunately 2.2 isn't and it's very difficult to back-port the fixes as they depend on changes in many other parts of the kernel. You probably should make the ltmodem driver check the region base registers and interrupts and if they are not set, recommend the user to change the OS or PNP settings in their BIOS setup. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ First law of socio-genetics: Celibacy is not hereditary. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! > > It belongs in arch/ppc/kernel/*pci*.c > > > > This is precisely the kind of compat stuff which should be fixed up in > > the arch-specific PCI support code. > > Martin, cross-platform party on PCI stuff It seems you forget to call pci_enable_device() in the PCI IDE driver. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "In accord to UNIX philosophy, PERL gives you enough rope to hang yourself." -- Larry Wall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
Hi! > I recently had a problem with linux 2.2.x and 2.4.0 oopsing early > in the boot process on a old pentium I had gotten hold of. printk > investigation showed the problem to be in the PCI detection code, > specifically the part where linux tries to go through the BIOS to > get the PCI settings. Picking 'Direct' (CONFIG_PCI_GODIRECT) make > the boot succeed where 'Any' had not. > > This stumped me since the help text had led me to believe > otherwise: The help text states that if CONFIG_PCI_GOANY is set > linux will first try to detect the settings directly and go > through BIOS if this fails. The code first goes through BIOS to > get the settings, then gets them directly and then pick the > direct settings (if valid) otherwise the BIOS settings (if > valid). Some years ago, the PCI routines have really used this strategy (and the obsolete help text reflects this situation), but unfortunately, there exist machines where the direct access detection gives bogus results, so it's much better to ask the BIOS first. Also, it's conceptually cleaner to use a well-defined BIOS interface than to probe random ports (well, they are random on all non-PCI machines). These are the reasons why I'd prefer keeping the current code and just fixing the documentation. Also, you can easily make your machine boot by specifying "pci=conf1" at the kernel command line. I admit it isn't a nice solution, but I don't know any way which would be 100% reliable on all machines and your machine is the only case I know about where the current algorithm breaks. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Unexpected ';', expecting ';'." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI detection in 2.2.x and 2.4.0
Hi! > I have an odd situation.. in 2.4.x on my old P60, if I choose 'any', the > machine has ghost devices and all PCI cards stop working. If I choose > 'direct', it almost works. If I choose 'BIOS', it works correctly. By the way, does 2.2.x behave in the same way? > If you want an lspci from each various boot I can do so.. it is a strange > strange machine. I'm interested in lspci -vvx outputs for all the cases and also in effect of "pci=bios", "pci=conf1" and "pci=conf2" switches. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "They'll release Windows 96 when 95 finishes loading." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
Hello! > Well, not really in this situation, after a simple modification. It is > trivial to show that using "shorter interval sorted first" approach one > can bound an amount of an extra memory, on stack or otherwise, and by a > rather small number. By O(log N) which is in reality a small number :) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c - 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] PCI-Devices and ServerWorks chipset
Hello! > 0x44 is the primary bus number of the host bridge, and 0x45 is the > subordinate bus number for the bridge. Just like a PCI-PCI bridge, but > different :) Since there are two CNB30 functions, each has unique values > for this. The primary bus of the second bridge must be the subordinate bus > of the first bridge + 1. PRIMARY(1) = SUBORDINATE(0) + 1; Yes, this holds for the registers, but not for the actual bus numbers in the dump sent by Adam -- it shows primary busses 00 and 02, registers of function 0 say 00--00, of function 1 it's 01--06. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ New PC concept: "plug and pray" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] ServerWorks peer bus fix for 2.4.x
Hello!
> The ServerWorks peer bus problem is still present on the 2.4.1 kernel. The
> problem stems from the fact that there can be more than one secondary bus
> for a given north bridge. For example, the Compaq Proliant DL580 has two
> "root busses" coming off of a single north bridge. I'm including below an
> email from Adam Lackorzynski. In his email, he includes a patch that fixes
> the problem. I think Martin objected because he thought the patch got the
> meaning of the two config registers wrong, but it is, in fact, correct.
What leads you to your belief it's correct? The lspci dump Adam has sent
to the list shows that there's something utterly wrong with our understanding
of the ServerWorks config registers -- they seem to say that the primary
bus numbers are 00 and 01, but in reality they are 00 and 02.
For now, it will be better to comment out the whole ServerWorks fixup thing
and let the generic peer bus code do its magic work -- it's far better to rely
on BIOS and chipset to behave sanely (i.e., BIOS reporting last_bus not lower
than the real one and chipset not decoding out-of-range bus numbers) than on
guesses of register values which are probably wrong, at least until we have
some more examples for comparison.
Dan, can you send me outputs of 'lspci -MH1 -vvx' and 'lspci -vvxxx -s0:0'
and also try commenting out the lines
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_CMIC_HE, pci_fixup_serverworks },
in arch/i386/kernel/pci-pc.c, please?
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
This message transmited on 100% recycled electrons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] VIA IDE 4.0 and AMD IDE 2.0 with automatic PC
Hello! > Not the case, sorry. An IDE drive is needed. However, it still might be > worth to pass the PCI speed to other drivers ... But beware, the timing should be a per-bus value. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ The first myth of management is that it exists. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC][REPOST] __init_msg(x) and friends macro
Hi!
> Patch adds __init_msg (and friends) macro that places its argument
> (string constant) into corresponding .data.init section and returns
> pointer to it. The goal of this patch is to allow constructions like this:
>
> static void __init foo(void)
> {
> printk(__init_msg(KERN_INFO "Some random long message "
> "going to .data.init and then to bit bucket\n"));
> }
>
> I hope this patch can save some memory and will be usefull :))
I think it's better to teach GCC understanding another function attribute
defining the default section of all read-only data defined in the function.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
Even nostalgia isn't what it used to be.
-
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: multiple independent keyboard kernel support
Hello! > Btw, Aivils Stoss created a nice way to make several X instances have > separate keyboards - see the linux-console archives for the faketty > driver. I haven't looked recently, but when I tried that several years ago, the biggest problem was to make two simultaneously running X servers not switch off each other's video card I/O ports off :) All other things looked solvable with a reasonably small effort. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth There is no place like ~ - 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > Just make it so. The name is fine, the concept is unavoidable. The people > who complain are whiners that haven't ever had to deal with the fact that > there are broken machines around. I complain as well as the maintainer of the pciutils. Breaking all userspace accesses to extended configuration space just because there is a couple of chipsets which have MMCONFIG messed up is completely unacceptable. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "This quote has been selected randomly. Really." -- M. Ulrichs -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > it's not "just a couple of chipsets", it's actually > * a whole lot of bioses > * at least one whole CPU generation > * .. > * .. > > Do you really want to code all of that into your userspace access code as > well? No, I certainly don't. But I expect this to be handled reasonably in the kernel. If I understand the proposed patch correctly, it's only swepping the problem under the carpet -- if you have one of the malfunctioning systems and you happen to load a driver which wants to use the extended config space, it crashes anyway. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth It said, "Insert disk #3," but only two will fit! -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hi! > The fact is, 99% of the hardware you buy *today* has absolutely zero need > for extended PCI config access. In fact, I would not be surprised at all > if most hardware sold today generally doesn't have *any* devices that even > have config registers in the 0x100+ range. Most PCI Express bridges have root complex control block capabilities which have to reside in the extended range. However I agree that hardware _requiring_ extended config register access is rare. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > - During that probe, you set a flag if any device has capabilities that > extend beyond 0xff. Can this work? The extended capabilities are not linked to the normal ones in any way. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A bug in the code is worth two in the documentation. -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > (and yes I realize this needs lspci to be expanded some to set the > flag if the admin really asks for it, but such is life) Reading past the first 256 bytes of the sysfs file should be enough -- only root can do that (other users get only 64 bytes anyway) and problems with reading random registers have hopefully taught programs not to read blindly a long time ago. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Never make any mistaeks. -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
> Reading past the first 256 bytes of the sysfs file should be enough > -- only root can do that (other users get only 64 bytes anyway) and > problems with reading random registers have hopefully taught programs > not to read blindly a long time ago. ... except for lspci itself which reads the first few bytes of the extended space to see if there are any capabilities, which is generally safe, but it would always enable MMCONFIG. So an extra switch will be really needed. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The best way to accelerate Windows is at 9.8 m / sec^2 -- 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 1/1] PCI: Dynids - passing driver data
Hello! > >Which is a good thing, right? "driver_data" is usually a pointer to > >somewhere. Having userspace specify it would not be a good thing. > > That depends on the driver usage, and the patch allows it to be > configurable and defaults to not being used. Maybe we could just define the operation as cloning of an entry for another device ID, including its driver_data. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Only dead fish swim with the stream. - 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 3/2] drivers/char/vt.c: remove unnecessary code
Hello! > I agree :) . But, if we look to the code, we can notice that there is actually > no reason for npar to be unsigned. What do you think of this version? What does it try to solve? Your version is in no way better than the previous one. The previous one was more readable and it's quite possible that both will be compiled to the same sequence of instructions. Also, as Arjan noted, if you want to improve the code, use memset. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth American patent law: two monkeys, fourteen days. - 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: lspci != scanpci !?
Hello! > Now the scanpci command shows the M7101 BUT lspci and /proc/pci, > /proc/bus/pci, /sys/bus/pci NOT. What can I do? Is there anything like a > "update_pci" command? What does `lspci -vv -M' and `lspci -vv -M -H1' print? (Please Cc to me, I usually read LKML in large batches.) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Air conditioned environment -- Do not open Windows. - 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] API for true Random Number Generators to add entropy (2.6.11)
Hello! > We trust hardware, anyway. Like your disk *could* accidentaly turn on > setuid bit on /bin/bash, and we do not insist on userspace > disk-validator. But there is a very important difference: the most likely (both in theory and practice) failure of a disk is clearly visible, while failures of HW RNG's are likely to be silent (the data are just less random than they should be). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Top ten reasons to procrastinate: 1. - 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: pci-disable-decode-of-io-memory-during-bar-sizing.patch
Hello! > something like > int pci_enable_mmconfig(struct pci_dev *pdev) ? > sounds like a very solid plan to me... Please remember that the driver is not the sole user of the PCI config space -- user-space programs (e.g., lspci) can access it via sysfs, too. Should we force users of such programs to add a magic kernel parameter to enable MMCONFIG? Does not make much sense. Maybe we should do all bus scanning with conf1 and then try if MMCONFIG returns the same values? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K. - 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 5/5] x86: Set PCI config space size to extended for AMD Barcelona
Hi! > it's so very unfortunate the PCI standard has no feature bit to indicate > the presence of ECS. > > FWIW in my testing on a range of machines spanning 7 or 8 years i could > read config space reg 256... and get 0x when the device didn't > support ECS, and get valid data when the device did support ECS... granted > there may be some system out there which behaves really badly when you do > this. > > perhaps someone could write a userspace program and test that concept on a > far wider range of machines. If you want to experiment with this in user space, it's easy to write a couple of access functions for the libpci in pciutils. (Patches welcome, as usually :) ) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth God is real, unless declared integer. - 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] [467/2many] MAINTAINERS - SVGA HANDLING
Hello! > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index e0020d6..cde4be1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4440,6 +4440,9 @@ P: Martin Mares > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Maintained > +F: Documentation/svga.txt OK. > +F: drivers/video/svgalib.c > +F: include/linux/svga.h These two are not a part of the video mode selection code, but arch/i386/boot/video.S is. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Got mole problems? Call Avogadro, 602-1023! - 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] [467/2many] MAINTAINERS - SVGA HANDLING
> SVGA HANDLING > P:Martin Mares > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > S:Maintained > F:Documentation/svga.txt > F:arch/i386/boot/video.S Please also kill linux-video and replace it by linux-kernel. Not a single on-topic mail has arrived to linux-video in a couple of years and it seems that the list didn't survive update of the list server a week or so ago. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth War doesn't determine who's right. It determines who's left. - 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] [467/2many] MAINTAINERS - SVGA HANDLING
> Martin, do you still want to be CC'd on changes > to arch/i386/boot/vid* here? Yes, I would like to. Although HPA has rewritten the code to C, the logic remains. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth God is real, unless declared integer. - 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: Why are ipmi modules being loaded?
Hello! > Hmm, is lspci truncating the class code? > > > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active > Management) [8086:108e] (rev 03) > > Because this smells like an IPMI-ish device. Yes, it is a IPMI class code, only older versions of lspci know nothing about it, so they at least show the base class (Serial bus controller) and then add the complete class ID in square brackets. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "How I need a drink, alcoholic in nature, after the tough chapters involving quantum mechanics!" = \pi - 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: Understanding lspci output
Hello! > I ran lspci -vvv on a system: > http://linux.kernel.free.fr/halt/lspci.txt > > (I used lspci version 2.2.5 in case it matters.) > > But I'm having a hard time making sense of the output. > > 1. How many PCI buses are there in the system? Two, just see the bus numbers of the devices. (However, there might be additional buses with no devices present and in case these are connected to a separate host bridge, they need not be visible.) > 4. Does the system have a PCI-X bus? Yes, the devices on bus 01 are PCI-X devices, so there is a PCI-X bus. > 2. Do any of the PCI buses support 66 MHz operation? Yes, PCI-X does. > 3. Do any of the PCI slots support 64-bit data path? This cannot be inferred from the lspci output -- there is no way how to tell if a bus has physical slots or it exists only internally. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth hAS ANYONE SEEN MY cAPSLOCK KEY? - 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: pci-disable-decode-of-io-memory-during-bar-sizing.patch
Hello! > > Maybe we should do all bus scanning with conf1 and then try if > > MMCONFIG returns the same values? > > that is already in the code today but not nearly enough; there's a ton > of cases where it's "touch mmconfig and the box is dead"... Argh. However I still do not think it is an acceptable reason for breaking all userspace access to the extended config space. At the very least, there should be a sysfs toggle to enable MMCONFIG if root really wishes that (maybe for a particular device, as the drivers would do). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Do not believe in miracles -- rely on them. - 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] pci_bus conversion to struct device
Hello! > I recommend we just delete the pci_bus class. I don't think it serves > any useful purpose. The bridge can be inferred frmo the sysfs hierarchy > (not to mention lspci will tell you). The cpuaffinity file should be > moved from the bus to the device -- it really doesn't make any sense to > talk about which cpu a bus is affine to, only a device. It doesn't seem to serve any useful purpose other than the affinity now, but I still think that it conceptually belongs there, because it makes sense to have per-bus attributes. For example, in the future we could show data width and signalling speed. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay - 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] pci_bus conversion to struct device
Hello! > So, if it were to stay, where in the tree should it be? Hanging off of > the pci device that is the bridge? Or just placing these files within > the pci device directory itself, as it is the bridge. I originally didn't realize that we already represent devices on the subordinate bus as subdirectories of the bridge device's directory, without any extra level of abstraction. So it probably makes sense to put the bus-specific files there or, in case of a root bus, to /sys/devices/pci:YY/. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "It is only with the heart that one can see rightly; What is essential is invisible to the eye." -- The Little Prince - 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: Binary Drivers
Hello! > I disagree. The manufacturer has a right to choose to sell its devices > under any legal business model. Part of that model is deciding what > level of support to provide and what systems to support in selling it. At the very least, if they decide that they wish to provide a binary-only driver for i386, then their claims that they support Linux (without telling that they in fact support a single specific variant of Linux) are (a) blatant lie, and (b) false advertising. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth COBOL -- Compiles Only Because Of Luck - 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: Finding hardlinks
Hello! > High probability is all you have. Cosmic radiation hitting your > computer will more likly cause problems, than colliding 64bit inode > numbers ;) No. If you assign 64-bit inode numbers randomly, 2^32 of them are sufficient to generate a collision with probability around 50%. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A Bash poem: time for echo in canyon; do echo $echo $echo; done - 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: somebody dropped a (warning) bomb
Hello! > void* comparisons are unsigned. Period. As far as the C standard is concerned, there is no relationship between comparison on pointers and comparison of their values casted to uintptr_t. The address space needn't be linear and on some machines it isn't. So speaking about signedness of pointer comparisons doesn't make sense, except for concrete implementations. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Top ten reasons to procrastinate: 1. - 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: GPL vs non-GPL device drivers
Hello! > >I think you have a bit of a misunderstanding... Linux is not royalty > >free. Just the royalty is not in the form of cash, but in the form of > >having to give your improvements back to the open source world. > > Sure. But this is not legally binding. Maybe it's not, but it certainly doesn't mean that the kernel developers should try to make your life easier, especially if they believe that what you do is unethical. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This message is transmitted on 100% recycled electrons. - 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: GPL vs non-GPL device drivers
Hello! > Assuming these need not be GPL, I have a problem with > EXPORT_SYMBOL_GPL and the general trend in the direction of making > proprietary drivers harder on companies. Most kernel developers did always say they don't agree with proprietary drivers, don't want to support them and that they are convinced such drivers are illegal. And according to the language of the GPL and the copyright law, it's quite possible they really are illegal (although a court _might_ rule that the modules are not a derived work of the kernel). Even with all that, you still decided to distribute such modules. What you are complaining about? > So why beat about the bush? Just make it illegal to load proprietary > drivers, or remove EXPORT_SYMBOL_GPL. The point is that it's impossible to make it illegal (although many of the authors of the kernel would like to) -- the point is that if kernel modules aren't derivative works of the kernel, the kernel license cannot control them. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This mail doesn't contain viruses, because it wasn't sent from MS Windows. Checked by eyes. - 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: Finding hardlinks
Hello! > You mean POSIX compliance is impossible? So what? It is possible to > implement an approximation that is _at least_ as good as samefile(). > One really dumb way is to set st_ino to the 'struct inode' pointer for > example. That will sure as hell fit into 64bits and will give a > unique (alas not stable) identifier for each file. Opening two files, > doing fstat() on them and comparing st_ino will give exactly the same > guarantees as samefile(). Good, ... except that it doesn't work. AFAIK, POSIX mandates inodes to be unique until umount, not until inode cache expires :-) IOW, if you have such implementation of st_ino, you can emulate samefile() with it, but you cannot have it without violating POSIX. > 4 billion files, each with more than one link is pretty far fetched. Not on terabyte scale disk arrays, which are getting quite common these days. > And anyway, filesystems can take steps to prevent collisions, as they > do currently for 32bit st_ino, without serious difficulties > apparently. They currently do that usually by not supporting more than 4G files in a single FS. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Oh no, not again!" -- The bowl of petunias - 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: O_DIRECT question
Hello! > Maybe you need to say why you want to use O_DIRECT with its terrible > performance? Incidentally, I was writing an external-memory radix-sort some time ago and it turned out that writing to 256 files at once is much faster with O_DIRECT than through the page cache, very likely because the page cache is flushing pages in essentially random order. Tweaking VM parameters and block device queue size helped, but only a little. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Linux vs. Windows is a no-WIN situation. - 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: Entropy Pool Contents
Hello! > - Whether you automatically bump up the entropy estimate when > root users write to /dev/random is a design choice where you could > reasonably go either way. On the one hand, you might want to ensure > that root has to take some explicit action to allege that it is > providing a certain degree of entropy, and you might want to insist > that root tell /dev/random how much entropy it added (since root > knows best where the data came from and how much entropy it is likely > to contain). More importantly, it should be possible for root to write to /dev/random _without_ increasing the entropy count, for example when restoring random pool contents after reboot. In such cases you want the pool to contain at least some unpredictable data before real entropy arrives, so that /dev/urandom cannot be guessed, but you unless you remember the entropy counter as well, you should not add any entropy. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Q: How to start hacking Linux? A: vi /boot/vmlinuz - 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: Entropy Pool Contents
Hello! > After a reboot the entropy estimate starts at zero, so if you are adding > data to the pool from the previous boot, you DO want the estimate to > increase because you are, in fact, adding entropy. I'm adding entropy, but unless I record the exact amount of entropy when dumping the pool, I don't know how much I am adding, so using any fixed number is obviously wrong. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Object orientation is in the mind, not in the compiler." -- Alan Cox - 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: Entropy Pool Contents
Hello! > You aren't dumping and restoring the entropy pool; you are dumping > random data generated by the pool, and using that data to stir the new > entropy pool after the next boot. There is no direct relationship > between the entropy of the old and new pools. The kernel needs to > decide how much entropy you added based on how much random data you > provide it with to stir the pool. Yes, but the point is that you cannot tell how much randomness is in the data you provide. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Noli tangere fila metalica, ne in solum incasa quidem. - 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: Entropy Pool Contents
Hello! > I still don't see how feeding tons of zeros ( or some other carefully > crafted sequence ) in will not decrease the entropy of the pool ( even > if it does so in a way that is impossible to predict ), but assuming it > can't, what good does a non root user do by writing to random? Even if so, you should control that by filesystem permissions, not by in-kernel policy. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Man is the highest animal. Man does the classifying. - 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: Entropy Pool Contents
Hello! > That is exactly my point. Since you can not tell how much randomness is > in the data you provide, you can not tell the kernel how much to add to > its entropy estimate. Instead it just has to estimate based on the > amount of data you provide. No, the only safe thing the kernel can do is to add NO entropy, unless explicitly told otherwise. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "All that is necessary for the triumph of evil is that good men do nothing." -- E. Burke - 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: [x86 setup 27/33] Video mode probing support for the new x86 setup code
> Video mode probing for the new x86 setup code. This code breaks down > different drivers into modules. This code deliberately drops support > for a lot of the vendor-specific mode probing present in the assembly > version, since a lot of those probes have been found to be stale in > current versions of those chips -- frequently, support for those modes > have been dropped from recent video BIOSes due to space constraints, > but the video BIOS signatures are still the same. Acked-By: Martin Mares <[EMAIL PROTECTED]> Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "It's a lemon tree, my dear Watson." -- Sherlock Holmes (?) - 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: x86 setup rewrite tree ready for flamage^W review
Hello! > As far as I could tell, "scan" simply caused the nonstandard video > driver scan modules (unsafe probes) to be invoked. Since those modules > are no longer present, there appeared to be no need for them. The VGA > and VESA probes are safe. "scan" is still useful, because it is able to find BIOS video modes with non-standard numbers (they are still sometimes found on recent cards). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Entropy isn't what it used to be. - 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] vt: Do not clear UTF when resetting console
Hello! > Resetting the console, either by ANSI escape sequences or by the reset > utility, > will drop the console back to legacy (non-UTF-8) mode. Yes, and as far as I understand the logic behind these escape sequences, it's the intended behavior, not a bug. The escape sequence for terminal reset should reset as much as possible, I see no reason for making an exception for the UTF-8 mode. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Lottery -- a tax on people who can't do math. - 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] vt: Do not clear UTF when resetting console
Hello! > Does whatever defines what these escapes mean, have any comment to make > about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" > mode, the default that would be dropped to on a full reset, and if > anyone wanted to switch that out to non-default not-UTF-8 mode, they > could, but that a reset will always reenable it again..? Maybe it would be a little bit more convenient, but I doubt that such bit of convenience justifies breaking backward compatibility. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A computer without Windows is like a chocolate cake without mustard. - 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] vt: Do not clear UTF when resetting console
Hello! > Please note that I have dropped this patch in favor of this one: > > http://lkml.org/lkml/2007/4/2/422 Yes, this sounds very reasonable. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Ctrl and Alt keys stuck -- press Del to continue. - 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: arch/i386/boot rewrite, and all the hard-coded video cards
Hi! > I mean the SVGA chip-specific code. Feel free to kill it, anybody using these cards is very unlikely to run a 2.6.x kernel. However, the BIOS mode switching is still useful. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! - 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 v2] pci: export class IDs from pci_ids.h
Hello! > That's a good idea. Martin, could you please answer the following: > assuming that linux exported linux/pci_ids.h providing class > IDs that are currently in /usr/include/pci/header.h > in a header /usr/include/linux/pci_ids.h, > would libpci be open to replacing part of > /usr/include/pci/header.h with #include , > assuming that a solution for old systems that lack this > header is also provided? Please remember that libpci is cross-platform. Your proposal would make it use on Linux and provide its own definitions on all other systems, which is likely to bring less consistency, not more. I do not see any point in using kernel headers for things, which are unrelated to the kernel. > pciutils does nothing with this value itself, it's possible for a distro > to ship a wrong header, and no one will notice. OTOH Linux will break if > it's wrong. In fact there are 3 values libpci does appear to use > internally: > PCI_CLASS_BRIDGE_HOST > PCI_CLASS_DISPLAY_VGA > PCI_CLASS_BRIDGE_PCI > > I'm guessing others are re-exported for the benefit of > applications using libpci. Exactly. And I expect that it will be quite similar with the kernel -- most classes defined in are not likely to be used anywhere in the kernel. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support
Hi! > Ping? Sorry for the delay, I was alternatingly ill and overloaded with other stuff... As I said before, I do not like the current implementation of hwdb much (it's too much tied to Linux, and hardware description strings, originally intended for internal use between the kernel and its modules, are far from a nice API). I would prefer a more general HW identification library and I am willing to write it, but I have to admit that with my current load, it will be hardly finished before this summer. I will merge your patches. It's better to have the current hwdb than nothing. Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth First law of socio-genetics: Celibacy is not hereditary. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support
Hello and sorry for the delay,
> >> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ]
> >> ; then
> >> + HWDB=yes
> >> + else
> >> + HWDB=no
> >> + fi
> >
> > Does this make sense? Does every version of libudev support hwdb?
>
> Good point. I'll replace it with a pkg-config call, is that acceptable?
Sure.
> > As you wrote it, hwdb has always priority over pci.ids (unless local lookup
> > is
> > disabled). As a user, I would expect that pci.ids (being a part of the
> > pciutils)
> > is the primary source of data and other sources (network lookups, hwdb) are
> > used only if pci.ids do not match or if explicitly requested.
>
> Hm, this was actually intentional. The reason being that I'd like to
> avoid reading in the pci.ids db in the common case, as using the hwdb
> should be much more efficient (it is most likely already in memory and
> lookup is constant time), and also we (at the distro level) want to
> move away from the {usb,pci}.ids and rather default to hwdb
> everywhere.
>
> My original intention was to make hwdb a replacement for pci.ids, but
> I ended up going the less invasive route, would making it a
> replacement be more acceptable?
Before establishing priorities, I want to understand several things:
First of all, how is the hwdb populated? I really don't want lspci users
to be stuck with an obsolete list of PCI devices. Currently, the user
can easily run update-pciids to get a fresh copy of pci.ids, or to use
the DNS-based protocol to resolve unknown devices on the fly. Does hwdb
provide anything like that?
>From a brief examination of systemd-208, I understand that the PCI part
of the hwdb is generated by systemd maintainers calling ids-update.pl,
which not even a part of the systemd tarball. Is it expected that the only
way how to get a recent hwdb is to update systemd packages?
Also, did you consider the opposite, that is making hwdb call libpci
to resolve PCI IDs? What are the downsides?
Have a nice fortnight
--
Martin `MJ' Mares http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Make $$$ fast. Learn Perl!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support
Hello Kay, > Libpci and its linear search through megabytes of text files for evey > new query is too inefficient, that we cannot afford to use it during > early bootup. It was the largest hit left in bootup profiling on > machines booting userspace in the sub-1-second range on common > machines. It was probably never meant to provide efficient queries, > but it's the reason we can never use it during early boot. I do not know what you are speaking about -- libpci definitely does not perform linear scans on pci.ids. It builds a hash table from pci.ids on the first query and and all subsequent queries are O(1) on average. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support
Hello! > It does that per process doing that, and that's the problem for how > udev works/worked. The binary hwdb is on-disk and can be mmaped, and > there is no difference between initialization, first, or subsequent > queries. OK, point taken. I see that a mechanism for fast lookup of hardware identification data is needed. However, why should such a mechanism depend on udev, systemd, or Linux in general? What I would really like to have is a universal library for HW lookup, independent of anything else and widely portable. All the hardware data would be provided by other packages -- pci.ids, usb.ids, kernel modules, etc. -- and compiled to a binary format available for instant queries. Do I miss anything? Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A half-joke: What is the difference between a cat? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)
Hi Tom! The support for hwdb has finally landed in mainline pciutils. I have modified your patch to bring it closer to the rest of device naming logic. Namely: • The interface to HWDB now lives in a separate source file lib/names-hwdb.c. It is called from the main entry point to the name resolver (lib/names.c). • Resolved names are cached in the hash table and they participate in the system of priorities. They have lower priority than pci.ids, but higher than remote lookups via DNS. (Therefore if a distro decides not to ship pci.ids, hwdb is used exclusively for all local lookups.) • There is a flag to suppress the use of HWDB (PCI_LOOKUP_NO_HWDB) and also a configuration parameter for the same (hwdb.disable). Aside of the README, everything should be ready for a public release. Could you please verify that it still works for you? Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Uncle Ed's Rule of Thumb: Never use your thumb for a rule. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 7/7] pciutils: Allow 32-bit domains
Hello!
> PCI-e segments will continue to use the lower 16 bits as required by
> ACPI. Special domains may use the full 32-bits.
>
> Signed-off-by: Keith Busch
> ---
> lib/filter.c |2 +-
> lib/pci.h|2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/filter.c b/lib/filter.c
> index d4254a0..075dc2f 100644
> --- a/lib/filter.c
> +++ b/lib/filter.c
> @@ -45,7 +45,7 @@ pci_filter_parse_slot_v33(struct pci_filter *f, char *str)
> if (str[0] && strcmp(str, "*"))
> {
> long int x = strtol(str, &e, 16);
> - if ((e && *e) || (x < 0 || x > 0x))
> + if ((e && *e) || (x < 0))
> return "Invalid domain number";
> f->domain = x;
> }
> diff --git a/lib/pci.h b/lib/pci.h
> index 10ba831..7e42765 100644
> --- a/lib/pci.h
> +++ b/lib/pci.h
> @@ -119,7 +119,7 @@ struct pci_param *pci_walk_params(struct pci_access *acc,
> struct pci_param *prev
>
> struct pci_dev {
>struct pci_dev *next; /* Next device in the chain */
> - u16 domain;/* PCI domain (host bridge) */
> + int32_t domain;/* PCI domain (host bridge) */
>u8 bus, dev, func; /* Bus inside domain, device and
> function */
This is definitely not enough. Try grepping the source for "domain" :-)
At least the following places need updating, too:
o struct pci_filter and operations on it
o Format strings for printing domains at various places
o ABI compability ... changing a field in the middle of struct pci_dev
(or pci_filter) is going to break ABI, so you either need to change the
structures in a backward-compatible way, or to use ABI versioning.
Also, we should decide on what type the domain should have -- currently, some
places use "int", others use u16, and your patch introduces int32_t. I would
prefer u32 myself, but especially in the filters we should be careful about
how to encode "any domain".
Have a nice new year
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/29] svga.txt: standardize document format
> diff --git a/Documentation/svga.txt b/Documentation/svga.txt > index cd66ec836e4f..119f1515b1ac 100644 > --- a/Documentation/svga.txt > +++ b/Documentation/svga.txt > @@ -1,24 +1,31 @@ Acked-By: Martin Mares Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Press any key to quit or any other key to continue
Re: [PATCH] documentation/svga.txt: update outdated file
Hi! > From: Randy Dunlap > > Drop CONFIG_VIDEO_400_HACK info completely. > Drop CONFIG_VIDEO_RETAIN and CONFIG_VIDEO_LOCAL completely. > Drop CONFIG_VIDEO_COMPACT and CONFIG_VIDEO_VESA info completely. > Drop CONFIG_VIDEO_SVGA info since it has been removed. > Drop chapter number & section number references since they are wrong. > Drop (bad) ftp URL for 800x600 Thinkpad XF86Config. > > Rename CONFIG_VIDEO_GFX_HACK to VIDEO_GFX_HACK since it is not a > Kconfig symbol. And to match the source code. > > Build options are controlled by the kernel kconfig utility. > > Signed-off-by: Randy Dunlap Acked-By: Martin Mares Martin
