* FYI: issue resolved in -dj
From: Joshua Kwan @ 2003-01-08 5:08 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
just fyi (orig by me):
> 1. [linux-dj] (i think?) after pulling linux-dj i noticed that the
> references to 'font.h' in drivers/video/console were broken. They were
> like#include "font.h" - I have fixed this to refer to the right font.h
> (#include <linux/font.h>)...
Fixed! :D
http://linux-dj.bkbits.net:8080/linux-2.5/cset@1.859?nav=index.html|ChangeSet@-1d
Regards
Josh
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Gerhard Mack @ 2003-01-08 5:01 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Richard B. Johnson, Max Valdez, Jan Hudec, kernel
In-Reply-To: <20030107115544.W31555@schatzie.adilger.int>
On Tue, 7 Jan 2003, Andreas Dilger wrote:
> Date: Tue, 7 Jan 2003 11:55:44 -0700
> From: Andreas Dilger <adilger@clusterfs.com>
> To: Richard B. Johnson <root@chaos.analogic.com>
> Cc: Max Valdez <maxvaldez@yahoo.com>, Jan Hudec <bulb@ucw.cz>,
> kernel <linux-kernel@vger.kernel.org>
> Subject: Re: Undelete files on ext3 ??
>
> On Jan 07, 2003 13:17 -0500, Richard B. Johnson wrote:
> > Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> > file-systems. Somebody should then modify `rm` and the kernel unlink
> > to `mv' files to the dumpster directory on the file-system, instead of
> > really deleting them. Then, just like the Redmond stuff, a separate
> > program can be used to clear out the "dumpster" or `mv` them back.
>
> This is very FAQ. Please see the l-k archives for any year to find
> lengthy discussions about this.
>
Funny my gnome2 install has a wastebasket and last I checked if you open a
command shell in windows and del *.* you are screwed anyhow.
So we have exactly the same functionality windows does.
Gerhard
--
Gerhard Mack
gmack@innerfire.net
<>< As a computer I find your faith in technology amusing.
^ permalink raw reply
* sym53c8xx(2) problems on PPC
From: Ethan Weinstein @ 2003-01-08 4:52 UTC (permalink / raw)
To: linux-scsi
Greetings.
We recently changed out this card (32-bit card, one channel):
10:14.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c895
(rev 02)
Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 1020
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (7500ns min, 16000ns max), cache line size 08
Interrupt: pin A routed to IRQ 54
Region 0: I/O ports at 0400 [size=256]
Region 1: Memory at 80081000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at 80084000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 800c0000 [disabled] [size=128K]
sym.16.20.0: setting PCI_COMMAND_PARITY...
sym0: <895> rev 0x2 on pci bus 16 device 20 function 0 irq 54
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi2 : sym-2.1.17a
For this one (64-bit PCI card, with 2 channels)
10:14.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR)
53c1010 Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 1030
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (4250ns min, 4500ns max), cache line size 08
Interrupt: pin A routed to IRQ 54
Region 0: I/O ports at 0800 [size=256]
Region 1: Memory at 80082000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 8008a000 (64-bit, non-prefetchable) [size=8K]
Expansion ROM at 800e0000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
10:14.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR)
53c1010 Ultra3 SCSI Adapter (rev 01)
Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 1030
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr+ DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 16 (4250ns min, 4500ns max), cache line size 08
Interrupt: pin B routed to IRQ 54
Region 0: I/O ports at 0400 [size=256]
Region 1: Memory at 80081000 (64-bit, non-prefetchable) [size=1K]
Region 3: Memory at 80088000 (64-bit, non-prefetchable) [size=8K]
Expansion ROM at 800c0000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
sym.16.20.0: setting PCI_COMMAND_PARITY...
sym.16.20.1: setting PCI_COMMAND_PARITY...
sym0: <1010-33> rev 0x1 on pci bus 16 device 20 function 0 irq 54
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
sym1: <1010-33> rev 0x1 on pci bus 16 device 20 function 1 irq 54
sym1: No NVRAM, ID 7, Fast-80, SE, parity checking
sym1: SCSI BUS has been reset.
sym1: SCSI BUS mode change from SE to SE.
scsi2 : sym-2.1.17a
scsi3 : sym-2.1.17a
The old card was attached to our SEAGATE Model: ULTRIUM06242-XXX Rev: 1470
for nightly backups. The backups ran fine.
After attaching the tape drive to the new card, during the backup we get this:
sym0:6: ERROR (40:0) (0-20-0) (1f/18/0) @ (scripta ad8:10001e00).
sym0: script cmd = 10000000
sym0: regdump: da 10 c0 18 47 1f 06 0a 00 00 86 20 80 01 08 01 00 ac c7 1e 08 00
00 00.
sym0: PCI STATUS = 0x8100
sym0: SCSI BUS reset detected.
sym0: SCSI BUS has been reset.
st0: Error 80000 (sugg. bt 0x0, driver bt 0x0, host bt 0x8).
st0: Error with sense data: Current st09:00: sense key Unit Attention
Additional sense indicates Power on,reset,or bus device reset occurred
st0: Error on write filemark.
The system is a powerpc G4 SMP @533mhz, with 1G of ram. We're using
kernel-2.4.20, SMP, and HIMEM enabled. Termination and cabling are definately
correct. We tried the sym53c8xx module with both 32 and 40 bit DMA addressing..
same results.. the old card works fine, the new card causes these errors and the
backup aborts.
We'd definately rather use the new 2 channel card, as we'd like to attach a disk
to the other channel.. but this is preventing us from doing it. Any ideas? I'm
up for trying anything here to get this to work.
thanks,
Ethan Weinstein
^ permalink raw reply
* Re: [PATCH] linux-2.5.54_delay-cleanup_A1
From: john stultz @ 2003-01-08 4:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
In-Reply-To: <1042001318.1050.116.camel@w-jstultz2.beaverton.ibm.com>
On Tue, 2003-01-07 at 20:48, john stultz wrote:
> Linus, all,
>
> Here again is my delay-cleanup patch. As described earlier, this patch
> tries to cleanup the delay code by moving the timer-specific
> implementations into the timer_ops struct. Thus, rather then doing:
>
> if(x86_delay_tsc)
> __rdtsc_delay(loops);
> else if(x86_delay_cyclone)
> __cyclone_delay(loops);
> else if(whatever....
>
> we just simply do:
>
> timer->delay(loops);
>
> Please apply on top of linux-2.5.54_timer-none_A0.
doh! patch below.
sorry,
-john
diff -Nru a/arch/i386/kernel/timers/timer_cyclone.c b/arch/i386/kernel/timers/timer_cyclone.c
--- a/arch/i386/kernel/timers/timer_cyclone.c Tue Jan 7 20:16:28 2003
+++ b/arch/i386/kernel/timers/timer_cyclone.c Tue Jan 7 20:16:28 2003
@@ -150,7 +150,6 @@
}
-#if 0 /* XXX future work */
static void delay_cyclone(unsigned long loops)
{
unsigned long bclock, now;
@@ -162,12 +161,12 @@
now = cyclone_timer[0];
} while ((now-bclock) < loops);
}
-#endif
/************************************************************/
/* cyclone timer_opts struct */
struct timer_opts timer_cyclone = {
.init = init_cyclone,
.mark_offset = mark_offset_cyclone,
- .get_offset = get_offset_cyclone
+ .get_offset = get_offset_cyclone,
+ .delay = delay_cyclone,
};
diff -Nru a/arch/i386/kernel/timers/timer_none.c b/arch/i386/kernel/timers/timer_none.c
--- a/arch/i386/kernel/timers/timer_none.c Tue Jan 7 20:16:28 2003
+++ b/arch/i386/kernel/timers/timer_none.c Tue Jan 7 20:16:28 2003
@@ -15,10 +15,23 @@
return 0;
}
+static void delay_none(unsigned long loops)
+{
+ int d0;
+ __asm__ __volatile__(
+ "\tjmp 1f\n"
+ ".align 16\n"
+ "1:\tjmp 2f\n"
+ ".align 16\n"
+ "2:\tdecl %0\n\tjns 2b"
+ :"=&a" (d0)
+ :"0" (loops));
+}
/* tsc timer_opts struct */
struct timer_opts timer_none = {
.init = init_none,
.mark_offset = mark_offset_none,
.get_offset = get_offset_none,
+ .delay = delay_none,
};
diff -Nru a/arch/i386/kernel/timers/timer_pit.c b/arch/i386/kernel/timers/timer_pit.c
--- a/arch/i386/kernel/timers/timer_pit.c Tue Jan 7 20:16:28 2003
+++ b/arch/i386/kernel/timers/timer_pit.c Tue Jan 7 20:16:28 2003
@@ -27,6 +27,19 @@
/* nothing needed */
}
+static void delay_pit(unsigned long loops)
+{
+ int d0;
+ __asm__ __volatile__(
+ "\tjmp 1f\n"
+ ".align 16\n"
+ "1:\tjmp 2f\n"
+ ".align 16\n"
+ "2:\tdecl %0\n\tjns 2b"
+ :"=&a" (d0)
+ :"0" (loops));
+}
+
/* This function must be called with interrupts disabled
* It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
@@ -129,4 +142,5 @@
.init = init_pit,
.mark_offset = mark_offset_pit,
.get_offset = get_offset_pit,
+ .delay = delay_pit,
};
diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c Tue Jan 7 20:16:28 2003
+++ b/arch/i386/kernel/timers/timer_tsc.c Tue Jan 7 20:16:28 2003
@@ -16,7 +16,6 @@
int tsc_disable __initdata = 0;
-extern int x86_udelay_tsc;
extern spinlock_t i8253_lock;
static int use_tsc;
@@ -107,6 +106,17 @@
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
+static void delay_tsc(unsigned long loops)
+{
+ unsigned long bclock, now;
+
+ rdtscl(bclock);
+ do
+ {
+ rep_nop();
+ rdtscl(now);
+ } while ((now-bclock) < loops);
+}
/* ------ Calibrate the TSC -------
* Return 2^32 * (1 / (TSC clocks per usec)) for do_fast_gettimeoffset().
@@ -272,8 +282,6 @@
* We could be more selective here I suspect
* and just enable this for the next intel chips ?
*/
- x86_udelay_tsc = 1;
-
/* report CPU clock rate in Hz.
* The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
* clock/second. Our precision is about 100 ppm.
@@ -310,4 +318,5 @@
.init = init_tsc,
.mark_offset = mark_offset_tsc,
.get_offset = get_offset_tsc,
+ .delay = delay_tsc,
};
diff -Nru a/arch/i386/lib/delay.c b/arch/i386/lib/delay.c
--- a/arch/i386/lib/delay.c Tue Jan 7 20:16:28 2003
+++ b/arch/i386/lib/delay.c Tue Jan 7 20:16:28 2003
@@ -15,54 +15,17 @@
#include <linux/delay.h>
#include <asm/processor.h>
#include <asm/delay.h>
+#include <asm/timer.h>
#ifdef CONFIG_SMP
#include <asm/smp.h>
#endif
-int x86_udelay_tsc = 0; /* Delay via TSC */
-
-
-/*
- * Do a udelay using the TSC for any CPU that happens
- * to have one that we trust.
- */
-
-static void __rdtsc_delay(unsigned long loops)
-{
- unsigned long bclock, now;
-
- rdtscl(bclock);
- do
- {
- rep_nop();
- rdtscl(now);
- } while ((now-bclock) < loops);
-}
-
-/*
- * Non TSC based delay loop for 386, 486, MediaGX
- */
-
-static void __loop_delay(unsigned long loops)
-{
- int d0;
- __asm__ __volatile__(
- "\tjmp 1f\n"
- ".align 16\n"
- "1:\tjmp 2f\n"
- ".align 16\n"
- "2:\tdecl %0\n\tjns 2b"
- :"=&a" (d0)
- :"0" (loops));
-}
+extern struct timer_opts* timer;
void __delay(unsigned long loops)
{
- if (x86_udelay_tsc)
- __rdtsc_delay(loops);
- else
- __loop_delay(loops);
+ timer->delay(loops);
}
inline void __const_udelay(unsigned long xloops)
diff -Nru a/include/asm-i386/timer.h b/include/asm-i386/timer.h
--- a/include/asm-i386/timer.h Tue Jan 7 20:16:28 2003
+++ b/include/asm-i386/timer.h Tue Jan 7 20:16:28 2003
@@ -14,6 +14,7 @@
int (*init)(void);
void (*mark_offset)(void);
unsigned long (*get_offset)(void);
+ void (*delay)(unsigned long);
};
#define TICK_SIZE (tick_nsec / 1000)
^ permalink raw reply
* [PATCH] linux-2.5.54_delay-cleanup_A1
From: john stultz @ 2003-01-08 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
In-Reply-To: <1042001164.1048.112.camel@w-jstultz2.beaverton.ibm.com>
Linus, all,
Here again is my delay-cleanup patch. As described earlier, this patch
tries to cleanup the delay code by moving the timer-specific
implementations into the timer_ops struct. Thus, rather then doing:
if(x86_delay_tsc)
__rdtsc_delay(loops);
else if(x86_delay_cyclone)
__cyclone_delay(loops);
else if(whatever....
we just simply do:
timer->delay(loops);
Please apply on top of linux-2.5.54_timer-none_A0.
thanks
-john
^ permalink raw reply
* [PATCH] linux-2.5.54_timer-none_A0
From: john stultz @ 2003-01-08 4:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
Linus,
As requested, here is a simple implementation of a default initializer:
timer_none, which is for the moment completely empty.
The following delay-cleanup_A1 patch will land on top of this.
Please apply.
thanks
-john
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Tue Jan 7 20:15:44 2003
+++ b/arch/i386/kernel/time.c Tue Jan 7 20:15:44 2003
@@ -78,7 +78,8 @@
spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED;
EXPORT_SYMBOL(i8253_lock);
-struct timer_opts* timer;
+extern struct timer_opts timer_none;
+struct timer_opts* timer = &timer_none;
/*
* This version of gettimeofday has microsecond resolution
diff -Nru a/arch/i386/kernel/timers/Makefile b/arch/i386/kernel/timers/Makefile
--- a/arch/i386/kernel/timers/Makefile Tue Jan 7 20:15:44 2003
+++ b/arch/i386/kernel/timers/Makefile Tue Jan 7 20:15:44 2003
@@ -2,6 +2,6 @@
# Makefile for x86 timers
#
-obj-y := timer.o timer_tsc.o timer_pit.o
+obj-y := timer.o timer_none.o timer_tsc.o timer_pit.o
obj-$(CONFIG_X86_CYCLONE) += timer_cyclone.o
diff -Nru a/arch/i386/kernel/timers/timer_none.c b/arch/i386/kernel/timers/timer_none.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/arch/i386/kernel/timers/timer_none.c Tue Jan 7 20:15:44 2003
@@ -0,0 +1,24 @@
+#include <asm/timer.h>
+
+static int init_none(void)
+{
+ return 0;
+}
+
+static void mark_offset_none(void)
+{
+ /* nothing needed */
+}
+
+static unsigned long get_offset_none(void)
+{
+ return 0;
+}
+
+
+/* tsc timer_opts struct */
+struct timer_opts timer_none = {
+ .init = init_none,
+ .mark_offset = mark_offset_none,
+ .get_offset = get_offset_none,
+};
^ permalink raw reply
* Re: Broadcom Gigabit 5703 and Bridging
From: sbolderoff @ 2003-01-08 4:41 UTC (permalink / raw)
To: Paul Schulz, linux-kernel
In-Reply-To: <E18W7jh-0001Co-00@mars>
On Wed, Jan 08, 2003 at 02:52:37PM +1030, Paul Schulz wrote:
> Greetings,
>
> I'm seeing 'TCP Checksum' Errors after packets pass through a host
> bridging TCP packets with:
>
> - Kernel 2.4.20
> - Bridge code
> - tg3 (Broadcom Gigabit 5703)
>
> eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)]
> (PCIX:100MHz:64-bit) 10/100/1000BaseT
> (eth1 is similar)
The BCM95703A30 rev 1002 has issues with the hardware checksumming.
The following patch for the tg3 (linux-2.4.20-ac2/drivers/net/tg3.c)
driver, fixes the problem.
Note: I've tested this on the 2.4.20-ac2, but it should work OK with
2.4.20 too.
diff -u linux-2.4.20/drivers/net/tg3.c linux-2.4.20-ac2/drivers/net/tg3.c
--- linux-2.4.20/drivers/net/tg3.c Fri Nov 29 10:23:14 2002
+++ linux-2.4.20-ac2/drivers/net/tg3.c Wed Jan 8 14:34:44 2003
@@ -6161,6 +6161,10 @@
if (tp->pci_chip_rev_id == CHIPREV_ID_5700_B0)
tp->tg3_flags |= TG3_FLAG_BROKEN_CHECKSUMS;
+ /* 5703 A2 have issues with checksumming too. (sarah) */
+ if (tp->pci_chip_rev_id == CHIPREV_ID_5703_A2)
+ tp->tg3_flags |= TG3_FLAG_BROKEN_CHECKSUMS;
+
/* Regardless of whether checksums work or not, we configure
* the StrongARM chips to not compute the pseudo header checksums
* in either direction. Because of the way Linux checksum support
Cheers,
Sarah Bolderoff
--
Foursticks Pty Ltd, http://www.foursticks.com
33 King William Street, ADELAIDE South Australia 5000
Phone +61 8 841114 309 Fax +61 8 841114 777
This message was brought to you by the numbers 0 and 1.
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Joshua Kwan @ 2003-01-08 4:43 UTC (permalink / raw)
To: dhinds, linux-kernel
In-Reply-To: <20030107175801.A23794@sonic.net>
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
No, it's not fixed...
joshk@fuuma:~/pcmcia-cs-3.2.4$ make all
cc -MD -O3 -Wall -Wstrict-prototypes -pipe -Wa,--no-warn
-I../include/static -I/usr/src/linux-2.5/include -I../include
-I../modules -c cardmgr.c In file included from cardmgr.c:200:
/usr/src/linux-2.5/include/scsi/scsi.h:185: parse error before "u8"
/usr/src/linux-2.5/include/scsi/scsi.h:185: warning: no semicolon at end
of struct or union
/usr/src/linux-2.5/include/scsi/scsi.h:186: warning: type defaults to
`int' in declaration of `ScsiLun'
/usr/src/linux-2.5/include/scsi/scsi.h:186: warning: data
definition has no type or storage class
make[1]: *** [cardmgr.o] Error 1
make[1]: Leaving directory `/home/joshk/pcmcia-cs-3.2.4/cardmgr'
But is this a problem with scsi.h itself?
Regards
Josh
Rabid cheeseburgers forced dhinds <dhinds@sonic.net> to write this on
Tue, 7 Jan 2003 17:58:01 -0800:
> On Tue, Jan 07, 2003 at 05:21:46PM -0800, Joshua Kwan wrote:
>
> > 2. [linux-2.5] pcmcia-cs 3.2.3 will no longer build: here is the
> > build log, pertinent details only.
> >
> > cc -MD -O3 -Wall -Wstrict-prototypes -pipe -Wa,--no-warn
> > -I../include/static -I/usr/src/linux-2.5/include -I../include
> > -I../modules -c cardmgr.c
> > In file included from cardmgr.c:200:
> > /usr/src/linux-2.5/include/scsi/scsi.h:185: parse error before "u8"
>
> This should be fixed in the current beta for 3.2.4 available from
> http://pcmcia-cs.sourceforge.net/ftp/NEW.
>
> -- Dave
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: aic7xxx broken in 2.5.53/54 ?
From: Justin T. Gibbs @ 2003-01-08 4:23 UTC (permalink / raw)
To: Tomas Szepe; +Cc: dipankar, linux-scsi, linux-kernel
In-Reply-To: <20030108024107.GA1127@louise.pinerecords.com>
>> [gibbs@scsiguy.com]
>>
>> These reads are actually more expensive than just using PIO. Neither of
>> these older drivers included a test to try and catch fishy behavior.
>
> Justin, are you quite sure that these tests actually work?
> I too have just run into
See my recent post to the SCSI list. The tests don't work on
certain older controllers that lack a feature I was using. The
latest csets submitted to Linus correct this problem (as verified
on a dusty dual P-90 PCI/EISA box just added to our regression cluster).
--
Justin
^ permalink raw reply
* User mode drivers (Honest does not pay here ...)
From: Pete Zaitcev @ 2003-01-08 4:19 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel
In-Reply-To: <mailman.1041987068.25081.linux-kernel2news@redhat.com>
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".
It is a question often asked in comp.os.linux.development.system.
If performance penalties and security problems are no obstacle,
a lot of hardware can be serviced with a user mode driver, except
one that requires interrupts to operate. There is no way to deliver
an interrupt safely to the user mode, because a device specific
deactivation or ack-ing must be performed before interrupts are
enabled (on i386 at least). Other problems can be worked around
with ioperm and friends.
-- Pete
^ permalink raw reply
* Re: long stalls
From: Russell Leighton @ 2003-01-08 4:07 UTC (permalink / raw)
To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1B8A19.6070602@emageon.com>
I am pretty sure we are at 2.4.19.
Brian Tinsley wrote:
> Out of curiosity, which RH kernel are you using? I moved on to 2.4.19
> and 2.4.20 primarily because the RH 2.4.18 series of kernels
> apparently has a scheduler bug (at least one) that causes the
> heartbeat software from Linux-HA to loose heartbeat signals and
> failover. Not a good scenario when you are trying to provide HA
> systems to hospitals!
>
>
> Russell Leighton wrote:
>
>>
>> I can't help, but I can echo a "me too".
>>
>> We only see it when I have 2 file I/O intensive processes...they both
>> will just stop for some few seconds, system seems idle...then
>> they just start again. RH7.3 SMP, Dual PIII, 4GB RAM, 3com RAID
>> Controller .
>>
>> Brian Tinsley wrote:
>>
>>> We have been having terrible problems with long stalls, meaning from
>>> a couple of minutes to an hour, happening when filesystem I/O load
>>> gets high. The system time as reported by vmstat or sar will
>>> increase up to 99% and as it spreads to each procesor, the system
>>> becomes completely unresponsive (except that it responds to pings
>>> just fine - interesting!). When the system finally returns to the
>>> world of the living, the only evidence that something bad has
>>> happened is the runtime for kswapd is abnormally high. I have seen
>>> this happen with the stock 2.4.17, 2.4.19, and 2.4.20 kernels on SMP
>>> PIII and PIV machines (either 4GB or 8GB RAM, all SCSI disks, dual
>>> GigE NICs). I've searched the lkml archives and google and have
>>> found several similar postings, but there is never an explanation or
>>> resolution. Any help would be *very* much appreciated! If any info
>>> from the system in question is desired, I will be glad to provide it.
>>>
>>>
>>>
>>
>
^ permalink raw reply
* Re: fbmem.c : FBIOGETCMAP
From: Antonino Daplas @ 2003-01-08 3:49 UTC (permalink / raw)
To: James Simmons; +Cc: Jon Smirl, Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0301072230180.17129-100000@phoenix.infradead.org>
On Wed, 2003-01-08 at 06:37, James Simmons wrote:
>
> > I can run the fb color map tests now if you had a
> > chance to fix the code.
> >
> > I am just running fbtest from the sourceforge fb cvs.
>
> I'm CC the fbdev list because the fb color map code is a mess. I like to
> know what the best approach would be to clean it up.
>
> FIrst the main bug. In fb_copy_cmap we should be testing to see if
> copy_from[to]_user fails. We don't. The other issue is for fb_copy_cmap
> We handle memcpy, copy_from_user, and copy)to_user. Now in fb_set_cmap
> we use get_user also without any checks.
>
> So we could have fb_copy_cmap keep handling all these issues and remove
> get_user from fb_set_cmap. We would just pass in fbcmap we got from
> fb_copy_cmap and pass into fb_set_cmap. The other approach is to
> remove copy_from_user in fb_copy_cmap and place it int fb_set_cmap.
>
> What do you think is the best approach to this?
>
>
I don't know, it looks okay to me except for the following:
1. In case FBIOPUTCMAP, fb_set_cmap() must pass 1 (to imply get info
from user space).
2. In case FBIOGETCMAP, fb_copy_cmap() must pass 2 (to imply copy cmap
from kernel space to user space)
3. no checks when doing the user access functions (should have no
effect really, except for the extra processing).
I think fb_set_cmap() is a bit misleading. It mostly implies set the hardware
DAC based on the color information in fb_cmap. fb_cmap is either in kernel
space or user space. There is no need to copy the actual cmap to kernel
space and we just let the user app keep a copy of its own.
So fb_copy_cmap() is not necessary when doing an fb_set_cmap() because
you have to allocate memory for it, which has to be deallocated after
doing an fb_set_cmap(). We cannot use info->cmap because it might be of
different length, and it will clobber the console cmap.
The copy_from_user() of fb_copy_cmap() may not be needed unless we
have support for it. If this is the case, then we have to find a way of
saving info->cmap first then allocate memory for the new cmap. Then
deallocate the new cmap and restore the default cmap to info->cmap
afterwards. You will need additional code for this. In any case, info->cmap
is driver-private anyway, and user apps have no business replacing
info->cmap with its own.
I think the main use of those 2 ioctls is this:
1. save kernel cmap by doing FBIOGETCMAP,
2. set hardware DAC based on user app's cmap using FBIOPUTCMAP,
3. upon exit of the app, restore hardware DAC by doing FBIOPUTCMAP using
the cmap taken from FBIOGETCMAP.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: portforwarding-HOWTO
From: Joel Newkirk @ 2003-01-08 3:59 UTC (permalink / raw)
To: oarojo, netfilter
In-Reply-To: <2132.192.168.0.1.1041835837.squirrel@mail.intermediacorp.com>
On Monday 06 January 2003 01:50 am, oarojo@intermediacorp.com wrote:
> Hello people!!!
>
> I have set-up a linux box firewall with two ethernet cards; eth0
> facing the internet and eth1 facing the internal network. Inside my
> network is my mail server with an IP of 192.168.0.5. Now since my ISP
> had only given me one valid IP address for my network, I wish to do
> port-forwarding for ports 25 and 110. I did something like:
>
> # iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx
> --dport 25 -j DNAT --to 192.168.0.5:25
>
> # iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx
> --dport 110 -j DNAT --to 192.168.0.5:110
>
> # iptables -A FORWARD -p tcp -i eth0 -d 192.168.0.5 --dport 25
> -j ACCEPT
> # iptables -A FORWARD -p tcp -i eth0 -d 192.168.0.5 --dport 110
> -j ACCEPT
>
> # iptables-save > /etc/sysconfig/iptables
>
> When i used nmap to determine if ports 25 and 110 are open, it says:
>
> 25/tcp filtered smtp
> 110/tcp filtered pop-3
>
> and when i try telnetting its valid ip
>
> #telnet xxx.xxx.xxx.xxx 25
>
>
> it says "trying...." and can't connect at all...
>
> How's this? Did I missed something here? Please Help!!!
Do you have a FORWARD rule to allow return traffic back out? You don't
mention one, so I have to ask. Something like this would work, if no
other more general rule allows it:
iptables -A FORWARD -p tcp -o eth0 -s 192.168.0.5 -m multiport \
--sport 25,110 -j ACCEPT
Are you trying to telnet from outside the network? If you are trying to
do it from the firewall box or from anywhere on the 192.168 network it
will fail unless you have other rules to help 'guide' the traffic back
through the firewall. (of course the rules you list are presumably for
traffice from outside...) See Oskar's tutorial's DNAT info at:
http://iptables-tutorial.frozentux.net/chunkyhtml/targets.html#DNATTARGET
where he explains the problem and the solution, if you need to allow
access from the local network or firewall.
j
^ permalink raw reply
* Re: long stalls
From: Russell Leighton @ 2003-01-08 4:00 UTC (permalink / raw)
To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1B8439.8040209@elegant-software.com>
Minor correction: 3ware RAID controller.
Russell Leighton wrote:
>
> I can't help, but I can echo a "me too".
>
> We only see it when I have 2 file I/O intensive processes...they both
> will just stop for some few seconds, system seems idle...then
> they just start again. RH7.3 SMP, Dual PIII, 4GB RAM, 3com RAID
> Controller .
>
> Brian Tinsley wrote:
>
>> We have been having terrible problems with long stalls, meaning from
>> a couple of minutes to an hour, happening when filesystem I/O load
>> gets high. The system time as reported by vmstat or sar will increase
>> up to 99% and as it spreads to each procesor, the system becomes
>> completely unresponsive (except that it responds to pings just fine -
>> interesting!). When the system finally returns to the world of the
>> living, the only evidence that something bad has happened is the
>> runtime for kswapd is abnormally high. I have seen this happen with
>> the stock 2.4.17, 2.4.19, and 2.4.20 kernels on SMP PIII and PIV
>> machines (either 4GB or 8GB RAM, all SCSI disks, dual GigE NICs).
>> I've searched the lkml archives and google and have found several
>> similar postings, but there is never an explanation or resolution.
>> Any help would be *very* much appreciated! If any info from the
>> system in question is desired, I will be glad to provide it.
>>
>>
>>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: More tests [Was: Problem with read blocking for a long time on /dev/scd1]
From: Jakob Oestergaard @ 2003-01-08 4:03 UTC (permalink / raw)
To: Greg Stark; +Cc: linux-kernel
In-Reply-To: <87n0mxt8md.fsf@stark.dyndns.tv>
On Mon, Dec 23, 2002 at 03:58:02AM -0500, Greg Stark wrote:
> Jakob Oestergaard <jakob@unthought.net> writes:
>
...
> When your process is blocked, what wait channel does ps -elf list for it?
> What system call does strace -T show it executing and for how long?
On the NFS server, knfsd and kupdated will block on "wait_on_b" (WCHAN
in top).
I guess an strace on the NFS client would just show the process waiting
in some open/read/write/close code, waiting for NFS/RPC. Not much good.
The hangs last for approximately 5 seconds, sometimes around 10.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
^ permalink raw reply
* Re: Aic7xxx and Aic79xx driver updates.
From: Justin T. Gibbs @ 2003-01-08 3:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-scsi
In-Reply-To: <679640000.1041997595@aslan.btc.adaptec.com>
> "bk send" version can be found here:
>
> http://people.FreeBSD.org/~gibbs/linux/SRC/aic79xx-linux-2.5-bksend.gz
Should be:
http://people.freebsd.org/~gibbs/linux/SRC/aic79xx-linux-2.5-20030107.bksen
d.gz
--
Justin
^ permalink raw reply
* Re: OT: curious about eth0/eth1
From: Joel Newkirk @ 2003-01-08 3:47 UTC (permalink / raw)
To: Tommy McNeely, netfilter
In-Reply-To: <6620000.1041983993@leverage>
On Tuesday 07 January 2003 06:59 pm, Tommy McNeely wrote:
> I am curious about why people choose to make a certain interface
> internal or external...
> I notice several people pick eth0 as their outside interface, and
> sorta "oh yea" the rest of the inside network is on eth1. I know the
> linux kernel could really care less what they are called, its mostly a
> "neatness" thing I guess... Also it seems like that leaves your box
> open to attack from the time it installs (if you do a NET based
> install) till the time you get around to actually putting a firewall
> on it.
Why would this in particular leave a box exposed?
I think that the main reason for 'some one way, some the other' is random
chance. However, consider this scenario:
You have two NICs, eth0 and eth1. The connections on one you trust (-i
eth0 -j ACCEPT), the other you don't. One of them fails, or the board
works loose from it's socket, or something, so that upon booting the
machine you only have one interface. No matter which board fails, the
remaining board would be eth0. If eth0 is your 'trusted' internal
network in normal conditions, and it fails, then suddenly the untrusted
network is operating under the trusted network's rules. However, the IP
assignment (if static!) would remain that of the trusted network, so as
long as eth0 is configured with a static IP this shouldn't present a
risk. If, however, both are dynamic, (say DHCP assigned) then this
would qualify as a security hole, possibly a huge one. To be fair, this
is probably a very rare intersection of situations, but if eth0 is the
untrusted network, then any failure would be an annoyance, not a risk.
j
^ permalink raw reply
* Re: Aic7xxx and Aic79xx driver updates.
From: Justin T. Gibbs @ 2003-01-08 3:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-scsi
In-Reply-To: <175810000.1041300864@aslan.btc.adaptec.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
I've uploaded a new "bk send" file relative to the 2.5.X repository.
I've also attached the output from "Documentation/.../bksend". The
"bk send" version can be found here:
http://people.FreeBSD.org/~gibbs/linux/SRC/aic79xx-linux-2.5-bksend.gz
This should correct the false positives some have seen with the
mmapped I/O test on some of the older controllers that the aic7xxx
driver supports.
--
Justin
[-- Attachment #2: bksend.out --]
[-- Type: application/octet-stream, Size: 39794 bytes --]
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===================================================================
ChangeSet@1.893.1.4, 2003-01-07 19:58:41-07:00, gibbs@overdrive.btc.adaptec.com
aic7xxx and aic79xx driver updates:
o Correct memory mapped I/O test for legacy controllers
that do not have the "auto-access-pause" feature.
o Prevent NMIs from triggering should the MMAP I/O test fail.
o Fix aic7770 (EISA/VLB) controller regression.
o Kill a few compiler warnings.
ChangeSet@1.893.1.3, 2003-01-07 19:40:37-07:00, gibbs@overdrive.btc.adaptec.com
aic7xxx and aic79xx drivers Correct several DV issues:
o Do not fallback to a wide speed if the device does not support
wide transfers.
o Don't bother allocating target instances for wide IDs on narrow
controllers.
o Add a few additional diagnostics to aid in tracking down DV bugs.
ChangeSet@1.893.1.2, 2003-01-07 19:32:07-07:00, gibbs@overdrive.btc.adaptec.com
aic7xxx/aicasm:
Remove the numerical_value portion of the grammer which is no
longer referenced. This eliminates a yacc warning.
ChangeSet@1.897, 2003-01-07 18:31:40-08:00, anton@samba.org
[PATCH] small module patch
Add a missing inline, shows up when modules are turned off.
ChangeSet@1.893.1.1, 2003-01-07 19:29:46-07:00, gibbs@overdrive.btc.adaptec.com
Update the aic7xxx Makefile so that the register information tables
are not rebuilt on every build.
Use better Kbuild rule style for building firmware.
Submitted by: Sam Ravnborg <sam@ravnborg.org>
ChangeSet@1.896, 2003-01-07 16:41:22-08:00, greg@kroah.com
PCI hotplug: clean up the try_module_get() logic a bit.
ChangeSet@1.895, 2003-01-07 16:29:23-08:00, greg@kroah.com
PCI: properly unregister a PCI device if it is removed.
This is only used by pci hotplug and cardbus systems.
ChangeSet@1.894, 2003-01-07 16:24:14-08:00, greg@kroah.com
IBM PCI Hotplug: fix compile time error due to find_bus() function name.
Makefile | 49 ++++++++++++++---------------
aic79xx_core.c | 16 +++++----
aic79xx_osm.c | 25 +++++++++++++-
aic79xx_osm.h | 13 ++++---
aic79xx_osm_pci.c | 5 ++
aic79xx_pci.c | 25 ++++++++++----
aic7xxx.h | 3 -
aic7xxx.reg | 4 +-
aic7xxx.seq | 4 +-
aic7xxx_core.c | 74 ++++++++------------------------------------
aic7xxx_osm.c | 29 ++++++++++++++---
aic7xxx_osm.h | 15 ++++----
aic7xxx_osm_pci.c | 6 +--
aic7xxx_pci.c | 34 +++++++++++++-------
aic7xxx_reg.h_shipped | 5 +-
aic7xxx_reg_print.c_shipped | 4 +-
aic7xxx_seq.h_shipped | 4 +-
aicasm/aicasm_gram.y | 15 +-------
18 files changed, 173 insertions(+), 157 deletions(-)
diff -Nru a/drivers/scsi/aic7xxx/Makefile b/drivers/scsi/aic7xxx/Makefile
--- a/drivers/scsi/aic7xxx/Makefile Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/Makefile Tue Jan 7 20:41:22 2003
@@ -1,7 +1,7 @@
#
# Makefile for the Linux aic7xxx SCSI driver.
#
-# $Id: //depot/linux-aic79xx-2.5.0/drivers/scsi/aic7xxx/Makefile#3 $
+# $Id: //depot/linux-aic79xx-2.5.0/drivers/scsi/aic7xxx/Makefile#5 $
#
# Let kbuild descend into aicasm when cleaning
@@ -44,40 +44,39 @@
$(obj)/aic7xxx_core.o: $(obj)/aic7xxx_seq.h
$(obj)/aic79xx_core.o: $(obj)/aic79xx_seq.h
+$(obj)/aic79xx_reg_print.c: $(src)/aic79xx_reg_print.c_shipped
+$(obj)/aic7xxx_reg_print.c: $(src)/aic7xxx_reg_print.c_shipped
$(addprefix $(obj)/,$(aic7xxx-y)): $(obj)/aic7xxx_reg.h
$(addprefix $(obj)/,$(aic79xx-y)): $(obj)/aic79xx_reg.h
+aic7xxx-gen-$(CONFIG_AIC7XXX_BUILD_FIRMWARE) := $(obj)/aic7xxx_seq.h \
+ $(obj)/aic7xxx_reg.h
+aic7xxx-gen-$(CONFIG_AIC7XXX_REG_PRETTY_PRINT) += $(obj)/aic7xxx_reg_print.c
+
+aicasm-7xxx-opts-$(CONFIG_AIC7XXX_REG_PRETTY_PRINT) := \
+ -p $(obj)/aic7xxx_reg_print.c -i aic7xxx_osm.h
+
ifeq ($(CONFIG_AIC7XXX_BUILD_FIRMWARE),y)
-aic7xxx_gen = $(obj)/aic7xxx_seq.h $(obj)/aic7xxx_reg.h
-ifeq ($(CONFIG_AIC7XXX_REG_PRETTY_PRINT),y)
-aic7xxx_gen += $(obj)/aic7xxx_reg_print.c
-aic7xxx_asm_cmd = $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic7xxx_reg.h \
- -p $(obj)/aic7xxx_reg_print.c -i aic7xxx_osm.h \
- -o $(obj)/aic7xxx_seq.h $(src)/aic7xxx.seq
-else
-aic7xxx_asm_cmd = $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic7xxx_reg.h \
- -o $(obj)/aic7xxx_seq.h $(src)/aic7xxx.seq
+$(aic7xxx-gen-y): $(src)/aic7xxx.seq $(src)/aic7xxx.reg $(obj)/aicasm/aicasm
+ $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic7xxx_reg.h \
+ $(aicasm-7xxx-opts-y) -o $(obj)/aic7xxx_seq.h \
+ $(src)/aic7xxx.seq
endif
-$(aic7xxx_gen): $(src)/aic7xxx.seq $(src)/aic7xxx.reg $(obj)/aicasm/aicasm
- $(aic7xxx_asm_cmd)
-endif
+aic79xx-gen-$(CONFIG_AIC79XX_BUILD_FIRMWARE) := $(obj)/aic79xx_seq.h \
+ $(obj)/aic79xx_reg.h
+aic79xx-gen-$(CONFIG_AIC79XX_REG_PRETTY_PRINT) += $(obj)/aic79xx_reg_print.c
+
+aicasm-79xx-opts-$(CONFIG_AIC79XX_REG_PRETTY_PRINT) := \
+ -p $(obj)/aic79xx_reg_print.c -i aic79xx_osm.h
ifeq ($(CONFIG_AIC79XX_BUILD_FIRMWARE),y)
-aic79xx_gen = $(obj)/aic79xx_seq.h $(obj)/aic79xx_reg.h
-ifeq ($(CONFIG_AIC79XX_REG_PRETTY_PRINT),y)
-aic79xx_gen += $(obj)/aic79xx_reg_print.c
-aic79xx_asm_cmd = $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic79xx_reg.h \
- -p $(obj)/aic79xx_reg_print.c -i aic79xx_osm.h \
- -o $(obj)/aic79xx_seq.h $(src)/aic79xx.seq
-else
-aic79xx_asm_cmd = $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic79xx_reg.h \
- -o $(obj)/aic79xx_seq.h $(src)/aic79xx.seq
+$(aic79xx-gen-y): $(src)/aic79xx.seq $(src)/aic79xx.reg $(obj)/aicasm/aicasm
+ $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic79xx_reg.h \
+ $(aicasm-79xx-opts-y) -o $(obj)/aic79xx_seq.h \
+ $(src)/aic79xx.seq
endif
-$(aic79xx_gen): $(src)/aic79xx.seq $(src)/aic79xx.reg $(obj)/aicasm/aicasm
- $(aic79xx_asm_cmd)
-endif
$(obj)/aicasm/aicasm: $(src)/aicasm/*.[chyl]
$(MAKE) -C $(src)/aicasm
diff -Nru a/drivers/scsi/aic7xxx/aic79xx_core.c b/drivers/scsi/aic7xxx/aic79xx_core.c
--- a/drivers/scsi/aic7xxx/aic79xx_core.c Tue Jan 7 20:41:21 2003
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c Tue Jan 7 20:41:21 2003
@@ -37,7 +37,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aic79xx.c#148 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic79xx.c#150 $
*
* $FreeBSD$
*/
@@ -2321,13 +2321,13 @@
/* Skip all PACED only entries if IU is not available */
if ((*ppr_options & MSG_EXT_PPR_IU_REQ) == 0
- && maxsync < AHD_SYNCRATE_DT)
- maxsync = AHD_SYNCRATE_DT;
+ && *period < AHD_SYNCRATE_DT)
+ *period = AHD_SYNCRATE_DT;
/* Skip all DT only entries if DT is not available */
if ((*ppr_options & MSG_EXT_PPR_DT_REQ) == 0
- && maxsync < AHD_SYNCRATE_ULTRA2)
- maxsync = AHD_SYNCRATE_ULTRA2;
+ && *period < AHD_SYNCRATE_ULTRA2)
+ *period = AHD_SYNCRATE_ULTRA2;
}
/*
@@ -5680,7 +5680,8 @@
/*lowaddr*/BUS_SPACE_MAXADDR,
/*highaddr*/BUS_SPACE_MAXADDR,
/*filter*/NULL, /*filterarg*/NULL,
- /*maxsize*/MAXBSIZE, /*nsegments*/AHD_NSEG,
+ /*maxsize*/(AHD_NSEG - 1) * PAGE_SIZE,
+ /*nsegments*/AHD_NSEG,
/*maxsegsz*/AHD_MAXTRANSFER_SIZE,
/*flags*/BUS_DMA_ALLOCNOW,
&ahd->buffer_dmat) != 0) {
@@ -7856,7 +7857,8 @@
#ifdef AHD_DEBUG
if ((ahd_debug & AHD_SHOW_MISC) != 0) {
ahd_print_path(ahd, scb);
- printf("Handled Residual of %d bytes\n", resid);
+ printf("Handled %sResidual of %d bytes\n",
+ (scb->flags & SCB_SENSE) ? "Sense " : "", resid);
}
#endif
}
diff -Nru a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c Tue Jan 7 20:41:21 2003
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c Tue Jan 7 20:41:21 2003
@@ -1,7 +1,7 @@
/*
* Adaptec AIC79xx device driver for Linux.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm.c#103 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm.c#104 $
*
* --------------------------------------------------------------------------
* Copyright (c) 1994-2000 Justin T. Gibbs.
@@ -2058,7 +2058,7 @@
* negotiation will occur for the first command, and DV
* will comence should that first command be successful.
*/
- for (target = 0; target < AHD_NUM_TARGETS; target++)
+ for (target = 0; target < host->max_id; target++)
ahd_linux_alloc_target(ahd, 0, target);
ahd_intr_enable(ahd, TRUE);
ahd_linux_start_dv(ahd);
@@ -2883,6 +2883,23 @@
break;
}
+#ifdef AHD_DEBUG
+ if (ahd_debug & AHD_SHOW_DV) {
+ int i;
+
+ ahd_print_devinfo(ahd, devinfo);
+ printf("Inquiry buffer mismatch:");
+ for (i = 0; i < AHD_LINUX_DV_INQ_LEN; i++) {
+ if ((i & 0xF) == 0)
+ printf("\n ");
+ printf("0x%x:0x0%x ",
+ ((uint8_t *)targ->inq_data)[i],
+ targ->dv_buffer[i]);
+ }
+ printf("\n");
+ }
+#endif
+
if (ahd_linux_dv_fallback(ahd, devinfo) != 0) {
AHD_SET_DV_STATE(ahd, targ, AHD_DV_STATE_EXIT);
break;
@@ -3525,6 +3542,8 @@
targ->dv_next_narrow_period = MAX(period, AHD_SYNCRATE_ULTRA2);
if (targ->dv_next_wide_period == 0)
targ->dv_next_wide_period = period;
+ if (targ->dv_max_width == 0)
+ targ->dv_max_width = width;
if (targ->dv_max_ppr_options == 0)
targ->dv_max_ppr_options = ppr_options;
if (targ->dv_last_ppr_options == 0)
@@ -3619,7 +3638,7 @@
period++;
}
} else if ((ahd->features & AHD_WIDE) != 0
- && tinfo->user.width != 0
+ && targ->dv_max_width != 0
&& wide_speed >= fallback_speed
&& (targ->dv_next_wide_period <= AHD_ASYNC_XFER_PERIOD
|| period >= AHD_ASYNC_XFER_PERIOD)) {
diff -Nru a/drivers/scsi/aic7xxx/aic79xx_osm.h b/drivers/scsi/aic7xxx/aic79xx_osm.h
--- a/drivers/scsi/aic7xxx/aic79xx_osm.h Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.h Tue Jan 7 20:41:22 2003
@@ -36,7 +36,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm.h#99 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm.h#102 $
*
*/
#ifndef _AIC79XX_LINUX_H_
@@ -288,7 +288,7 @@
#include <linux/smp.h>
#endif
-#define AIC79XX_DRIVER_VERSION "1.3.0.ALPHA6"
+#define AIC79XX_DRIVER_VERSION "1.3.0.BETA2"
/**************************** Front End Queues ********************************/
/*
@@ -458,10 +458,11 @@
/*
* The next "fallback" period to use for narrow/wide transfers.
*/
- u_int dv_next_narrow_period;
- u_int dv_next_wide_period;
- u_int dv_max_ppr_options;
- u_int dv_last_ppr_options;
+ uint8_t dv_next_narrow_period;
+ uint8_t dv_next_wide_period;
+ uint8_t dv_max_width;
+ uint8_t dv_max_ppr_options;
+ uint8_t dv_last_ppr_options;
u_int dv_echo_size;
ahd_dv_state dv_state;
u_int dv_state_retry;
diff -Nru a/drivers/scsi/aic7xxx/aic79xx_osm_pci.c b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
--- a/drivers/scsi/aic7xxx/aic79xx_osm_pci.c Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c Tue Jan 7 20:41:22 2003
@@ -36,7 +36,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c#19 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c#20 $
*/
#include "aic79xx_osm.h"
@@ -170,6 +170,9 @@
ahd->platform_data->hw_dma_mask =
(bus_addr_t)(0x7FFFFFFFFFULL & (bus_addr_t)~0);
}
+ } else {
+ ahd_pci_set_dma_mask(pdev, 0xFFFFFFFF);
+ ahd->platform_data->hw_dma_mask = 0xFFFFFFFF;
}
#endif
ahd->dev_softc = pci;
diff -Nru a/drivers/scsi/aic7xxx/aic79xx_pci.c b/drivers/scsi/aic7xxx/aic79xx_pci.c
--- a/drivers/scsi/aic7xxx/aic79xx_pci.c Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic79xx_pci.c Tue Jan 7 20:41:22 2003
@@ -38,7 +38,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aic79xx_pci.c#60 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic79xx_pci.c#61 $
*
* $FreeBSD$
*/
@@ -379,15 +379,20 @@
ahd_pci_test_register_access(struct ahd_softc *ahd)
{
ahd_mode_state saved_modes;
+ uint32_t cmd;
int error;
- uint8_t seqctl;
+ uint8_t hcntrl;
saved_modes = ahd_save_modes(ahd);
error = EIO;
- /* Enable PCI error interrupt status */
- seqctl = ahd_inb(ahd, SEQCTL0);
- ahd_outb(ahd, SEQCTL0, seqctl & ~FAILDIS);
+ /*
+ * Enable PCI error interrupt status, but suppress NMIs
+ * generated by SERR raised due to target aborts.
+ */
+ cmd = ahd_pci_read_config(ahd->dev_softc, PCIR_COMMAND, /*bytes*/2);
+ ahd_pci_write_config(ahd->dev_softc, PCIR_COMMAND,
+ cmd & ~PCIM_CMD_SERRESPEN, /*bytes*/2);
/*
* First a simple test to see if any
@@ -397,7 +402,8 @@
* be zero so it is a good register to
* use for this test.
*/
- if (ahd_inb(ahd, HCNTRL) == 0xFF)
+ hcntrl = ahd_inb(ahd, HCNTRL);
+ if (hcntrl == 0xFF)
goto fail;
/*
@@ -407,6 +413,10 @@
* either, so look for data corruption and/or flaged
* PCI errors.
*/
+ ahd_outb(ahd, HCNTRL, hcntrl|PAUSE);
+ while (ahd_is_paused(ahd) == 0)
+ ;
+ ahd_outb(ahd, SEQCTL0, PERRORDIS);
ahd_outl(ahd, SRAM_BASE, 0x5aa555aa);
if (ahd_inl(ahd, SRAM_BASE) != 0x5aa555aa)
goto fail;
@@ -440,7 +450,8 @@
}
ahd_restore_modes(ahd, saved_modes);
- ahd_outb(ahd, SEQCTL0, seqctl);
+ ahd_outb(ahd, SEQCTL0, PERRORDIS|FAILDIS);
+ ahd_pci_write_config(ahd->dev_softc, PCIR_COMMAND, cmd, /*bytes*/2);
return (error);
}
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx.h b/drivers/scsi/aic7xxx/aic7xxx.h
--- a/drivers/scsi/aic7xxx/aic7xxx.h Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx.h Tue Jan 7 20:41:22 2003
@@ -37,7 +37,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.h#66 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.h#67 $
*
* $FreeBSD$
*/
@@ -1053,7 +1053,6 @@
u_int pci_cachesize;
u_int stack_size;
- uint16_t *saved_stack;
/* Per-Unit descriptive information */
const char *description;
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx.reg b/drivers/scsi/aic7xxx/aic7xxx.reg
--- a/drivers/scsi/aic7xxx/aic7xxx.reg Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx.reg Tue Jan 7 20:41:22 2003
@@ -39,7 +39,7 @@
*
* $FreeBSD$
*/
-VERSION = "$Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#36 $"
+VERSION = "$Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#37 $"
/*
* This file is processed by the aic7xxx_asm utility for use in assembling
@@ -672,6 +672,8 @@
address 0x06f
access_mode RO
}
+
+const STACK_SIZE 4
/*
* Board Control (p. 3-43)
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx.seq b/drivers/scsi/aic7xxx/aic7xxx.seq
--- a/drivers/scsi/aic7xxx/aic7xxx.seq Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx.seq Tue Jan 7 20:41:22 2003
@@ -40,7 +40,7 @@
* $FreeBSD$
*/
-VERSION = "$Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#52 $"
+VERSION = "$Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#53 $"
PATCH_ARG_LIST = "struct ahc_softc *ahc"
PREFIX = "ahc_"
@@ -70,7 +70,7 @@
* Turn off the selection hardware. We need to reset the
* selection request in order to perform a new selection.
*/
- and SCSISEQ, TEMODE|ENSELI|ENRSELI|ENAUTOATNP, SCSISEQ;
+ and SCSISEQ, TEMODE|ENSELI|ENRSELI|ENAUTOATNP;
and SIMODE1, ~ENBUSFREE;
poll_for_work:
call clear_target_state;
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_core.c b/drivers/scsi/aic7xxx/aic7xxx_core.c
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c Tue Jan 7 20:41:22 2003
@@ -37,7 +37,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.c#105 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.c#108 $
*
* $FreeBSD$
*/
@@ -230,7 +230,6 @@
u_int start_instr, u_int *skip_addr);
static void ahc_download_instr(struct ahc_softc *ahc,
u_int instrptr, uint8_t *dconsts);
-static int ahc_probe_stack_size(struct ahc_softc *ahc);
#ifdef AHC_TARGET_MODE
static void ahc_queue_lstate_event(struct ahc_softc *ahc,
struct ahc_tmode_lstate *lstate,
@@ -1166,6 +1165,13 @@
ahc_name(ahc), scbptr, scb_index);
ahc_dump_card_state(ahc);
} else {
+#ifdef AHC_DEBUG
+ if ((ahc_debug & AHC_SHOW_SELTO) != 0) {
+ ahc_print_path(ahc, scb);
+ printf("Saw Selection Timeout for SCB 0x%x\n",
+ scb_index);
+ }
+#endif
/*
* Force a renegotiation with this target just in
* case the cable was pulled and will later be
@@ -1178,13 +1184,6 @@
ahc_force_renegotiation(ahc);
ahc_set_transaction_status(scb, CAM_SEL_TIMEOUT);
ahc_freeze_devq(ahc, scb);
-#ifdef AHC_DEBUG
- if ((ahc_debug & AHC_SHOW_SELTO) != 0) {
- ahc_print_path(ahc, scb);
- printf("Saw Selection Timeout for SCB 0x%x\n",
- scb_index);
- }
-#endif
}
ahc_outb(ahc, CLRINT, CLRSCSIINT);
ahc_restart(ahc);
@@ -4005,8 +4004,6 @@
free(ahc->name, M_DEVBUF);
if (ahc->seep_config != NULL)
free(ahc->seep_config, M_DEVBUF);
- if (ahc->saved_stack != NULL)
- free(ahc->saved_stack, M_DEVBUF);
#ifndef __FreeBSD__
free(ahc, M_DEVBUF);
#endif
@@ -4542,12 +4539,6 @@
size_t driver_data_size;
uint32_t physaddr;
- ahc->stack_size = ahc_probe_stack_size(ahc);
- ahc->saved_stack = malloc(ahc->stack_size * sizeof(uint16_t),
- M_DEVBUF, M_NOWAIT);
- if (ahc->saved_stack == NULL)
- return (ENOMEM);
-
#ifdef AHC_DEBUG_SEQUENCER
ahc->flags |= AHC_SEQUENCER_DEBUG;
#endif
@@ -4602,7 +4593,8 @@
/*lowaddr*/BUS_SPACE_MAXADDR,
/*highaddr*/BUS_SPACE_MAXADDR,
/*filter*/NULL, /*filterarg*/NULL,
- /*maxsize*/MAXBSIZE, /*nsegments*/AHC_NSEG,
+ /*maxsize*/(AHC_NSEG - 1) * PAGE_SIZE,
+ /*nsegments*/AHC_NSEG,
/*maxsegsz*/AHC_MAXTRANSFER_SIZE,
/*flags*/BUS_DMA_ALLOCNOW,
&ahc->buffer_dmat) != 0) {
@@ -6275,7 +6267,8 @@
#ifdef AHC_DEBUG
if ((ahc_debug & AHC_SHOW_MISC) != 0) {
ahc_print_path(ahc, scb);
- printf("Handled Residual of %d bytes\n", resid);
+ printf("Handled %sResidual of %d bytes\n",
+ (scb->flags & SCB_SENSE) ? "Sense " : "", resid);
}
#endif
}
@@ -6655,41 +6648,6 @@
}
}
-static int
-ahc_probe_stack_size(struct ahc_softc *ahc)
-{
- int last_probe;
-
- last_probe = 0;
- while (1) {
- int i;
-
- /*
- * We avoid using 0 as a pattern to avoid
- * confusion if the stack implementation
- * "back-fills" with zeros when "poping'
- * entries.
- */
- for (i = 1; i <= last_probe+1; i++) {
- ahc_outb(ahc, STACK, i & 0xFF);
- ahc_outb(ahc, STACK, (i >> 8) & 0xFF);
- }
-
- /* Verify */
- for (i = last_probe+1; i > 0; i--) {
- u_int stack_entry;
-
- stack_entry = ahc_inb(ahc, STACK)
- |(ahc_inb(ahc, STACK) << 8);
- if (stack_entry != i)
- goto sized;
- }
- last_probe++;
- }
-sized:
- return (last_probe);
-}
-
int
ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
const char *name, u_int address, u_int value,
@@ -6768,6 +6726,7 @@
cur_col = 0;
if ((ahc->features & AHC_DT) != 0)
ahc_scsisigi_print(ahc_inb(ahc, SCSISIGI), &cur_col, 50);
+ ahc_error_print(ahc_inb(ahc, ERROR), &cur_col, 50);
ahc_scsiphase_print(ahc_inb(ahc, SCSIPHASE), &cur_col, 50);
ahc_scsibusl_print(ahc_inb(ahc, SCSIBUSL), &cur_col, 50);
ahc_lastphase_print(ahc_inb(ahc, LASTPHASE), &cur_col, 50);
@@ -6787,11 +6746,8 @@
if (cur_col != 0)
printf("\n");
printf("STACK:");
- for (i = 0; i < ahc->stack_size; i++) {
- ahc->saved_stack[i] =
- ahc_inb(ahc, STACK)|(ahc_inb(ahc, STACK) << 8);
- printf(" 0x%x", ahc->saved_stack[i]);
- }
+ for (i = 0; i < STACK_SIZE; i++)
+ printf(" 0x%x", ahc_inb(ahc, STACK)|(ahc_inb(ahc, STACK) << 8));
printf("\nSCB count = %d\n", ahc->scb_data->numscbs);
printf("Kernel NEXTQSCB = %d\n", ahc->next_queued_scb->hscb->tag);
printf("Card NEXTQSCB = %d\n", ahc_inb(ahc, NEXT_QUEUED_SCB));
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c Tue Jan 7 20:41:21 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c Tue Jan 7 20:41:21 2003
@@ -1,7 +1,7 @@
/*
* Adaptec AIC7xxx device driver for Linux.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm.c#166 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm.c#169 $
*
* Copyright (c) 1994 John Aycock
* The University of Calgary Department of Computer Science.
@@ -576,6 +576,7 @@
static void ahc_linux_setup_tag_info(char *p, char *end, char *s);
static void ahc_linux_setup_tag_info_global(char *p);
static void ahc_linux_setup_dv(char *p, char *end, char *s);
+static int aic7xxx_setup(char *s);
static int ahc_linux_next_unit(void);
static void ahc_runq_tasklet(unsigned long data);
static int ahc_linux_halt(struct notifier_block *nb, u_long event, void *buf);
@@ -1297,6 +1298,7 @@
*/
.max_sectors = 8192,
#endif
+#if defined CONFIG_HIGHIO || LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,18)
/* Assume RedHat Distribution with its different HIGHIO conventions. */
.can_dma_32 = 1,
@@ -1304,6 +1306,7 @@
#else
.highmem_io = 1,
#endif
+#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
.name = "aic7xxx",
.slave_alloc = ahc_linux_slave_alloc,
@@ -1764,7 +1767,7 @@
* to a parameter with a ':' between the parameter and the value.
* ie. aic7xxx=stpwlev:1,extended
*/
-int
+static int
aic7xxx_setup(char *s)
{
int i, n;
@@ -1888,7 +1891,7 @@
* negotiation will occur for the first command, and DV
* will comence should that first command be successful.
*/
- for (target = 0; target < AHC_NUM_TARGETS; target++) {
+ for (target = 0; target < host->max_id*host->max_channel+1; target++) {
u_int channel;
channel = 0;
@@ -2732,6 +2735,22 @@
AHC_SET_DV_STATE(ahc, targ, AHC_DV_STATE_EXIT);
break;
}
+#ifdef AHC_DEBUG
+ if (ahc_debug & AHC_SHOW_DV) {
+ int i;
+
+ ahc_print_devinfo(ahc, devinfo);
+ printf("Inquiry buffer mismatch:");
+ for (i = 0; i < AHC_LINUX_DV_INQ_LEN; i++) {
+ if ((i & 0xF) == 0)
+ printf("\n ");
+ printf("0x%x:0x0%x ",
+ ((uint8_t *)targ->inq_data)[i],
+ targ->dv_buffer[i]);
+ }
+ printf("\n");
+ }
+#endif
if (ahc_linux_fallback(ahc, devinfo) != 0) {
AHC_SET_DV_STATE(ahc, targ, AHC_DV_STATE_EXIT);
@@ -3365,6 +3384,8 @@
targ->dv_next_narrow_period = MAX(period, AHC_SYNCRATE_ULTRA2);
if (targ->dv_next_wide_period == 0)
targ->dv_next_wide_period = period;
+ if (targ->dv_max_width == 0)
+ targ->dv_max_width = width;
if (targ->dv_max_ppr_options == 0)
targ->dv_max_ppr_options = ppr_options;
if (targ->dv_last_ppr_options == 0)
@@ -3459,7 +3480,7 @@
period++;
}
} else if ((ahc->features & AHC_WIDE) != 0
- && tinfo->user.width != 0
+ && targ->dv_max_width != 0
&& wide_speed >= fallback_speed
&& (targ->dv_next_wide_period <= AHC_ASYNC_XFER_PERIOD
|| period >= AHC_ASYNC_XFER_PERIOD)) {
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_osm.h b/drivers/scsi/aic7xxx/aic7xxx_osm.h
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.h Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.h Tue Jan 7 20:41:22 2003
@@ -53,7 +53,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm.h#114 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm.h#118 $
*
*/
#ifndef _AIC7XXX_LINUX_H_
@@ -72,7 +72,6 @@
#endif
#include <linux/module.h>
#include <asm/byteorder.h>
-#include <asm/io.h>
#ifndef KERNEL_VERSION
#define KERNEL_VERSION(x,y,z) (((x)<<16)+((y)<<8)+(z))
@@ -302,7 +301,7 @@
#include <linux/smp.h>
#endif
-#define AIC7XXX_DRIVER_VERSION "6.2.25"
+#define AIC7XXX_DRIVER_VERSION "6.2.26"
/**************************** Front End Queues ********************************/
/*
@@ -472,10 +471,11 @@
/*
* The next "fallback" period to use for narrow/wide transfers.
*/
- u_int dv_next_narrow_period;
- u_int dv_next_wide_period;
- u_int dv_max_ppr_options;
- u_int dv_last_ppr_options;
+ uint8_t dv_next_narrow_period;
+ uint8_t dv_next_wide_period;
+ uint8_t dv_max_width;
+ uint8_t dv_max_ppr_options;
+ uint8_t dv_last_ppr_options;
u_int dv_echo_size;
ahc_dv_state dv_state;
u_int dv_state_retry;
@@ -864,6 +864,7 @@
#define PCIM_CMD_BUSMASTEREN 0x0004
#define PCIM_CMD_MWRICEN 0x0010
#define PCIM_CMD_PERRESPEN 0x0040
+#define PCIM_CMD_SERRESPEN 0x0100
#define PCIR_STATUS 0x06
#define PCIR_REVID 0x08
#define PCIR_PROGIF 0x09
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
--- a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c Tue Jan 7 20:41:22 2003
@@ -36,7 +36,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c#42 $
+ * $Id: //depot/aic7xxx/linux/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c#43 $
*/
#include "aic7xxx_osm.h"
@@ -167,8 +167,8 @@
ahc->platform_data->hw_dma_mask =
(bus_addr_t)(0x7FFFFFFFFFULL & (bus_addr_t)~0);
} else {
- ahc_pci_set_dma_mask(pdev, 0xffffffffULL);
- ahc->platform_data->hw_dma_mask = 0xffffffffULL;
+ ahc_pci_set_dma_mask(pdev, 0xFFFFFFFF);
+ ahc->platform_data->hw_dma_mask = 0xFFFFFFFF;
}
#endif
ahc->dev_softc = pci;
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_pci.c b/drivers/scsi/aic7xxx/aic7xxx_pci.c
--- a/drivers/scsi/aic7xxx/aic7xxx_pci.c Tue Jan 7 20:41:21 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_pci.c Tue Jan 7 20:41:21 2003
@@ -39,7 +39,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx_pci.c#54 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx_pci.c#55 $
*
* $FreeBSD$
*/
@@ -1202,15 +1202,20 @@
int
ahc_pci_test_register_access(struct ahc_softc *ahc)
{
- int error;
- u_int status1;
- uint8_t seqctl;
+ int error;
+ u_int status1;
+ uint32_t cmd;
+ uint8_t hcntrl;
error = EIO;
- /* Enable PCI error interrupt status */
- seqctl = ahc_inb(ahc, SEQCTL);
- ahc_outb(ahc, SEQCTL, seqctl & ~FAILDIS);
+ /*
+ * Enable PCI error interrupt status, but suppress NMIs
+ * generated by SERR raised due to target aborts.
+ */
+ cmd = ahc_pci_read_config(ahc->dev_softc, PCIR_COMMAND, /*bytes*/2);
+ ahc_pci_write_config(ahc->dev_softc, PCIR_COMMAND,
+ cmd & ~PCIM_CMD_SERRESPEN, /*bytes*/2);
/*
* First a simple test to see if any
@@ -1220,7 +1225,8 @@
* be zero so it is a good register to
* use for this test.
*/
- if (ahc_inb(ahc, HCNTRL) == 0xFF)
+ hcntrl = ahc_inb(ahc, HCNTRL);
+ if (hcntrl == 0xFF)
goto fail;
/*
@@ -1230,8 +1236,13 @@
* either, so look for data corruption and/or flagged
* PCI errors.
*/
- ahc_outl(ahc, SRAM_BASE, 0x5aa555aa);
- if (ahc_inl(ahc, SRAM_BASE) != 0x5aa555aa)
+ ahc_outb(ahc, HCNTRL, hcntrl|PAUSE);
+ while (ahc_is_paused(ahc) == 0)
+ ;
+ ahc_outb(ahc, SEQCTL, PERRORDIS);
+ ahc_outb(ahc, SCBPTR, 0);
+ ahc_outl(ahc, SCB_BASE, 0x5aa555aa);
+ if (ahc_inl(ahc, SCB_BASE) != 0x5aa555aa)
goto fail;
status1 = ahc_pci_read_config(ahc->dev_softc,
@@ -1248,7 +1259,8 @@
ahc_pci_write_config(ahc->dev_softc, PCIR_STATUS + 1,
status1, /*bytes*/1);
ahc_outb(ahc, CLRINT, CLRPARERR);
- ahc_outb(ahc, SEQCTL, seqctl);
+ ahc_outb(ahc, SEQCTL, PERRORDIS|FAILDIS);
+ ahc_pci_write_config(ahc->dev_softc, PCIR_COMMAND, cmd, /*bytes*/2);
return (error);
}
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped b/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped
--- a/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped Tue Jan 7 20:41:22 2003
@@ -2,8 +2,8 @@
* DO NOT EDIT - This file is automatically generated
* from the following source files:
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#52 $
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#36 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#53 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#37 $
*/
typedef int (ahc_reg_print_t)(u_int, u_int *, u_int);
typedef struct ahc_reg_parse_entry {
@@ -1779,6 +1779,7 @@
#define MAX_OFFSET 0xff
#define BUS_16_BIT 0x01
#define SCB_UPLOAD_SIZE 0x20
+#define STACK_SIZE 0x04
/* Downloaded Constant Definitions */
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped b/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped
--- a/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped Tue Jan 7 20:41:22 2003
@@ -2,8 +2,8 @@
* DO NOT EDIT - This file is automatically generated
* from the following source files:
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#52 $
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#36 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#53 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#37 $
*/
#include "aic7xxx_osm.h"
diff -Nru a/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped b/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped
--- a/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped Tue Jan 7 20:41:22 2003
+++ b/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped Tue Jan 7 20:41:22 2003
@@ -2,8 +2,8 @@
* DO NOT EDIT - This file is automatically generated
* from the following source files:
*
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#52 $
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#36 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.seq#53 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx.reg#37 $
*/
static uint8_t seqprog[] = {
0xb2, 0x00, 0x00, 0x08,
diff -Nru a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
--- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y Tue Jan 7 20:41:21 2003
+++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y Tue Jan 7 20:41:22 2003
@@ -38,7 +38,7 @@
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*
- * $Id: //depot/aic7xxx/aic7xxx/aicasm/aicasm_gram.y#28 $
+ * $Id: //depot/aic7xxx/aic7xxx/aicasm/aicasm_gram.y#29 $
*
* $FreeBSD$
*/
@@ -209,7 +209,7 @@
%type <value> export ret f1_opcode f2_opcode jmp_jc_jnc_call jz_jnz je_jne
-%type <value> numerical_value mode_value mode_list macro_arglist
+%type <value> mode_value mode_list macro_arglist
%left '|'
%left '&'
@@ -781,17 +781,6 @@
}
$$ = $1 + 1;
add_macro_arg($3, $1);
- }
-;
-
-numerical_value:
- T_NUMBER
- {
- $$ = $1;
- }
-| '-' T_NUMBER
- {
- $$ = -$2;
}
;
===================================================================
This BitKeeper patch contains the following changesets:
1.893..1.893.1.4
## Wrapped with gzip_uu ##
begin 664 bkpatch12837
M'XL(`.*=&SX``^Q<^U<;.9;^V?XKM)#.0H)M2?5V.IDFV$E\`H0VI">SFST^
M]9!Q+7:5IZH<8->]?_O>*Y5?8,#/9#)GZ`Z%77KKTW<?NM(N^9R*I%JX##TO
M+>Z2#W&:50OQ-Y$$2?A-E+W,+[N!V\^$7_;C'J1HQC&DJ`S2I-*)>Z(B<U:\
MJTHWC`8W)5XVBI#JS,W\#H%BTFJ!E;7Q-]EM7U0+S?K[S\>'S6+Q]6MRU'&C
M2W$N,O+Z=3&+DV]N-TA_<[-.-X[*6>)&:4]D+E8^'"<=<DHY_&<P2Z.&.60F
MU:VASP+&7)V)@'+=-O5):7T170["1XO3**,6UZAEL"$U-8L6:X25;4<C5*M0
M5J$684:5VE7#*L%O2LGCI9.7E)1H\2W9;)>.BCXY$<FE(-Y5M5*Y$DDDNF7O
MR@NSM!R)K!*XWT2ODO;=Q)=SX9,PRF(RMXU5-8/YN\JHI95$].,TA(^A2/,J
MU.P60R++_^U>O?,&DVO0DZ%N&-0L?B2F!8^35?.?37!2+"WY4RRNA`3;L``)
MV.H<"6569E-H<*K<J>IFB5J(!KD,?GMPX9"7;%MP^-P/W$R0K".(&_K6S<T-
M.7&O1#OL"I+&\+V;R9>)N`S33"0`B':<]-PLC".2N5Y7I%"*FP@2Q1FD\@9A
M-R/P3D!G;@E^#,J0`JM*`7<BPT(^RN]),L!:LEOX#86JQ&%T2=IATKN&,O.,
MYP.O%T*^@'BW57+N]DC3_19Y<7))?DW=WF])_JD,_]Y(L#"ZYIQ3EQ;?D#ZR
MSORQEO.4I)743\-*/G*5T<A-QM^FG)E#C7/;&+JZ9KB:K3M.VPY88#XUZT_7
M@6"#&KBCTR'3;9L7BT^5>0^L*K^)8&5T"JQ\!JP:KU+KAX-U-`;P=-->%;Z!
MGZ;H05LD2*-!3R3PKMN"B@>"].-$XC1NR]>7B=N#!.2Z$X(P"5.`K"H"6G<)
MWR>B+1(1^2(H$W+1@02B&_;""!9(2EQRZ_H^`5A&`-&R@IGQ0V"FNI\_6MBK
M\NT]R)G4MH:.,'1+>+K;MKG/=&,UR#U47PX?C5,V-$R'6:O!#_)+KH31G,!/
MFX&?3JO:PO`SMPP_XD:!_-N!O_,!(T=QD@@_(RGRGMLEM3\`8.E`I%7%820F
MM5AR9-OM=CW7OX(&`JBNPP`HL"^`W$*%TD!\"WUXQ"*5Z=-!'W&LD"J3RYX`
M5-/R5-G1OV?$BZ&`A$`%L0\,#4R:N2#M,R#M-',!V*GD65E(HY8B34=NDL37
MJG`_CK(D[G9G2CX,H+.D+:Z)&P0A+B?H71"ZEQ$H>Z&?RFZ$T/H(V^5?8:U!
M?!WA"'B#RQ17"DRR\Z-6"CY;<=HK=^XM$=W4*"R4P&.&;KJP0CS+$BLOD=F*
M<FSK\,?0H-3DT/J52W9FN^!PG0%9Z_J0VR8WAY;+;"9LVW-,;AB";ZBBZ2XP
M73>L=;O@QR#2_=D^@+ZLV1RFP3)LYK;;;5OS34_?5$73?3"QQG7Z,)K@J2[8
MNJG;0\YLS1DRPZ<6I4[;L,V`!MZ&*II%DF8[FT#2O5G0N&'I0]-FT'Z`D4X]
MMTW76`S.0UV@&C/MU9?RJ.73RI6E\:&G^8$M3.HRU_>8YJXW^/,!Q`R3T]5D
M'.0'&2=Y<"+C]!D99]A5G2VL8NG?7\B1@;051A*M$(^%7@]4,%#V>VZ_#W*L
M4?E$(%DF94U77+K^[;1HP:Q$&1:!DH@=-]??=MQ!%I=`S1)I6NJ[@U3L@.1Q
MLX$R!:#&LP3D:Y21TY,&R+($AB)+PDM0WE#LI)UX`%8%EG1R<G@VU1`W[.8%
MO`MO9+<LBY*]>N/\L/+'\=O]J?:AI9-`_2#H\BP?PVXW%X$PJ/T0$^5JH))N
MNKZNB:FDV^.3^>BJ@$9/S;%.J3TT0*C90RO@+E`J,YFF,ZZO:'3<J28'M6%K
M0!FZS=C/*)JA]<;0X$"I/ZUHEA/`=,U>8P+F#+X&$GEH.C;`R#/;0=N@CO$D
M)RU0R72KN:[KZVATJ?C[G)8;NJ8-':;[T'@KH'Y@F'JP'FQD1:VT$R*WW84/
MC#S=A$K1ZOOA'+6"VP8=>B"*-1H8GN>T?6&M;L/=KVRZ*TQSK$VH%G>[DJL7
M.M/8T-$"ESH@_)AKBL#:8%TS"X(:5%\#6E,=F&8D6^=#1[=\[C&/MRTAO/8:
MRWFFHAE&TBQ]+4@YLUT8S0$?@E#@SK`=4*'Q0`M@&JC/UX"3,[\+.FH7?"U2
MQ<$!4=/J@UC/RO[TZANO#\9A?9B@Q0C'%QIS/#<0`<J*K50[/4.@RCGV>N(:
M2.6>N#8YHT/+IYK&=.91A[;;IK,>Z^;53,^-`0.W]MS\,"-(K1`3_EYC?<,4
MSQ,=W(3U;1J.(W3/`N/'L_WUAE]5]!"*0!/7^4]G!TD,48N;5&Z_+6"%X\;<
M]_(:;*PB6",@V'6J&T.34K!7T6@S[[DDZ:+FFD-*UE:LM9$%YG:"5CN,@E9Z
M&_D)6&E[^S/;-ZZ?#=PN9!B]E_8=&E_2[NJY-V%OT!N_W4'O>"\.PG8H`LCE
MW4I#*E4%HE,\FY3DN2E8?7%$SLZ:).ZCBW#D/ZQ''70[@DV5AL%@QG&(?D-H
M<.AC$;GK<Y0,]QW;TGQ,192*F3TG^#+"#U"6F[G3OM"/1'EX/I%2<BW_!]/J
M;!&,KF"QU71*6+$A?Y,7Y%DCJ))*)1#].+N[BD:5E?U=!GKTLV*-:UPGO-B`
MIP'/`GG^G+SH@Q$;!^17<OBAUCK_V^E1\_"BWJI=[!<+A='+UW=?OI*%.:HP
MC3Y1V.?CB^8A?Z1`E0`*-4Q;P_[))Q1:*!#U4WD!6$G#_Q$O*GN8]?2\_IZ4
M"-N'03@[?%]OG3?^HWXPDP%F\+('1GOZHC+*<5"L6;;A8`WRB35(J=O>V_D`
MR.P"H'Y)FR/4Q&WR"V[^`0:_1CM8>E[X7NI[I3?MKGN9DN?D_.AMZ[P.Y>^3
MOY"=<PF='5(E.SL'"EK[KYYF+2ERUB:M)7QLFZI(<1;4P,$L,6`=(&<QMCII
M<4Y*VE98ZQTL8ESO811FH=HL27TW.@`2Z=[FFQ7P`O>EU?Y%[/TWL!RZCI`4
M<.M"$A'D(>(F3#.R%Y9%664?])%:&C5BW=W?D#_P9U/`LE=^HA'Q>8,4MT6R
MCJQ@O$6#FQJ=42N0/;-DX*,[2M+G($6W52BW0`!L^/6U(!'N`$WO\D`^N>,"
MK7'S]N0EEF?;A5LM,!13'*D:$^)R"*._#\+D%J-B@)5]28;(>=*=N@SE2<2L
MQ'B2\![A.QGE47FZ\EU8#9(&J<FPS/Q9P-[NY3/^FM!7H]G_E71@.$IO8+):
M83#Z^N7+?<AJVP9A5G$W;`>B+<FL5G_[^3T2$(B0/92+@?`&ET`/DND^?/IK
MJ_;'/OE?3%$`QB'AJ^)7^0'32A)JX18<B!S,?4#R#\`=F&C$4HU\.KQ!&Z0/
MZ85I#Q6YZDZ>3O8E5-T(<QX^;IQ^_@*UMQJGO[>.ZZ?P!CJ1-T4V%W(\)_3F
MW3X0$*'[ZL6XSJ_1""RC6L:OZ,TO-U5Z0W^Y(9(?)_R[MS>`)'8K(R_V<>!*
M;P!)+92=^_\9_M<!F4FL$@3?6JI;D""OZ,_B;$/R!OQ9W!4@P]LP@@W0H"TD
M<NS'N!R<,K6N1AV:]THM/1`[F@FD`XC(GU`#"+,Y.?X-"EN,RCL;H?(%O7N;
MJDA2.:>,@2T-C*YBB!A=G<I-4C*VPN1(63,S`U28K]HQ5Z:2+-,.@.=JO#\.
MBB4T!)/;,HH+F$SM,2Y+99U5J$R3JH?\O2:9=8#,I$ZG`X?IP(^F3HQB(5]S
M<F7!^$3B)FLIZF\IS>O5_#0H*!Y,,1[E^:_Z_:25J]_W$W3=-)M-L2&PWM\E
MGJ-W&'95TQ?6.TB);P6L;P>]OHPJ13LB&O0\(&X`("MK95I^6[\XY`J&Z$__
M"6'(I4QUE$B5CUV0B6$DR&'CR'*^@.AI-OZH-UOP[[SQZ93L3/5\9R$Z5?Z^
M35#J$F[B3=:5*\DZ,X<4_M0E6(W5L:J3$ML.L7:OW=MTI"&#O2454>A(*^BY
ML-S3*XE5Z>I>$JMJ.'XH7E43=CDR9X-9G&C%PI]$=$&A1FU(:F+0U51DX^[N
M]4$1.T#E*/^1&@BD++WI=]T,'012JRF]Z5R/,Z'^-<ZP@/&W&7@OX7W?5$6,
M`ZP=R@T^-"BW52"GMCJNF;TMCU4M3#%JF)S7FTVI&,A]?HGNJ4UXT#1C2<X@
M"W%JP^@2\L8#T+3O1!F,0C7SS?^.]!ZHXEPH-VY#OJGH@YG`@^EX`]6.'2CN
MW3AL83;K@33XSH_>DL3M22M5N`'Z)E+T@_D=^74:1KZ`?-@`@"4&._=<%?_@
M@C4)B,:XO!0J:(-9*RU%&<4`R=\V/IW+G-!`L".O,>P`:P2%VL6<HH\I0Q45
MV(X'42`I0&ZV+$,!*R]_78H6^7M!EU>^SD$U@G4.8A5U>E1,-`Z:B=\+4.57
MCB;UF&@M'1_&O2O?V\`.0#J46,5"Y46Q`'77(XFALZ,&$:!4850ZC'0RZ*/:
MZ68#F"MOH$(G,99#AHO(C)<B$NBT1&^2@F#BANB^#`9B2G=UO3A!I12R5(K8
M4""2$2DE,.LMF,]V>+DGZ0=XJ97&[<P_P`8U6T>?3DX.3VL'I/)"NJQ>5#AR
MU2C_=1)F8J$"QEXT;,!S\G_P\J1U=`)6+#2\?GY6/[U31TVGN5=2>@+5&.9-
M#R-/V;,?CDXOFL?8(K341FD44>YC7@?T6-G:>)#-Y#D@*O7P[/#S>1U+N.[@
M.0%I98=I2ZZ@`#]-[-=7=XLZK_]^='%,H:O0B4_-6N-<-ER7*,`'?SK'\-UA
MXUCE7&%8<3CO#-RC@N%F(U[!)??-)H=.\)3-L@$U4\H.!U70QB`14U_;C.3:
MOSR"__@>014DNJA$N/F1+L&;B4O0M*0NR!W4+G>!FI3M$I"C3Z?O&N];'QKO
M/S0^D>&0*#=:;L3`JJ[5R9O7Y&.]>5H_'GV]QP^,`R"@!M.HB04J-U6-V<H^
MRI_+NQQ!/VUP2X,^FQ.GX]%=IZ,_Y70\>L+IZ-]S.OJ;<SH>_3,['1N:9J[O
M<M1-Y7)4SR=<CML*Z7[`9V(L88=NC9BO7:#&0/A=-V<Y5+%"OX1&Z21*+AOT
M]_9!>_Y]$(H,CTN-8F6+4X>FY*9POF<-Q`R:-ZBQ*E`XNP9J]:&%D>@2U;<$
M[5\P!43IWHD6*$:=DU$G6NZ(#<F",DKDIV-!!UG0L&PH30TSJK;DSCC#,"7D
M18J*$[-,:93GSTD>R75:SG7:XESW8O(AGXV7;);_%E&6-F!)KQ`:N9;2=-=+
MQ+F%_G?=R14G<_75N36UZ13L6#PZAE/[^?B87'=$I`0G+A67:-P+,S0^I?XD
MS449YKGDLOB1'J.9)NR"??`,08_V#6">R<@!*4,7=!?YFW(7/1`LN#;D5XY[
MW$ZU4XXEC'LT'W`L+;P4MN;<;XJ1;3]U?/PCD;&:R\!]SD"L`GR,ZVF8\&L1
M3TD>J[EK(+H7S0`-W=50:7X0IN.#_(#)[1YE7PU[,W4P#DBCAJ.#+:PS@RN5
MR"&45QBO:*"MTRI;DG0W[YI7)IFXZ7=#'Y@59@A441'YMWBSP;4`]IW"#RI+
MD`._2?JS+`'VX>4`3<`>C`%Q\0!Z[@*5NA'D@@GKJ$-8W^(P&',XEJ9P/CG8
MGB+D\2*&CX0;H/<LA/?1X*^E\.S.0E5=XI+[_O`"D3*=3^RCRG<Q#J2AXSIY
MM@<F_?[8<3@UC%7R;"]-_+GOQDMT*OO-(]D?6N$;`;#&0")A;*^:!00PI_?N
M_%@J_HIO9]L>K^)(W<A'$`$:K]1U'+WQQ1_C*SE&5*KNYLBWZ?&BB9\'8H;4
MJ#FQBOFK$BR@TK.]W*^`>Z-?OGQIO?W<.*ZUWC6:)W\];-;W"]77Y`ZFY$D@
M\C6WC\%PO8^Y<N?Q2IKU]ZVS9OWBXF_P:)Q>[!=>WJMF"I[%KUB<F_9*LLBX
MGZ4+E$F@Z=#*4O^1DDDI'-L4:OOZ*\@LG3@@M#C183E-]^-V_^XB0G%U]RLH
M?JK&R8T1Q<*\;TFIH?(#D.:.I!IIY2*0S9D=AUO(&#\R1:.,=UM=K)D&;BB8
M%C&+(QS=FRSG240X3R#"F4'$@Y4\A0CG040X<Q$QM\RYB'#F(V(2T%`#+=O!
M`-TQ'ISY>'#NX\'9&!Z<Q_'@/(@'YPD\.",\V!3P\*2N/SG-L.43&^OI\?</
M,6C<'C+&3'6["EOC%(.Q+3/V.Q\34.?XES$*OMLQ@1MU3(!:*J2,&C(W/A\.
MPC]:.@C_:!2$;W+I:6K(YW<,PM_:Y0P2XM8:<0^,E(SM!#Y,W5/53V)/M$"?
M]Z]`L0^$C&%`M4ON,*5@#V#P#^31P<(0?=PGNG^/P@$>\,&2T-4#F?HQ3!U8
M`?+LC0R)<+N00IH/&(*I[B-"%U$BQOFR<;77&#X!.0?]5&3C^^`LB^9>VS-$
M!HD'ZIW<B9V^%([(38]!K]_RW23`ON$9I#SOR:CCJ>@*7UT=%_8$%C:UTD?G
ME<"N4@,PN9!+WC%'8$+`$@*`X2*69]#^H=>PK8[Z*!\L,VUB/;AC-'_+Z+Q^
M?/%I7^X\C#9L)MM%:!^JO2)8?G?VB<[=:W(^'NJ+?*B1*#%Z!;=M\A4\7L-0
M1@MH5MS<V6*I,68S:#A&%B!#U'1#-T!QJIFF"6+30#W*DOLFV#(9BZ':)WND
M8@Z@B1(N^P?DN3](8"*Z!\2@Z+TV+8<368B#-N"]#:SSB\.CCY+-U+95<=3>
M44]E9X!99FJ3N?:'>W.^)+_^2NS]!7;\5>#XEN]46(L'Q['B8P<=-PU-F9WK
M,.#V''0_*_]]).JVBB789K5XX!6(IK,K-\YK#$8?LBT4R+(.M)>YKZ6HKFN-
M!GA+:QA=N?*NUL5*1]&N44MS`->Z;=MJ#X:O<9S-)"7S'_X,A+HJ;ME=RY7`
M)O'2D+_7W+?L[#*&7I::A>IJ38<'GH0`E?*?_23$/<C.7ODG(<O7VC?\KB<A
MS#(O<S-7VM3%CVHS4>H1[3Q&"Z,N\U@ZHN+M2-IW_<D=P:D\9PY_]?+H3,!_
M/T9#0*BX34"[!+N\?.DG!+O4[#0J?93J,7W2XLN<DQ9J9'>*#=LT)\D+]R,Z
M"_0&8/3$X;:;Z5#U[W#-S7H+9&Z4.E3)U5$A>XW-1-SCV<[YBW^%J6\V3%U=
M:[3,6E\]3%W&<\G?"VI1>7"!(848`WR@@QB>%D9"@_0H*!Y#6=*2'U60.7LU
MB68G,II]+&O(.'X=,,]4<4S[X1'L_IP(=G^)"'9_7JCU(P4L'\'..%<&,SYG
M8]BGC+G'8]BA$$V3`2)<TW',,6\>3^XO$,SNSP2S^W>"V:>+4J'IL['L=Y/\
M?W-7UYL@#$6?]5<0EKWY`'1%R.82=3Z8;-,(>UMB&)*,3''QX\T?O]Y;.F#H
MH#1NOE`-A-IZTH]S3\\=#J;^K*,9N5O+[UOS0=\;@4R%!@&E["+:Q)O[XT'.
M!63/0DLIU[-":57^O*)P7O;?;"*<+W@@J4Q7$JY-RDJ8HFM3?MHRJ9VF='`O
M<%EW0@/#K:8D13!9'URX_&5L=IW<8==6QAG!6NJF&J(%AT<5B$IX4JI!M.1)
MF8<H<0S7587HG\NTT$A3!J*%/KAPB/X&P5)FA88(;)@1HC$0C]<G5%S4.-C$
M(M81-A)2B=3VN68X-,\3<U1-&U+.&8*B<\B"41/&I1X\_YG,4I57EHM1"A/7
MS+RXAC1;VAWVQ3VXP$5IO^#')1RN6@7A9CUG*TWX!EY>;`]<33ZB(J`R3U?5
M&^KY7*M1ZZ*:W+!J$^+0$QO6VN3Z632)@H/D/#:$A0N*;V[0+<-=L]8K[KL$
M[]'3=*F14H=0$%CCO;:Q"?G)O'HF1Q&*&KYJ&[.JX4M4DS^V;W?)*4+D_ZU3
M/%0$)O%.A&K6^TT8P6`8KSZ7,5>TOD5I`IOM#I(FL2$4XBD)Q&200]C$BT64
M8+`XT?0@6>A(3P!%+HXNHCNM#%9!P=,$J_RX,6F`5;$,T-FXAV_!:XLUI^4-
MO3';<W4T?_0T>1@=0`;Q.&;%+"W[+_ZD[S]/;[,LA^%[%'YL]ZL>6QY:1I=&
*[2]EW9025G$`````
`
end
^ permalink raw reply
* RH8 IDs SB16 wrong
From: Jack Heller @ 2003-01-08 3:45 UTC (permalink / raw)
To: linux-hams
I just installed a new SB16 pnp card under RH 8. and it identifies the
card as: Ensoniq | 5880 Audio PCI
Of course, this does not work and I cannot find a cure. Help.
Thanks -- A Linux newbie -- Jack
^ permalink raw reply
* Re: [PATCH] linux-2.5.54_delay-cleanup_A0
From: john stultz @ 2003-01-08 3:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
In-Reply-To: <Pine.LNX.4.44.0301071927190.1892-100000@home.transmeta.com>
On Tue, 2003-01-07 at 19:29, Linus Torvalds wrote:
> Wouldn't it be saner to initialize the timer to something that can at
> least do estimated loops, and then just unconditionally do
>
> timer->delay(..);
>
> instead?
Basically a default timer_null structure? Sure that can be done (I think
others have suggested this as well, but I've just not had the time to
get around to it). I'll see if I can scratch that out quickly and
resend.
thanks for the feedback!
-john
^ permalink raw reply
* Re: [PATCH] linux-2.5.54_delay-cleanup_A0
From: Linus Torvalds @ 2003-01-08 3:29 UTC (permalink / raw)
To: john stultz; +Cc: lkml
In-Reply-To: <1041993975.1052.71.camel@w-jstultz2.beaverton.ibm.com>
On 7 Jan 2003, john stultz wrote:
>
> if (timer)
> timer->delay(loops);
Why the "if (timer)"?
Wouldn't it be saner to initialize the timer to something that can at
least do estimated loops, and then just unconditionally do
timer->delay(..);
instead?
Linus
^ permalink raw reply
* Re: [PATCH] Set TIF_IRET in more places
From: Daniel Jacobowitz @ 2003-01-08 3:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Richard Henderson, Zack Weinberg, Jamie Lokier, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301071832210.1892-100000@home.transmeta.com>
On Tue, Jan 07, 2003 at 06:33:48PM -0800, Linus Torvalds wrote:
>
> On Tue, 7 Jan 2003, Richard Henderson wrote:
> > > We're open to better ideas ...
> >
> > Something like having dwarf2 unwind information for the
> > vsyscall page on the page as well?
>
> What would the unwind info look like? The current BK kernel will put the
> signal return into the vsyscall page, so gdb could pick up the info from
> there. But I have no idea what the unwind info looks like, or how to tell
> gdb about it.
Right now you can't, since GDB won't use the unwind info anyway; but
Richard is probably talking about MD_FALLBACK_FRAME_STATE_FOR, which is
used for exception handling unwinding instead of debugging unwinding.
Someday soon I hope to have GDB properly using this info, too.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: [parisc-linux] kernel panic when extracting large tar files
From: Carlos O'Donell @ 2003-01-08 3:20 UTC (permalink / raw)
To: Thibaut VARENE, grundler, jsoe0708, markov, parisc-linux
In-Reply-To: <20030108013458.GC22018@systemhalted>
>
> As it turns out Vlad's archive is on 14MB's but contains lots of very
> small files. I'm trying to get a hold of this to test it out.
>
I just downloaded the archive that Vlad had problems with and it doesn't
crash my machine. We'll need some more detailed info about the hardware,
scsi setup, and the procedure.
c.
^ permalink raw reply
* RE: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: Kamble, Nitin A @ 2003-01-08 3:19 UTC (permalink / raw)
To: Andrew Theurer
Cc: Martin J. Bligh, linux-kernel, jamesclv, Nakajima, Jun,
Mallick, Asit K, Saxena, Sunil, Schlobohm, Bruce
Hi Andrew,
> I am seeing if I can get together a test for Netbench with/without
your
> patch.
> Looking at the patch, I would expect a slight increase in performance.
> I'll
> let you know the results as soon as I have them.
>
[NK] Thanks for trying it out. The numbers from my post may be useful to
you.
> I do have one question for you: Have you tested netperf using only
one
> gigabit adapter? If so, have you been able to max out the adapter
when
> using
> hyperthreading? If not, could you test this? So far I have not been
able
> to, while I can quite easily with no hyperthreading (in Netbench).
This is
> the case with both irq_balance and irq affinity. having ints
processed by
> one and only one logical CPU at one time really seems to bottleneck
> network
> throughput. I'm sure some of this has to do with sharing those
resources
> among 2 logical CPUs, but I also wonder if int processing is just a
lot
> slower than P3 overall.
[NK] While testing we had 4 100mbps NICs with 4 Way Intel P4 Xeon
1.6GHz. What is your system configuration? Some numbers from your
experiments would be useful in understanding the situation better. Also
what do you mean by no hyper-threading, Is HT disabled in the BIOS, or
the HT awareness is disabled in the code. I need more details of your
setup to test it out.
>
> I am bringing this up, because I recall James Cleverdon having some
code
> which
> allows interrupts to be dynamically routed to two CPU destinations, a
pair
> of
> CPUs with consecutive CPU ID's. Interrupts are dynamically routed to
the
> least loaded CPU, and if both are idle, to the CPU with the lower
CPUID.
> I
> like this idea, because when in HT, if consecutive logical CPU ID's
map to
> one physical core, we get to use "whole" processor, and both
destinations
> share the cache. Anyway, just a thought.
[NK] This case will work well if the CPUs are lightly loaded. For
Heavily loaded CPUs to let then perform their on task, it is required to
move the interrupts out of the package.
Thanks,
Nitin
>
> -Andrew Theurer
^ permalink raw reply
* Re: fb_imageblit()
From: Antonino Daplas @ 2003-01-08 2:41 UTC (permalink / raw)
To: James Simmons; +Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301072215370.17129-100000@phoenix.infradead.org>
On Wed, 2003-01-08 at 06:23, James Simmons wrote:
> > >
> > > If monochrome image data would be packed as well, it could be handled by
> > > setting fb_image.fg_color = 1 and fb_image.bg_color = 0 (or vice versa for
> > > mono10), and fb_set_logo() becomes simpler as well.
> > >
> > > If we retain the unpacked data for images, we need some other flag to
> > > indicate color expansion. Perhaps setting fb_image.depth to 0?
> > >
> > If we change the contents of the logo data, then it makes sense to pack
> > the logo data also. However, if we stick to indices, we might as well
> > retain the "unpacked" 8-bit format. I think setting fb_image.depth to 0
> > to mean color expansion is more appropriate. Drivers that will need
> > trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
> > and of course cfb_imgblt.c, softcursor.c and fbcon.c.
>
> The requirement I made of imageblit was to always use packed data. What
> the indices approach was to to always use a struct fb_cmap. This way it
> didn't matter if used a pseudocolor mode or a directcolor mode.
I've thought of that also, packing the data according to the pixel depth.
However, this will be very inefficient since image blitting
will go like this:
a. Prepare logo data so each pixel of data is in directcolor format (if
we will use the cmap), so depth corresponds to framebuffer depth, and
data is packed.
b. Pass the structure to cfb_imageblit.
c. In cfb_imageblit, unpack the logo data:
d. Get each color component from the cmap data.
e. Recreate pixel data based on var.[color].offset and
var.[color].length.
f. Write the pixel data in packed form to the framebuffer.
Whereas, with the current approach:
a. Prepare logo data such that each pixel corresponds to one byte.
b. Pass the structure to cfb_imageblit.
c. Read color information from pseudopalette if directcolor/truecolor.
d. Write the pixel data in packed form to the framebuffer.
Aside from the inefficiency of the method (pack, unpack, pack), drawing
the logo will become inconsistent with the behavior of the rest of the
functions, since it's the only one that gets color info differently. If
you look at color_imageblit() and slow_imageblit(), they basically use
the same code logic.
Secondly, indexing the cmap instead of the pseudo_palette means that
cfb_imageblit has to know the native framebuffer format. This was
argued before that the generic drawing functions need not know of the
format, one of the reasons we have info->pseudopalette. Actually, in
order to be really consistent, I would rather have everything refer to
the pseudopalette, regardless of the visual format. This will be better
especially for some of the corner cases, like monochrome cards with
bits_per_pixel = 8.
Thirdly, it's much simpler for drivers to draw the logo. Just get the
corrct pixel data from it's own palette. No need to construct each
pixel from the cmap. That's tedious, slow, and will contribute to code
bloat. Which is easier? Get each byte from the logo data, and use it as an
index to the pseudo_palette, or unpack the data, separate each unit to 4
color components, and construct pixel data from cmap using the 4 extracted
indices?
I agree that it would be faster in some cases to draw a packed logo
data, but if we're going to be inconsistent, let's do it all the way.
Make the logo data match the native framebuffer format. This will be
very efficient, and this is the one that I actually prefer.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.