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 o
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).
>
> S
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
>
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 t
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
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/inse
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 cou
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 s
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 li
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 de
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 ha
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->sl
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 --
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]
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
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
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 Li
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
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
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 t
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
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 concept
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
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
>
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
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 listen
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?
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 unload
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)
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
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
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.
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
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 the
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.
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 setting
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 fro
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 numb
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 subordina
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 in
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
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(_
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
n
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 c
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 t
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
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 <[E
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 rando
> 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 fir
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
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 po
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.)
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 failure
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
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
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 Mar
> 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 li
> 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
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
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. (
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 ac
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
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
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
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%.
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 po
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 d
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
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
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 th
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
> p
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
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
> decid
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?
Eve
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
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 ni
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
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 re
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
>
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
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 PROTEC
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/pc
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 modu
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.
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.
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
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
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/filte
> 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
--
Ma
kconfig utility.
>
> Signed-off-by: Randy Dunlap
Acked-By: Martin Mares
Martin
90 matches
Mail list logo
