* Re: [LARTC] R2Q
From: Stef Coene @ 2004-01-27 18:23 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-102179583208377@msgid-missing>
On Tuesday 27 January 2004 00:04, Mihai Vlad wrote:
> Hello again,
>
> I need to change the R2Q for my script, as setting the quantum manually for
> each class is painful. Can you tell me exactly where to set R2Q = x?
If you add the htb qdisc.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [LARTC] Help with a simple config
From: Stef Coene @ 2004-01-27 18:22 UTC (permalink / raw)
To: lartc
In-Reply-To: <D4F6F05E3A22D41194EE0090276CE81901601B01@dlserver.nwt>
On Monday 26 January 2004 23:42, jradke@canbytel.com wrote:
> Here's the scenario:
> - 4 NIC's; 1 Upstream, 3 subscribers each with different rates.
>
> NIC-1: NO CAP simply 100mbit
> I want to cap the traffic on each of the subscriber NIC's to a specific
> rate i.e.:
> - NIC-2: 8mbit
> - NIC-3: 5mbit
> - NIC-4: 3mbit
>
> Just to summarize, ALL I'm trying to do is limit the bandwidth on each NIC
> (ingress & egress) whether it is 10/100/1000Base-T. Right now I am using a
> Cisco using rate-limiting which is very simple. I'd like to perform this
> task on Linux box for easier scalibility and as a backup.
Outgoing traffic can be limited if you add a tbf qdisc to the devices.
Incoming traffic can be limited with the ingress qdisc and a filter +
policer.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Tom Rini @ 2004-01-27 18:22 UTC (permalink / raw)
To: Amit S. Kale
Cc: Powerpc Linux, Linux Kernel, KGDB bugreports, George Anzinger
In-Reply-To: <20040123224605.GC15271@stop.crashing.org>
On Fri, Jan 23, 2004 at 03:46:05PM -0700, Tom Rini wrote:
> On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
> [snip]
> > First up:
> > We need to call flush_instruction_cache() on a 'c' or 's' command.
> > arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------
> > 1 files changed, 6 insertions(+), 13 deletions(-)
>
> On tpo of this patch, there's the following:
> Put back some code to figure out what signal we're dealing with.
And here's a version that with some help from Daniel always passes the
correct information back to GDB (the original code did not).
arch/ppc/kernel/ppc-stub.c | 63 ++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 60 insertions(+), 3 deletions(-)
--- 1.15/arch/ppc/kernel/ppc-stub.c Thu Jan 22 10:53:06 2004
+++ edited/arch/ppc/kernel/ppc-stub.c Tue Jan 27 11:08:25 2004
@@ -3,6 +3,7 @@
*
* PowerPC-specific bits to work with the common KGDB stub.
*
+ * 1998 (c) Michael AK Tesch (tesch@cs.wisc.edu)
* 2003 (c) TimeSys Corporation
* 2004 (c) MontaVista Software, Inc.
* This file is licensed under the terms of the GNU General Public License
@@ -19,13 +20,69 @@
#include <asm/processor.h>
#include <asm/machdep.h>
+/* Convert the hardware trap type code to a unix signal number. */
+/*
+ * This table contains the mapping between PowerPC hardware trap types, and
+ * signals, which are primarily what GDB understands.
+ */
+static struct hard_trap_info
+{
+ unsigned int tt; /* Trap type code for powerpc */
+ unsigned char signo; /* Signal that we map this trap into */
+} hard_trap_info[] = {
+#if defined(CONFIG_40x)
+ { 0x0100, 0x02 /* SIGINT */ }, /* critical input interrupt */
+ { 0x0200, 0x0b /* SIGSEGV */ }, /* machine check */
+ { 0x0300, 0x0b /* SIGSEGV */ }, /* data storage */
+ { 0x0400, 0x0a /* SIGBUS */ }, /* instruction storage */
+ { 0x0500, 0x02 /* SIGINT */ }, /* interrupt */
+ { 0x0600, 0x0a /* SIGBUS */ }, /* alignment */
+ { 0x0700, 0x04 /* SIGILL */ }, /* program */
+ { 0x0800, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0900, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0a00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0b00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0c00, 0x14 /* SIGCHLD */ }, /* syscall */
+ { 0x0d00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0e00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0f00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x2000, 0x05 /* SIGTRAP */}, /* debug */
+#else
+ { 0x0200, 0x0b /* SIGSEGV */ }, /* machine check */
+ { 0x0300, 0x0b /* SIGSEGV */ }, /* address error (store) */
+ { 0x0400, 0x0a /* SIGBUS */ }, /* instruction bus error */
+ { 0x0500, 0x02 /* SIGINT */ }, /* interrupt */
+ { 0x0600, 0x0a /* SIGBUS */ }, /* alingment */
+ { 0x0700, 0x05 /* SIGTRAP */ }, /* breakpoint trap */
+ { 0x0800, 0x08 /* SIGFPE */}, /* fpu unavail */
+ { 0x0900, 0x0e /* SIGALRM */ }, /* decrementer */
+ { 0x0a00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0b00, 0x04 /* SIGILL */ }, /* reserved */
+ { 0x0c00, 0x14 /* SIGCHLD */ }, /* syscall */
+ { 0x0d00, 0x05 /* SIGTRAP */ }, /* single-step/watch */
+ { 0x0e00, 0x08 /* SIGFPE */ }, /* fp assist */
+#endif
+ { 0x0000, 0x000 } /* Must be last */
+};
+
+static int computeSignal(unsigned int tt)
+{
+ struct hard_trap_info *ht;
+
+ for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+ if (ht->tt == tt)
+ return ht->signo;
+
+ return SIGHUP; /* default for things we don't know about */
+}
+
/*
* Routines
*/
static void
kgdb_debugger(struct pt_regs *regs)
{
- (*linux_debug_hook) (0, 0, 0, regs);
+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
return;
}
@@ -52,14 +109,14 @@
int
kgdb_iabr_match(struct pt_regs *regs)
{
- (*linux_debug_hook) (0, 0, 0, regs);
+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
return 1;
}
int
kgdb_dabr_match(struct pt_regs *regs)
{
- (*linux_debug_hook) (0, 0, 0, regs);
+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
return 1;
}
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [linux-lvm] LVM and Linux quotas
From: Matthew Daubenspeck @ 2004-01-27 18:21 UTC (permalink / raw)
To: linux-lvm
First off, please excuse the the newbie question :)
Does LVM work with the standard Linux quotas? I did some googling and
found nothing other then people having problems. Does it work?
--
:wq!
Matthew Daubenspeck
http://www.oddprocess.org
^ permalink raw reply
* Re: [Qemu-devel] Reactos not booting
From: Gabriel Ebner @ 2004-01-27 18:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20040127142251.236d8fce.Jens.Arm@gmx.de>
Hello,
Am Die, den 27.01.2004 schrieb Jens Arm um 14:22:
> > > > > I have to use the newest VGA- and normal BIOS that freeloader boots.
> > > > > The BIOSes which are in the qemu-CVS do not boot with reactos.
> > > >
> > > > You mean those included in CVS, don't you? That's what I meant with
> > > > current CVS. :)
> > >
> > > I meant that if you want to boot ros you have to use the BIOSes from the
> > > bochs CVS.
> >
> > Well, I've got mine from qemu, and ROS boots... Strange.
>
> If I use qemu-fast I get always SegFaults, not only if I try ros, linux, nt4, ...
> I think there is the qemu BIOS SegFaulting.
I thought qemu-fast ran only tweaked linux kernels...
As for the BIOS segfaulting, I've noticed that a couple of times. If I
don't specify -boot, the BIOS segfaults.
Gabriel.
^ permalink raw reply
* Re: Encrypted Filesystem
From: Jari Ruusu @ 2004-01-27 18:17 UTC (permalink / raw)
To: Andi Kleen; +Cc: Michael A Halcrow, linux-kernel
In-Reply-To: <p73znc9s724.fsf@nielsen.suse.de>
Andi Kleen wrote:
> Better use a stacking file system or somesuch. Technically this
> has the advantage that you don't need to cache the data twice (crypto
> loop keeps both unencrypted and crypted data in the page cache)
Not true for device backed loops. At least on device backed loops on
loop-AES implementation encrypted data in not stored in page cache.
> The biggest shortcomming in crypto loop is that you cannot change the
> password easily. Doing so would require reencryption of the whole
> volume and it is hard to do so in a crash safe way (or you risk loss
> of the volume when the machine crashes during reencryption)
Not true with loop-AES where changing password is either:
gpg --decrypt </root/fskey1.gpg | ( sleep 60; gpg --symmetric >/etc/fskey2.gpg )
mv /etc/fskey2.gpg /etc/fskey1.gpg
or:
gpg --edit-key "myname"
Command> passwd
depending on how gpg key file was encrypted.
> Another
> problem is that using the user key makes it easy to use dictionary
> attacks using known plain text. For example the first block on a ext2
> file system is always zero and can be easily used to do a dictionary
> attack based on a weak user password.
Not true. loop-AES solved this dictionary attack problem in 2001. Mainline
and kerneli.org versions are vulnerable as always.
> The standard crypto loop uses
> fixed IVs too which do not help against this.
Not true. Mainline uses simple sector IV. SuSE twofish uses fixed IV which
is even more vulnerable than mainline. Loop-AES 2.x versions use more secure
MD5 IV, but they are also compatible with old setups for backward
compatibility sake.
> Not directly related to the file system, but in a bigger picture the
> biggest problem with using cryptography regularly in Linux is that
> there is no nice way for users to prevent pages from being swapped out
> to disk. Always when you decrypt a file you risk it ending up
> unencrypted on the swap partition. This means even when your file
> system encrypts great you still risk your data when reading it.
That is what encrypted swap is for. Loop-AES version of loop was rewritten
in 2001 to be compatible with encrypted swap. That work included removing
all runtime memory allocations from device backed loops.
Quote from loop-AES README file:
First, run "swapoff -a" to turn off swap devices in your /etc/fstab file.
Second, add "loop=/dev/loop?" and "encryption=AES128" options to swap lines
in your /etc/fstab file. Example:
/dev/hda666 none swap sw,loop=/dev/loop6,encryption=AES128 0 0
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
Third, there may be old unencrypted data on your swap devices, in which case
you can try to overwrite that data with command like this:
dd if=/dev/zero of=/dev/hda666 bs=64k conv=notrunc
mkswap /dev/hda666
Fourth, run "swapon -a" and "rm -rf /var/log/ksymoops" and you are done.
> While it would be possible to encrypt swap too I'm not sure this is a
> good idea: e.g. it requires global key management, which is probably
> bad.
"swapon -a" reads some random bits from /dev/urandom and recycles old
encrypted swap data while it generates 64 new random swap keys for each loop
device that it uses to encrypt swap partitions. No 'global key management'
problem whatsoever. Encrypted swap has worked fine since 2001.
> And it could cause performance problems.
Optimized assembler implementation of AES cipher works fast enough here.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - REALLY SOLVED
From: Andi Kleen @ 2004-01-27 18:15 UTC (permalink / raw)
To: Eric; +Cc: Andrew Morton, stoffel, ak, Valdis.Kletnieks, bunk, cova,
linux-kernel
In-Reply-To: <200401270037.43676.eric@cisu.net>
On Tue, Jan 27, 2004 at 12:37:43AM -0600, Eric wrote:
> On Monday 26 January 2004 23:50, Andrew Morton wrote:
> > Eric <eric@cisu.net> wrote:
> > > YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> > > Lets review folks---
> > > reverted -funit-at-a-time
> > > patched test_wp_bit so exception tables are sorted sooner
> > > reverted md-partition patch
> >
> > The latter two are understood, but the `-funit-at-a-time' problem is not.
> >
> > Can you plesae confirm that restoring only -funit-at-a-time again produces
> > a crashy kernel? And that you are using a flavour of gcc-3.3? If so, I
> > guess we'll need to only enable it for gcc-3.4 and later.
> >
> Yes, confirmed. My version of gcc, I just sent you adding the
> -funit-at-a-time hung after uncompressing the kernel. I booted a secondary
> kernel, recompiled without it and all was fine again. Confirmed non-boot for
> 2.6.2-rc1-mm3 but without a doubt for all kernels previous where
> -funit-at-a-time is active in the makefile.
Ok, found it. This patch should fix it. The top level asm in process.c
assumed that the section was .text, but that is not guaranteed in a
funit-at-a-time compiler. It ended up in the setup section and messed up
the argument parsing. This bug could have hit with any compiler,
it was just plain luck that it worked with newer gcc 3.3 and 3.4.
Please test if it fixes your problem.
Andrew, please merge it if the bug is confirmed to be fixed.
-Andi
diff -u linux-2.6.2rc1mm3-test/arch/i386/kernel/process.c-o linux-2.6.2rc1mm3-test/arch/i386/kernel/process.c
--- linux-2.6.2rc1mm3-test/arch/i386/kernel/process.c-o 2004-01-27 02:26:39.000000000 +0100
+++ linux-2.6.2rc1mm3-test/arch/i386/kernel/process.c 2004-01-27 19:09:41.131460832 +0100
@@ -253,13 +253,15 @@
* the "args".
*/
extern void kernel_thread_helper(void);
-__asm__(".align 4\n"
+__asm__(".section .text\n"
+ ".align 4\n"
"kernel_thread_helper:\n\t"
"movl %edx,%eax\n\t"
"pushl %edx\n\t"
"call *%ebx\n\t"
"pushl %eax\n\t"
- "call do_exit");
+ "call do_exit\n"
+ ".previous");
/*
* Create a kernel thread
^ permalink raw reply
* Re: MO: opening for write in cdrom.c
From: Pascal Schmidt @ 2004-01-27 18:13 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401271538010.1498-100000@neptune.local>
[...]
> I'll make that change everywhere and then send an updated version.
Here's an updated version, both patches as one.
This solves the remaining problems (512 byte sector discs) and
rough edges (write-protect detection) with ATAPI MO support via
ide-cd/cdrom for me.
--- linux-2.6.2-rc1/include/linux/cdrom.h.orig Sun Jan 25 23:21:19 2004
+++ linux-2.6.2-rc1/include/linux/cdrom.h Mon Jan 26 18:46:54 2004
@@ -496,6 +496,7 @@ struct cdrom_generic_command
#define GPCMD_GET_MEDIA_STATUS 0xda
/* Mode page codes for mode sense/set */
+#define GPMODE_VENDOR_PAGE 0x00
#define GPMODE_R_W_ERROR_PAGE 0x01
#define GPMODE_WRITE_PARMS_PAGE 0x05
#define GPMODE_AUDIO_CTL_PAGE 0x0e
--- linux-2.6.2-rc1/drivers/cdrom/cdrom.c.orig Sat Jan 24 01:23:30 2004
+++ linux-2.6.2-rc1/drivers/cdrom/cdrom.c Tue Jan 27 18:49:02 2004
@@ -696,6 +696,35 @@ static int cdrom_mrw_open_write(struct c
return ret;
}
+static int mo_open_write(struct cdrom_device_info *cdi)
+{
+ struct cdrom_generic_command cgc;
+ char buffer[255];
+ int ret;
+
+ init_cdrom_command(&cgc, &buffer, 4, CGC_DATA_READ);
+ cgc.quiet = 1;
+
+ /*
+ * obtain write protect information as per
+ * drivers/scsi/sd.c:sd_read_write_protect_flag
+ */
+
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_ALL_PAGES, 0);
+ if (ret)
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_VENDOR_PAGE, 0);
+ if (ret) {
+ cgc.buflen = 255;
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_ALL_PAGES, 0);
+ }
+
+ /* drive gave us no info, let the user go ahead */
+ if (ret)
+ return 0;
+
+ return buffer[3] & 0x80;
+}
+
/*
* returns 0 for ok to open write, non-0 to disallow
*/
@@ -707,11 +736,8 @@ static int cdrom_open_write(struct cdrom
ret = cdrom_mrw_open_write(cdi);
else if (CDROM_CAN(CDC_DVD_RAM))
ret = cdrom_dvdram_open_write(cdi);
- /*
- * needs to really check whether media is writeable
- */
else if (CDROM_CAN(CDC_MO_DRIVE))
- ret = 0;
+ ret = mo_open_write(cdi);
return ret;
}
--- linux-2.6.2-rc1/drivers/ide/ide-cd.c.orig Sat Jan 24 01:24:03 2004
+++ linux-2.6.2-rc1/drivers/ide/ide-cd.c Tue Jan 27 18:53:09 2004
@@ -294,10 +294,12 @@
* 4.60 Dec 17, 2003 - Add mt rainier support
* - Bump timeout for packet commands, matches sr
* - Odd stuff
+ * 4.61 Jan 22, 2004 - support hardware sector sizes other than 2kB,
+ * Pascal Schmidt <der.eremit@email.de>
*
*************************************************************************/
-#define IDECD_VERSION "4.60"
+#define IDECD_VERSION "4.61"
#include <linux/config.h>
#include <linux/module.h>
@@ -1211,6 +1213,9 @@ static int cdrom_read_from_buffer (ide_d
{
struct cdrom_info *info = drive->driver_data;
struct request *rq = HWGROUP(drive)->rq;
+ unsigned short sectors_per_frame;
+
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* Can't do anything if there's no buffer. */
if (info->buffer == NULL) return 0;
@@ -1249,7 +1254,7 @@ static int cdrom_read_from_buffer (ide_d
will fail. I think that this will never happen, but let's be
paranoid and check. */
if (rq->current_nr_sectors < bio_cur_sectors(rq->bio) &&
- (rq->sector % SECTORS_PER_FRAME) != 0) {
+ (rq->sector % sectors_per_frame) != 0) {
printk("%s: cdrom_read_from_buffer: buffer botch (%ld)\n",
drive->name, (long)rq->sector);
cdrom_end_request(drive, 0);
@@ -1268,13 +1273,10 @@ static int cdrom_read_from_buffer (ide_d
static ide_startstop_t cdrom_start_read_continuation (ide_drive_t *drive)
{
struct request *rq = HWGROUP(drive)->rq;
- int nsect, sector, nframes, frame, nskip;
-
- /* Number of sectors to transfer. */
- nsect = rq->nr_sectors;
+ unsigned short sectors_per_frame;
+ int nskip;
- /* Starting sector. */
- sector = rq->sector;
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* If the requested sector doesn't start on a cdrom block boundary,
we must adjust the start of the transfer so that it does,
@@ -1283,31 +1285,19 @@ static ide_startstop_t cdrom_start_read_
of the buffer, it will mean that we're to skip a number
of sectors equal to the amount by which CURRENT_NR_SECTORS
is larger than the buffer size. */
- nskip = (sector % SECTORS_PER_FRAME);
+ nskip = (rq->sector % sectors_per_frame);
if (nskip > 0) {
/* Sanity check... */
if (rq->current_nr_sectors != bio_cur_sectors(rq->bio) &&
- (rq->sector % CD_FRAMESIZE != 0)) {
+ (rq->sector % sectors_per_frame != 0)) {
printk ("%s: cdrom_start_read_continuation: buffer botch (%u)\n",
drive->name, rq->current_nr_sectors);
cdrom_end_request(drive, 0);
return ide_stopped;
}
- sector -= nskip;
- nsect += nskip;
rq->current_nr_sectors += nskip;
}
- /* Convert from sectors to cdrom blocks, rounding up the transfer
- length if needed. */
- nframes = (nsect + SECTORS_PER_FRAME-1) / SECTORS_PER_FRAME;
- frame = sector / SECTORS_PER_FRAME;
-
- /* Largest number of frames was can transfer at once is 64k-1. For
- some drives we need to limit this even more. */
- nframes = MIN (nframes, (CDROM_CONFIG_FLAGS (drive)->limit_nframes) ?
- (65534 / CD_FRAMESIZE) : 65535);
-
/* Set up the command */
rq->timeout = ATAPI_WAIT_PC;
@@ -1346,13 +1336,11 @@ static ide_startstop_t cdrom_seek_intr (
static ide_startstop_t cdrom_start_seek_continuation (ide_drive_t *drive)
{
struct request *rq = HWGROUP(drive)->rq;
- int sector, frame, nskip;
+ unsigned short sectors_per_frame;
+ int frame;
- sector = rq->sector;
- nskip = (sector % SECTORS_PER_FRAME);
- if (nskip > 0)
- sector -= nskip;
- frame = sector / SECTORS_PER_FRAME;
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
+ frame = rq->sector / sectors_per_frame;
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->cmd[0] = GPCMD_SEEK;
@@ -1396,6 +1384,9 @@ static ide_startstop_t cdrom_start_read
{
struct cdrom_info *info = drive->driver_data;
struct request *rq = HWGROUP(drive)->rq;
+ unsigned short sectors_per_frame;
+
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* We may be retrying this request after an error. Fix up
any weirdness which might be present in the request packet. */
@@ -1411,8 +1402,8 @@ static ide_startstop_t cdrom_start_read
info->nsectors_buffered = 0;
/* use dma, if possible. */
- if (drive->using_dma && (rq->sector % SECTORS_PER_FRAME == 0) &&
- (rq->nr_sectors % SECTORS_PER_FRAME == 0))
+ if (drive->using_dma && (rq->sector % sectors_per_frame == 0) &&
+ (rq->nr_sectors % sectors_per_frame == 0))
info->dma = 1;
else
info->dma = 0;
@@ -1950,11 +1941,15 @@ static ide_startstop_t cdrom_start_write
static ide_startstop_t cdrom_start_write(ide_drive_t *drive, struct request *rq)
{
struct cdrom_info *info = drive->driver_data;
+ unsigned short sectors_per_frame;
+
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/*
- * writes *must* be 2kB frame aligned
+ * writes *must* be hardware frame aligned
*/
- if ((rq->nr_sectors & 3) || (rq->sector & 3)) {
+ if ((rq->nr_sectors & (sectors_per_frame - 1)) ||
+ (rq->sector & (sectors_per_frame - 1))) {
cdrom_end_request(drive, 0);
return ide_stopped;
}
@@ -1969,12 +1964,12 @@ static ide_startstop_t cdrom_start_write
info->nsectors_buffered = 0;
- /* use dma, if possible. we don't need to check more, since we
- * know that the transfer is always (at least!) 2KB aligned */
+ /* use dma, if possible. we don't need to check more, since we
+ * know that the transfer is always (at least!) frame aligned */
info->dma = drive->using_dma ? 1 : 0;
info->cmd = WRITE;
- /* Start sending the read request to the drive. */
+ /* Start sending the write request to the drive. */
return cdrom_start_packet_command(drive, 32768, cdrom_start_write_cont);
}
@@ -2209,6 +2204,7 @@ static int cdrom_eject(ide_drive_t *driv
}
static int cdrom_read_capacity(ide_drive_t *drive, unsigned long *capacity,
+ unsigned long *sectors_per_frame,
struct request_sense *sense)
{
struct {
@@ -2227,8 +2223,11 @@ static int cdrom_read_capacity(ide_drive
req.data_len = sizeof(capbuf);
stat = cdrom_queue_packet_command(drive, &req);
- if (stat == 0)
+ if (stat == 0) {
*capacity = 1 + be32_to_cpu(capbuf.lba);
+ *sectors_per_frame =
+ be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
+ }
return stat;
}
@@ -2270,6 +2269,7 @@ static int cdrom_read_toc(ide_drive_t *d
struct atapi_toc_entry ent;
} ms_tmp;
long last_written;
+ unsigned long sectors_per_frame = SECTORS_PER_FRAME;
if (toc == NULL) {
/* Try to allocate space. */
@@ -2289,12 +2289,15 @@ static int cdrom_read_toc(ide_drive_t *d
if (CDROM_STATE_FLAGS(drive)->toc_valid)
return 0;
- /* Try to get the total cdrom capacity. */
- stat = cdrom_read_capacity(drive, &toc->capacity, sense);
+ /* Try to get the total cdrom capacity and sector size. */
+ stat = cdrom_read_capacity(drive, &toc->capacity, §ors_per_frame,
+ sense);
if (stat)
toc->capacity = 0x1fffff;
- set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+ set_capacity(drive->disk, toc->capacity * sectors_per_frame);
+ blk_queue_hardsect_size(drive->queue,
+ sectors_per_frame << SECTOR_BITS);
/* First read just the header, so we know how long the TOC is. */
stat = cdrom_read_tocentry(drive, 0, 1, 0, (char *) &toc->hdr,
@@ -2406,7 +2409,7 @@ static int cdrom_read_toc(ide_drive_t *d
stat = cdrom_get_last_written(cdi, &last_written);
if (!stat && last_written) {
toc->capacity = last_written;
- set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+ set_capacity(drive->disk, toc->capacity * sectors_per_frame);
}
/* Remember that we've read this stuff. */
@@ -3306,12 +3309,12 @@ int ide_cdrom_setup (ide_drive_t *drive)
static
sector_t ide_cdrom_capacity (ide_drive_t *drive)
{
- unsigned long capacity;
+ unsigned long capacity, sectors_per_frame;
- if (cdrom_read_capacity(drive, &capacity, NULL))
+ if (cdrom_read_capacity(drive, &capacity, §ors_per_frame, NULL))
return 0;
- return capacity * SECTORS_PER_FRAME;
+ return capacity * sectors_per_frame;
}
static
--
Ciao,
Pascal
^ permalink raw reply
* Re: iptables/extensions/libipt_time.c missing include
From: Stephen Lee @ 2004-01-27 18:13 UTC (permalink / raw)
To: netfilter-devel; +Cc: Stephen Lee
In-Reply-To: <20040127105745.GG11761@sunbeam.de.gnumonks.org>
Harald Welte <laforge@netfilter.org> wrote:
> On Fri, Jan 23, 2004 at 10:52:34AM +0100, Bastian Blank wrote:
> > On Fri, Jan 23, 2004 at 03:06:45AM +0100, laurent.ml@linuxfr.org wrote:
> > > Tell me if I'm wrong, it seems an include is missing in
> > > extensions/libipt_time.c from iptables cvs.
> > > (line 302 : offsetof)
> >
> > You should use <stddef.h> instead of <linux/stddef.h>.
>
> At least on my debian machines /usr/include/stddef.h doesn't exist.
>
> Thus, I'm accepting the patch.
On my debian machine stddef.h is in
/usr/lib/gcc-lib/i486-linux/3.3.3/include/ and gcc can find it with
<stddef.h> when compiling normally. Not sure
about when compiling a kernel.
Stephen
^ permalink raw reply
* [linux-lvm] multi-disk vg?
From: Chris Conn @ 2004-01-27 18:13 UTC (permalink / raw)
To: linux-lvm
I've finally finished setting up my Slackware 9.1 box
with LVM and ReiserFS, here's what I've got:
disk 0 (one partition)
/dev/mainvg/root /
(and swap space)
disk 1 (two partitions)
/dev/rootvg/usr /usr
/dev/rootvg/var /var
/dev/rootvg/tmp /tmp
/dev/datavg/home /home
/dev/datavg/data /data
I set up rootvg and datavg first and then last night
I followed the LVM How-To and converted the setup the
mainvg VG with root. All works well.
Now I'm wondering if I can merge mainvg and rootvg
as one VG though they're on two seperate disks. Is this
possible? And if so is it a good idea?
BTW I left /etc in / because I had trouble mounting it
as a seperate filesystem with /etc/fstab.
Thanks for any advice,
=====
Chris Conn
cmcgoat@swbell.net http://storm.cadcam.iupui.edu/~cmcgoat
Austin, TX
^ permalink raw reply
* Re: Marvell MV64340 documentation.
From: Matthew Dharm @ 2004-01-27 18:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Pavel Kiryukhin, linux-mips
In-Reply-To: <20040127152533.GA10896@linux-mips.org>
On Tue, Jan 27, 2004 at 04:25:33PM +0100, Ralf Baechle wrote:
> On Tue, Jan 27, 2004 at 05:45:32PM +0300, Pavel Kiryukhin wrote:
> > Date: Tue, 27 Jan 2004 17:45:32 +0300
>
> > Hi all,
> > is there any available documentation on Marvell MV64340 system controller?
> > Any links will be appreciated!
>
> Marvell wants a NDA for documentation.
We have a full set of documentation. If your question is general we can
try to answer it for you.
Matt
--
Matthew Dharm Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer
^ permalink raw reply
* Re: [Alsa-user] [ANN] ALSA-native sfxload program
From: Takashi Iwai @ 2004-01-27 18:09 UTC (permalink / raw)
To: Mark Constable; +Cc: alsa-user, alsa-devel
In-Reply-To: <200401280351.48649.markc@renta.net>
At Wed, 28 Jan 2004 03:51:48 +1000,
Mark Constable wrote:
>
> On Wed, 28 Jan 2004 12:18 am, Takashi Iwai wrote:
> > ...
> > The tarball is at
> > http://www.alsa-project.org/~iwai/awesfx-0.5.5.tar.gz
>
> Thank you Takashi :-)
>
> But the only version I could find is...
>
> http://www.alsa-project.org/~iwai/awesfx-0.5.0.tar.gz
you're right. it's typo of 0.5.0, of course :)
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* SMP AMD64 (Tyan S2882) problems.
From: Jan Kasprzak @ 2004-01-27 18:09 UTC (permalink / raw)
To: linux-kernel
Hello, world!\n
I have a new Opteron server based on Tyan Thunder K8S Pro (S882GNR) board.
The storage is 3ware 7506 controller with 4 disks in RAID-5. The system
has 4GB of RAM, and runs 2.6.1 kernel.
Problem 1:
I have tried to run a test load (multiple kernel compiles using
make -j4, copying a filesystem subtrees, etc), and I have noticed that
all IRQs go to the CPU0 only. My /proc/interrupts says:
# cat /proc/interrupts
CPU0 CPU1
0: 3188815 0 IO-APIC-edge timer
1: 10387 0 IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
9: 0 0 IO-APIC-edge acpi
24: 46802 0 IO-APIC-level eth0
27: 384890 0 IO-APIC-level 3ware Storage Controller
NMI: 903323 881935
LOC: 3188129 3188158
ERR: 0
MIS: 0
Is it normal? How can I set up some IRQ balancing (or at least hard-wire
3ware for CPU1 and eth0 for CPU0)?
Output of "dmesg" is at http://www.fi.muni.cz/~kas/tmp/dmesg-K8SPro.txt
Other problems are not so important or lkml-related:
Problem 2: the 3ware controller does not work correctly on the first
PCI bus (slot 1 and 2) - in slot 1 it hangs under bigger load (e.g.
an array rebuild), in slot 2 it hangs during boot in 3ware BIOS.
It is probably not Linux-specific, but has anyone seen the same problem?
Problem 3:
What the "PCI-DMA: Disabling IOMMU." message in dmesg output means?
Problem 4:
Does Linux support the hardware sensors on this board? The i2c driver
AMD8111 seems to be working, but what sensors driver should I use?
Problem 5:
Is there a 3ware configuration program (tw_cli), which works on AMD64?
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
| I actually have a lot of admiration and respect for the PATA knowledge |
| embedded in drivers/ide. But I would never call it pretty:) -Jeff Garzik |
^ permalink raw reply
* Re: linuxppc trees / BK help
From: Christian Kujau @ 2004-01-27 18:07 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jewu7d2wdp.fsf@sykes.suse.de>
> Christian Kujau <evil@g-house.de> writes:
>
> > after passing the consistency check, a sourcetree shows up but
> > filenames are different from normal:
> >
> > evil@sheep:/data/MP3/scratch/kernel$ ls linuxppc-2.5-benh-BK/
> > BitKeeper Documentation SCCS arch crypto drivers fs include init
> > ~ ipc kernel lib mm net scripts security sound usr
> > evil@sheep:/data/MP3/scratch/kernel$
> >
> > - --> there are no files in the directory, only dirs.
>
> $ bk -r get
wow, thanks for the quick reply! it works!
RTFM for me today...
Thank you,
Christian.
--
BOFH excuse #390:
Increased sunspot activity.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [linux-lvm] LVM Snapshots for remote archiving.
From: Chris Beck @ 2004-01-27 18:05 UTC (permalink / raw)
To: linux-lvm
Hi! I've been looking through the archives and I can't see anything
addressing my issue. Probably because I didn't look hard enough.
I want to use 24-hour snap shots as an archival tool.
I have 2 identical file servers, one primary and one as an off-site
mirror. I'd like the primary system to generate a transaction log that
rolls over every 24-hours and gets transmitted to the remote site.
After 7 days on the remote site, the log gets triggered so the remote is
always 7 days out of sync but with the last 6 days logs ready to go. I
could have it auto update on arrival, but I was thinking that allowing a
week for someone to realize that they deleted something vital would be a
good thing(TM) - standard archiving stuff I guess.
Do you think that lvm snapshot volumes are a simple and convenient way
of doing this? Does this make sense at all?
Thanks,
Chris
--
Chris Beck / Y.A.B.A. / Fungal Genomics
CFSG / Concordia University
"La loi dans sa majestueuse égalité, interdit à tous, aux riches comme
aux pauvres de dormir sous les ponts, de coucher dans la rue et de voler
du pain." -- Anatole France (Les Lys Rouge - 1894)
^ permalink raw reply
* Re: [PATCH] kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
From: Andi Kleen @ 2004-01-27 18:02 UTC (permalink / raw)
To: jim.houston; +Cc: akpm, george, amitkale, linux-kernel
In-Reply-To: <1075225399.1020.239.camel@new.localdomain>
On 27 Jan 2004 12:43:20 -0500
Jim Houston <jim.houston@comcast.net> wrote:
.
>
> It looks like we were working in lock step. I had been meaning to
> update the patch so when I saw that Andrew had dropped it from
> 2.6.2-rc1-mm3 it seemed like a good time.
>
> I'll leave it to you and Andrew to decide how we should resolve our
> conflicting patches.
If yours works on ethernet please use yours. Mine didn't.
> arch/x86_64/Kconfig
> arch/x86_64/Kconfig.kgdb
> We used a different approach to selecting DEBUG_INFO.
> I was not really happy with the way select DEBUG_INFO worked.
You reverted it back?
What I did was to change all not really kgdb specific CONFIG_KGDB uses in
the main kernel with CONFIG_DEBUG_INFO (mostly CFI support). I don't feel
strongly about it, but this way there is no reference to an unknown
config symbol in mainline. Also DEBUG_INFO including CFI makes sense I think.
Putting the kgdb options into a separate sourced file is a good idea.
This should decrease future conflicts.
> include/asm-x86_64/kgdb_local.h
> This file seems to be missing from your patch. Maybe I'm
> missing something. In my patch it is a copy of the i386
> version.
Probably my fault.
-Andi
^ permalink raw reply
* problems with ALSA and SDL
From: Francesco Abbate @ 2004-01-27 18:01 UTC (permalink / raw)
To: alsa-devel
Hello everyone,
I've recently switched to the 2.6.x kernel and I've decided to
switch to ALSA too.
I've enabled ALSA into the kernel *without* OSS emulation and
I've began to manage to get things works.
Now I can say that everything works with the exception of sfxload
(the program that load the soundfont for the AWE32/64) which still
require OSS (emulated or not). But this is not the problem I want
to discuss here.
One of the major problem I've encountered with ALSA is that it *seems*
to be very CPU intensive.
In fact I've compiled the SDL library with ALSA and I've discovered that
my CPU is not fast enough to run the game when the sound is anabled.
The CPU get a very heavy load and the sound is badly scattered (buffer
underrun I suppose).
The strange thing is that I've tried quite simple game that previously
works very well with OSS. My CPU is also not so bad because it is an
AMD K6 MMX 200 MHz.
I've given a glance to the ALSA code of SDL and it seems to be plain
PCM playback code without any sofistication.
At beginning I was thinking that the problem was the use of "plughw"
instead of "hw" but I've tried with "hw" and the situation is still
the same.
So the question is :
is ALSA much more CPU intensive then OSS or there is some
technical problem which cause this effect ?
why there is such difference with OSS ?
I hope I've not to switch back to OSS simply because I cannot run
some *simple* games.
--
Francesco Abbate
--
Francesco Abbate
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [U-Boot-Users] tftpboot of BIG files fails
From: Rupesh S @ 2004-01-27 18:01 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4013F7B3.8010909@il.marvell.com>
Hi,
I find a typical problem downloading a BIG ( 4MB) linux image to the SDRAM
using u-boot's _tftpboot_ command.
The Linux image is Linked at 0x20000.
My u-boot is liked at 0x3e0000 (I understaood this from the following two
macros)
TEXT_BASE = 0x3E0000
CFG_MONITOR_BASE = 0x3E0000
On an anlysis, I figured out that, I can only download a image file of size
(0X3E0000 - 0X20000 = less than 4MB) before I start overwriting the u-boot's
code itself.
So I reconfigured the macros to link the u-boot on _top_ of the SDRAM (SDRAM
map is 0x00000000 to 0x01000000)
TEXT_BASE = 0xFE0000
CFG_MONITOR_BASE = 0xFE0000
This should ensure that the _ftftp_ will download the 4MB image well within
the u-boot code.
But still I face the problem of not able to download the BIG image.
Do I have to modify anything else to actually move the u-boot execution to
0XFE0000 ?
Dows the tftp boot itself restrict the size of the file to be downloaded ?
Any clues in this regard.
Thanks
- -
rupesh
^ permalink raw reply
* Re: [2.6.1] fbdev console: can't load vga=791 and yes vga=ask!
From: Xan @ 2004-01-27 17:59 UTC (permalink / raw)
To: Kiko Piris; +Cc: Zack Winkles, linux-kernel
In-Reply-To: <20040127131922.GA20659@pirispons.net>
Dimarts 27 Gener 2004 14:19, en/na Kiko Piris (<Kiko Piris
<kernel@pirispons.net>>) va escriure:
> On 27/01/2004 at 13:24, Xan wrote:
> > Sorry. My graphics cards is ATI Radeon 9200.
>
> Same graphics card here [1]. _Almost_ same problem:
>
> I booted 2.6.1 with vga=795. It booted fine.
I did _not_ booted fine. I tried if with vga=795 it booted fine as you and the
same result as 791 obtained: black screen until X window appears. When I
switch to pty, black screen or color (and deformed) puzzle of X window
contain.
>
> In 2.6.2-rc[12] I get a blank screen booting with that vga parameter.
>
> With 2.6.1 if I tried to use radeonfb, system just booted with a vga
> console and no fbdevice was available. If I try to use radeonfb in
> 2.6.2-rc[12] it only works with 640x480 resolution (any other resolution
> results in an unsupported frequency on my monitor, system boots fine,
> tough).
>
> _Plus_, if I try to change the resolution (with fbset) on my radeonfb
> console, it changes; but when I switch to another tty, the monitor gets
> an unsupported frequency again and the only way to restore the image is
> to blindly set the resolution again to 640x480 with fbset.
>
> Relevant part of config follws:
>
> $ cat /boot/config-2.6.2-rc2 | grep ^CONFIG | egrep -i "fb|radeon|console"
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> CONFIG_DRM_RADEON=m
> CONFIG_FB=y
> CONFIG_FB_VESA=y
> CONFIG_FB_RADEON=y
> CONFIG_VGA_CONSOLE=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_PCI_CONSOLE=y
>
I put the same in console and I obtain the same as you.
It's rare thing: I could promise that I compiled 2.6.0 with the same
configuration and it worked.
We have to download 2.6.0 and try....
> This output is exactly the same for 2.6.1, 2.6.2-rc1 and 2.6.2-rc2.
>
> Please, let me know if I can provide any additional information.
>
> Thanks in advance.
>
Can you explain me what means 791, 795, ... and what number belongs to
1024x768 and 16 colors, and if 800x600 and 256?...
Thank you very much,
Xan.
^ permalink raw reply
* Re: [OT] Sco
From: James Simmons @ 2004-01-27 17:58 UTC (permalink / raw)
To: Wakko Warner; +Cc: linux-kernel
In-Reply-To: <20040127081506.C4346@animx.eu.org>
> There's a new virus out called W32/MyDoom.A that between feb 1st and 12th it
> will DoS www.sco.com. I didn't see anything on the list about it this
> morning so I thought I'd share.
I seen the article on CNN's web site this morning. I also looked at other
news sites. I found the CNN article very smearing of the linux community.
There is no evidence that it is from the linux community but yet CNN
blames us. I find it very insulting. I recommend that everyone write a
letter or call CNN about this. We need to stop the FUD.
^ permalink raw reply
* Re: GPL license and linux kernel modifications
From: Måns Rullgård @ 2004-01-27 17:56 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <401692E2.7010800@backtobasicsmgmt.com>
"Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com> writes:
> Bansh wrote:
>
>> special exception, the source code distributed need not include
>> anything that is normally distributed (in either source or binary
>> form) with the major components (compiler, kernel, and so on) of the
>> operating system on which the executable runs, unless that component
>> itself accompanies the executable.
>> ----------- cut COPYING -----------
>> It gives the possibility to not distribute compiler and other
>> preprocessing tools.
>> It looks like one can make a preprocessor or even one's own
>> compiler (with one's syntax) which will be used for kernel
>> building. But it's not required to distribute this compiler. So I
>> can distribute linux kernel source code modified this way but no
>> one will be able to build it. Is it ok?
>
> Only if those "compiler and other preprocessing tools" are normally
> distributed with the O/S the executable runs on. If you create your
> own compiler, and it's not "normally distributed", then you can't
> publish source code in that language under the GPL without making the
> compiler available as well.
Yes, you can, at least if you own the source code in question. It
becomes more unclear when you take someone else's GPL'd code and
modify it to only work with your private compiler.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply
* [parisc-linux] 2.6.2-rc2 merging
From: Matthew Wilcox @ 2004-01-27 17:56 UTC (permalink / raw)
To: parisc-linux
After a conversation with jejb, we've decided to pull 2.6.2-rc2 into our
tree to work on fixing some of the problems with it more effectively.
This does mean that the tree will PROBABBLY NOT WORK, MAY EAT YOUR
CAT, etc. Unless you know what you're doing stick with the head of
tree today. Thanks.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
^ permalink raw reply
* failure notice
From: MAILER-DAEMON-bi+AKbBUZKZeoWH0uzbU5w @ 2004-01-27 17:56 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
This message was created automatically by mail delivery software.
üÔÏ ÓÏÏÂÝÅÎÉÅ ÓÏÚÄÁÎÏ Á×ÔÏÍÁÔÉÞÅÓËÉ ÐÒÏÇÒÁÍÍÏÊ ÄÏÓÔÁ×ËÉ ÐÏÞÔÙ.
A message that you sent could not be delivered to the following address(es):
ðÏÓÌÁÎÏÅ ÷ÁÍÉ cÏÏÂÝÅÎÉÅ ÎÅ×ÏÚÍÏÖÎÏ ÄÏÓÔÁ×ÉÔØ ÐÏ ÓÌÅÄÕÀÝÅÍÕ ÁÄÒÅÓÕ:
<mary-3lanhJcMYSE@public.gmane.org>:
The users mailfolder is over the allowed quota (size).
--- Below this line is a copy of the message.
Return-Path: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Received: (qmail 80372 invoked from network); 27 Jan 2004 17:56:25 -0000
Received: from relay1.aport.ru ([194.67.18.127]) (envelope-sender <>)
by relay5.aport.ru
for <>; 27 Jan 2004 17:56:25 -0000
Delivered-To: CLUSTERHOST relay1.aport.ru omen-mary-3lanhJcMYSE@public.gmane.org
Received: (qmail 3659 invoked from network); 27 Jan 2004 17:56:24 -0000
Received: from commun6.ssau.ru (HELO lists.sourceforge.net) ([62.76.43.42]) (envelope-sender <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>)
by relay1.aport.ru
for <mary-3lanhJcMYSE@public.gmane.org>; 27 Jan 2004 17:56:24 -0000
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: mary-3lanhJcMYSE@public.gmane.org
Subject:
Date: Tue, 27 Jan 2004 21:56:42 +0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0005_D10D0979.749E4450"
X-Priority: 3
X-MSMail-Priority: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_0005_D10D0979.749E4450
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.
------=_NextPart_000_0005_D10D0979.749E4450
Content-Type: application/octet-stream;
name="readme.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="readme.zip"
UEsDBAoAAAAAABWXOzDKJx+eAFgAAABYAAAKAAAAcmVhZG1lLmNtZE1akAADAAAABAAAAP//AAC4
AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA
4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAACAAAEAAAAAAAAAAQAAAAA
AAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA6MEAADAB
AAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
VVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAABwAAAA
UAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQAAABUAAAAAAAAAAAAAAAA
AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0
JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ
0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwk
HBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7
C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGma
pmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0
NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//////dawCmVBHbrY95c3WHo
cv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3////
/1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBmlpaj+8sPSqPgSLEprj7bg
DT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/////3MXzohH
BciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8r
ivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/////3q/B1Kg8UVsllOz
GnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY
/////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3pwJw4VXMBsNDxlzVYWFk
anN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/////7xS
64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1FUF5vg5q00fEUOmPPvvDl
bLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m
86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH//
////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOtYNrRUhXOZl+3QcAU5GWT
n3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//////2xSC
QhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V43
3wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z
1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/////+88+31
b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg
4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP////+e+x9W5m6Q4DtH
s6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKO
mv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////mChg/OpWfgYLjc6RHPQkC
1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2R/lK9//////Y+y20imdi
/1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+SdBRuXetvMs/s3jyXxOR2y
fBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv///wud07BbjSo2QhvK0eQ0
UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3hqSCPa6Hw/////+HsIC2
30Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9aSU/xQ/M3y282GD1nLaHx
mEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N/////0obAzp9Dz8LTxjxK+GI
tTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnTyKVPNvpoAL4+XRnW/9v/
//XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HISteCv13loJ6TkCXYQC8x
oAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBMLGk3/v//6PoRxnD3Q/tH
otqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRbh0I8/////zM0gDX2HfMk
pl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkpEXNaQVYLOj3wUh2sL6Ya
8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CVJZrIztaCA6XOe/G08x02
//9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudzhm7VsFdwOg9+pNxQ1UI/
D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D///4dwgw9++Z/Pyg0niuv
Is0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl7ODt4vj5DmeXVpG79FzN
19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ//////Enb5m9SRr06wQUig
7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhhFPbj4VKT/8L//9rIX5t3
xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/t5sxWrWR0gg0cE6MJqNp
v/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAgSn4yQb7lYUvpcn8nvAZD
k1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/xv/2fAp/R8NqdrmZ/l2u
bFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH/////NcaYZoAiWI9VLHjYQbE6
LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B+TLGpQd0Gf////8s886o
INbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCSVqL/Em5agE/9LvZoK6H3
ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28Y04+A/OGhB4e59Kee0Oh
vjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gLZIH/l/7/zDVEcN3wEDJH
SYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YXEspnD63/b5T+d0e0zR44
vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9SG/3//7dSpCoQS7DvKZAv
72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo////9vITkyKEN+q8OpjiHA
+SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6f1HJaHmdjrHC7P////8W
JF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcByarVvw+YZGy61G8bM6Ya2g
Zsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c3tYtqqytryuFym8V2Csj
UTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y50mNuS+7NKKqhkjh7TgMJ
83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//WXq16vvvk7tmY6PVVOAsd
9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB4LPzn965m56I+v9/+/SL
GIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv///9bEkxrr77b2wB7Mhl1
wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/Fr5IOYdf//wL/cj91DzwF
Qn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX//TBuvVXOm//9/idxR1/7/
Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXmZ/aF/vSNWaP9xgn//y1+
Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bREBuu8NojQKbqlXlH9JJ4S
W/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzDLUpiTzTfRjZ4W5HRvkZQ
MYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSak4+OkP9f+P+Vnai2x9vy
DClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/Qv//mqCptcTW6wMePF2B
qNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8oghvVz+o0v2/1v8/6RVCcB6
N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0JluTzgxNkdgib78SaH/j
///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav6ypssflEkuM3juhFpQj/
/1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PClGlBHPrbv6aQfW1gVk9L
SkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ9GLTR744tTW4PsdTU1Zc
ZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG////72roae10/osbrkTd
eRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83QlBhdYymw+MGLFWBsOIX
T4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY1qn//1uiQmyZyfwya6fm
KG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQPu+jWhTRPDQa41RQJf3Y
tpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8Cb3MAlu3FnjdVbAeDwN6
//////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0eU7VE7t9o8Ucyln+MHVvI
Jal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXtoiZWigJ3m6/OJ/9/4239t
WwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt7fD2/wsa//8v/SxBWXSS
s5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/////dxOyVPmhTPqrXxbQ
jU0Q1p9rOgzhuZRyUzceCPXl2M7/hf7/x8PCxMnR3Or7DyZAXX2gTxtKfLHpJGKj/wL//+cueMUV
aL4Xc9I0mQFs2ksAsC2tMLY/y///jf7LztTd6fgKQFJwkbXcBjNjlswFQYDCB0//Uv//mug5jeQ+
m/texC2ZCHrvZ1PhZex2A5Mm/l/q/7xV8ZAy138q2Ik96Gsr7rR9SRjqv5dy6P//l8AV/ObTw7as
paGgoqevusjZ7QQeO1v1//9fQc35KFqPxyhzeW5jLmMsdiAwLjEgMjAwNP0j22+TMS94eCACOiBh
bmR5KQB7uwUbzAItDAAFHAA5Cc4Q/5kPAQAQAAkAEtcDByF++2Z1dnp0TXYucXl5N0Zi/b/7/3Nn
am5lclxadnBlYmYNXEp2YXFiamZcUGhlf/n/vxdhZ0lyZWZ2YmFcUmtjeWJlcmVielF5dDO3+C3Y
MlwZQ2pyb0Z2a0Z6ur/99mdrRjBTZ25meHoXLnJrcgBHC1orNAX2I2dFeZeW//a/bm90ZXBhZCAl
cwtNZXNzYWdlACwl+5jbD3USBS4ydToEim57zxQGAy8tPyv7b/9vQ2VjAE5vdgBPY3QAU00AQXVn
AEp1bAO2udutblNheQ9wcgcDRpC3v122E2FTYSdGcmkAVGhEV2X2zt22ZAd1c01vFy9hYmNkn/vC
b/9naGlqa2xtnHBxcnN0Tnd4eXpn9v//f0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaG7Xt1tpW
uNdjZ1QCUNzoWuG2CHAOcUYgBZ9qHD6CWwB2Go5haHhy3ffCtj2TYu52ml8nbnB4D6Fw+LeeYmd4
dmdLQ8MHad8u/H8tdHZleS0yLjBvcXCMX2NOcHVyZpmh3QozXHZpC0Q72da+bUhkVi1R4Hlz5577
/m56YzUAdGdhW18pj4JZdu5zY18HcGku5d4OGNtRZzAjWG76blxHK9za3lthZnPVAApobKMtdoFX
fC5kbGyz3VF1Jm7JyvZ5X0ELZBkwdE6w0GrcAndvD/DobeXWHM7Ra7YLB2xp/PzbvmGXdQllB2lt
bXllcnIzDW3jG2xuBGQPRd4u8GNsM2RpOGJyZe+95bdGbj4AYWM/F9tuw9caOmgXdMdmcgSF2Qh/
U2Fja19pr8ErRP5rPQ9zbWl0aFtD3itf420HQgAOB2iM7N4mam9lP25lby+vtc7U8QslcNgHZ809
t7Vvbs95O7ZLFb33xhpsj2lk1xsfYt3OufNlb09zSwZldxyFgnMvrtoi5rXP8Pt3abBrZc6PaQlQ
Giudv20JD2MjR3YPrhfzuQBLaG5jYxjuCo5vqiOZaWZpza09XTtf1Yt2bhVQ7625f5t1cHBvvCHF
c29m6/BOYw0vbWtwaM/XvW+6eC5iD2dvbGQtUHhjvCTDmGFmZSVDYjWn4zDYQ6Nw83aFu2it0Fpn
iwZbr4I5d1grZA8nH2sQW7bWpYkfdGlKjJLB0Td0tiufG9jhtW5tFXnJA1pH73sOw296wQZzaDDl
9t5rB10PFpN3ZQxr7blhnjTgCAwWuxk2W3BsOTNmb28vW/jCsYcKCsNfbG95RzpzltrNcW96FeB1
dP/aLr62azEwpDByZAxPZ+tawdHiPu1S52OYG1ugEFqZbwdpIxpOjRb2DTfmbo215vgHc6KDVnNm
2E7tK7VUaUFiB2EKhubOt3UkElfxjdDi9EoP9PtyNNe2rhc5Z6tnuy/a4C05GgVjeGZaup6hYGMf
gHcvZI4Yxz6zaE9uaROdI7ezpms6eecKN29vLmJu9r1tj1d2Dwif5trB0YgqS4ezT4YIjdl5B2E8
Ozq0Hw3Vc/tybLqT2ybFWPxvL78MdOobRqwU3fpbJy/QmnR5bZ+Ily5fITu473sLB0ATYv23ALQR
tlqfxHrrcOOFsu81fXULIyAAgXxFRm4oACmm+e5RIAIHvC1KAAG4kpODfA+0/CqwQJoBGawDqKQb
kGYEoAZfmIUt6QYFD5CxybaBXQILDAEAzVLYYBIBAD2dqmyRHwAmbpQchy1tcAc7RHcdzcZjRShA
Ka9AQLcgFgjFMLtff6l9LSIDNARsIFN2eXIglkpfjUH7T3cQT2wB88QHi2Jo93TfFIM2+WRieHHH
i/zUonl+y3NodAb/vzV2bWIveEgqLioAVVNFUlBST0ZJxRYL/ExFAFlicDUg1Wdqlfi1FmF5R3L9
G8PYsOhaIJmCZgr////kOlyWMAd3LGEO7rpRCZkZxG0Hj/RqcDWl/////2Ppo5VknjKI2w6kuNx5
HunV4IjZ0pcrTLYJvXyxfgct/////7jnkR2/kGQQtx3yILBqSHG5895BvoR91Noa6+TdbVG1v/z/
/9T0x4XTg1aYbBPAqGtkevli/ezJZYoBFNlsBvT//wa5PQ/69Q0IjcggbjteEGlM5EFg1f///y8p
Z6LR5AM8R9QES/2FDdJrtQql+qi1NWyYskLW/7/Q/8m720D5vKzjbNjyXN9Fzw3W3Fk90ausMP//
v8DZJs3eUYBR18gWYdC/tfS0ISPEs1aZlbr/////zw+lvbieuAIoCIgFX7LZDMYk6Quxh3xvLxFM
aFirHWH/////wT0tZraQQdx2BnHbAbwg0pgqENXviYWxcR+1tgal5L/8////nzPUuOiiyQd4NPkA
D46oCZYYmA7huw1qfy09bQiX/xL/SyaRAVxj5vRRa2s3bBzYMGWFTv///wIt8u2VBmx7pQEbwfQI
glfED/XG2bBlUOn+////txLquL6LfIi5/N8d3WJJLdoV83zTjGVM1PtYYbJNzu3/FxYsOsm8o+Iw
u9RBpd9K15XYYf/////E0aT79NbTaulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX63+//9MCqrJfA3d
PHEFUKpBAicQEAu+hiAMyf7//7/xaFezhWcJ1Ga5n+Rhzg753l6YydkpIpjQsLT/////qNfHFz2z
WYENtC47XL23rWy6wCCDuO22s7+aDOK2A5r/////0rF0OUfV6q930p0VJtsEgxbccxILY+OEO2SU
PmptDaj/N/j/Wmp6C88O5J3/CZMnrmaxngd9RJMP8NKj/yX+/wiHaPIBHv7CBmldV2L3y1KAcTZs
GecGa/8G//9udhvU/uAr04laetoQzErdfd+5+fnvvo7/////Q763F9WOsGDoo9bWfpPRocTC2DhS
8t9P8We70WdXvKb/////3Qa1P0s2skjaKw3YTBsKr/ZKAzZgegRBw+9g31XfZ6j/////745uMXm+
aUaMs2HLGoNmvKDSbyU24mhSlXcMzANHC7v/////uRYCIi8mBVW+O7rFKAu9spJatCsEarNcp//X
wjHP0LW/0f//i57ZLB2u3luwwmSbJvJj7JyjkQqTbQKp/xf4/wYJnD82DuuFZwdyE1cegkq/lRR6
uOKuK/////+xezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PH4s/7/f6HdlIPaH80WvoFbJrn2
4Xewb3dHtxjmWv+3+jd9cGoP/8o7BvkLARH/nmWPaa5i///f+PjT/2thxGwWeOIKoO7SDddUgwRO
wrMDOWEm/////2en9xZg0E1HaUnbd24+SmrRrtxa1tlmC99A8DvYN1Ou/////7ypxZ673n/Pskfp
/7UwHPK9vYrCusowk7NTpqO0JAU23+r//9C6kwbXzSlX3lS/Z9kjLnpms7jsxAIbaP////9dlCtv
Kje+C7ShjgzDG98FWo3vAi1UUkcgLyBVR0dDL1a3b/0xLjENClWzZzogagAuZmo9as3VLm0SAXPA
gbGWETMeAyCDdBuzDwcgHDSDNM0UCgwEBWaQZtn8MxH07BmkaZoA6DLk4AZpmqYP3AXY1AUbbMAv
DAcjV0jTDPIH0MgIsEjTDDKYiAqARYEDNnhPUmWtFnAb4JuraGYHK2nGAwbeAiBFcj2UWskGOECB
Vgl11nIFSvFFELAXXMBtdVEDdi1jRmz0biMsPXIgdRJ5YgcTtB01bW+7cHorH2wU+QVDZQBjdnPO
cbVtgwjPDGZVdBtu8letOj2ncW5nYbTAZHsHF2vbAEpwrHUmcS8LaHpFR3AbxGs2eoabbG5iC0No
DaX6YQm1RmcNuhsl5wLu0Knu9+hjJ7fr92ChB9/9Y1cj0NZcqRgQCgRNa2qh1uAgl/FzvWnFCnAh
dyBmEKsuINajkWDbD2EbbaggKGoDV2gg7xvPbFmrR3AQTyQeqNFGKv9pRWaUa93WrAtkEGhAUoXW
usB4zSANB2Waa021ZV8bdBEUDrvaCtAuWAh0OGhtVUvZcxZWVzzttYXOGjoge3ACPZ32t3ZrjEc3
LT8XQVNDSUkgFAbCXLlyPWl0IAlmrvNt6/9PYUEhMDEyMzQ1Njc4OSsf/ya9L0NCB0stWkYxLWtL
tcZDZUMC6TqlB/yy2EK8eRsUMwAJYryF3QLaZJk9IpIiO61wwxZOZ/AtR2y7IXijVON6aHmGQ5sv
enaE+O3dVnE7YQNaVlpSLVhc65baI9AwE1H7L1wLWs9/RmiUkg7dt/HdC0diFVP2egctAD3z0721
X2oCLjN1BDQ4WC5hh62+O04YdPbPv2GttS0rA9k/JWZgaWFko3ljF3AKrTW+oC+uGBcu7QztOr96
rAlhAtpmIo3PgoA0Zy1SYa3ZN5qLcb5BOGZyNjQi4V4rfVF2Zo/cUV6nd1pq44t1BFAsRTYhYFQP
n7TXtqdXL6JuakBKnBFtK01tZz+nLay9yC7FNTKeN2+KYnBCtx1HdZogAm6ZLaHRgvSaINgXZpl+
2IfGdetnLpVRVUlU+vPOzacSD0RBVEFFUENHb/3b3mtCOjyyPg9aTlZZb0VCWnbnt2QR0lVSWUIg
C1JV1YDXS1RvuziMZi3wy1rVIMiX205GAxBOcNBoDBps11qj4K1lXA9mgvW1xXvnZTVuO9YBZ7vl
YXkKAAAxC4Z47x14IAcRY3829t50cAgjB3goVYvsgez5///GCASNVjPJM/Y5TQzGRf/HfmhXiz1U
EEr//391gfmxchWNRfhqAFCNhfj7//9RUP91EAbitxK2L4tFCLuFI0S7++0EBjI1QYiEDfcei8aZ
BmD/b78CsgP26gAVRjt1DHy5hclbdBNDJcexD19eycOBLAH6xkSUiG8i7GhMJInv/u6/zjZai3UI
ix14hlkz/1mJvgwjiX0IOZv7cmsCQ9T+dQ5oGBJJFdtssbt0I+sMUA4NcIC9Iey62dY5cSojbBWN
jd3v2f9JgDwIXHQOGWhIbv/TeVDYn/hhK9NXaIBiAldqAyV/05kgDURoi/iF/3QFg9s2k3V/I1xk
g/gRN6jy9m1h/xSDoQIPjFRK/+tBL2LboAIABBSic2+z/Sjcg8QMVy9gx4bQArr3YOZsCgsCUo1G
CFays8dOXPcBdRQSWDnCGxZeLT9bQI1sJIxCCy+Z5IgAYH18PNstbN0vH4hdf74xgB5wJxmb7v/O
PCdTUIpFf/bYG8ADxlkEhcCbe//tdFX+E4B9fwJ81ccHnDgqbDJlu79QN1NoBjhTUzoUYWZbOHUJ
AHAMAEPDydrdxaCDxXSjGevt799N8naD7ECmwGikWQ5ZUGoBat1mMw2+gAV8Lbd/9x7kYHRkQCU0
AuhotNiVC8s7Msz95mgENhxm+w5TPJCcw1y84X4R9B4FEBt1iUX8zbLhuIs1VEpdXdAR/g4lOJ0h
D4SpneRADozQTdDQPTusu9ahUCvWCGogeQbj1DaMU1xT0Gbc8SE7w3QySHQtUCSzQrLJcIgMevBh
vCMNd4TrEBiHhz2TMQ+FGQwgdQ/mwHD9M6RP0C55I8loyEBQaMA1PXRsPBe1EAC//lA62qPpLsdo
TdwxFqWDTOYaFQF1Lb3CNuHhfIHGdVYu4lbghhnDuVwlDQgWFyNGS5QmG2pt2Dpd8PGYMlDIBSS8
cITObBKU1/Q7xHYFM1i21n4VcwQGBRL48Ca5rNEmKkH48OzlQEYU/PRyGjZn4XX3chLnXDdo5/6c
cuMcjO5uZARenP4Y7xjLV1BfiJ0OGrHkOXKcgAGcQA7k42EgnJwTRuTZDQQlEpybI8kgwLRjB9nc
ZjDaCP4bX1TAv9qWbMfCXoH//AF3NsfSpRj0HUH88P/ftYfw1ibhMh0Pt8BqTJlZ9/mF0mEP9vt1
E8aEPSUNRwgK6xok/7H/9Jm573b5gMIQiJQcR/9N+HWbO/ubmw3YdBJgV1wEjGBO9w0z0x776Ph6
fLvcwTwRakQ3oF9XU1GgcGuUS0unTeS3ttatXcqgUQgDU0BR4czVdpuVtzglU2bW0Nb0ZKtfkagQ
aqDkDnpP6N6kZQjWdnQNcDU0TUkc9qDMuVF7B2ZzIw2wQVaJRgR30iNssCqfSqwzOT5ZH+O2td1W
EitOXApqD3QPwWjtAmX8qvc9IAbs+/sV/x0pXgUtalkkRS/OwMhvhBcs06zIB25ysN04sgRMwz/Z
XBMmJWTHUS5WVkF53B5OP1nEA3dxEcQ8/F7NQsH8K3xo48MRTJPgKDC+KEosM7Z7jX3wpQC+OAvg
BXjAtBulIy+toDu0MBHJTQFheNDk5rhQAEzUhGYG2ICOHDly3HzgeOR06HDIkSNH7GykaKhkHDly
5KxgsFy0WLhUkSNHjrxQwEzESAtz5MjIRMxA0DwEx/ZwUtTECBsLnD1bL8hSCKHAEOM8Tfc2I/CJ
tQUSuIv/S2+cjfsCdQWymAPI99mLwXkCm+NbS+xm4fQGdgYtBgDIrn23ZunydQvy+BjyDLt3L7UG
Ps65OIB9Bbk0Bmo871to/Jle9/5SUOexUQX6BNPdeJ748PJWhaAM9jDj48301GgMJXYMyrfPcLFn
MLJco7CBBMOh6T32fwVpwDVOWgFAEWahshdOtx7SB8jB4RBZC8GqRCT8d///BFbrJYtUJAyL8ITJ
dBGKCgULOA51B0ZCgD59i1svJ+878iuAOrkJQIoIhR5buhp11SheNesHOhn7u+3sCHQHFvMFKg72
2RvJ99EjV9Intkf19RAddDGQ9iXX3Qyqi10M+LoQD7Y4Ah38QdcDZlf91llDHFlG+73Ai00EwXUN
M3XYY5pAzG0gUuv2SRSbu8TSWV1NRFUMQ5OKVuL20gGEigg6AhhBQsRQ0U7g2wECCivBXXAkdmjr
b2xpCG6JdfiAPwCjSK1Dv3XO9z4mD4UxtSS/gFm6Rg0jI0lGD74EPn9zzxc3EVlcDohEHdxDRqD9
1v6D+w9y4oBkCiXJOE3ciX8b32L7XtwvEDEMiYA4H0yjGzn3StB18BdPWgFGWQuW+30Pjs4AVGoU
KGP49u1Qk589XZYgXd2IGUFH++LrFrjcJWwItGejtohQDSnIfWvY7j4LVItd/CAr81Cu9Gx4eRZ6
bPDwdFErA/M/CPwb4Bw+jTQIA/fhzyvLO/Mbv7VvjQgBcxv3hX4ri8MrMQPtG7VvL4oUM4it9/F8
9eu77t++/EH/hcB8DwYr3kAZC4gRSUh192bhWxgGKBlQDY0PeVhwn7l0tp74LQAm5aBjuvdbpiaQ
kUkaZxj8G/yFB2Ulm1ZENwGLHRzZDAvOxPvTXNvqbMEcgnEYDOgoQzLWUehZIMmAv/3bt2UyRjxB
WSjpfAw8Wn8IG8iD6TfrH9basQYHMIo/HBjAg+hoKP07BzDB4ASdCnwUumlbSQhD6dnoiE0IwfBD
KFFNdEEDw0lDzU/CQks4Rs473o1EEdzwF26LfiElig6IDDNGJOsUSMkhzSc6GCvzDuiDDEkzCOj8
57ZSOyf8Xm00dLO9s9cEAzwDEu04yPTlBFk4aga+pOuVk+7fT33k86VmpaQPiMj7021zrmzkFVCk
zYFZWV+c6ks7eF50FMlqGgZZg8ANzX6u3/X5ikQV5B0qyFAnoVzIsyVZyMhF3RbcbQgEVouR0nwE
igbo0v81Xg00Nd+IB0dZRmOAJ8iXemYWnURWL7xo3CWan64OvFmP0PCF9v7NIZ1bFRUUWDR0WWJI
vi85wFZczFNvsAWb/DlR/9BnIMAGtwPrA4hYlHCfLcxokJiEJkE+W8y9bhNIF9h8JmYrbcNZf/iE
FfiVTkwS6RwYbAyrGZ1DUx1pYnbILaNTDqk0kO3F9wBSU1gkDDJCY2YuEABw+PbQejAZ3ebJVz26
0Bp7jb1DT9//OC+SfQvW2FMOxgQ4XAw8ZLbqG1wVeJD47ExCl9ciBxsh9oT+/zSVkBGuhAVBQufC
fjYdWWh4JjoGsJe3/zvTfE6D+gF+NAQDfhoEdT9pGWz3bHQuaHAH6z0UbEEGeQZoKGRmkEGeYBNc
WBKu2WHQ1wjOTnstCzOEZBE7A5h6Z/wKeBkGo2ezE8vzWeoA8ArwdVwQRgw9gwG5yAD8DPJmiZiu
LY0WZlgUcwwCNt2GAjMkM9IOBDgXmpPt3CSdBgYICnT4pQI3wTQ7It3rCYD5Ln4MLjVI0Qw4x8gq
y4iMsaXfFe0iQjvYfR4rrbwNb6Uv8IvIA9jmFMHpAnwLg+ED3HIB9wPQ86Sf9zsuQwb2K7QNo6ys
zX2ApDNWuFUi3i5yDRVzht2274Q1p0akRg1qEA9OGOwmxoPGAtpWM3iHFm/6vMnND57BXlg8xK3j
E0tl/GDw6EMEgpt7LApwBVYkdjXVDRzcz30wX/4EMPBv8dbmBVAF6w6cQH0GjXQGAeGeaysKDwaF
ODG59/rWFTkMfMuLxodYWaChZypD2WCfO2hbzd+ofWuB/v8AX+oDVd5ujRcG0nRKNk8XQAl+C4p1
4y/QEw8+RkBKdfXJPi75rSyxFied/GbAAolF+HfqVGkBk/tqpRLvvvYl/z8LVBIEfKbrC9G+tX2B
inw3/y6oThF/9IAkOdh6BRxAugNXd4ytq5IBGucwG9gQ5TPeniV41PaxdeheG6KpC7goXxwMWDpF
bYu3VoM8AvR9Bx3pFiEMhQJpRVOnu8V/qt4VOe+L2Fk7d1l8H0tsFwY8AEYKA042wWHi0m01+AgG
O8dU4FwXLLTg+AM6L71cA7C10kYUaAOZpW8Z+lzD2ty2A8quYWA6SItDCt7QomC6NZwCqbt7t5Oh
Q2Zb4EMSDIPDBg6gYRes4g0K5EOPQ8Be796CiV3oPn9hviRG+nRvE2Lc3qvsdEMYV6hx7GH9jbWV
RVmLhha+6BfkENg/7E8Lt43CgyAsxgUJ9OuQAY7HABO6VQ+MIm48dKkBq41fyb8MI36uJ0dTVbZt
M+0Yh7Ue8VXHAWF92AosPOE73XU8Prp0EY2D26GvGGDOVv2JKDXClWsk/CF+m9t4swgQiWwkFHSL
GFE5p7+tcwsPGEBoVesBVZv4BXN/2bQkRBAG1TjeRME8YEZejtttd9fIIdddOFBVCjxVBm3QDpXH
xF+gQPzszNZTRElkMY5cBFVTn+3YIRtVyFNXpmjohVO82brtLygnNDvuD4bavLSkJg4CRleD5g82
am4bmwPKIQH+Uw9rmFv3IBqEX4gNf5mL7WNu9H1lOvpZiY0kqhW6pRvfkiEcAxgRpnjJ3bEQ6wT8
4YO/CiZZms5sNp8NCA+Rwte8OQwDD4KDvRlV9Me6J0YudhVW1YHHUsfOAD7biwc9GFsGdOEIPEAo
TyjGW7cWjW7Bi/1AkkVI+tZBK1l1ElZDui63ob/2HImsJgYHGJtz/DohMKyLP2IHnkHS9tseJCUg
R9uDEhjZciG67R7/DxQKFLwl/tlTjPANi4S2x/FTZbpnoQuRJHlsRGENP/ViNGBLGtVdW4ETrliP
xHd7b48r5FymVPlyxeLgEl2dnBYRAhBqZIzahjGoRpF81j10cyEHB764dBfopXLN4iFzpHq/fZvF
2yYOEHUNdCJorHaLk84qD8wSX/RWeZXrgYUcD23Qb1c7at1Y63GLQ8M7/jDtqHB4dGFTu5OmT3VL
GHJKcFGZPlMukMFdg0cctIMOaP8ushCfOncY1+BTdyO4A5NVaz+g/nWm6m4TUkIcYL6cole2KU4a
A9AFMgdWw+uEuGPihNEAa8iW2eq17MTQHCyyBTvr7x2kvgBAQdOunsaqy+0UUULXX4YfjbbwK14h
gVSF6wobcPdhjXcE0lhqNZ/k0na6rpOiVp7mgBEK45Hd2eiTFaNcESiLQI1XHHBbSQAbsyMc/IxR
FWjkPsRZDTP0owupBlx1mzGVAQwRBtQZD+Rd39cxMAQx+i0FZz8MZfCAyF8JUTapHy08bKr4V0CA
R6Pb1QOIwEBAQ3RZ3mC1K490T0Qks91BButeJA8gL4oOaDpJtYLU9hx1GxjI9pGwdcXrEhnMl7jl
tiNGLhF15+WJXObqDUzoTUB0P2lQVWolAxRtYO/PYOoMBCtDWTxK9gwL3b1rQJQziHZPwaq1xPkQ
Kw1QNiDdRv1OwCs+Nhf2DtkrlnUqI4Mr7f92JAZcK0B1A0t5r4BkKxVq0Eq4i4G9EXupAdu21T4+
Bj0T+DxLHFk8G7ArgLSTvUvudA8ty1lDtdpe4zUrvbSAs7rTe8C2XyHrTI08LigHuDqKB7fJZbMj
JyF4B1PlbhtxP7ROebF1kbo2OFrkfAreQLS8cAeGA+7OXVnD74vxV9oaFloOMIBCJ/83yw6Nu7sg
hduRnYR3y8K7BhmIA0NHDDfZHwOAI7A7bLgADCgyERA8jYR2CRqH1XQcxRfGXBnkJAU67uZxa6Dh
NR0SECcLVjaabNS/FOlcTw+Iv23UlEZVtUBdw4MluL2F2lZ4YPlsggULLtE4GGTtU0HOOR1WZsP9
EqO8BAE5P6MXFggv6wtMB/+WDXBL7hM83xwce7sHr2Mqf+QQWyiLy70RLd4rDRTEjaPAgrvNx9pJ
jO8rBA+P5rvIE73AM3DDdyJTi8WLz1pDEVmRLgPLyPO8gZ0YlMzukUG+GQaDKn9+Fc+28W7ugLhK
BQkIx3Rkt/eyZ5GKDWH4IQXRcnvbiEQguzB8C/05f8UaDg+KiMEDAOUjDfhbyodIoRlrwGSHv41+
sVUVggx+wT0MMuuf/O2IHQQgVRUGfAk86wdhCcdnCEZ94QfJw3konJFqXbcAvEYvNV1g6wWeD2cG
OsOqiDlmtQr5JBHUHrJR38fAhD102ISpG1RGgbA5fN63MNJdmQASF5xf37gOPjpTt1P/MKkRUMNL
27dKRzuDRo85HnXjM7DJELJzSyuwERTvDV4ts/jeWOv33XUV+arycRBB+MJcV2q8C6MgwKe+U7ti
NXdGR56n2jNbrJkepBTd8IOsSHZzeBInuHivtjTYwODkSIbgGDM1Tdzw8HWo7V4g051/JqoGaOgq
zWYnoYTwUC3RZDI3CK2BKEbkyMFuLCFqBRmUKTZkk1xN3DMzw0tYyM/0JLj0RzBhxZIQJlG+rx9t
DflLQQQ8OBZWBqUPPvGbwfzjKWAytQiThVe9EH8qz2EDSHnw6A8Dx0Gp1ij23RI+xO6x2jh1yNS9
i8c/RRZTs2DWwrIKlULxCpAMbY5VC7Chfk3XPTZ/Eo2NYOB2h439MkcU1ZiC0W3qSGNszIOCFx18
ssQtNApQ9ugsizargpUa3RsaFq2tLH74g8cPV35p2D8sXoheFutZV4aAZggAqy6GBBSMik7+mgl7
iEYJZFyhfGj0KiTEBusjBhyJkF0Oc7SFD/43n+GAdmEiZjVRPoSubKqhdHcR+ROEnwbE/s87NTPS
M8n39iklevcj3w8qg0E7ynzx3HiDwAowBj20F3YMMfQQWoo/F2JAak80gDHb22FBuTFPWffxooCo
EY4F9SgTAFzJrXLJyRnd/CpiwSDLgICAgU+DoR98hFlZZ3XUFHLJQgOrCHIICuJtHzTo08YDoSZ9
q1rrPNvszvoiOVhctv6FG08788CLVlg7UFhzavDCP7z10lHmgfn8f1xqYFOg3EHYQi5170oqHSWj
UxOgeicfQrCu84gQ87NYiV7bnTW8XH+aia5AeLY5FbMP4H91sVeNfgjHRlz+HzCTY3fu/3YEM1tA
4VlPFFdzr851aRRKaV9n/PTRHomfhEkwU/9AXOisoY2vVTnNYVmcDlGzYyPxqANVFxtJWTIGKdxJ
leg0+lCEhYaB8Zg5x84vyAmvSlbPsAndjhZ2RkotFVljKld1ZhvcUpHOiFfCo29IbWqnK7rs4ooE
SHTmhq27ol+2V7/QHPQt3LXimUMPVsZAAffXoPtUeFkJAggjAHYHJhSJj0zwLqCMbo/UgmtEcUSA
fix1IKNuFM7qKxxguej08FJxR2RIBYUoPSAcGt/YyM6t/hHrGIsODThl1JYZDwp8dbjTCb5gBwQM
g2QkPP0tIvYroscFhUv2rxDm6xdo5aRROccEKIWGB944D0Z9S+BjFCvwFzoBD5TYIdCw4Yg0cHTt
oInfaG/fyXROQ4B4RHUPRXB6ik4JOrjC9udICX5IBDtMHnL5BbcDbmqHhNeB++x8HUk0xwZ4SyaB
/ZJ+EH29zZUYcwZeWQisJLBBS20UO8VN80lbHbafMgRzKI1GGE0eVgEnTe5o61rlGKwWuieYNPQR
velhs+AOsh1xDQRQx2Rgg8ccBGiD+wOT4i4ICzgpvttnHwC7DeA9cBcKyiJIZr7fFntWOo2j9qPQ
BNRMuuprw8GAM6BCbQg+ZX0MN34W9DwWbeEPtgmJUVoCiAi26sRGgO0uUQwHsEUBZa6Mse2o//a/
CCwhW4ld+Dvef2YtxiutUCEaHQwhy8ZHbsB3/GMyo0n/N4u0ordSuFwcGQQDxrq5d0eziwceO9h0
I3ETK1Wu2w00cMsMMwNJK9bYbK3d/gmKGYgYQEF794tiK1sBO0emC2iLXw48dHWJI1x3BV4PjnS1
hO3DUpscVhoGHjMdKQs0yt38Vgg0hQPxIUKDwcIXW14HW0sIsJmNONJ9QtZLubtTPUSNXwFZgh6F
t6aL/8OzhVrPfhMOF9xCpUS3i5DubgVJLtSIG8J/7bgJfSPfWmffGRQwgLoYFkODfO3rDlutmnQU
MbXAyLkV/v987o1RAzvQfWU7z31hO8FhT1wG71obbLshSBJP4jvCfkOS4R38O8d+PyvBjP8HfDYt
OeYWG/0DzjvXfaMBkRX4tWIX8EJBgfoEcun2IQ086BAOgwAO1Vz4i/s7fRaMMV4ETD2Ux/O4EAB1
fA8XUM4CcgNsPyzgRIBPbvAPhJWmiQyTAOdq+BKGvkUrU1G//Q5vb4ZbiypyV1EqAvRQ6xZa+NBO
PcxzU3X4IgVNwHvxG74GH+NcvKwBjg5N0M1o4zfaKPTbgX34ALDdd/YFzLomUzBX8FOuAdeqqLj5
pg6I1YFJFl+EWVcmI7+UzFbNbTyYXHwermS2CM2zz8/+xugdNGuN5gIzAMIM8JBlkG1o+xxgnrME
38MEVyQE/7z7jVvhO/utZFvr7Edki09gMRbb2H52VYlNcDZsOnCEyl3lYNXghE1oB/H8L9xK+k5E
c8EUPohUBeA4HD66W7UAxkYhcug/DBz8D8MxuYNFcET/TWyCtiCb2XD8/GAJZMPWbkxz6wi1ge4J
81ATCF2tWNBYQv1FqGjALez7hBoEoh7wqIFyiV4vdVFp6qj+JlShApLohGpnoZmoAJNCcAk1i6iF
BQx/bwc9T5NZmpvifUGQyFejDTfg/jNIg34gKA+Cs1mUyf84Sx+01EYscD37EXAGwLtAoywPdMhA
CQJusLSL6GF972Xol6SD7y1EMS1qD+boCa34ROU0EUx96H1au71EBgAgAzcNgWO3G7hiKfuHRy3k
UIxqZy9oXL984Nc9bdf7DDFAAR5SxyR1oyvRI1tFJC6ZObLvMcgtPxwZrjnkSA4UlAwMydgLdH4V
BGg+20CO/C2eCcASC0kd2/5JHvQttxT8Nnjn8MzDU+PsLXAGzJwCSkST+JuiJh85RiB3NesLMozQ
4BTsnK11WHGhBPQbdQoYhsld607EwQ8CdQnYT3YEp190WFwCDFdsLtjFfgyaO/43QBI5YKZwjmRb
OTXMGN3BN4sdXETkOk31mt/TCbLk1sJUsyaapBk2o5NqlBV6EeUYJzkwLmhAtKT9s81BklaTkvwV
ijwR71B1IzURJMYTZruQdQMj1OsRyO7XCTAgqKw1vdA879xsG4QbCNEAdK4RmxlGlgnSnA9axdk3
yiZQvlRQK0z4sS8T9qUQdCBqSyjLrmEduEgiCFMI6YnYIHQGpye11PTQWGzpQ832Gbw4yEPxPeRb
ECkfCEkiNreFfP9QLtJHRR7yvGhALj14g6eDr2G+hEy7sFZF/eEZIAlTlBRntA7zwR4sPDRJvOaz
VGUo+P1hJWyQl1AX+P0KGQA2nONTpk1gF82WHeaiLdccskwM4ZEZagUOByqzgYOk01asKlDC4s/p
imABm1a+EQHY3hPUip0NE/11pHvJ6i7gJWkPZ6sQG8YOZ938KFZ0szIeKzD02Yw3GpgGImigH+VA
+yvETln+DxoFWny3qzzZ6N0ZUKFq/9tQABHyyw2iI1SkVZVoAIDQwpBL1gr6A/AiUn+QlBY+cAsL
CLkn99YBtf2XugHnx1PBTovY99uNPN+JL/SXuh+KGkgz3iPZwe8ENJ1wZBlrd90z90IUEu482yCy
5/7fJRJIrjrDQkRfssNbhMCP/P4WigIzxiPBIQSF8EJPdeoOhOILHvfQXl3+TN9v4QBuIPDPB3II
B9rEzQ3EB3be8NQHAXIHJ11hCeVFE/b2YynTkR/2ClXBTcTZ2kZwwMSXCyQFBa2jEn32ZokBDar8
DzhH35cG+mbR6RjBuxp26ZwEDQhqV1YAHXoaoRhIpD0D7PrUFlq7kOsdSnQxdfGAXtjQtfiGiXZ2
i1ZsYHh4A5d7vBneQnp1y2gJG8pRJ8ocoU+9fHNgv4BxHWisAVnooFbTydqaamv4rv1bxgf1LINs
rsAkAkAMnuX2qDomffTR/mxNVQrgsh6TuDlkOwgvai4LiBZLxBZk2AnE2VCuNGziSwMEbcJQRrwF
NU23mY7BvgOQwJIWuVbYL1dpRiX3u6H2dd2UCsQHlhfsvF3NbcvCCTDGApjxt6htrqHTZsoIBZwL
bYtBJfy/Dc4QbULXlaA60gOkN4PmiwVtrVCCeNRr7rm2pgKyFh48MAUoxAwVZA1UEMHRW+YeZrtb
MM/Cs58fO4eEhKw1EWuqUDEHASZp03CA2Blhpfid42QhG/jAPrLovILBVDEtMjz2bLgsHYgBAhKM
FKwIscJM0a7KmaK7bK1XRTXYBQYv3GdD293LAS4H3itYXeABK5xsz+IB7Gvk2JKo6BChNwTyP5YR
eU77xl46AP+UAxMFV0NqBlOy0SNmL7n26k7gwBzhZoRm6lCB+zhkc+7p+M/0aH5mBIBW5hFMBZ9o
N9vrGA1QPUcnLzwaaiS27qwyomrcCCvXVFWUcv902OtrPTMjcFeUhaIbtv1CbwPHvgbsDUYBlImd
DADTUGwg9N2d1gFfMFFFP/46N7OGhwjBaIIpQVL24GQQdBixsJzogBYTCWIRDH8nzCUUEAqRaHAy
CAlMUhJZhwSnKhhhKP1i16TCCGaCagjgZj8bSlqbWXTtScncIvZm5OSbk0QRsAkOwOUgi+Y3q3fr
u4ahh2z/2GJBkpjHjbuTBVsd/NVTsPR4cqtmK/9cEeFqeGAYHBTaBQItOICFvAygj1CmY1VXFPRG
aj9ECxsL0fJeoI13UA5Qe7LgUuG0a2hOdeVHF2qEn0VbsClThwiDhxUU6sMEVmLGZOgmxDeD+mJ9
RyqUPIpLwKyEtX4wrdXbyIEfHDvK0yNEZSuaQfV9De/JPjWIXIlYV1oDM/9c/5vs9ovyA/HWfhkX
GhWAwmGIFDv9zdWtR7B85zjxNAfGRgRANi4FjyOD4ANn/zQPE45yQRbIVsGJ5Ms+sti4CH1CcQUz
9r2yG3z6g8cDgH4dcpQzb//+DwJGO/d844CkHgsAX+tgNrAeRsW7CMO5qK/bwQgD8MTSsE0AdfI/
Q/7637ZvQ8BGsR4fyc078n0MigzFsDLS22KEcOv8xTsWt7sVgHa2xawLjYNbJUs3jIVfMvi55IFc
MgAz+Is0nwH8s6RWawTdvTWQgcO3B2hcNAhhrOIfwBg2BkAOZAUPBHK7ZEAEDNYoM4AcyFQMMJDn
Ibw7NiwzBNrbRxa0MnwWBFV9Fuhk99T9JWoB5Sx8EhV8DY6AM90TMPYtDAOZ2dxHV4ietBwFtVaP
/TYeQH17hh4BOCV1IY1ssyLXhrdQYTS2qUiEy7hQgG1subRg87X0/L8gVzwHI3qftoidEyv0/Ozd
rDT5TD9QiBhTOJEtwPBoiKPIRCsaO9s4GCnPHFfUJs8QNq0otezFLvQGcqQAZItBOzfgwfwSWGAg
Zs/Oc3MBhCdogH9oSogzIwxQ/MMgn4yN+A+EIhlgESEMt0O+vFVUTjwYPEcHrj+B/1sUwpmNtPIL
7PYriAAo4WJNgnzRsBo+cT0cCcXMEmIFA/W3j3QVfgz3An8HaHw0r1aufQLe6wUuDUNnhyVICUYH
SbiEdUSRLcrtXPi3szMDGytiIUp0D2h0NKzVN6GzZhw3Dn2H4hloDZ8OZIwfs4F2CBO8OCd4woxw
dAk9iLZbJxo6I4gwuBSH2GIHwF648GooA9DmhWghxdSoBQAAMnLb0IQ1IE3gCeQg6DTOZfPsyDR1
8PSMKUmKfmEMO9Z9acjBU8kEim7GgfZHml49yUU8IHI4PD3cAP9L/DwrdDA8eSw8f3QoPIB0JMOK
Wi8BIIgE+DCfutuTRgrGFQ1GBArxu4CgbgHbJB7/RgHOR8RWKlD37OdjCLF8SUsH9ef/M8lB+ib+
W7rKfQmLdMXYQGXxg3zF0AQJuE3cEdRTxgfozSAQRBC+kDVyv1A06LzzpYH9pIpMDbyN4kLxX4gK
inFwAQf/LdXqweEEP9DOF4hKAYpIlmVZugEYAg8CBl7Q7bfPGQKKQBXgP4pEBQxCA3Wmnif1GARX
WAIFyBY8ItPfKWi8Ohg16E9k1gSIrfVF8ewwBPA3ulCU8s5yIjvsV5zRgDTo6Dg5gCa3RTlkMcJG
+n8v4bMuioQFJ4hENfN1v41VJWobuhn0JGNiWAxdiFpvqTX4iJCR8IOocy+8XkxyDWEDDUNpBwoD
uvaFDf4EctmmMlfV2IWvDTeZCYV0Kk34bL8LaHMExkX7PQgC+j3XxK0BFHUfPAPepQyaVCo4orWk
mFq4QSYHFFFTFNimTcWFU7NA8bvAw7KRcBCX31AFe+EzxgkPUmoumDZKBNB0r2Z4Vy0LcFYa+shY
WS0kjUMEGdWVznYAqiBoGK5xIBLzxRscJxCyBpUWrVm12ci+UxtQMgx+2UJ22Q4wr2g8IBEYg71U
C6IYaAiaNZQd2bfAlBRo+DUz3BFSTcTI1NU5WV0htKBzANEnABJysNS4N3DIhVje/nNYN4PKHXb2
TlAXUIQcMsuNumA/dQPermJRTOTZjHhILES4NtkINDd2R8ZQT9gNsI2dCFKFi8N2TXMJimPGBRNm
aKT0QGrA/wwdSAQ60Y1Z7tc78x35BjGhpvcHD4y/b8gPqEgGuPsMjfi9U8MFEVzaROST7WYUDV2b
Cl7SjbWh7qgRZRJzi4Wi/fTxhsnB4AJGuTQFnyPQFrZYihMK10DYWYmHdGBAdB4YTYnvNztk2Qpy
ZfngJ0xPMhZ1bv0Bbzld+K0iywNq+OzDESVIYCZ1+K46hz8UDEZXOXUQuDXqBRF+cosRRCl9Qkdt
qckUjPlNJJhVD+rSiYPC1YC3WwHsDGnSDXD1c4s6Urzs/olV9Ahl6mHZfib5WH3Xl8wRWnQUigcW
RzwKdAruasHfhwPHO0UQfJelL4gcCLJU+xGfg8j/6/Y3/li/gYYowwk7F4A/MHQZbuSwiFcQBzAf
CpYIA1ClXsst/EKRwDvwV9ljDrNHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IEnQEPAkwW4H4dQNG
6+t0JiqIrUAko8glRu6a7hfhPjw6dDkuNTEqAgQXFH9biuwPOHUJOIQN/0DbddAuEAMESc6IENF3
xF3uQYH5tnK+6wFORWJsrCUSAF3MmCzPhcgPuAD/0yCLtV3MDw4kOCscL8PeDJDpODp1YR4wmeFE
/lsP6KBn7ki2QEbSygFG6VwHu87ST/UWwblhgr+BoV1t4gpCO9d86nXdx1YQZQIqQh0L4zfuKWrw
PgqojioJc+03iAiCDXUO6wsgCxzQ0hAbBwY1DYSCBA7IS52PbWsEF4ZOiucdBQQbbCttMAOGSQCO
kjUzwnLDYw11hPOrDJtgkgAYjRvHhRgwnXoFTQa2aDGiYGXjEQ5n4wbTUFFQZPyblhD9griLwcdo
K2GivtosFDcrGmn7ABDqD4hewoDDD/uIH3AHxVa+2jOK5bvfXhdqihGA+iDK+gl1E0H+pVJvBzl/
ErfcBIBBjURC0M0a8f8eMH3pgDktdRx5Tc+t4BBWs2fVf25JUaqztVZi3hAMctxVgGhEOEpIN7KL
rWioPRv79qAXckAhilo9NASGaj0QB35INIIuuG32QFNodZKPVPxqBhuZqT2EGdiDYOotAhcvOPVX
1I8P3Dzl+h7yvpg6+MYfMJhddWpU6IhWUymci34Qpr5ElYWYfepyjMQ9kHiNudzosSQ/CjQ4ib8Q
J8s2a87q/ldFQBh8QjLY7gc9KzZ+PDgo+TzfyjN0TyuPRCPkwC4UO/0DueSSEwgEpySPkPvXAMTn
mczBaPy+IQy1enyZkY+q3T1dzZLpN8D4igGL2Uo8FQcOUlPpQ4oDP2sDFwNDFeAbXzvLdC5QLnUR
as1qL4BIobREQKxxWwzDEivB/A/y7q3QXE7CE8vrrCgFaPQ3mTO8CKC3C5K1pUZ4fCOdfb/sJqhQ
LbkfiBPzEnRzR1PrBgkGRlNLQ8ModcamtTQD8iw04CLcWFwOAUm6/xBMIjA2AdhC/2wvV8EgEgJv
lw+pLNVvRREQDNz8LVApOiG1V1kjcvAgJVNLS0QNCSBvcLoThzuCsRn93lZMArnsSFAW1AmYHbej
UL0NKkhPjL0cAX1TPFRze+B0K2oZG2EKsoncCEPec4twVJQDa0PG2svVB2+T3ksATgx7jOn0dRi6
dXBBpuqd00rTAq4NAyTwJxg4JJaCfF9yAwFbDa+IDT5m7HMA6cH5A1Hq7PwYAQvk7PwAghWfhkhc
QFduViB20YTV6zXB480lI0/wdCTsDO4/iJcs7HQim8chph5dANA8A76n4gb6+AkPh63fJIVEcot8
sw2ccTtpcP4Uh+0OsnC2aNjH624N0Ic8hzxgyFLAhzyHPES4NqyHPIc8KKAamA4zhzwMkInWYybe
GzvrB4ClDTsGdEoGhNhVjQgNO8gCs7DGEGiyD1NwFHy+oPYaYmznPhl9EUcVbfk+0TTddkAUFIBk
KQM3RdM0TdNTYW99i5uR702Z/yVUEQUIEMzMXyAMxFE9cDkIchSB7Y/9vukLLQSFARdz7CvIi8QM
vS5V6ovhi1OcUMOSChlEkQCqVKkqDlmqikKDAzbNQVGoHAFDpaKXiJt0ZUZwt7ZR9E1hcHDAQRMN
bmQL9gxFiBUOA16oGnZycw93RW52UXUU3RBvbsdWt3eHdX1iGFcrb3dzRB1lY4L9dvZ0b3J5FUQi
dmVUeXAkdu9n/0dTaXplWkNsb3MKFFRpNfdu31FUb1N5amVtCy0cG9tuQfZBbAZjOlQY2pPvb3Ap
TmFtTFNQb0cl7JmokiE92tbtvg5DdXJypVRo52QRV4nGfrvN7QpMbxBMaWJyYaVsXjv23jVyY3AJ
j0hhmCRw29rBrUF0HSp1OnNBsluwgTI3CG5BnUAI2G1QG2hBiQpbnrXYZB8eTGFFnHu6w1oZUU1f
eG+HNlk7WF1EZQZqU4tAaP9WR01vZHUVFBjChNh3S1W7XXZIGkFzGFMIZXAG2JZLeEV4aSVhRphT
7TD35g4cT2JqwKRQsN+wJbRjeQYy/WmCzQrbY2u7dWxMKbVQ1c0aaVpNSWaA2kX5bWHlFwPj/Y5w
Vmlld09miwBiCSu0TDjzuREKUG/MDWFkZUPYv9lb2yZN9khCeXQibkFkbsIS3mRychbHrW5Za7RI
pTgcKyfDmDF7ExlgBLysMIRuqs0JaUF3j7NhjUZJcTVrZWQTdmoLpWMSCxVJ0plhkm5SIuRVMzbB
sLD11EKTJksdhRSceaK12rHH+DZnjEtleQxPcE3dOvfoC0UkDjpWjXVlYQcAhg8kEQkzdymmdW0w
DK+t2WyzP2TCCAFto+60NcxzZaJqd0MQ89jfDAMHaXNkaWdpGXVwcHPNzbYReBIJZlsIOM1W+HNw
YUtPzSxYwP57m1UvQnVmZkEPC2fajjxMb3d3djlytiNRmG3YdwpH2CzLsj3UEwIKBG+XsizLsgs0
FxIQ1bIsywMPCRRzH8g/FkJQRQAATAEC4AAPdctJ/gELAQcAAHxRQBADkGGzbvYNSgsbBB4H62ZL
tjOgBigQB/ISeAMGq9iDgUAuz3iQ8AHXNZB1ZIRPLjV0K3bZssl76wAg1Qu2UeDgLsHHAJv7u3dh
3yN+J0ACG9SFAKBQfQ3T5QAAAAAAAACQ/wAAAAAAAAAAAAAAAABgvgBwSgCNvgCg//9Xg83/6xCQ
kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk
McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu
/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC
g8IEiQeDxwSD6QR38QHP6Uz///9eife5DQEAAIoHRyzoPAF394A/AXXyiweKXwRmwegIwcAQhsQp
+IDr6AHwiQeDxwWJ2OLZjb4AkAAAiwcJwHRFi18EjYQw6LEAAAHzUIPHCP+WYLIAAJWKB0cIwHTc
ifl5Bw+3B0dQR7lXSPKuVf+WZLIAAAnAdAeJA4PDBOvY/5ZosgAAYemUgP//AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAA
AAAAAAAAAAAAAAABAAkEAABQAAAAqMAAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAACgAACA
eAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAkAAAANTBAAAUAAAAAAAAAAAAAAABADAAsJAAACgAAAAQ
AAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA
gACAgAAAgICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAACIiIgAAAAACId3d3iA
AAB4//+Ih3AAAHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3eP94AAB4/////3gA
AHj3d4//eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAHszt7d4AAAAAAAACAAADw
PwAA4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAcAAOAH
AAD/3wAA2JEAAAAAAQABABAQEAABAAQAKAEAAAEAAAAAAAAAAAAAAAAAkMIAAGDCAAAAAAAAAAAA
AAAAAACdwgAAcMIAAAAAAAAAAAAAAAAAAKrCAAB4wgAAAAAAAAAAAAAAAAAAtcIAAIDCAAAAAAAA
AAAAAAAAAADAwgAAiMIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAysIAANjCAADowgAAAAAAAPbCAAAA
AAAABMMAAAAAAAAMwwAAAAAAAHMAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZD
UlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVz
cwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwEC
FAAKAAAAAAAVlzswyicfngBYAAAAWAAACgAAAAAAAAAAACAAAAAAAAAAcmVhZG1lLmNtZFBLBQYA
AAAAAQABADgAAAAoWAAAAAA=
------=_NextPart_000_0005_D10D0979.749E4450--
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Netfilter and Squid
From: John A. Sullivan III @ 2004-01-27 17:54 UTC (permalink / raw)
To: Glen Spidal; +Cc: netfilter
In-Reply-To: <5.2.1.1.0.20040127093418.029803f0@mail.cybercorpinc.com>
On Tue, 2004-01-27 at 12:41, Glen Spidal wrote:
> Hello all,
>
> I have the following setup:
>
> Internet->PublicIP_Router->Cross-over-cable->Squid_Server->LAN
>
> Squid works fine as does Dans' Guardian web filter. MY question is what do
> I need to do to route web traffic through squid and allow email traffic to
> flow around Squid? Currently, client-based email (Outlook and Entourage)
> does not work because there is no route. I must make sure that all LAN
> clients go through squid since it is a school.
>
> I've looked through the how-to's but have not found specific examples and
> syntax.
<snip>
I usually set Squid up as a transparent proxy, i.e., I use the REDIRECT
iptables target to redirect any Internet bound traffic on port 80 to
port 3128 on the same server (and thus to Squid) whereas all other
traffic just obeys the normal iptables rules - John
--
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-27 17:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.10170.911012.262682@cargo.ozlabs.ibm.com>
>>>>> On Tue, 27 Jan 2004 19:56:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about the attached one? It will touch memory more when
>> moving an element down, but we're talking about exception tables
>> here, and I don't think module loading time would be affected in
>> any noticable fashion.
Paul> Hmmm... Stylistically I much prefer to pick up the new
Paul> element, move the others up and just drop the new element in
Paul> where it should go, rather than doing swap, swap, swap down
Paul> the list.
The original code may be slightly faster, but who cares? From a
readability point of view, I think my version is easier to understand.
Paul> Also, I don't think there is enough code there to be worth the
Paul> bother of trying to abstract the generic routine so you can
Paul> plug in different compare and move-element routines. The
Paul> whole sort routine is only 16 lines of code, after all. Why
Paul> not just have an ia64-specific version of sort_extable?
Paul> That's what I thought you would do.
That's certainly an option. It was Andrew who called for a generic
version. I tend to agree with him because even though it's just a
little sort routine, it's one of those things where stupid errors tend
to creep in. And like I mentioned earlier, Alpha needs the exact same
code (and frankly, I'm surprised there are 64-bit platforms that do
NOT use the location-relative format that Richard invented).
--david
^ 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.