On Fri, 20 Jul 2001, Geert Uytterhoeven wrote:
> On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> > New findings:
> > - The problem doesn't happen with kernels <= 2.2.17. It does happen with all
> > kernels starting with 2.2.18-pre1.
> > - The only related stuff that changed in 2.2.18-pr
On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> On Thu, 21 Jun 2001, Geert Uytterhoeven wrote:
> > On Tue, 8 May 2001, Geert Uytterhoeven wrote:
> > > In the mean time I down/upgraded to 2.2.17 on my PPC box (CHRP LongTrail,
> > > Sym53c875, HP C5136A DDS1) and I can confirm that the problem d
On Wed, 27 Jun 2001, Jeff Garzik wrote:
> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers... It's quite reasonable for two different scsi ca
On Fri, 15 Jun 2001, Mike Black wrote:
> This is a very common misconception -- I worked a contract many years ago
> where I actually had to quote the author of TCP to convince a banking
> company I was working with that TCP is not a guaranteed protocol.
> Guaranteed delivery at layer 5 - yes -
On Sun, 3 Jun 2001, Adrian Cox wrote:
> Marc Lehmann wrote:
>
>
> > Aren't PCI delayed transaction supposed to be handled by the pci master
> > (e.g. my northbridge), not by the (software) driver for my pdc(?) I would
> > also be surprised if my pdc actually used that feature, not to speak of
On Thu, 31 May 2001, Tim Hockin wrote:
> All,
>
> Attached is a patch for sym53c8xx.c to handle the error timer better, and
> be more proper for SMP. The changes are very simple, and have been beaten
> on by us. Please let me know if there are any problems accepting this
> patch for general
On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote:
> #Include
>
>
>
> I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds
> the first one (1 0 5 0), the other two i have to add with
>
> echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi
> echo "scsi add-single-devi
On Fri, 1 Jun 2001, Jeff Garzik wrote:
> Tim Hockin wrote:
> > spinlock_t sym53c8xx_lock = SPIN_LOCK_UNLOCKED;
> > +spinlock_t sym53c8xx_host_lock = SPIN_LOCK_UNLOCKED;
> > #defineNCR_LOCK_DRIVER(flags) spin_lock_irqsave(&sym53c8xx_lock,
>flags)
> > #defineNCR_UNLOCK_DRI
On Sun, 20 May 2001, Ivan Kokshaysky wrote:
> On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote:
> > I was only talking about when you get the "pci_map_sg failed" because
> > you have not 3 but 300 scsi disks connected to your system and you are
> > writing to all them at the sam
On Tue, 8 May 2001, Dan Hollis wrote:
> On Tue, 8 May 2001, Larry McVoy wrote:
> > which is a text version of the paper I mentioned before. The basic
> > message of the paper is that it really doesn't help much to have things
> > like ECC unless you can be sure that 100% of the rest of your sy
On Sun, 29 Apr 2001, Steffen Persvold wrote:
> [EMAIL PROTECTED] wrote:
> > On Sun, 29 Apr 2001, Steffen Persvold wrote:
> >
> > > I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a
> > > Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on
> >
On Sun, 29 Apr 2001, Steffen Persvold wrote:
> Hi all,
>
> I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
> Whenever I try to add a write-combining region, it gets rejected. I took a peek
> in the arch/i386/kernel/mtrr.c and found that this is just as expected with
>
On Tue, 24 Apr 2001, Hamilton, Eamonn wrote:
> Hi Folks.
>
> Under all of the kernels I have access to try ( 2.2.19, 2.4.X & 2.4.X-ac* ),
> when I try and write an image in XA2 format to my SCSI writer ( Yamaha
> CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the
> beta
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:
> hi,
>
> when trying to scan with xsane and "agfa snapscan 1236s", i get the
> following message:
>
> Attached scsi generic sg2 at scsi0, channel 0, id 5, lun 0, type 6
> sym53c895-0-<5,*>: target did not report SYNC.
This message is just a warni
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:
> Still experimenting with my SDT-9000... tried connecting it to another
> controller
> (2940AU in place of 2904, sorry but I've only Adaptec stuff :). Same
> problem.
> Tried with another tape (even with an old DDS-2 tape). Same. Even tried
> anothe
On Mon, 9 Apr 2001, Jim Studt wrote:
> G*rard Roudier insightfully opined..
> > Looks like an IRQ problem to me.
> > I mean the kernel wants to change IRQ routing and just do the wrong job.
>
> Give the man a prize!
>
> After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I
> enabl
Looks like an IRQ problem to me.
I mean the kernel wants to change IRQ routing and just do the wrong job.
Ingo reported me a similar problem a couple of week ago that made failed
the sym53c8xx driver. Looks very similar to this one with the kernel PCI
code wanting to assign IRQ 11 to almost ever
On Sat, 7 Apr 2001, Tim Waugh wrote:
> On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
>
> > Please apply this little patch instead of wasting time by
> > finger-pointing and arguing.
>
> This patch would make me happy.
>
> It would allow support for new multi-IO cards to gene
On Sat, 7 Apr 2001, Michael Reinelt wrote:
> Tim Waugh wrote:
> >
> > On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> >
> > > Adding PCI entries to both serial.c and parport_pc.c was that easy
> >
> > And that's how it should be, IMHO. There needs to be provision for
On Sat, 7 Apr 2001, Michael Reinelt wrote:
> Brian Gerst wrote:
> >
> > Gérard Roudier wrote:
> > >
> > > On Sat, 7 Apr 2001, Michael Reinelt wrote:
> > >
> > > > The card shows up on the PCI bus as one device. For the card provides
> &
On Sat, 7 Apr 2001, Michael Reinelt wrote:
> Hi there,
>
> I've got a problem with my communication card: It's a PCI card with a
> NetMos chip, and it provides two serial and one parallel port. It's not
> officially supported by the linux kernel, so I wrote my own patch and
> sent it to the pa
On Fri, 6 Apr 2001, Gérard Roudier wrote:
> Here is a patch that removes the offending PPC PCI hacky area from the
> driver (sym53c8xx_defs.h):
>
> --- sym53c8xx_defs.h Fri Apr 6 16:23:48 2001
> +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001
> @@ -175,6 +1
On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:
>
> BTW, my 2.4.3-pre8 kernel just said
>
> | sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
Illegal instruction detected.
> | sym53c875-0: script cmd = 1100
> | sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 2
On Fri, 6 Apr 2001, Stefano Coluccini wrote:
> > I'm still waiting for other reports of st/sym53c8xx on PPC under
> > 2.4.x. BTW,
> > does it work on other big-endian platforms, like sparc?
>
> I don't know if it is the same problem, but ...
> I have a Motorola MVME5100 (PowerPC 750 based CPU)
}
break;
/*
- Cut Here -
Gérard.
On Mon, 2 Apr 2001, Gérard Roudier wrote:
>
>
> On Sat, 31 Mar 2001, Christian Kurz wrote:
>
> > Hi,
> >
> > I'm currently running 2.4.2-ac28 and today I got a failing
On Sat, 31 Mar 2001, Christian Kurz wrote:
> Hi,
>
> I'm currently running 2.4.2-ac28 and today I got a failing assumption in
> sym53c8xx.c. I'm not sure about the exact steps that I did to produce
> this error, but it must have been something like: cdparanoia -blank=all,
> then sending Ctrl+C
On Thu, 29 Mar 2001, Butter, Frank wrote:
> 2.2.16 claimes to find a ncr53c1510D-chipset, supported by
> the driver ncr53c8xx. Which kernel-param would be the correct one for this?
There is no specific kernel option apart configuring the NCR53C8XX and/or
the SYM53C8XX driver. (And not the 53c7
On Sun, 25 Mar 2001, LA Walsh wrote:
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx
me root=/dev/sda5 ro
Just replace the lilo_config_entry_name and the root partition name by the
values that match your configuration.
Gérard.
On Sat, 24 Mar 2001, Gérard Roudier wrote:
> On Sat, 24 Mar 2001, LA Walsh wrote:
>
> > I have a machine with 3 of these controllers (a 4
On Sat, 24 Mar 2001, LA Walsh wrote:
> I have a machine with 3 of these controllers (a 4 CPU server). The
> 3 controllers are:
> ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58
> ncr53c810a-0: ID 7, Fast-10, Parity Checking
> ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x30
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> > Btw, 'decade' comes from Latin 'deca'=10 and dies=days
>
> No. It is from the Greek dekas, dekados (group of ten).
All my french dictionnaries agree with you. Thanks for the fix. :-)
> > Could it be due to the word 'decadent'
>
> Unrelated. (
On Fri, 23 Mar 2001, Stephen E. Clark wrote:
> Alan Cox wrote:
> >
> > > You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
> > > Machine)
> >
> > The JVM doesnt actually. The JVM will itself spontaenously explode in real
> > life when out of memory. Maybe the JVM on a DOS
On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > Is the corruption reproducible? If so, does the corruption go away if
> >
> > Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB
On Sun, 11 Mar 2001, John William wrote:
> If shared, edge triggered interrupts are ok then I will talk to the driver
> maintainers about the problem. If this isn't ok, then maybe the sanity check
> in pci-irq.c would be to force level triggering only on shared PCI
> interrupts?
DEFINITELY
On Fri, 9 Mar 2001, David Brownell wrote:
> Gérard --
>
> > Just for information to people that want to complexify the
> > pci_alloc_consistent() interface thats looks simple and elegant to me:
>
> I certainly didn't propose that! Just a layer on top of the
> pci_alloc_consistent code -- use
On Fri, 9 Mar 2001, David Brownell wrote:
> > > > > extern void *
> > > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > > >
> > > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > > yet.
> > >
> > > Some hardware (like OHCI) talks to driver
On Mon, 19 Feb 2001, Peter Samuelson wrote:
> [Justin Gibbs]
> > I've verified the driver's functionality on 25 different cards thus
> > far covering the full range of chips from aic7770->aic7899.
>
> That's very good to hear. I know the temptation of only testing on new
> hardware; that's wh
On Tue, 13 Feb 2001, Ion Badulescu wrote:
> On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]>
>wrote:
> > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
> >
> >> On 12 Feb 2001, Jes Sorensen wrote:
> >>> In fact one has to look out for t
Updated drivers for SYMBIOS 53C[8XX|1010] chips are available from
the ftp.tux.org site.
sym53c8xx-1.7.3-pre1 + ncr53c8xx-3.4.3-pre1
---
URL (entered by hand):
ftp.tux.org://roudier/drivers/linux/stable/sym-1.7.3-ncr-3.4.3-pre1.tar.gz
sym-2.1.6
-
On Fri, 9 Feb 2001, Alan Cox wrote:
> > > For non routing paths its virtually free because the DMA forced the lines
> > > from cache anyway.
> >
> > Are you actually sure about this? I thought DMA from PCI devices reached
> > the main memory without polluting the L2 cache. Otherwise any larg
You missed the newer statements about every piece of hardware being
assumed to be hot-pluggable and all the hardware being under full control
by CPU.
You also missed the well known point that only device drivers are broken
under Linux and that all the generic O/S code is just perfect. :-)
Gér
On Fri, 2 Feb 2001, Manfred Spraul wrote:
> Gérard Roudier wrote:
> >
> > So, why not using a pure software flag in memory and only tampering the
> > things if the offending interrupt is actually delivered ? If the given
> > interrupt is delivered and the software
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2001, Andrew Morton wrote:
> +/*
> + * It appears there is an erratum which affects at least the 82093AA
> + * I/O APIC. If a level-triggered interrupt input is being masked in
> + * the redirection entry while the interrupt is send
On Wed, 31 Jan 2001, Alan Cox wrote:
> > If the pci_enable_device() thing is to be added to the drivers, it must
> > preferently be placed after the checking against RAID attachement.
>
> You cant check the signature until the device has been enabled. Maybe you
> could poke the LSI guys and fi
You missed that SYMBIOS devices can be attached by RAID firmware and,
that, in such situation, the kernel should avoid tampering the SYMBIOS
device. The [ncr|sym]53c8xx drivers are aware of that, and donnot attach
SYMBIOS devices owned by RAID.
If the pci_enable_device() thing is to be added to
On Thu, 25 Jan 2001, Rasmus Andersen wrote:
> Hi.
>
> I apparently forgot to cc the lists on this one. Replies should be cc'ed
> to [EMAIL PROTECTED] also.
>
> Thanks.
The change should not harm, but request_region() is very unlikely to fail
here. Reason is that the drivers previously perfor
On Sun, 28 Jan 2001, paradox3 wrote:
> I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM
> 10 GB SCSI drive
> (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The
> SCSI drive
> performs the worst. In tests of writing 100 MB and sync'ing, one o
On Fri, 19 Jan 2001, Bob Frey wrote:
> On Thu, Jan 18, 2001 at 11:24:54PM +, Stephen Kitchener wrote:
> > The only thing that might be odd is that the scanner's scsi card and the
> > display card are using the same IRQ, but I thought that IRQ sharing was ok in
> > the new kernels. The dis
On Thu, 11 Jan 2001, Boszormenyi Zoltan wrote:
> Hi!
>
> I just wanted to let you know that I successfully ruined
> a CD with 2.4.0 + sym-2.1.0-20001230. The system is a RH 7.0
> with glibc-2.2-9, cdrecord-1.9.
Thanks for the report.
But with so tiny information, it gives about no usefulness
I just released sym-2.1.0 driver, that, according to my personnal QA
plan :-), is the first Beta-release of this major driver version.
People interested in either using or just trying it can found the
reference tarball at the following URL:
ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/
On Wed, 13 Dec 2000, Justin T. Gibbs wrote:
> > Date: Wed, 13 Dec 2000 20:56:08 -0700
> > From: "Justin T. Gibbs" <[EMAIL PROTECTED]>
> >
> > None-the-less, it seems to me that spamming the kernel namespace
> > with "current" in at least the way that the 2.2 kernels do (does
> > t
On Wed, 13 Dec 2000, Linus Torvalds wrote:
>
>
> Ehh, I think I found it.
>
> Hint: "ptep_mkdirty()".
>
> Oops.
>
> I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that
Poor European Gérard as slim as 1.84 meter - 78 Kg these days.
What about old days poor European L
On Tue, 12 Dec 2000, David S. Miller wrote:
>Date: Tue, 12 Dec 2000 20:17:21 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>On Mon, 11 Dec 2000, David S. Miller wrote:
>
>> Tell me one valid use of this information first :-)
>
>
On Mon, 11 Dec 2000, David S. Miller wrote:
>Date: Mon, 11 Dec 2000 23:07:01 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>So, if you want to fix this insane PCI interface:
>
>1) Provide the _actual_ BARs values in the pci dev structure, ot
On Tue, 12 Dec 2000, Martin Mares wrote:
> 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
> > t
On Mon, 11 Dec 2000, David S. Miller wrote:
>Date: Mon, 11 Dec 2000 22:30:59 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>On Mon, 11 Dec 2000, David S. Miller wrote:
>
>> Really, in 2.4.x sparc64 requires PCI config space hacker
On Mon, 11 Dec 2000, David S. Miller wrote:
>Date: Mon, 11 Dec 2000 21:49:52 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>If now, the PCI stuff is claimed to be cleaned up, then _all_ the
>hacks have to be removed definitely. As a re
On Mon, 11 Dec 2000, Martin Mares wrote:
> 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, the
On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote:
> On Mon, 11 Dec 2000, Jamie Lokier wrote:
>
> > Here are a few more:
> >
> > net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
>
> Acenic is at least setting it to the correct values, not hardcoding it.
>
> > net/gmac.c: PCI_C
On Mon, 11 Dec 2000, Jamie Lokier wrote:
> Here are a few more:
>
> net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
> net/gmac.c: PCI_CACHE_LINE_SIZE, 8);
> scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n",
For this one, this happens on
On Sat, 9 Dec 2000, Alan Cox wrote:
> > If/When x86 (or all?) architectures use this, will it make sense to
> > remove the PCI space cache line setting from drivers ?
> > Or is there borked hardware out there that require drivers to say
> > "This cacheline size must be xxx bytes, anything else
On Sat, 9 Dec 2000, Abramo Bagnara wrote:
> Gérard Roudier wrote:
> >
> >
> > Based on that, let me claim that most of blind barriers inserted this way
> > are useless (thus sob-optimal) and may band-aid useful barriers that are
> > missing. The result is sub
On Sat, 9 Dec 2000, Abramo Bagnara wrote:
>
> Here you are two patches:
>
> alpha-mb-2.2.diff add the missing mb() to the cores that still lack it
> (against 2.2.18pre25)
>
> alpha-mb-2.4.diff add missing defines from core_t2.h for non generic
> kernel (against 2.4.0test11)
>
> Please apply
On Tue, 21 Nov 2000, David Riley wrote:
> Horst von Brand wrote:
> >
> > So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even
> > end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no
> > trouble for years. Not the only case of WinXX running (apparent
On Sat, 11 Nov 2000, Ivan Kokshaysky wrote:
> On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
> > I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
> > still exist bridges that have been designed prior to spec. 1.1.
>
> Yes, DEC 2105x bridges, for example
On Fri, 10 Nov 2000, Ivan Kokshaysky wrote:
> On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
> > Hmmm...
> > The PCI spec. says that Limit registers define the top addresses
> > _inclusive_.
>
> Correct.
>
> > The spec. does not seem to imagine that a Limit register lower tha
On Thu, 9 Nov 2000, Ivan Kokshaysky wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my opinion. :-)
This let me think t
On Wed, 8 Nov 2000 [EMAIL PROTECTED] wrote:
> I looked at the IO-mapping.txt file. It says that
> on x86 architecture it should not make any difference.
> It also says that "on x86 it _is_ the same memory space. So
> on x86 it actually works to just dereference a pointer".
For bus_to_virt() to
On Sat, 14 Oct 2000, Torben Mathiasen wrote:
> On Sat, Oct 14 2000, David S. Miller wrote:
> >Date: Sat, 14 Oct 2000 11:43:09 +0200
> >From: Torben Mathiasen <[EMAIL PROTECTED]>
> >
> >David, why is tpnt->proc_name NULL on sparc for devices not
> >existing? Every driver has th
On Wed, 11 Oct 2000, Mike A. Harris wrote:
> On 10 Oct 2000, Gnea wrote:
>
> >> Please add this to your list. Linux is unusable in these machines.
> >> I have cc'ed Martin and Linus because they play in that PCI area.
> >
> >erm, looking at your list it says that you're using Redhat 7.0, whi
810A
Your problem doesn't look like an SCSI transport error to me. Any SCSI
controller will probably not give better result.
Your device does not like some SCSI command and returns CHECK CONDITION
status, then returns SENSE DATA that are passed to the application
client.
> CDB: 52 01 00
On Thu, 28 Sep 2000, Peter Samuelson wrote:
> [Peter Samuelson]
> > > But it really bugs me when someone uses the term 'Linux 6.2' (:
> > > I could not resist pointing out the distinction.
>
> [Gérard Roudier]
> > You seem to do the same confu
On Thu, 28 Sep 2000, Peter Samuelson wrote:
> [Peter Samuelson]
> > > There is no Linux 6.2. The newest version is a prerelease of 2.4.0.
>
> [Igmar Palsenberg <[EMAIL PROTECTED]>]
> > I'll bet you a beer he's using RedHat :)
A german beer ? ;-)
> Yes, yes. You know he's using Red Hat and
On Fri, 22 Sep 2000, Jamie Lokier wrote:
> Michel Lanners wrote:
> > >> static inline int pci_enable_device(struct pci_device *dev)
> > >> {
> > >> return pci_enable_device_features(USE_IO|USE_MM);
> > >> }
> > (snip)
> > > And what about other features ?
> > > I mean:
> > > - Bus Master
> > >
On Mon, 18 Sep 2000, Alan Cox wrote:
> > All I wanted was a function that allows the driver to decide that which
> > needs to be enabled.
> >
> > pci_enable_device(struct pci_dev *dev, byte enable_mask)
> >
> > This would allow drivers to enable that which it needs and not weird out
> > the h
On Sun, 17 Sep 2000, Rik van Riel wrote:
> On 17 Sep 2000, Peter Osterlund wrote:
> > Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> >
> > > While the queue is plugged or with things like SCSI your logic
> > > change won't work because in such case if your request is lower the
> > > lowest in
On Fri, 15 Sep 2000, Richard B. Johnson wrote:
> On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote:
>
> >
> >
> > On Fri, 15 Sep 2000, Linus Torvalds wrote:
> >
> > > On Fri, 15 Sep 2000, Gérard Roudier wrote:
> > > >
>
[
On Fri, 15 Sep 2000, Linus Torvalds wrote:
> On Fri, 15 Sep 2000, Gérard Roudier wrote:
> >
> > > Just as an example: imagine that the IO windows haven't been set up
> > > correctly. If the low-level driver just blindly enables IO cycles by
> > >
On Fri, 15 Sep 2000, Linus Torvalds wrote:
> On Fri, 15 Sep 2000, Richard B. Johnson wrote:
> >
> > The PCI Specification states, in part, that either the BIOS or the
> > driver has to enable the device. So, many drivers find that the device
> > has not been enabled. This is normal and necessa
79 matches
Mail list logo
