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
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-pre1 seems
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
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 does not
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
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 cards to
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 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
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
the
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
On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote:
#Include hallo.h
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-device 2 0
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 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(_lock,
>flags)
> > #define
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_DRIVER(flags)
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
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 same time
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
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 system
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:
[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
the last
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 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
>
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
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
>
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
another
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 warning. If
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
>
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
enabled
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
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
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
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
On Sat, 7 Apr 2001, Michael Reinelt wrote:
Brian Gerst wrote:
Grard 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
both serial and parallel ports, it will be driven by two subsystems, the
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
more than
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 generally be
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
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
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) with a
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 21 80
On Fri, 6 Apr 2001, Grard 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 +175,9 @@
#define
}
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 assum
Hello,
The patch I sent you yesterday has a typo that can lead to serious
breakage. This has been pointed out by Michal Jaegermann. Thanks, Michal.
(k must be compared against -1 and not against 1)
You want to apply this new tiny patch instead and let me know if it fixes:
--- sym53c8xx.c.0402
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
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 to
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
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
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.
>
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
Hello,
You sent me by private e-mail, the /proc/pci information of your system.
I donnot see anything wrong in these data. If the problem is PCI-related,
you would probably have better help by sending these infos to the l-k
list, in my opinion.
To be honest (I may be wrong here - sorry if I
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,
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 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 extender 8)
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=0x3000,
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 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 each to
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 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 NO!
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 --
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
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 drivers using those dma handles.
On Fri, 9 Mar 2001, David Brownell wrote:
Grard --
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 -- used as a
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
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 why I was
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
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
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
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. :-)
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. :-)
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, Manfred Spraul wrote:
Grard 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 mask is set we could simply do:
-
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
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
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 find out
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
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
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
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 of my
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
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 display
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
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 to
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:
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:
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
> >
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
this occur in
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
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 Linus
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
1 - 100 of 148 matches
Mail list logo
