* Re: unexpected IO-APIC
From: Erik Mouw @ 2006-07-07 13:12 UTC (permalink / raw)
To: Danielle Hines; +Cc: linux-smp
In-Reply-To: <160F71AB-85EA-4304-A9E5-A84DFDAC30B0@ninds.nih.gov>
On Thu, Jul 06, 2006 at 04:37:45PM -0400, Danielle Hines wrote:
> I received this messge in the /var/log/messages after having some
> problems with NFS mounts and samba.
[...]
> Now I know you need to know about the hardware. It is a i686 with 4
> processors 1.8 Tb of space, it is running a modified redhat linux
> flavor:
>
> uname -a
> Linux minnie 2.4.19-122_MVD_SNAPenterprise #1 SMP Fri Aug 20 15:51:56
> CST 2004 i686 unknown
Ancient vendor kernel, not interesting anymore. Probably already fixed
in recent kernels. If you have the chance, try a more recent kernel. If
everything just works, don't bother.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: splice/tee bugs?
From: Jens Axboe @ 2006-07-07 13:14 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: mtk-manpages, linux-kernel, akpm, Ingo Molnar
In-Reply-To: <20060707131247.GX4188@suse.de>
On Fri, Jul 07 2006, Jens Axboe wrote:
> On Fri, Jul 07 2006, Jens Axboe wrote:
> > On Fri, Jul 07 2006, Michael Kerrisk wrote:
> > > Jens Axboe wrote:
> > >
> > > > > > > > In this case I can't kill it with ^C or ^\. This is a
> > > > > > > > hard-to-reproduce behaviour on my (x86) system, but I have
> > > > > > > > seen it several times by now.
> > > > > > >
> > > > > > > aka local DoS. Please capture sysrq-T output next time.
> > > [...]
> > > > > I'll see about reproducing locally.
> > > >
> > > > With your modified ktee, I can reproduce it here. Here's the ktee and wc
> > > > output:
> > >
> > > Good; thanks.
> > >
> > > By the way, what about points a) and b) in my original mail
> > > in this thread?
> >
> > I'll look at them after this.
>
> I _think_ it was due to a bad check for ipipe->nrbufs, can you see if
> this works for you? It also changes some other things:
>
> - instead of returning EAGAIN on nothing tee'd because of the possible
> deadlock problem, release/regrab the ipipe/opipe mutex if we have to.
> This makes sys_tee block for that case if SPLICE_F_NONBLOCK isn't set.
>
> - Check that ipipe and opipe differ to avoid possible deadlock if user
> gives the same pipe.
>
> You can still see 0 results without SPLICE_F_NONBLOCK set, if we have no
> writers for instance. This is expected, not much we can do about that as
> we cannot block for that condition.
BTW, I'm seeing an odd lockdep message on the first invocation of the
test:
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
ktee2/6208 is trying to acquire lock:
(&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
but task is already holding lock:
(&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
other info that might help us debug this:
1 lock held by ktee2/6208:
#0: (&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
stack backtrace:
[<c01041ab>] show_trace+0x12/0x14
[<c0104874>] dump_stack+0x19/0x1b
[<c01399b6>] __lock_acquire+0x645/0xc77
[<c013a32a>] lock_acquire+0x5d/0x79
[<c0392082>] __mutex_lock_slowpath+0x6e/0x296
[<c03922c6>] mutex_lock+0x1c/0x1f
[<c018d37f>] sys_tee+0x292/0x4a4
[<c0103075>] sysenter_past_esp+0x56/0x8d
I cannot see where this could be happening, Ingo is this valid?
--
Jens Axboe
^ permalink raw reply
* Re: zeroing old superblocks & upgrading...
From: John Stoffel @ 2006-07-07 13:10 UTC (permalink / raw)
To: Neil Brown; +Cc: John Stoffel, Luca Berra, linux-raid
In-Reply-To: <17581.38932.532010.388731@cse.unsw.edu.au>
>>>>> "Neil" == Neil Brown <neilb@suse.de> writes:
>> I can't seem to zero it out:
>>
>> # mdadm --misc --zero-superblock /dev/hde
>> mdadm: Couldn't open /dev/hde for write - not zeroing
>>
>> Should I just ignore this, or should I break off /dev/hde from the
>> array and scrub the disk and then re-add it back in?
Neil> You could ignore it - it shouldn't hurt.
Ok.
Neil> But if you wanted to (and were running a fairly recent kernel) you
Neil> could
Neil> mdadm --grow --bitmap=internal /dev/md0
Did this. And now I can do mdadm -X /dev/hde1 to examine the bitmap,
but I think this totally blows. To create a bitmap, I add it to an
md# device, but to examine it, I have to know which sub-devices to
query? That's really not what I would expect.
I do see that
mdadm -q --detail /dev/md0
shows the bitmap status (though not the size or parameters of the
bitmap), which is good.
Neil> mdadm /dev/md0 --fail /dev/hde1 --remove /dev/hde1
Neil> mdadm --zero-superblock /dev/hde
Neil> mdadm /dev/md0 --add /dev/hde1
Worked wonderfully! Cleaned out the old superblock nicely, which I
think is a good thing here.
Neil> mdadm --grow --bitmap=none /dev/md0
Neil> and it should work with minimal resync...
So why would I want to remove the bitmap? The re-sync happened pretty
much quickly enough that I didn't even see any non-in-sync status when
I did the --add of the device back in. Very very cool...
Though... if I was paranoid, I'd disable the bitmap because there's no
way to be sure that I didn't write some garbage at a random block N
somewhere in the array. Hmm... can't make that guarrentee now either,
so it's probably a moot point.
In any case, I'm planning on keeping the bitmap.
Neil> Though thinking about it - after the first --grow, check that
Neil> the unwanted bitmap is still there. It is quite possible that
Neil> the internal bitmap will over-write the unwanted superblock
Neil> (depending on the exact size and aligment of hde1 compared with
Neil> hde). If it is gone, then don't bother with the rest of the
Neil> sequence.
It was still there after the addition of the bitmap.
Thanks Neil!
John
^ permalink raw reply
* Re: splice/tee bugs?
From: Jens Axboe @ 2006-07-07 13:12 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: mtk-manpages, linux-kernel, akpm
In-Reply-To: <20060707124105.GW4188@suse.de>
On Fri, Jul 07 2006, Jens Axboe wrote:
> On Fri, Jul 07 2006, Michael Kerrisk wrote:
> > Jens Axboe wrote:
> >
> > > > > > > In this case I can't kill it with ^C or ^\. This is a
> > > > > > > hard-to-reproduce behaviour on my (x86) system, but I have
> > > > > > > seen it several times by now.
> > > > > >
> > > > > > aka local DoS. Please capture sysrq-T output next time.
> > [...]
> > > > I'll see about reproducing locally.
> > >
> > > With your modified ktee, I can reproduce it here. Here's the ktee and wc
> > > output:
> >
> > Good; thanks.
> >
> > By the way, what about points a) and b) in my original mail
> > in this thread?
>
> I'll look at them after this.
I _think_ it was due to a bad check for ipipe->nrbufs, can you see if
this works for you? It also changes some other things:
- instead of returning EAGAIN on nothing tee'd because of the possible
deadlock problem, release/regrab the ipipe/opipe mutex if we have to.
This makes sys_tee block for that case if SPLICE_F_NONBLOCK isn't set.
- Check that ipipe and opipe differ to avoid possible deadlock if user
gives the same pipe.
You can still see 0 results without SPLICE_F_NONBLOCK set, if we have no
writers for instance. This is expected, not much we can do about that as
we cannot block for that condition.
diff --git a/fs/splice.c b/fs/splice.c
index 05fd278..de323df 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1316,7 +1316,7 @@ static int link_pipe(struct pipe_inode_i
struct pipe_buffer *ibuf, *obuf;
int ret, do_wakeup, i, ipipe_first;
- ret = do_wakeup = ipipe_first = 0;
+ i = ret = do_wakeup = ipipe_first = 0;
/*
* Potential ABBA deadlock, work around it by ordering lock
@@ -1332,14 +1332,14 @@ static int link_pipe(struct pipe_inode_i
mutex_lock(&ipipe->inode->i_mutex);
}
- for (i = 0;; i++) {
+ do {
if (!opipe->readers) {
send_sig(SIGPIPE, current, 0);
if (!ret)
ret = -EPIPE;
break;
}
- if (ipipe->nrbufs - i) {
+ if (i < ipipe->nrbufs) {
ibuf = ipipe->bufs + ((ipipe->curbuf + i) & (PIPE_BUFFERS - 1));
/*
@@ -1370,6 +1370,7 @@ static int link_pipe(struct pipe_inode_i
do_wakeup = 1;
ret += obuf->len;
len -= obuf->len;
+ i++;
if (!len)
break;
@@ -1379,11 +1380,9 @@ static int link_pipe(struct pipe_inode_i
/*
* We have input available, but no output room.
- * If we already copied data, return that. If we
- * need to drop the opipe lock, it must be ordered
- * last to avoid deadlocks.
+ * If we already copied data, return that.
*/
- if ((flags & SPLICE_F_NONBLOCK) || !ipipe_first) {
+ if (flags & SPLICE_F_NONBLOCK) {
if (!ret)
ret = -EAGAIN;
break;
@@ -1400,10 +1399,22 @@ static int link_pipe(struct pipe_inode_i
kill_fasync(&opipe->fasync_readers, SIGIO, POLL_IN);
do_wakeup = 0;
}
+
+ /*
+ * To avoid ABBA deadlocks, we need to drop the ipipe
+ * lock before dropping/grabbing the opipe lock in
+ * pipe_wait().
+ */
+ if (!ipipe_first)
+ mutex_unlock(&ipipe->inode->i_mutex);
opipe->waiting_writers++;
pipe_wait(opipe);
opipe->waiting_writers--;
+
+ if (!ipipe_first)
+ mutex_lock(&ipipe->inode->i_mutex);
+
continue;
}
@@ -1417,12 +1428,7 @@ static int link_pipe(struct pipe_inode_i
if (ret)
break;
}
- /*
- * pipe_wait() drops the ipipe mutex. To avoid deadlocks
- * with another process, we can only safely do that if
- * the ipipe lock is ordered last.
- */
- if ((flags & SPLICE_F_NONBLOCK) || ipipe_first) {
+ if (flags & SPLICE_F_NONBLOCK) {
if (!ret)
ret = -EAGAIN;
break;
@@ -1437,7 +1443,18 @@ static int link_pipe(struct pipe_inode_i
wake_up_interruptible_sync(&ipipe->wait);
kill_fasync(&ipipe->fasync_writers, SIGIO, POLL_OUT);
+ /*
+ * To avoid ABBA deadlocks, we need to drop the ipipe
+ * lock before dropping/grabbing the opipe lock in
+ * pipe_wait().
+ */
+ if (ipipe_first)
+ mutex_unlock(&opipe->inode->i_mutex);
+
pipe_wait(ipipe);
+
+ if (ipipe_first)
+ mutex_lock(&opipe->inode->i_mutex);
}
mutex_unlock(&ipipe->inode->i_mutex);
@@ -1468,7 +1485,7 @@ static long do_tee(struct file *in, stru
/*
* Link ipipe to the two output pipes, consuming as we go along.
*/
- if (ipipe && opipe)
+ if (ipipe && opipe && ipipe != opipe)
return link_pipe(ipipe, opipe, len, flags);
return -EINVAL;
--
Jens Axboe
^ permalink raw reply related
* Re: [KJ] [Kj] [PATCH] drivers/acpi/cm_sbs.c: if statement moved
From: tom hisch @ 2006-07-07 13:09 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <8ef77f2e0607070606y4367b47fw5cc3b195b5fe21a@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1986 bytes --]
sorry for the mistake with the "h" in the patch. here is the new patch
--- linux-2.6/drivers/acpi/cm_sbs.c.orig 2006-07-06 23:54:
04.000000000 +0200
+++ linux-2.6/drivers/acpi/cm_sbs.c 2006-07-07 15:07:57.000000000 +0200
@@ -69,10 +69,10 @@ void acpi_unlock_ac_dir(struct proc_dir_
down(&cm_sbs_sem);
if (acpi_ac_dir_param) {
lock_ac_dir_cnt--;
- }
- if (lock_ac_dir_cnt == 0 && acpi_ac_dir_param && acpi_ac_dir) {
- remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
- acpi_ac_dir = 0;
+ if (lock_ac_dir_cnt == 0 && acpi_ac_dir) {
+ remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
+ acpi_ac_dir = 0;
+ }
}
up(&cm_sbs_sem);
}
On 7/7/06, tom hisch <t.hisch@gmail.com> wrote:
>
> hello.
>
> this is my first "little" patch it only moves an if statement in
> drivers/acpi/cm_sbs.c
> Any recommendations on this are welcome.
>
> ------
> thomas hisch
>
>
> --- linux-2.6/drivers/acpi/cm_sbs.c.orig 2006-07-06 23:54:
> 04.000000000 +0200
> +++ linux-2.6/drivers/acpi/cm_sbs.c 2006-07-07 14:54:49.000000000+0200
> @@ -1,4 +1,4 @@
> -/*
> +h/*
> *
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *
> * This program is free software; you can redistribute it and/or modify
> @@ -69,10 +69,10 @@ void acpi_unlock_ac_dir(struct proc_dir_
> down(&cm_sbs_sem);
> if (acpi_ac_dir_param) {
> lock_ac_dir_cnt--;
> - }
> - if (lock_ac_dir_cnt == 0 && acpi_ac_dir_param && acpi_ac_dir) {
> - remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
> - acpi_ac_dir = 0;
> + if (lock_ac_dir_cnt == 0 && acpi_ac_dir) {
> + remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
> + acpi_ac_dir = 0;
> + }
> }
> up(&cm_sbs_sem);
> }
>
>
[-- Attachment #1.2: Type: text/html, Size: 4149 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: LibPATA code issues / 2.6.15.4
From: Mark Lord @ 2006-07-07 13:08 UTC (permalink / raw)
To: Justin Piszcz, Sander; +Cc: Jeff Garzik, linux-kernel, IDE/ATA development list
In-Reply-To: <Pine.LNX.4.64.0607061906550.5107@p34.internal.lan>
Justin Piszcz wrote:
> Look at this:
>
>> From smartctl, look at the correspondence:
> 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always
> - 4
>
> [4301946.802000] ata4: translated ATA stat/err 0x51/04 to SCSI
> SK/ASC/ASCQ 0xb/00/00
> [4301946.802000] ata4: status=0x51 { DriveReady SeekComplete Error }
> [4301946.802000] ata4: error=0x04 { DriveStatusError }
> [4302380.482000] ata4: translated ATA stat/err 0x51/04 to SCSI
> SK/ASC/ASCQ 0xb/00/00
> [4302380.482000] ata4: status=0x51 { DriveReady SeekComplete Error }
> [4302380.482000] ata4: error=0x04 { DriveStatusError }
> [4302493.664000] ata4: no sense translation for status: 0x51
> [4302493.664000] ata4: translated ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0xb/00/00
> [4302493.664000] ata4: status=0x51 { DriveReady SeekComplete Error }
> [4302863.673000] ata4: no sense translation for status: 0x51
> [4302863.673000] ata4: translated ATA stat/err 0x51/00 to SCSI
> SK/ASC/ASCQ 0xb/00/00
> [4302863.673000] ata4: status=0x51 { DriveReady SeekComplete Error }
>
> different drive, different cable, same controller, but second port
>
> So that Stat/err = UDMA_CRC_Error_Count!
No, I don't think it is -- there's a bit in the drive status
for indicating CRC errors, and it is not showing up here.
I think it's still just libata sending some command that this
drive does not implement. You really need to dump out the failed
ATA opcode.
I *think* this (uncompiled, untested) patch may do it for you on 2.6.16/17:
--- linux/drivers/scsi/libata-scsi.c.orig 2006-06-19 10:37:03.000000000 -0400
+++ linux/drivers/scsi/libata-scsi.c 2006-07-07 09:06:57.000000000 -0400
@@ -542,6 +542,7 @@
struct ata_taskfile *tf = &qc->tf;
unsigned char *sb = cmd->sense_buffer;
unsigned char *desc = sb + 8;
+ unsigned char ata_op = tf->command;
memset(sb, 0, SCSI_SENSE_BUFFERSIZE);
@@ -558,6 +559,7 @@
* onto sense key, asc & ascq.
*/
if (tf->command & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ)) {
+ printk(KERN_WARN "ata_gen_ata_desc_sense: failed ata_op=0x%02x\n", ata_op);
ata_to_sense_error(qc->ap->id, tf->command, tf->feature,
&sb[1], &sb[2], &sb[3]);
sb[1] &= 0x0f;
^ permalink raw reply
* Problem loading rules
From: Steve @ 2006-07-07 13:07 UTC (permalink / raw)
To: linux-audit
I am trying to load rules from a file that contains:
-a exit,always -F path=/etc/shadow -S open -k myrule_000000
-a exit,always -F path=/usr/sbin/chroot -S execve -k myrule_000001
-a exit,always -F path=/var/repository/important.doc -S unlink -k
myrule_000002
-a exit,always -F path=/var/log/secure -S open -k myrule_000003
-a exit,always -F path=/usr/bin/nmap -S execve -k myrule_000004
using auditctl -R
I am getting the following error:
Cannot realloc memory!
-F path must be before -S
There was an error in line 2 of iitds_audit.rules
--
I originally had the -S options before the -F. When I got the error, I
switched the order, but the same error is returned.
I have tried entering the rules individually from the command line and
they work without error.
I am using audit-1.2.4
Thanks,
Steve
^ permalink raw reply
* [KJ] [Kj] [PATCH] drivers/acpi/cm_sbs.c: if statement moved into
From: tom hisch @ 2006-07-07 13:06 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 1067 bytes --]
hello.
this is my first "little" patch it only moves an if statement in
drivers/acpi/cm_sbs.c
Any recommendations on this are welcome.
------
thomas hisch
--- linux-2.6/drivers/acpi/cm_sbs.c.orig 2006-07-06 23:54:
04.000000000 +0200
+++ linux-2.6/drivers/acpi/cm_sbs.c 2006-07-07 14:54:49.000000000 +0200
@@ -1,4 +1,4 @@
-/*
+h/*
*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* This program is free software; you can redistribute it and/or modify
@@ -69,10 +69,10 @@ void acpi_unlock_ac_dir(struct proc_dir_
down(&cm_sbs_sem);
if (acpi_ac_dir_param) {
lock_ac_dir_cnt--;
- }
- if (lock_ac_dir_cnt == 0 && acpi_ac_dir_param && acpi_ac_dir) {
- remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
- acpi_ac_dir = 0;
+ if (lock_ac_dir_cnt == 0 && acpi_ac_dir) {
+ remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
+ acpi_ac_dir = 0;
+ }
}
up(&cm_sbs_sem);
}
[-- Attachment #1.2: Type: text/html, Size: 2068 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* [KJ] kafow VIAGzRA
From: Natsumi Schaefer @ 2006-07-07 13:04 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 247 bytes --]
Hi,
VALIzUM from $ 1,21
AMBIzEN
CIALzIS from $ 3,75
VIAGzRA from $ 3,33
www. gesanais .com
spears and axes stood the wolves at a respectful distance, watching and
waiting.
He could hear the goblins beginning a horrible song:
[-- Attachment #1.2: Type: text/html, Size: 636 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: libata EH appears to be NFG up to 2.6.17 (at least).
From: Mark Lord @ 2006-07-07 13:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: IDE/ATA development list, Jens Axboe, Ric Wheeler
In-Reply-To: <44AD8A25.7020006@pobox.com>
Jeff Garzik wrote:
> Mark Lord wrote:
>> Enable libata-scsi to report correct sense data on errors.
>>
>> Signed-off-by: Mark Lord <mlord@pobox.com>
>> ---
>> --- linux/drivers/scsi/libata-scsi.c.orig 2006-07-06
>> 17:09:54.000000000 -0400
>> +++ linux/drivers/scsi/libata-scsi.c 2006-07-06 17:17:43.000000000
>> -0400
>> @@ -667,6 +667,13 @@
>> qc->ap->ops->tf_read(qc->ap, tf);
>>
>> /*
>> + * Restore the error bit, which got cleared when the
>> + * interrupt handler first read the ata_status.
>> + */
>> + if (qc->err_mask & AC_ERR_DEV)
>> + tf->command |= ATA_ERR;
>> +
>> + /*
>> * Use ata_to_sense_error() to map status register bits
>
>
> Again it's an LLDD issue. Your answer of "all LLDDs" sounds a bit
> suspicious.
>
> AC_ERR_DEV should not be set unless (a) some code noticed that ATA_ERR
> was already present in the Status register, or (b) some code set
> AC_ERR_DEV for some reason other than ATA_ERR presence. Both of those
> factors depend heavily on LLDD behavior.
So that *is* the meaning of AC_ERR_DEV --> "LLDD saw ATA_ERR" ?
I'm just not sure whether to check for that one bit,
or for any bit set in qc->err_mask.
Of course even doing this is not at all foolproof -- the code in libata-scsi
will then go and read the ATA status again (along with all of the others),
and the drive/software may well have cleared/changed bits by then.
In fact, you've even had isolated bug reports from the past month with
exactly this happening -- where the reported error status was 0x50
by the time libata-scsi got hold of it.
I dunno what the new EH does (yet), but the only good way to deal with this
is for the ATA status & error values to be read *and* saved on command completion,
and then reused by any later code that needs to do detailed sense reporting
or other diagnostics.
With NCQ/TCQ, this can be tough to achieve, possibly requiring the LLDD to
drop to legacy mode on error, and capture the values there. Of course, by then
it's too late to be perfect, as the host controller has probably already read
and discarded the drive status at least once. (the PDC sata_qstor device
is an exception there -- they save/return failed status during queuing).
In summary, when a command fails, we need to save the failed status and
error values that we saw when we decided it fails. Reading them again later
is not optimal, because they can change in the interim (asynchronous notifications,
or just drives that like to clear ERR after status is read).
I'm out today, but I'll try and fiddle with this some more on the weekend.
I have several host controllers here to try this with.
Cheers
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction
From: maestro @ 2006-07-07 12:57 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <AAF85A9A-DA5B-4AA7-BDDE-6B5D1158C8A7@gmx.de>
Am Freitag, den 07.07.2006, 14:30 +0200 schrieb Joachim Henke:
> Could you please check, if the attached patch works for you? A quick
> test showed that Linux boots fine with the MONITOR flag set now.
>
> This patch adds 'monitor' and 'mwait' as nops, as suggested by Fabrice.
>
hello just tested the patch against 0.8.1 and current cvs and at least
here it does not work:
still
Kernel panic - not syncing: Attempted to kill init!
im on a pentium D with ubuntu 6.06server as guest os (debian sarge host)
cheers
m
btw: when i patch < mwait.diff in the qemu-src directory patch cannot
find the files to patch and asks me for their location - did i do
anything wrong?
^ permalink raw reply
* Re: Setting kernel thread priority
From: linux-os (Dick Johnson) @ 2006-07-07 13:00 UTC (permalink / raw)
To: chinmaya; +Cc: Linux Kernel
In-Reply-To: <44AE572D.8000105@innomedia.soft.net>
On Fri, 7 Jul 2006, Chinmaya Mishra wrote:
> Hi,
>
> I am using linux kernel 2.6.10.
> In a kernel module i am calling two functions in two
> kernel threads using the api,
>
> kernel_thread((void *)funName, NULL, CLONE_KERNEL);
>
> Is there any procedure/apis available to set the thread priority?
> Please help . . . . .
>
> Thanks in advance.
> Chinmaya
My a FAQ! Your kernel version uses:
set_user_nice(current, PRIORITY); from __inside__ the kernel
thread (like one of the first things it does upon startup).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* [ALSA - driver 0002068]: No sound in headphones - A3H ASUS
From: bugtrack @ 2006-07-07 12:51 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2068>
======================================================================
Reported By: awisniewski
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2068
Category: PCI - hda-intel
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 04-25-2006 12:03 CEST
Last Modified: 07-07-2006 14:51 CEST
======================================================================
Summary: No sound in headphones - A3H ASUS
Description:
Hello
I have ASUS A3H model laptop. I've just compiled kernel 2.6.16.11 from
kernel.org (newest). I used CONFIG_SND_HDA_INTEL=y option in kernel config
and it seems to be working propertly till I'm not trying use headphone
(internal speaker from laptop is working propertly). When I plug in
headphones into the jack port in laptop, internal speaker is silent but I
can not hear anything in headphones. It seems like turned on MUTT option
in mixer but I can not find option for headphones in my mixer
application.
Few facts:
lapek:/proc/asound# cat version
Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04
08:57:20 2006 UTC).
andy@lapek:~/moje/instalki/Linux/kernele/linux-2.6.16.11$ uname -a
Linux lapek 2.6.16.11 #1 Tue Apr 25 10:07:45 CEST 2006 i686 GNU/Linux
lapek:/proc/asound# cat timers
G0: system timer : 4000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-0-3: PCM capture 0-0-3 : SLAVE
P0-1-0: PCM playback 0-1-0 : SLAVE
lapek:/proc/asound# cat pcm
00-01: ALC880 Digital : ALC880 Digital : playback 1
00-00: ALC880 Analog : ALC880 Analog : playback 1 : capture 2
lapek:/proc/asound# cat devices
0: [ 0] : control
16: [ 0- 0]: digital audio playback
17: [ 0- 1]: digital audio playback
24: [ 0- 0]: digital audio capture
33: : timer
I will add /proc/asound/card0/codec#0 file also (as attachmets).
======================================================================
----------------------------------------------------------------------
awisniewski - 05-10-06 08:15
----------------------------------------------------------------------
Because I had to recompile kernel and in this case alsa drivers also I can
be 100% sure that I must go into test mode (in assus mode I can not do
anything with headphones) and :
- Front must have some volume level
- Front pi must be Line Out
- Surround must have some volume level (with this option I can chanege
volume in my headphones)
- Surround pi must be Line Out
When I used asus or default model option in my alsa driver I can not
change volume for headphones even if I had Surround option in my
alsamixer.
I think it's all what you need :)
Tx again ...
----------------------------------------------------------------------
dcomsa - 07-07-06 14:51
----------------------------------------------------------------------
Hi,
I'm facing the same issue. How can I help to fix this? Following the
instructions above, i was able to get the headphones working, using the
model test. I'm willing to provide you any info so that the headphones
will work by default. Please note that I'm not an expert, rather an medium
linux user.
Issue History
Date Modified Username Field Change
======================================================================
04-25-06 12:03 awisniewski New Issue
04-25-06 12:03 awisniewski File Added: codec#0
04-25-06 12:08 awisniewski File Added: codec.zip
04-25-06 18:16 tiwai Note Added: 0009493
04-25-06 18:21 tiwai Note Added: 0009494
04-26-06 12:49 awisniewski Note Added: 0009506
04-26-06 12:54 awisniewski File Added: codec_v2.zip
04-26-06 13:01 tiwai Note Added: 0009507
04-26-06 13:49 awisniewski Note Added: 0009509
04-26-06 14:34 tiwai Note Added: 0009510
04-26-06 20:26 awisniewski Note Added: 0009523
05-10-06 08:15 awisniewski Note Added: 0009702
07-07-06 14:51 dcomsa Note Added: 0010913
======================================================================
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [PATCH 3/10][CTNETLINK] Fix race condition on conntrack creation
From: Pablo Neira Ayuso @ 2006-07-07 12:51 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
In-Reply-To: <44ADE6F4.2090909@trash.net>
Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>
>>Current conntrack creation path can run into rare race conditions, make
>>the creation process atomic.
>>
>>As side-effect, this patch simplifies the conntrack core API.
>>
>>This patch depends on [PATCH 4/10] and [PATCH 5/10]
>>
>>Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
>
> Commenting on this and the next two at once, since they belong together.
> First of all, they are ordered incorrectly, the code should compile and
> stay working between all patches, otherwise it makes understanding and
> testing individual patches harder and people doing bisections will
> have unpleasant surprises. This patch uses a function that is only
> introduced two patches later and introduces a deadlock by only removing
> the lock inside ip_conntrack_hash_insert one patch later. All this looks
> like it belongs in a single patch.
Yup, this should go in a single patch, I'll merge them and resend. Sorry.
>>------------------------------------------------------------------------
>>
>>[CTNETLINK] Fix race condition on conntrack creation
>>
>>Current conntrack creation path can run into rare race conditions, make
>>the creation process atomic.
>
>
> In patch 5 you refer to timer activation and hash insertion. Why does
> helper lookup needs to be done inside the lock?
On helper module removal, the conntracks in the hashes are unhelped but
the conntrack that we are about to create is not yet in hashes, and it
will be refering to a unexistant helper. To overcome this Harald added
the function helper_find_get() that uses appropiate module refcounting,
so the helper can not vanish in the ctnetlink conntrack creation path.
At the time that I was cooking the patch, I realised that we don't need
find_get() anymore if we can move the helper lookup inside the locked
section.
>>Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>>
>>Index: net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c
>>===================================================================
>>--- net-2.6.orig/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-07-07 00:15:14.000000000 +0200
>>+++ net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-07-07 01:52:14.000000000 +0200
>>@@ -1059,13 +1059,12 @@ ctnetlink_create_conntrack(struct nfattr
>> ct->mark = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_MARK-1]));
>> #endif
>>
>>- ct->helper = ip_conntrack_helper_find_get(rtuple);
>>-
>>- add_timer(&ct->timeout);
>>+ /* we do no want any races on hash insertion */
>>+ write_lock_bh(&ip_conntrack_lock);
>>+ ct->helper = ip_conntrack_helper_find(rtuple);
>> ip_conntrack_hash_insert(ct);
>>-
>>- if (ct->helper)
>>- ip_conntrack_helper_put(ct->helper);
>>+ add_timer(&ct->timeout);
>>+ write_unlock_bh(&ip_conntrack_lock);
>>
>> DEBUGP("conntrack with id %u inserted\n", ct->id);
>> return 0;
>
>
> I also see another race, the caller of create_conntrack does a lookup
> within locks, drops the locks and we reaquire them here. The entire
> lookup-insertion needs to be atomic.
Not really, the lookup-update must be atomic, as it is now, since the
conntrack is in the hashes, but for the lookup-creation-insertion I
don't see why we would need to. The conntrack that we are creating is
not yet in the hashes, therefore we only need the locking in the step of
timer activation and insertion.
> From patch 5:
>
>
>>--- net-2.6.orig/net/ipv4/netfilter/ip_conntrack_core.c 2006-07-06
>
> 23:27:55.000000000 +0200
>
>>+++ net-2.6/net/ipv4/netfilter/ip_conntrack_core.c 2006-07-06
>
> 23:28:41.000000000 +0200
>
>>@@ -428,12 +428,12 @@ void ip_conntrack_hash_insert(struct ip_
>> {
>> unsigned int hash, repl_hash;
>>
>>+ ASSERT_WRITE_LOCK(&ip_conntrack_lock);
>>+
>> hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
>> repl_hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
>>
>>- write_lock_bh(&ip_conntrack_lock);
>> __ip_conntrack_hash_insert(ct, hash, repl_hash);
>>- write_unlock_bh(&ip_conntrack_lock);
>> }
>
>
> Since we already have the hash values in the caller of create_conntrack
> and should hold the locks across the lookup-insertion anyway I think
> this obsoletes this entire function.
Same comment as above.
--
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
^ permalink raw reply
* Re: Kernel 2.6.17 and RAID5 Grow Problem (critical section backup)
From: Justin Piszcz @ 2006-07-07 12:49 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.64.0607070845280.2648@p34.internal.lan>
On Fri, 7 Jul 2006, Justin Piszcz wrote:
> On Fri, 7 Jul 2006, Justin Piszcz wrote:
>
>> p34:~# mdadm /dev/md3 -a /dev/hde1
>> mdadm: added /dev/hde1
>>
>> p34:~# mdadm -D /dev/md3
>> /dev/md3:
>> Version : 00.90.03
>> Creation Time : Fri Jun 30 09:17:12 2006
>> Raid Level : raid5
>> Array Size : 1953543680 (1863.04 GiB 2000.43 GB)
>> Device Size : 390708736 (372.61 GiB 400.09 GB)
>> Raid Devices : 6
>> Total Devices : 7
>> Preferred Minor : 3
>> Persistence : Superblock is persistent
>>
>> Update Time : Fri Jul 7 08:25:44 2006
>> State : clean
>> Active Devices : 6
>> Working Devices : 7
>> Failed Devices : 0
>> Spare Devices : 1
>>
>> Layout : left-symmetric
>> Chunk Size : 512K
>>
>> UUID : e76e403c:7811eb65:73be2f3b:0c2fc2ce
>> Events : 0.232940
>>
>> Number Major Minor RaidDevice State
>> 0 22 1 0 active sync /dev/hdc1
>> 1 56 1 1 active sync /dev/hdi1
>> 2 3 1 2 active sync /dev/hda1
>> 3 8 49 3 active sync /dev/sdd1
>> 4 88 1 4 active sync /dev/hdm1
>> 5 8 33 5 active sync /dev/sdc1
>>
>> 6 33 1 - spare /dev/hde1
>> p34:~# mdadm --grow /dev/md3 --raid-disks=7
>> mdadm: Need to backup 15360K of critical section..
>> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
>> p34:~# mdadm --grow /dev/md3 --bitmap=internal --raid-disks=7
>> mdadm: can change at most one of size, raiddisks, bitmap, and layout
>> p34:~# umount /dev/md3
>> p34:~# mdadm --grow /dev/md3 --raid-disks=7
>> mdadm: Need to backup 15360K of critical section..
>> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
>> p34:~#
>>
>> The disk only has about 350GB of 1.8TB used, any idea why I get this error?
>>
>> I searched google but could not find anything on this issue when trying to
>> grow the array?
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Is it because I use a 512kb chunksize?
>
> Jul 7 08:44:59 p34 kernel: [4295845.933000] raid5: reshape: not enough
> stripes. Needed 512
> Jul 7 08:44:59 p34 kernel: [4295845.962000] md: couldn't update array info.
> -28
>
> So the RAID5 reshape only works if you use a 128kb or smaller chunk size?
>
> Justin.
> -
> 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/
>
>From the source:
/* Can only proceed if there are plenty of stripe_heads.
@@ -2599,30 +2593,48 @@ static int raid5_reshape(mddev_t *mddev,
* If the chunk size is greater, user-space should request more
* stripe_heads first.
*/
- if ((mddev->chunk_size / STRIPE_SIZE) * 4 > conf->max_nr_stripes) {
+ if ((mddev->chunk_size / STRIPE_SIZE) * 4 > conf->max_nr_stripes ||
+ (mddev->new_chunk / STRIPE_SIZE) * 4 > conf->max_nr_stripes) {
printk(KERN_WARNING "raid5: reshape: not enough stripes. Needed %lu\n",
(mddev->chunk_size / STRIPE_SIZE)*4);
return -ENOSPC;
}
I don't see anything that mentions one needs to use a certain chunk size?
Any idea what the problem is here?
Justin.
^ permalink raw reply
* Re: Kernel 2.6.17 and RAID5 Grow Problem (critical section backup)
From: Justin Piszcz @ 2006-07-07 12:49 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.64.0607070845280.2648@p34.internal.lan>
On Fri, 7 Jul 2006, Justin Piszcz wrote:
> On Fri, 7 Jul 2006, Justin Piszcz wrote:
>
>> p34:~# mdadm /dev/md3 -a /dev/hde1
>> mdadm: added /dev/hde1
>>
>> p34:~# mdadm -D /dev/md3
>> /dev/md3:
>> Version : 00.90.03
>> Creation Time : Fri Jun 30 09:17:12 2006
>> Raid Level : raid5
>> Array Size : 1953543680 (1863.04 GiB 2000.43 GB)
>> Device Size : 390708736 (372.61 GiB 400.09 GB)
>> Raid Devices : 6
>> Total Devices : 7
>> Preferred Minor : 3
>> Persistence : Superblock is persistent
>>
>> Update Time : Fri Jul 7 08:25:44 2006
>> State : clean
>> Active Devices : 6
>> Working Devices : 7
>> Failed Devices : 0
>> Spare Devices : 1
>>
>> Layout : left-symmetric
>> Chunk Size : 512K
>>
>> UUID : e76e403c:7811eb65:73be2f3b:0c2fc2ce
>> Events : 0.232940
>>
>> Number Major Minor RaidDevice State
>> 0 22 1 0 active sync /dev/hdc1
>> 1 56 1 1 active sync /dev/hdi1
>> 2 3 1 2 active sync /dev/hda1
>> 3 8 49 3 active sync /dev/sdd1
>> 4 88 1 4 active sync /dev/hdm1
>> 5 8 33 5 active sync /dev/sdc1
>>
>> 6 33 1 - spare /dev/hde1
>> p34:~# mdadm --grow /dev/md3 --raid-disks=7
>> mdadm: Need to backup 15360K of critical section..
>> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
>> p34:~# mdadm --grow /dev/md3 --bitmap=internal --raid-disks=7
>> mdadm: can change at most one of size, raiddisks, bitmap, and layout
>> p34:~# umount /dev/md3
>> p34:~# mdadm --grow /dev/md3 --raid-disks=7
>> mdadm: Need to backup 15360K of critical section..
>> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
>> p34:~#
>>
>> The disk only has about 350GB of 1.8TB used, any idea why I get this error?
>>
>> I searched google but could not find anything on this issue when trying to
>> grow the array?
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Is it because I use a 512kb chunksize?
>
> Jul 7 08:44:59 p34 kernel: [4295845.933000] raid5: reshape: not enough
> stripes. Needed 512
> Jul 7 08:44:59 p34 kernel: [4295845.962000] md: couldn't update array info.
> -28
>
> So the RAID5 reshape only works if you use a 128kb or smaller chunk size?
>
> Justin.
> -
> 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/
>
From the source:
/* Can only proceed if there are plenty of stripe_heads.
@@ -2599,30 +2593,48 @@ static int raid5_reshape(mddev_t *mddev,
* If the chunk size is greater, user-space should request more
* stripe_heads first.
*/
- if ((mddev->chunk_size / STRIPE_SIZE) * 4 > conf->max_nr_stripes) {
+ if ((mddev->chunk_size / STRIPE_SIZE) * 4 > conf->max_nr_stripes ||
+ (mddev->new_chunk / STRIPE_SIZE) * 4 > conf->max_nr_stripes) {
printk(KERN_WARNING "raid5: reshape: not enough stripes. Needed %lu\n",
(mddev->chunk_size / STRIPE_SIZE)*4);
return -ENOSPC;
}
I don't see anything that mentions one needs to use a certain chunk size?
Any idea what the problem is here?
Justin.
^ permalink raw reply
* [U-Boot-Users] testing hardware
From: Andreas Schweigstill @ 2006-07-07 12:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <8bf247760607062357y2ec65f16k952aeeaae6e6c712@mail.gmail.com>
Dear Ram!
Ram schrieb:
> Can this be in done in u-boot. if i want to use u-boot what changes
> do u think i need to do?.
Yes, this can be done. The client just has to generate commands for the
U-Boot command line. Unfortunately this means that the client also must
have access to the serial console port.
If you only want a network connection between client und target, you
either have to use netnonsole (doc/README.NetConsole) or write your own
application. Probably you would like to use U-Boot's netconsole code
as a reference implementation.
Keep in mind that U-Boot is not a multi-tasking OS so it is not possible
to let such a test server run in the backgroud. U-Boot doesn't use
interrupts (on most platforms).
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
^ permalink raw reply
* Re: [KJ] [PATCH] drivers/block/DAC960.c: Add KERN_* to printk
From: Christophe Lucas @ 2006-07-07 12:47 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20060707124512.GA10521@chello.nl>
Richard (h.vanberkum@chello.nl) wrote:
> Add KERN_* to printk statements
http://lists.osdl.org/mailman/htdig/kernel-janitors/2005-March/003861.html
Have a nice day,
- Christophe -
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* [patch] domain builder rewrite, guest kexec
From: Gerd Hoffmann @ 2006-07-07 12:46 UTC (permalink / raw)
To: Xen devel list
Hi folks,
I've just uploaded my current state of the guest kexec and domain
builder rewrite work.
Booting a new kernel via kexec starts working now, I can boot to the
login prompt with a ttylinux rootfs on a ramdisk, so you can start
playing with it. It's far from being bug-free though, xenstore is
broken for example.
The new libxc domain builder code is in use here all day and runs stable
too, although I'm using it with 32bit only at the moment.
More verbose description is here:
http://www.suse.de/~kraxel/xen/kexec.html
Patch against unstable is here:
http://www.suse.de/~kraxel/patches/domain-builder-kexec-master-xen-10647.diff
have fun & cheers,
Gerd
--
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg
^ permalink raw reply
* Re: Kernel 2.6.17 and RAID5 Grow Problem (critical section backup)
From: Justin Piszcz @ 2006-07-07 12:46 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.64.0607070830450.2648@p34.internal.lan>
On Fri, 7 Jul 2006, Justin Piszcz wrote:
> p34:~# mdadm /dev/md3 -a /dev/hde1
> mdadm: added /dev/hde1
>
> p34:~# mdadm -D /dev/md3
> /dev/md3:
> Version : 00.90.03
> Creation Time : Fri Jun 30 09:17:12 2006
> Raid Level : raid5
> Array Size : 1953543680 (1863.04 GiB 2000.43 GB)
> Device Size : 390708736 (372.61 GiB 400.09 GB)
> Raid Devices : 6
> Total Devices : 7
> Preferred Minor : 3
> Persistence : Superblock is persistent
>
> Update Time : Fri Jul 7 08:25:44 2006
> State : clean
> Active Devices : 6
> Working Devices : 7
> Failed Devices : 0
> Spare Devices : 1
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> UUID : e76e403c:7811eb65:73be2f3b:0c2fc2ce
> Events : 0.232940
>
> Number Major Minor RaidDevice State
> 0 22 1 0 active sync /dev/hdc1
> 1 56 1 1 active sync /dev/hdi1
> 2 3 1 2 active sync /dev/hda1
> 3 8 49 3 active sync /dev/sdd1
> 4 88 1 4 active sync /dev/hdm1
> 5 8 33 5 active sync /dev/sdc1
>
> 6 33 1 - spare /dev/hde1
> p34:~# mdadm --grow /dev/md3 --raid-disks=7
> mdadm: Need to backup 15360K of critical section..
> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
> p34:~# mdadm --grow /dev/md3 --bitmap=internal --raid-disks=7
> mdadm: can change at most one of size, raiddisks, bitmap, and layout
> p34:~# umount /dev/md3
> p34:~# mdadm --grow /dev/md3 --raid-disks=7
> mdadm: Need to backup 15360K of critical section..
> mdadm: Cannot set device size/shape for /dev/md3: No space left on device
> p34:~#
>
> The disk only has about 350GB of 1.8TB used, any idea why I get this error?
>
> I searched google but could not find anything on this issue when trying to
> grow the array?
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Is it because I use a 512kb chunksize?
Jul 7 08:44:59 p34 kernel: [4295845.933000] raid5: reshape: not enough
stripes. Needed 512
Jul 7 08:44:59 p34 kernel: [4295845.962000] md: couldn't update array
info. -28
So the RAID5 reshape only works if you use a 128kb or smaller chunk size?
Justin.
^ permalink raw reply
* boot errors in kernels 2.6.17-mm6 plus 2.6.18-rc1
From: Uwe Bugla @ 2006-07-07 12:45 UTC (permalink / raw)
To: zippel; +Cc: linux-kernel, akpm
Hi Roman, hi John Stultz,
Andrew told me that you were working on that issue.
I use Debian Etch in connection with latest kernel-headers and kernels.
My system is a Pentium 4, the graphics card is an ATI Rage 128 Pro with 32 MB RAM.
When I compile both mentioned kernels, I can activate FB and FB_VESA.
But if I add „vga=791“ to menu.lst (i. e. as an additional parameter for the kernel to boot) two bugs happen:
1. The kernel takes an eternity to boot, taking about 4 long breaks to come up at all
2. the AT keyboard (atkbd.c) is not functional (i. e. I type in one letter at boot prompt and this letter is being duplicated for about 50 times
If I leave out the kernel parameter (vga=791) evrything is working fine so far without any faults.
Would you please fix this in the above mentioned kernels, so that I can use my system again with a startup screen including the small little penguin at startup?
Regards
Uwe
P. S. 1: This issue is not, as I thought first, a atkbd.c issue for Dmitry Torokhov, but a pure framebuffer issue.
P. S. 2: Is that email OK so far or should I open an entry at kernel.bugzilla?
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* [U-Boot-Users] [patch] Add support for EP866 and EP852 boards
From: Jeff Mann @ 2006-07-07 12:45 UTC (permalink / raw)
To: u-boot
Patch files attached (in a gziped file) to add support for two new
boards.
CHANGELOG
* Adds support for ep866 and ep852 boards from Embedded
Planet. Patch by Embedded Planet, Adapted from interal
U-boot v1.1 port and submitted by J. Mann, July, 6 2006.
begin 666 ep866_ep852_patch.tar.gz
M'XL("%%CK40``V5P.#8V7V5P.#4R7W!A=&-H+G1A<@#L/6MWXCBR_17.R7^H
M,WU/#R2!V 9#.MGN;4*<;G: L$"Z>^[N'%]C1/!M&[.VZ20[CU][?\BMDOPD
MD'=G=V?0AV!)526IJE2JDFRE^:'1?:^U3]^_^'9)PE23)/XK7?^5%%E](4M5
MM:+4Y*I2?2')4EU57X#T#?L4IX4?&![ "\]U at YO@;JO_#TW-2/[Y;6B,QS[X
MB_G<]0*8N!ZP^7ZM!L9L3$^J`B/7\!!DXKD.:,Z(C<=L#'F GFW,6%"&GA&8
M4QA=)96B9A>ICAPK"+ $:_]2AHXQF^T2ZE\6]M4NU$!!%<G_JYGQ!TR+T@@5
MNR27Y7)U[QNU07.<)O2Z^4_/?/Y+,LY\FO]R5:Z\`/4;]2>3_N#S/R/_N>L'
MWT )[B%_2:TJ*'^E4J]OY/\<Z;K\63!E7MDLS\F8/TD;?/VO5M?)7ZZJ2BQ_
M6:J@_*OU:F6S_C]'*I5*D-:!DNM9YQE%R.'2K)9DI2370)8/*J\/E/UR/'&A
M)*F2E-_9V8&UJD04:B6I7I(J("L'E?T#5<I0J"*%=^^@5%7DW1KLT(\LP[MW
M>?007K+9V)K WC9(L+V')3LO,3MF$VO&QH7F:?>D]5[7>NBH%.&77U94J$IQ
M*[^3VRX4%N841;U=A*/FH"\5X=4;^(T_ZMKP0[MW],/A&L!?WD A!M2Z\(NH
MT)NG[:$V&,;YD[-V^[C7_EPD0J+C^1T<@C7!;D'8I7[O<[/=& Q:S3S<K5>K
MX>[?*<'C:FVWCCQ6Y=U]SN(<9VN*J1 Q[Z1Q/"@BP&+,;.,*"C*)JWB8PX3B
MN#"L`&0)')\(E%XR>P6)1N?S?DU:)9F$#47BU8.1J?;O*+;[:<3RJ,2PDE%%
MPPK5+P^__DZ=T^N3=F%XP9.:_]OL/[I\:F+_%5K_JQ@(;NS_<Z0;[+]0A$>8
M_X1 ROI7I0-EM?67%6Z9Z">T3+G<;P7?,75K-F:7\.8-R/!G;M5DO3]0*HK6
MU64X6"I1T-#%TQ;MTO75`JU'NS74;K=*#T5]L$U"`Z3-C)'-H./.K !#\![%
MXD//F/DFL[XRCQNE-<M!N!IT.Z?=S\V/_80--\@_(S5SOO@6,>!=_7\9#4"U
M4B?_7Y'4C?__'.F:_)VYN7]Y^:1J<)_XKR:1_:]4E8W\GR6MDS\^HMFUGL03
MN"W^4VK)^E^1:RC_FBK5-^O_<Z35Z_]*17B8)["65-HGD _DVFJ?H%KE/@'^
MO(ZB%8 6N!<,II8#!DP\QF#$,,Z$$ER,?XH"FI4K__OAAV(.PB06Z=71)"['
M.5%/D"O7\?7UUUN!%5 ?M'Y'&X1D5@&TFF?[->4F@!Z%1Z*>F*547E/XK%0Q
M?*X*;GGS2],V?-\R.>>AD'&.=K*1*1\7NBU\VS^!3R+9Z_"J(N!5914\W.1!
MO7J55)T at L>Y'O3706UV]^['?Z!1%YVTK8-=[_J^>-+^CM&ZN^J;Y9$'@;?:_
M*B?K?Z4BH_U7JQ5E8_^?(]UJ_[DB/-KTQU2$U5?)ZDO*@5I=O0^XK_(]*O[#
M[9CE.%[IK>7HEDNGDV7\T>?CL1'P[;+>,9H/;4@;8?APF-XT%'M(R8JP>B-N
M3:B7CN?N'<L][]9>9!J)?6I5(O;1SX.W^'Z/&WPW;._]89>4M1.6>99A/\T2
M<(O]Q]@P.?^I$)Q<DS?O?SQ/NMW^AXKP^"4@12CM^RL'\NI50*[7N>^//\*,
M19-5_-)T3EFQ]4[_'V2[#S+K7G8`1&:U_#/2ZC1^T!KM]E/N_5.Z;?[7*I5X
M_M=K=/Y;4=$EW,S_9TBKYW^H" ^;\RGD[#ROKI[GJH+S>X?_Y<[*26^PKTKM
M7*[=Z ZU9B[W5\KG<L._=D0Y1L.Y]UH778=A+F=?..Z,P_ L!U*S0/J@F>L<
M?<[E_K$P9L'"$5 U0:J4$VEAHEN0+OA:J5-VAV=XB)L"BDMKM1 at 2ON/GU4^5
MGL<ER4K.^(*6RF9/; !N7?_EU/M?$JW_5;FZF?_/DM;,_U 1'F@`4MAI"U Y
M4.35\9Y4X^]]X(^L<".@M7M#G*&ZZ<XFUOD!SKR9>,19_:Z\YWP1.?BOPKN#
M$.A-$>9S$X2W`<R>!Q3XM;73S[33)?:T!&3N("&W<T=R<[XUQNFHRJ/HT)89
M#G PU+2._%K1XC'>>XA^P)B#)- at CXI>LM^8Z:$R?_ A0^/AW._^A at Q])5NJ2
MLCG_>8ZT2OZF,];GIF-:QK/$?[*L1O)']Z_&SW^4RB;^>Y:T)OZ[K@@/C/]6
M$TJ_#8CQW^I50:V+;:QZM(V%80W&,W"TZBL$\:$!]\HH9$+0TA.D&X/*&W8'
MH[CQ`1N+Z9#SIJ!R34S)ASZ<,LZI\'L-'Y<)'P(7IL97!E;PO0^CA0].&',&
MEL/<18!@`0'5MO?!M%WSBU_.`VS#X,=>LP^6#Q>>%3!P9R;]H:\VZ.U.-G$]
M!@[.(LJ";[L7N"Z!PQS7NX(1 at XF!RY3WA]U?^W=/F=G:UQK''>VIP__;[;]4
M2_Q_E;__4:EMWO]^EK3:_ at M%>)C)3W"SOG^UOGJ7;[<*._0'+7SI)3K8+S&&
MA@+:QJ8[O\+.3 /Z. Q1Z$>ERD^N/3DW9N=PS&9?=N%8ZWZ&@3L)+ at PT1=KL
M'.TB\ZS9^2Y<C-^-V>RR/&9HRUZ*0_)]<4B./^'94BXRH>U>KQGG.KWFOEJ5
M&L>#J"3<?\AB4)2RC*-];+0S2&H:"4,`91FGMMQ.#=O92:/0/D.2PQ@BU8M^
M*]7MLX'6_:$5YX?#(3.G:>@X\(A1/@[DN/IL^'E?J:IIA.%GZ74USG:U8>_#
M:5>+"SY6ZAOK_A^;,E.7^PM/_P;HG>,_G!=5_OV/HDK53?SW'&F%_+E]>4HM
MN(_\*SS^JU34S?=_SY+6RA_7S#F;C9^BC5O\/[52E4/YJVJEIO+O/Y1-_/\L
MB0N[[!Z(G<FR"7ON/$ 5V,LHAC4S[<68A>%\><I?2+P%DC8L[P[I"[6[$X(S
MYONA& '[=X&WK=GB<F^$L>[\3O"&[]P#6E"_^W Y]:N N=Z8>7=%"*[F[#YC
MC>CC.,YU.A,V[B2T96S_PA@]!.^<S= !-^^.>L_QS5W?NM3OB>0'8]28NW+\
M at 4U0V''7)NX'/0\\PV09Z'#O:X_9XR\83NTM?!+X;*]<QOZ,]LY-$X=QP;RY
M61+]JY:ELA131888WIW;W[^\U"W',>9W09C3EU_3FV&L,;L+J8EM^-.[`%J.
M<7XGBC0:47%7Z'/;'1FV/C8"XRXHXGSF+I#^W"I/\V*(:(/%P\8&;VSPQ@9O
M;/#&!C^!#=YL3=V<UL9_H73LL?_H-FZ)_VJ*(K[_D^KU2JU*W_^J%6D3_SU+
MVMO.P_:*[78J?> ^.Z<X8 SH'2!H]K7CUG# [Y.S+3\`=P)SYLZQZF+J`B[:
M:()'"[H:+G AF%H^H<\]]W^9&434AEA,9>>>X=!1)/_HSP^[<@A7[@),8P8>
M&UM^2 ZL@&ZNVW,](N"X8VMR166+&:Z._*PR8)[C4W<H\[Y[!N]IR31LZ"U&
MMF5"VS+9S&=@B!Y1H3\5-]@1Q at GU(6;'B8N$C<!R9X? +#H9A:_,\S$/"K9!
M% @II+D+R(V"$5#//4 [AG!%[.X5V$:0H*X;?C+*,5@S3GCJSG%$4R2)8[RP
M;)O.7A<^FRSL72*!P/"I-?QP>C:$1O='^-3H]QO=X8^'"!Q,Z?B7?66"E.7,
M;0LIX[@\8Q9<A=WO:'VZ+'#8.&JU6\,?:00GK6%7&PS@Y+0/#>@U^L-6\ZS=
MZ$/OK-\['6AEX'J 1(G #2PFY7#H('G,`L.R_6C@/Z)@?>R=/19GUQ[CKT6/
MP4#%F5_=+CPB8M at NZC -DZM7Q,A#L"8P<X/=\&";:]^26 D]D>PNM&9F>1?4
MUS!D#FEPST9_8!<&"R)0J4B[<.3Z`4)RAC5 4F19+LD5J0YG@T:>7B?(HP1Z
M9T.]@=PLA*Y!,3_0**\?M_H%\AN*AY N(:=B3:EK&O:-=9'W@<I58O9$P.;W
MMN'8A0L&.(7'7/$$*T-9(."?Z9-373_^L=OHM)KP!J1#^@051S#0FL/6:7>0
M_YD6X6WH,V-<HC<"P,<IBWSR=\%AWCE73N(JNZ27"\X=-@L.^!L54$9Z.S!H
M_;=V>J)_T!K'6G]P2.6(@+V%`_ at 9M@MAK at B_4M44?1"(4PA!A<5<C@.,KV;^
ME;,$( K3((&W`B3P(A"/V67>XS1(5)@",A*H!$@4%B$A1?[*-5)4F"$50Z5)
M<:@4*<^-P%*D1&$*S$C@TL2NP97/W0"N]0P+,QV+@=*TLD!E,W ]?YD0+RRF
M*,50:4I+4.7Q*E+C95+C5:26H,HCW[\^/"S,#"\&2E/*`I7G]@H^86&&4 R4
M)I0"XI\P+RLO%88])ORPE+"$QJ?4$+,_\V_ TQ_4!.3AN[F"4+H\K]^.<F%F
M8ETNYG$.)2=3ALCKC--_`V6:>;W^Z<?6L0:%N+3()V1*Z>(^T/B$.F6S\E*^
MC-,*W<JXE$WU"1I>%O4`.S>S,ARA at B+E?X4W$D%<TRVA,1 2N*8OXZ0Z99R$
M@0^M4]8X\=%=-TZ%,MHGZ5*23DZ*\ J?3GB2I$/..<]=S;ND/.0>0R.\S#N:
M/OQ9?W\Z5'1<4-N:'M&*()00Y*3U^:RW"B86+)>E3B at Z(U^*^=3_+&(ITU81
MWKY5^$!T3B6-1[<H9'"+')8S>Y4B9-0 at JP1^IH[GE 3T:F8XEBGR35Q-AOVS
MYO"T/XBU4S3W!I9YS,L%AT-AE<58%CI%+#IM3?&I$=64DXI(39*28LB_%#*;
MC07J$GU.5-=U=JD'_*.MN"8N$>23 at H@Z^@3S:Y at A]4:[];Y;4-1:41 CJZ"/
M&'K7\0!(J80)"?L?%X26 at L^V-$!<$ *L:R<9*Q6AY5MB7<J*1E(G69*)Y ]B
M,[*8CX5*-6$N>6R>=CJGW<3PB$8A*U=1B)W[O5ZU]V^9UL;_X7G@;T_0!C__
M7WO_NR(KT?M_"MW[0.?_577S_>_SI+WMK7 #()?9`)!Y\2#X/PJGX 2#+UPS
M?5P<_G1Q<8$+NT'E99S^;SE@SV(>AF^-LR.M/P28E[&>><&[%""'.RL=(1^!
MWS"/H3&]"BVNIX'V"7:BW3[1CSY5Y*)X=9E0ME;O3VP]>(,B)OJ(+8JM]!Y%
M3/!1NQ1;C]^FV'K\/L76`S<JUO+@GEL56X_?J]AZZ&9%+MJLV+KO;D4\^D?O
M5VP]<L-BZ\$[%ELKMRRH=&\KOY5_&6ZLPY^B\\>WV4)Q]I8IC/;@WZ;*^(GG
M6Z+X1)]H1-]I$$FT-@'RDK,/O7L8(]=TW_HG at T)4MIO4;B?/=&%SB+R8^=8Y
M75+"/[@W?'-*7INKT\D:%+*UV^:<,+_)6%Z*#SQ [YX.];.!=JSG1!32;$HJ
M`2#+T50M:"0^'RAW+?_V$[S9RO^\E<^19:?;T@9H`%'P% B5H7 ZF=!W'I(T
MI>EXUD.)TVU;'!3;Q3;8Q!R9IE3=I?AG4JF;^^$S8\R4PF=Y]'J_BL\<0YY,
MZE6LVJ6 "\UY($@E/=^%-<\TCKBC1PL/49?ZN?^X?DJCL1GW4Y(F$Y/W<^E9
MGHSVP^>'CR4[KOMC7!?9)YKF"2_DA_%B'UVL2&;2LLS4)Y'94D>5ARD7=E2*
MA%:MXO,ZH2DIH5530GO 8)Y0:'V&Z[T_3=A0N8D-$R-APT1-/4_,9%#BF6-,
M1$ZEFO0S4D(V5")L9 ,]9]C *["Y4:JY2M*<E'X>5;.#TBY-QA?]U+"::X<E
M39BQ'])#\:C5\%ETF)X3YFWE?_U6II.(\N6L.67F%_&](+30_PNLX.H@7M+(
M<IH$P7U-*'QUK7%1V,[Y(O"A\!W'/ #^S=W?9]^1K<]Y+%AX,RA(E/N5Z! >
MI.] 3!%*;GCAMQH*1MU\G0L'Q( \A4O+O#LKB7[R>ZXAH#MB+$97Q) [0A"T
M(+@(S9WK[;W;VHENB0:QO*=O1CO1FOQ"-3& CX9MH3LAND&?\P'_OPXS^EP0
M>Q%?5"-&]M5%SY"\ZDS32G+YF:)W6JWFL'UX'_C>I_[QI^YM*.'H.$9_,+P/
M>-R N$)G*R]D^PVT,_8_2%EHX88"Y;AP^<LNH>K$W>9O?. at H4OY FW1Q"49%
M)^_U5J?3/TQC.,PQ`YO>%D$8D4&T5QR-WZ(GR@@G[@VY27Q"YA9S)[QZH$"3
M?!>]'NXN%=-^!EFE'%UR2GCHUA92=478BXL)M2B<I-Q>;"3%!Z;HV#+?-&PC
MU![1J]);^M6=>3#WL-<TP$YOV.L+&ED8 at R!H7:"TOQ\WTT$^\;#-M6W4S9$Q
M^^*#''G,@V.:BE2XHEW7D\-63_NRWNMK[5;G<!EH% ,=I8&N]\^)A]#H]/77
MS=,VO(+";P6>[0T;6E'<2S=S,580K+EB0:@I\0UVBB0E+)PS#V>\$XZ"E,C"
M"?I/[N^#S_ZQ8/2%;D at AVQU3L(L66D6IU'C+*6;0-W91+X(+*Z22W*-77#=$
MG$CQ@ YI\6'";D7$EH9#%_(EXPF-M.A 1WPW/$#M$0M0 at +G7*$M[X<PH/&;1
M<H._W+-_D_;R,YPFQ>7JC9K+1ZD?-09:*"VAOYA$3:?Q6:?CR+!;D9$GJK&=
M_P:V(+-.A=],HTD]%S'F5S*\M,:6,6#U+1Z_A4 !?62-X2?S' P2_#AL-\Q@
M8=CV%1A?,3+E0B#Q<NZ,6'#!,&XVQF.4BL]\^)^1X;/O:0."$^!9V ''N"2$
M[\L85CK(58PY,2:UBQC3>F.^B\ \CPY>#!$#,Q.C>[ZNH@)A^(O+SU);8,>]
M7(;@V_EQ]5W#.""]TY%!"Y:.Z&@`J7PXD.<TJ&M,0-+=K(*=LT"/1E<0O8\Z
M'>H=IKWME2HTZ+6@^:'5 at X'6UII#7+R/M9LU-'Z=A/3+MMT+C#.X$!>^V-L*
M;::PDDC>G%ISM"DV2MB/_0Q>X>+09^-RBB*_ at 4 L8T3/!PMQFKWV,1%V%G9@
MH?Y><@I-L=>&A,IBPRBN)F*3Q8P?U-'V46S$^7;6B$C6T(+6:?/P:-#L5\L0
M=@$3=>R8?27#%:5?`$S_)?]%9,2-GNH at D.XY;Z.6M!X4-*W7/^T4DY;0?HE?
M_A ^11C#80<*M G#/ -ECXLDU<O7,>00XV\X1'8Y)S</GT8+_R=>K\1PU]I8
M at U&YCL';"+&..%^0U\@^O3G049LD_C\_D4WU;+D<LUV\RD*76T074- 93Z-[
M/$#IT!1J=HYU1%QUP\7@]&3(ZP0!23C0I&JH:=P7,OUB_N<U$]8[3%68<R><
ME.8<RZEZ:3HG\SF?,^= !XJ%!*O(Y["X61A+R>NF(6'[_ [%_V_O6[O3R)5%
MSU>\5OZ#)LXD$ /I;L#.V''V8, )9\!P`3N9NR>K%X:VPPFORR/VG)DYO_W6
M0U*KF\9V8IS,V;M[[XSIEE222J525:E4:F/W@:6"@)NF\!@P94BR[L&L[TW=
MZ;F*0$PRB UU>$- at H;KL8&R6_CBX_+A:_$\IP=BX\R5#7#)*YM.!ZWG3V00:
M%\9.XH6TM<+_2VTK*ZH+_$EZ@#]I`W.6Z16'$+_01-U""8XF+Z=140G&*=1*
M5M[B."OU06\VP528;ZH,3W5I[L1=),-D"=WG%I!W45\C0B01"2G1G3.<X/PF
MWH <`XM@DX/239:0%TT5-PQ[)+7<1 2)`!7TY@$JF-!0#GQ:^(/\#"AXBF:.
MS$5GWN4`@Y\HPS<J&S0B,& BV09L]3Y2`J%"\T H(,=(<4_(GZ*ZUJLS>5:8
M*&QTWI53UL;9%_@"<A=5!BT^@?9CJZ%_JBLWT/5?DK2Y[(W4_4<8D$'AB;\2
M0.4^>:,B.>H.;Z-O8=]&X N?LT(2*,(S(B+JK*Q$![PQ9\ F:>H6WO(-R,K^
M0K*R[T!6AP at GP0')\\#=_R=$4"LT9G]O$@M06*GM1%,7)- (:$%98B>P at M(R
M]R]#'LX7DH=S5_(`^@A2!1+%&HJQOSL+"M%';AU]Y.Y&'XE_'0+)?2&!Y%+*
MT+B6/M1=!G_K10DIXH769 P%AS49$FG8<VMRH?43UHB4!(.JE,0TPC$UIWT<
MEQYHT+Q\=:<@TDUG`S2I:EUG5?D*0\ER,#JD64FO9"T4Q@?<_!/0TU7!,<T?
M0\NM_&JP2/U%3PK #HC%9"$T:NZ-T4>,C7Q)(\$W_9E?_VE]0&^]+2,\N:\B
MK(]-'C\/_ZSU_Y)GD3=1QRW^7[D<W?]F.WLYI^#LROM?8_^O;_+X_E]!!ZM<
M[& 5.UAMV,%*Q Y6ZQVL;G6QTMY4F)>XLSL87TS<1<)_^2=O@+QWCVO%]EOW
MJ'CR2_L#[<A@*N&54MC:EN":48K S5_MVX2+/0-H-EH=]UVUW'E[X.?S1;V;
M"IP=:!^F!*=5R]"T]B_DQF1Z.!TWWR42X>*!Y+.5Y+,``$HL_5JJ56ST0B at 4
M"I&)#B8ZW6XXL5JV$PEK]:N32-BK7W,)!%-93<A3PK'R0/A"R_*ZAPE.B9R2
M7)2O&M$Q#S_N)/ >R>>ER]M>N/F2%B:I@%X"?PUO-QPY(G;W:C+KN]U1/[F:
M/TUC()[WO?F"?M.FC?)\VV _B1PU51F=6_&K"&;"?KOGEL ]&]I9UYN+52BX
MC[NK-$@@RG\:3Z[&O*^)LR$Y.+1 at VK^*F#<'8F=GD!)8FSG#!A^R\@W/*W#^
MTY-?3AKLGO"7WIG$!AV&!B?I#TX*JU35M2MI\=2H!.7E1W0T!C6^0()1>ZAZ
MU*MTQ:#=I!@"=0#4C?$"0#W>WA:G8T8"<P*TZ*O-WS9OJ%K7/UHOA]?PZT?@
ML_6CW\:/:;M4`D^K6EZ_=BS5SK^D%PEO=C=.JIU&BSHF7O,&N-]5'AEEC)OB
MF2G6@1HGN*3"K.J"SBG'B#HK\R0!QANWV6IT*J6.VZYTJ%6\_1*N]H:D'5FU
MR\"'WCAC&]E7QT&YA.CVJ*&0&] 2':M;Q_#1V#W>[$0A`X9"#PPN-4J(B.DK
MIXPQ,9"H,"7S>BTQI4)T,QK,YZCBPH at M`_2#JX+RC9*=-^8!&Q/"E3V5=9U5
M3LJX)'!E/=Q]YH1Z\<0MULO[?OWP)A[CQ83G,Z_["6N0=+)O-%)1]AD,
M\^OL=VI0Y]=F);)!Q7KM;#=OG>X_(DN%T%6FA?,3)=73,+$&[)GAX2E%A13,
MOM+H,!C5\A(J_!T#I8'2W ==2-"$W9>S%*6_'_NR\KF:L]Q1(M37KT&P3POY
MA;*Y/9!D%M+IP81+J:)-9\&*RE]@GYMD\LU58";;1#I+#L2/HI!2'"EA#-=O
M8^B<I!R_<N0][W^<!YJ/[0#.:WR2+ $^BG^(QR+9:J0>BWWXA<]CS)>2&#/K
M>_Q at T_%A8+Y0,K^Y8=^;@#@(>@ZZ98!@/UN.>8^.*/6'L!?%U\H(S#385\-?
M3\G35W27BXG:@)&&LGT0Q;M AMWQ\@*=4&:@NU3+S,1O*N=[+.$+N;4P7^F.
MYU?*K1 ;^4]3RD,[5Q($D12:\(I%_$?.3$B:P"E0*E]X0P$B`F at 1TGX7"<D)
M0"H4\-_700JVZ2<+_Q$DY3[!@!BL\F"2=S6,3*SA\+)K#<54L 6>/" +[W_A
M+0N at Q\EO6?:0(H40I+=/;(]$U1$-TU>#/J at WB%3\PCCMLW,$)66UWRZ[9:%7
M%DT9Q2*I+T8O04K^0$>A+RYP'M,$)P[)3J8IZ!;R[=/C8JFS3Q,]O,0$F3M-
M>\V?\<5 at CFL+&Z*6Y at X&]Z$X%6::E&B"E4E&"M at G%).-%T=E-$"_)O(/(<Q$
MK),_A-=)1@6"1[_#:JL%VN]1M<.YTCPK2)>%V8"C)LF'>>,*BG,?D%'2=\0G
MJ$R\[KB.>/J4^K!:)K^N3([X[1]1Z-PY#"UL-R#4=EY&H?3:XHMU)6YY5> X
M(0/Q*F*9@>\[.[P$<)M"W!WG#W$KZI[8$4GK&H_Z64#D`UXEB)_S?W".=H=H
M+9\MZ6X3#W#\@T0N[@KX?=<+@))<<*QY+AS^>"WH_[S<1^; N);<V)?\A
M=? `1'S-7_\R";BY5 SSO-O[A#* I+B^9_ I*\"<CBW\1\P),=$BQJT*&"*L
M7_L#+ILP-%*J]F;$3:+T3]I^<"\&,U1 ^07/-RC'/G,QPX[*#\]329/"6)@G
M.1CJN$R3ZI&FL!!I,73Q+Z;S@DE%TJ Y7J7I*(4O."=E0X#&>?-;?WBMFF6(
M/W<3LWT2S0@I:6N9^B]!>UPK^<83P41#5_L0\OPROC N;)_AL3QV6XO^_%/*
MG>&LKS7/**.[5S,55A)*W?&S!3=%:PE4FK0$P5IE1G3/0:CP^DI$#<T24Y,P
M&X^CI68&,1OL_:'$_0'AXM4A#P#*H/B^,@Y*:L3$#S[N)XN=G=#4PC*8$.YB
M1KSKSL8P/OLH;$MX7E\/!9E;I61&B.C_H/M)\*A#QI"&I5-9/],C]#=C:^&K
M/)C3'B2%19HMIR!47'T<P%H](JM]KXNR05??YT0<46G1E^@HS>5=OWQ2BOYW
M$K#N*C[="@_]SU]:M^?[XGH93:RU,!5.QD"(JZ/DVW\DEM>0$;[!FG4C&;%F
M(_Y at -_Z%01.\%B5"7$F$V)*DQ0.=E[DU=BQGX3].T02A^%1P'9AY&>ET;U '
MFK.]'NANW=GOOD2#U$#+,!>(( > =]7%C9.%&'IXX.>EM<2S_T,/[PZC)%N,
MYJ'C`:97/XNF[SS.K)RTZ$S:8C:XO 325*.AY5!LF^SE*ZDK7DZ M94;)Q6&
MJV*3H!Z#5#Z3Q[ 2!!AQ@QD4P=R <ZZ&UP.80H"U9%*A_JGP:32%\I[YZJNU
MP-S,EB0),'#$UX:UJ]+"`P>=QFEGA<]W>))JCAU@>%K"`?7KBG=RKKQG,\8F
MJH"&"(GMR!!FL6X:!*9%/!M&(=DF8TV*T^6B)Y+/LL]DI82W0USE at A2%*-]7
MA"7OA5LK5X1$"BZ at 3]>8"KCH3\9>Z""=]2"B!6UFZL,2$UZ%4!K'.N=\5@$M
MGHU?Z*<-/^6>#X\+?77 at ZS$M7SBOF9M+N<6WFY\O+RZBA1;I"3.?]=)2"V=E
MFW_WQDI\409UEIT!@_8NJHDYAQ01M,OCH0#0R4!WX-74U^^ O^$%4N_?RRF$
M!\E0R3A(D$O,>#DZ1[^="ZEZ`";TUN%8]):SF3?F*A()#6#H72S6E,<D`TC"
M*#5 [,YYGA)GI;R'V$]*T4(M`WD-Z'_ZE!-T"LO]VJ^$=AG2G#\3_ HC0RVB
M>85EN7V'#.(IFU^-S#83/*>BGVQ4NIQTO<GH'/=UYI/E3-HE<.=C,.8C5APQ
M;$([S1(/U/CGD%/@&5.<IX!1Q)HYDG/.11,QK"R9K6$U2?(+JNS5JT.A5#!<
M@Z `=Q>$SX'"!-K9"5.L87%)P*5Q"%2J54J74DJ2D1=HU9>$)#K4M8^R5W)3
ME F1>_-%5MXH,Z]D@#A^H<THGDE)WG]*\?Q1FT^F0A^T'4"K5\7/-)]:^D'S
MPB\S;<OVV0=JG8>JZ:"58AEIVE:_''R&?%23JLAOI+]B*Q4+@#Z,;J4L;GK0
MF)%)LQ9WD/(5.<=@'B36-(N6=,"8G*5]EG-A$ "R>78 at H4-B8V K_<'G07_9
M'=(><PH`^[OW&V._:W<OHSEQY/:EW$CTM3U3.52_%>.2"QM06%ITY_/E"-C#
MLH>B%7- K@$/<!VP:8(40G7Z;3 VT)7P;7]\[@_F-'<3QB YA^5DT!L`'QG^
MGI*=]L6C)'4"9A;S+1!.^,<?ALJ4= PU@D[T'>H)%*$//[1J at 2VXD^UV.:8S
MP00U7&BMF?:F0J&:+/P7L,BJI7!DV#X8P8Q7'DH6.F7>D7+SQ'1C)#<J?J\3
M<[DJ8M93Z7&*\[F\Q\"E(*N65%Q>-;V$="\B'5IN(M(,*3<LW@:DVW>M:B<H
MW2KD15F:0F*AP5"_,6>$RK^WT]W?Z%GK_UGO?O+0>6\#==SL_VDY>9O]/_,Y
MQ]IU+/3_W-N+[__])L_VHZVHVW;QZU<Z?Q+$>[E^;AN>GP3MGGZ?V_=V^]R^
MM]?G]M<Y?49V_XM=/K?O[?&Y?5^'S^TO]/>DCF_ VW/[?LZ>VU_KZ[D=Y>JY
MS1L>[-#Y)-EI-,O55DI=7#7ZA,FUZE$"-+G!^9/D4:/8*J>R7?S<./K/-GS7
M'Z5)(SO!Q"=)*)7:3\@[.R$79D<AXTFRV$J)WNRS>/*S_QE:LJD'@<EJ]Q-J
MS8":VEC5?G9RF&VG9,7TUB/1YTFR!"PG4X>4$CIU49[U14#L>/(S^30HY,DJ
M-]R5[\V,O\.S=OW71'G_.FY;_W.[#L;_S>\6\O:N at _<_%^!_\?K_+1Z]_@<%
M@#QQ[)D'BW_W\T#'_577G4V'W;&WD.%_M\-1?2E>FHK@&PL8L8 1"QC?4L"@
MGBF?$*0O:85")!A3,ZOC*_!:BCL!0$W=$;J@( CH/$.93J9+I!LUF^U=43]"
MF_.CK4[E?8?=O _ID at SFZ) IF&!)7R%L7K-6[," UMU2LTEK/UJ>,V5=X! $
M(_4;9(2JEI/$FJ*7E_USD;D83S(8K+>_''J9P7@^GD=]<_XM%_D;GMOB_V^B
MCEOC_]OF_>\VZO^Y0JS_?Y,GCO\?'T^-CZ?&\?_C^/]Q_/\X_G\<_S^._Q_'
M_W\4Q_^/X__'\?_C^/]Q_/\X_G\<__\@CO\?Q_^/X__'\?\S<?S_./Y_'/__
M7R+^__>/M1Q?`1!?`1!?`1!?`1!?`?#]Z2.^`B"^`B"^`B"^`N#?[XGV_]K=
M?;'!.LC_JU!8Y_]-O]'_RW%L9]?._X=EYW*%_'^(P@;;L/;Y-_?_6CO^\H3%
M)NK `=[-Y]>-?R&79_\_&/W"KI6C^Q^<?.S_]RT>&NSL9%_PCYYX,9DN@ 1>
M! A#NN^\4+X_XK<M<5M.=@BZ:\XYD]V="HSZ+A;J>Q?SN^2'=7EY_>(<]+[I
MG?)WYZ,OR,W0[]Y=@O[[PIO,^M[LK@5PE?^2OBKXT(]+%U?<[IT&+5QZ?M4]
M_YIRE^C;-NC=O>@7]F\ZF0^NW2\L-%_T at 6+NBO&OK *]3>]:Q9?EGBYFW9X7
MR"T/X[SPAOU/><MZL9SC@(]?9+/0GO,7E[T>=./*FTU[&6Y?/FME+0T5$-*=
MW;E^5$E(D[E+ at 6EWMH!\-^89]+V[@.)CCG?(.!AU+^\$$7O#"7?-?3F<G(/(
MC%M5=VJ)<R?25^Z16_(DY[X\TAGSX)@'QSPXYL$Q#[X'#];,]7L+V'_S9ZW^
M)_6!3=1Q\_DOV][-Y[3^5]C;0_TO;\7W_WV3)S[_%9__BL]_Q>>_[GG^BU2>
M+S at 1%A\`N[4O\0&P^ !8? `L/@`6'P#[8M;YG0Z [>[&!\#^=0Z /=RIC_@$
M6'P"+#X!%I\`BT^ Q2? [G "[$'M?VOMO](Z/^S/[UW'+?X_NXY3(/NOM;>7
MV\VC_;>0LYW8_OLM'G9Y7;6O?K5Y51['NX=QU;2MZO.%]["LWM^P>G^[ZE>:
M5==T_PN-JO>WJ7ZM257'Y_Q2BZKL^+WMJ?<TIWZU-372F,J')F$$FJ<=MPC8
M3,JMX=16NX+O;KG:2N*^<>I F%]P4WG-UPE(SS>FJ=UG(*Z,-[S at O"C)E"?B
MRA,PA?F&:$:E' O(^(\M$.U=M_SK2;%>+?%55?! #]J54J?:.&EO_;%%3O=H
ML,O01<IXJ1YZQ<,2AMM%2)R(5>\:E OO<@3Z]SYYL(LLP-L1*&XUCMVWE6*Y
MTFH?X'>Z#&4J]L4?XGE2OJ7$7YCT$:_(T8_, at 1]3B01EZ/\^GO\^"F7 at CV:6
MQ2PBRV*FLLR\899:;&91'XU,73^7GXD_IH0/BH2;,"BZM,<$I7.9H/AJ'Q_4
M;**R&:#XHY&MZ^<S@:WDRUY.%F*E9? QT#"=R805S)3E*S5#@.ACRH"D<YF0
M0KFR_2A0_3"H?A2H4*[L^7R^VCWX&.B>SF1""F;*3H<1>(*/`4 ZDPG(R$1V
MH3#QXD?98BPOOV(IIGB##.$59YL0O>E2^C:\H"MYLI-$DHENB]*?JS?Y<C&X
M7D[U&XR<C2\(WO4(_J'(XLQKMAIGU7)%)/77%$U(@^AT&[!_3$[!5SOTGH5I
M!6*E_NI]="^ \7JJ!="X\2" $?Q !^K_$H<6YEBA+:88(0<$O?3S:8$S-X
MR9V"S(EO\UMA3LDL\">ZP>@X13>"'M-C60>$.;SB-0IW_G>)/0^8<!AW.'WH
MM_NFT7%<6%!K%5?!4CD<F>6X^OZT&95'#RR-I8M%7 ]E*;I5*1DLF G4E1*O
M7SO4$9>@F.6RF-<LFZ*\A.PH0@B009 (YH$T>G/\K+^/NZ-!C]]+L)IT6J>E
M3J/5UM3)U1V*,([E59F(83E86>[+TD6-Q4771'6#%J5D_01%)OZ7E,2?41AO
MT*"B(?@$U'5=W XDO5JGZ"\,WO^@H(-,,%TI*:$7:]4W)TFGL)MB8, at 5W',/
MI&O=`20J9B&R_?J#Y!0TV\P,^H/,L*X>OZ_X"3A?"'4&%U6CCF.)+))^\&9P
M:DL/*J;(-_\GQH9HG/B,ARL5P7'ECRF, at O"]E:)_HV>M_B]]D3=1QRWQOW.Y
M7;[_:R_G%)Q=A\__Q/K_-WE\_Z^@`2 7.UC%#E8;=K 2L8/5>@>K6UVL`KY3
MYBVW"?_EG[S]\5[>T'E4//FE_8'V8S"5\,I7>M"I;'E_*>XXXMZO=FU"PSD#
M:#9:'?==M=QY>^#G\[=3;RIP=J!=F!*<5BV[> TT>3&9#D['S7>)1+AX(/EL
M)?DL`,"X\Q6=$ J%0F2B at XE.MQM.K);M1,):_>HD$O;JUUP"P516$_*4<*P<
M$#:T3\0$I^(-!.\_YLTM'G[<1^ =DL]+ES>]^+KLU0N1#6>WU1N4[WZ!\L%#
M7,WZ:$M3E=&Y%;>*8";LMWMN"75K\T!O+5:AX#[NK=(@@8K#]WOSU<5T"?LA
M7L'^*F+>'(B=G8&\V=:888,/67W#^:$<^].37TX:[)WPE]Z7Q 8=A@8GZ0].
MRK](%S<ET^*I40E?S8QBM[PQV$\P:@]5CT$U=,6'PDHQ!.J ONQ\>UN<!BXY
MQXAN:NNWS=NIUO6/ULOA-?SZ$?AL_>BW\6/:+)7 TZH6T PMU<Z_I!,);W4W
M3JJ at R_']/Z\/1;"K/#(J$M,4=68.@-$XP255WN2NKY>&SLH\2;SSQP6-H5,I
M==QVI4.M8O4D7.T-23NR:I>!#[UQQC:RKXZ#[Q&2" Z%W'Z6Z%C=.(:/#W:'
M,3D=*?3 X%*C1-3]YW+*&!,#B8IO`E]+3*D0W8P&\SG&-X$16P;H!U<%Y1HE
M.V_,`XXD$Z[LJ:SKK')2QB6!*^OAWC,GU(LG;K%>WO?KQTOKH9)$XGSF=3]A
M#9).]HU&*LH^@P&#AF)^G?U.#>K\VJQ$-JA8KYWMYJW3_4<4ID;H*M/"^8F2
MZFF86 /VR_#02J60@ME7&AT&HUI>PF at O'0.E@=+<!UU(T(3=E[,4I;\?^[+R
MN9JS\L)W)-37KT&P3POYA;*Y/;SL2[H\F' I5;3)%E!4W@+[W"23;ZX",]DF
M75D_$#^*0DIQI(0Q7+^-H7.2<OS*D?>\_W$>:#[=5S_X8'R2+ $^BG^(QR+9
M:J0>BWWXA<]CS)>2&#/K>_Q at T_%A8+Y0,K\9L+6'U]6#GH-.&2#8SY9CCM%(
ME/I#V(?B:V4$9AKLJ>&OI^3H*[K+Q41%WY-1DO9!%.\"&7;'RPMT09F![E(M
M,Q._J9SOKX0OY-3"?*4[GE\IKT)LY#]-*>^#><E\L8C_R)4)21,X!4KE"V\H
M0$28S%3PIDA(3@!2H8#_O@Y2L$T_6?B/(*GPN0R(P2K_I1<\MB,3:SB\[%A#
M>VJVP(,'%-[KOY;H[P\\B;]EV3^*%$*0WCYQ,"I4'3$JV=6@#^H-(A6_,$[[
M'!R7DK+:;9>=LM GBZ:,8I'4%Z.7("5_(%/XQ07.8YK at Q"'9QS0%W4*^?7I<
M+'7V::*'EY@@<Z=IK_DSOAC,<6UA0]32W,'@/K1/::9)B298F62D@'U",07X
MPE$9#="KB>(#$V8BULD?PNLDHP+!H]=AM=4"[?>HVN%<:9X5I,O";,!1D^3#
MO'$%Q;D/R"CI.^(35"9>=UQ'/'U*?5 at MDU]7)D?\]H\H=.X<AA:V&Q!J.R^C
M4'HM[W24N.55@?>)!^)5Q#(#WW=V> G at -H6X.\X?XE;4/;$CDM8UNJ)80.0#
M7B6(G_-_<(YVAQ@J;;9$3?VC!SC^02(70\+Y?=<+@))<<*QY+AS^>"WH_[S<
M1^; N);<V)?\A=? `1'S-7_\R";BY7.B[/GN?4 :0%-?W##YE!9 at 3WM)Y
MS,P),=$BQJT*&"*L7_L#+ILP-%*J]F;$3:+T3W)/=B\&,U1 ^06/-RBW/G,Q
MPX[*#\]329/"6)@G.1CJN$R3ZI&F;<&T&+KX%]-YP:0B:= <K])TDL(7G).R
M(4#C'/E4?WBMFF6(/W<3LWT2S0 at I:6N9^B]!`0Y7\HTG at HEFCN1/R//+^,*X
ML'V&Q_+8;2WZ\T\I=X:SOM8\HXSAOINIL))0ZHZ?+;@I6DN@TJ0E"-8J,Z)[
M#D*%UU<B:FB6F)J$V7@<+34SB-E@[P\E[@\(%Z\.>0!0!L7WE7%04B,F?O!Q
M/UGL[(2F%I;!A' 7,^)==S:&\=E'85O"\_IZ*,C<*B4S0D3_!]U/@D<=,H8T
M+)W*^ID>H;\96PM?Y<&<=@_)+6:VG()0<?5Q`&OUB*SVO2[*!EVQ&(P\M.$2
M1U1:]"6Z27-YUR^?E*+_G02LNXI/M\)#[_.7UNWYOKA>1A-K+4R%DS$0XNHH
M^?8?B>4U9(1OL&;=2$:LV8 at _V(E_8= $KT6)$%<2(;8D:?% YV5NC1W+6?B/
M4S1!*#X57 =F7D:ZW!O4@>9LKP>Z6W?VNR_1(#70,LP%(L@!X%UU<>-D(88>
MGO=Y:2WQ[/_06SR;<Y(M1O/0X0#3IY]%TW<>9U8'E.A(VF(VN+P$TE2CH>50
M;)OLY2NI*UY. at +65&R<5AJOVIE&/02J?R5-8"0*,N,$,BF!NP#E7P^L!3"'
M6C*I4/]4^#2:0GG/?/756F!N9DN2!!@XXFO#VE5IX7N.TL\+G.SQ)-<<.
M,#PMX8#Z=<4[.5?>LQEC$U5 0X3$=F0(LU at W#0+3(AX-(Y>\R5B3XG2YZ(GD
ML^PS62GA[1!7N2!%(<KW%6%1`.')>KDB)%)P`7VVQE3 17\R]D+GZ*P'$2UH
M,U,?E9CP*H32.-8YYY,*:/%L_$(_;?@I]WQX7.BK`U^/:?G"><W<7,HMOMW\
M?'EQ$2VTR--F\UDO+;5P5K;Y=V^LQ!=E4&?9&3!H[Z*:F'-($4&[/!X)`)T,
M= =>37W]#OA;O5EZ^?Z]G$)XC R5C(,$>3^-EZ-S#-I\(54/P(3>.AR+WG(V
MPUO?L8I$0@,8>A>+->4QR0"2,$H-$+MSGJ?$62GO(?:34K10RT!>`_J?/N4$
MG<)ROPXJ3+L,:<Z?"7Z%D:$6T;S"LMR^0P;QE,VO1F:;"9Y3\9*$J'0YZ7J3
MT3GNZ\PGRYFT2^#.QV#,!ZS88VQ".\T2#]3XYY!3X!%3G*> 4<2:.9)SSD43
M,:PLF:UA-4GR"ZKLU:M#H50P7(.@`'<7A,^!P@3:V0E3K&%Q2<"E<094JE5*
MEU)*DI$7:-67A"0Z>%[ Q.5>R4U1)D3NS1=9>:/,O)(!XOB%-J-X)B5Y_RG%
M\T=M/ID*?=!V`*U>%3_3?&;I!\T+O\RT+=MG'ZAU'JJF8U:*9:1I6_UR\!GR
M44VJ(K^1_HJM5"P`^C"ZE;*XZ4%C1B;-6MQ!RE?D'(-YD%C3+%K2^6*Z*<-G
M.1<&`2";9P<2.B(V!K;2'WP>])?=(>TQIP"POWN_,?:[=O<RFA-';E_*C41?
MVS.50_5;,2ZYL &%I45W/E^.@#TL>RA:,0?D&O#XU@&;)D at A5&??!F,#70G?
M]L>G_F!.<S=A#))S6$X&O0'PD>'O*=EI7SQ*4B=@9C'?`N&$?_QAJ$Q)QU C
MZ#S?H9Y $?KP0ZL6V(([V6Z78SH13%##A=:::6\J%*K)PG\!BZQ:"D>&[8,1
MS'CEH62A4^8=J1C_F&Z,Y$;%[W5B+E=%S'HJKQO ^5S>8^!2D%5+*BZOFEY"
MNA>1#BTW$6F&E!L6;P/2[;M6M1.4;A7RHBQ-(;'08*C?F#.^>. 3E?^[GK7^
MG_7N)P^=]S90Q\W^GY:3M]G_,Y]SK%W'PO.?F!S[?WZ#9_O1UG9D>+WMKW7^
M)(CW<OW<-CP_"=H]_3ZW[^WVN7UOK\_MKW/ZC.S^%[M\;M_;XW/[O@Z?VU_H
M[TD=WX"WY_;]G#VWO];7<SO*U7.;-SS8H?-)LM-HEJNME I</?J$R;7J40(T
MN<'YD^11H]@JI[)=_-PX^L\V?-<?I4DC.\'$)TDHE=I/R#L[(!=F1R'C2;+8
M2HG>[+-X\K/_&5JRJ0>!R6KW$VK-@)K:6-5^=G*8;:=DQ?36(]'G2;($+"=3
MAY02.G51GO5%0.QX\C/Y-"CDR2HWW)7OS8R_P[-V_==$>?\Z;EO_<[L.QG_(
M[Q;R]JZ#][\4[,)NO/Y_BT>O_T$!($\<>^;!XM_]/-!Q?U6X\^FP._86,OSO
M=CBJ+X5+4Q%\8P$C%C!B`>-;"AC4,^43 at O0EK5"(!&-J9O7ENKR6XDX`4%-W
MA"XH" (ZSU"FD^D2Z4;-9GM7U(_0YOQHJU-YWV$W[T,Z),T<'3(%$RSI*X3-
M:]:*'1C0NEMJ-FGM1\MSIJP+'()@I'Z#C%#5<I)84_3RLG\N,A?C209C]?:7
M0R\S&,_'\ZAOSK_E(G_#$WEYPH;KH/7_#O?_@?J?=W*X_N>LW%Y\_]^W>&Z\
M#FA#==Q]_'>M/-__E]^SXO'_%L]=KH.Z;QTWR_]Y>\_*Z?L_\WLVRO\%.[;_
M?9-GW?EO$#7P%A#ZKQ.?!8_/@L=GP;_=67 Y*=D<HZ^URPC^N9RQ(PH3R#S-
M^<1\ZO4&%X->&,I-RCGEY(.;8SS:[;HR`+AQ_MK\YA_I)C"NG<O5W_ZW4=E;
MO&R]!A0S!'9B-K8QU>>71=+KSLDKJ_<1(]VFC';(.F6-Z-H$C?4?>R4+M2.1
ML+>VMG$67R3D]W?%3NEMN?&&O4&NT'VJ/[E4^]32W>G1EFIW104T;WL+]+#C
M@]8<\K<<J%"%1L?VXZ;X<2 >.B at 9"_23`]K3WZ#W[5+)ICZ&6N_'65\7?UT(
M7>3XC5NNMDN-LTK+;;[]U<")D4DBKEH5@<=^9-Z\'NH)1B54%"#3X+-;/ZUU
MJJNP_21U+G;+;.+9^W>-UB]MMUXLN<U.2R2LZWS.L@0,0[,+6JC&M#Q6B'@\
MNWY'YY>("D+5'34:G28'#D@&/I4KQT5HAO at SF!/_>URM52B6LPS:3)2!,$-C
M<J!<X(:_DSO]<DJS!%D.I/JY:>26)GX at F7"W91 (=*2+9_2(40!IS/#+!)BV
M"C\V&P`+0G<R`$R^6!$443DY<W&$:7/]T>J4J'3>%LOE5L*R]FUKOU+:AQ].
M:;_HK.2L-BFC;>&%@UG0JU9RM"LMJ*G:5'ERNUMZ0A27B\F(G&R(>\SEM.#F
MCS\/9I,QADR##GWN0K]@3NDI at Z? HX at 21Z9<J15_361LFI5X'!"ES]"LW&;'
MM!O*%X+%NQ>X.A:DK^M<`E%GME>@%%ME.NC;3G SU+ S&Z7K)A5["/(4;$"Q
M]:;MPS2;AD&NBB=ECBF>^.W15N+QXF(QQ18>B,<B828`.@&)`M.Z,\ J"I>'
M+_K>YQ?C"WB[$O"'OCU)`MD`"0VFJ?TG2?PT[2X^IA >`1I,(<M@BM2$&<S,
MER S7'5_YQ>@XE%W_ at E_?H0E:(Q1^/;W)Q<7!QH4-F;T.+%"<.\[K2*19;O2
MZ51/WK3%;S(W.7X?9NS?K,<^X;1],B_)^RB"/%4O(;("C*F-`>#<=KUDPY @
M@Y(%83G&B8K?84!"HV&6<]:EG31.*BL44#PMMXJ=2B+QTZYEL<<GUW?>7?9G
M>-'%H<"D<PJ1LDI"M4:QW'8KI;<-24%>#R17:"DR#CG-^Y.K\7#2[2=\WI%
M]LAEL0DNRDQO*KQ ]2=X<H;9AVX%+X^)`)<X]MO/`?H2?U!;T\+^R<$_N9=X
M<XXH[/%'NP!?,3J#CC0?6)9+? K7C[P>ZJHDZG:"`NN7ZF6W6,,+#/Y'O9Y@
MZ+XR,F'YH5([-MZJ3DDQ89*N1GB$]1R]I$C3[(OB<:?28H\JK'C DLU%N'Z1
M!*8"DG"*>:8?*2=P#_%K,Z)^\S0M2N@=EB9BK _F/6^(^Q:3Y?P6DBS5&B58
MPJHG;OWM_Y5C3/=5@'@(:]B<=9,:WN>*<C:(0")()]![%(\:L$S4?@'I1&J\
M"$?8%A7(B"9@<C">@H1-L!,K`XT at H!L``A;TDP1YQ6 at H!0D%,H at 1(&ZT'-T%
M3O%]PLX9S0$)S at 34O;XC(+GZ)@IFUPJ6`4O%\="PPK2%D_0-PCIN5?Z/WRHI
ML>!I6A3_K Z><)_C692"I3'-O!3R)(-J31_%]@6Y)P*UC2<)Z6O&F9_UILO>
M\-,SO6:QW,^W+%!L_E0B- TP=DBEV#YM563/&5(=1-CES",G8(S)*GL9J"UY
M(:/VB!'G=B^A\F0JF$LUO@>3W^NG)-*E-+A2>U@@?/G^O?L>:"- 8L'J*,0S
MGUQ?MS("H%8%V+N+$@.H;0F^(00?0^1G]G7RYFVEUDPH+VML)A[J1P6,CUMP
M#P*EFJU&O=E))!X?OA:/&7\R^HOD/Z(YFXRFBX26'Y+A^?]4LY1?WI2/4B8>
M..4(!3[$@Y-/F&M(]45#'"TO+D!"P&@9T1)&`(13V+T#!$1B"#E-`H#+H^"+
M2!CBCO3N]S&1VK%W4X*.[Z(3N at G=E D3,BH1RAS0LUW&.<Q1XUR&"J. 8D3$
M2@$EL4EF]Q &R73%V>429;B5SH7)O]ZIM#MN&V2?#MW'EO<);401&SCZP&2\
MT@!5MH)R$18MJ:)YD<UFA>W(P"5X!4NP;KU:$E%B:5L3N&(MN,"J[:V(TL"[
M>6+P$NOU9A[V%V_,FGG_;Y_/L(&(^TD5UHM'#9;A*"W67#9$4FVLC;K3*7[%
M<RZ7 at SE6("_E8:8""=ZBETV%K19XUD!<?62##U^E,D&G7J!__##J?E(RP)P\
MKK-RE=[L00&,2S$;0UOES3MUZ WPT9;LBJS3'%6\' 4'Y+CHZ%V]C;7);)E3
M"N(?OVZ\FE4=#.H-1'ZC/CLEM]VL5,J*U48DUXIG%<3+GHX!IZY!PIYPL!.*
M?4*&.7F3S at MELQ3]F;Y'+=2@MZBR<*N(E!$<K5SZ.AZIPQC2IM9-VHWC#A?6
M9<\'B\PYTI74N)3HKEJ25!E2E%TVK!<>"J.AV'^,SJ=:V$2%JGB(%J]#&^2P
M0R<MRH>YE3+%4J>*2$L.)M/,ZVE_0%=)Z0N];#P&:N;OM*K ASK!$GB@:VV)
M5J4(8Y94V;L+><!39J8#GJ$B[7(1,9!"3CZXX)]^\6#[#@0J3W2<&Z.U^94$
MVA2"7ZK=$;YS)_A."#XKR2JN2R%%<MZ+/(TE7[O65PQ-QYX,T7*E@BL5LU[K
MNOB2!I4_KK*#8'ZW5CF15, 'TV"5,GDT+6'S3\9G.G#$1FHTEUR@$L0W1\ \
M>2QKQ=-$J@!%>;JM&6A%.:XUWN&ZL[?Y\U5EK:ZP9X7B^/,%QN&83NA8!Q\>
MQ&,6,*VZ>$).E)M\9^:F.-D*&DZJ'1<O-*.Q4^PZN##J/+@N6]<YM416QF2Y
M)#F:&JS:FPA+)6^.:FZYV"G2E6F)W;P0;$I!"08*\<#CD8\9&N1-_! VPHW6
MX!K'QR"'LK9IMA)UBG"UJ8A.M9L*1 38S1,!AQKPKU-3!]VA4=!5>?QXA6^*
M), at 18CE5FT9TMF8YI<A/+"2,)PNY:X/=\*^N$RXJT*X\DP3)%F4_P>S=X7S"
M9>BH_>1RT./7N0>SBV3\8AT-5:@938?=!<6JT[X_V2!'3P0K9NG-BECY_+B.
M)!(<1^4QHR\FM'//(RWKAT-&O@I!3H75'MF3@#(#D#A'/UFN')V^H=@L\HO6
M)S#6?,-M5\IV[J6UR^%;UJL:D'FE:M50Y'(835^\>@4J?8JOMB1Z%_CUTQ$1
M@]1SUM at UP^!LYV4$./P:"8Z['E06:K5&B8#=`=H([4V]I-)YI11PC!&P0#]
M291,'&D^`$K640HRB4Q-Z1UX;Q_-:2I+^W# N,G"(V<"'H1\B6(^<!:>$1A
M%".^+=C_3&^#*NO#B"50.3O8S/()+?%#7+A(0@[<>1E%ND@>]6*S#2I DM#@
M,!JJD at U)81=O_T-44"4:#YMD$3+*ZNRR.Y;-?3C>'XI@*U?AH,(HF1)=B+IJ
MX?$AX"U/"2"6"! JB at I:ZL8>K<P1>F,X! 8`L]1"(Z-?<$!J.OM:X>!/0#6C
M>6JE6>$#AVAV6 at .(SSV;@(*@T))=)=L>W;.,<G[ WA)*1W]'$2JN%-+C(@EW
M5E0>UK59:=53?S4;UT3=(XWC1CB"3 :=">ZZT$I+5W7IO1A_)X9GPRHL"IN+
M`%5 at -0J7@Y"TKR>/[1H`U'$06I-!]BQV5JN0Y at V\1AN^(S>0D4C,"OP=R57$
MBX>8C*5N#SC*`^F48:(M%4MO*[7J285Q;K-5"=DKQJU#X^;U-5I*YPEM]/LB
MNU>HCK?5XTZ";5^P^+/KKZ.<(+KG(%FS-2)D!-RP0/1KL]3"2-*_SQ?>",UZ
M*KASB2]C1BW4MC,_&;G138?B,,*J at 5NE"P_?,?(&[>O1P>$?-JCZ!W7=I^)H
M.=?VR X=MP9VEPY\9C4^+=KOQ#OE2H .1__M19A'J%>))/UQV^\Z)?$G]]0]
MJG>,WQ7]N_T.]TQ^(ZNP_M1,/<#P5$_K/#[54PSYMQR&9H,<GMU-H[M9JI>J
M12D*9]-BM!PN!AEM()^BM# ;9#"N0R1*J=V 4_KKUFNM$BGZF\9/YZA-Z$$R
M$$<X at T#"7RSG:CO3H&!GXS@J#;WN#.]']V84$+>J`@/(1J2I632OB?90$&+"
M[$>@C+J22-(?MU4Y+@*%Z9<C_=(Y.C9^5QX`I\TJX[3IS0:3/B at EX7X%D0NH
MS=D/@]JU+4@;7Y@#W '!U*]$DOZXS39@4?ZL=HX?`HVU9HOQ6*NET4"=:>+-
MGKRYV:+@"A*'VG0+R"QD<M:FD<F5X>XEV9+F/(AS-*3_CJ:<M."@%=[U=$!A
MWCC#.7M?<B(!TI$OC"S:NZ]ZH?0#T=6[E+2IJVHG'C(=#GILRL(`RA/RN;%S
M(FGGGMO6H9VS4BHB-FY733%9[E)>T88A`M^WI5EL98@)YXDD at D,=@M_=^G&5
ME]N4> @>73)74-K!)KS-UH^QL[?QY=&3&[<"I.OI4HXI'R=">H-%S0R/A2%_
M@!;9)Q;)$D-:=R]INX4-WWB-_(0\8 =JOX%WU$,S"WO/WE[TJW)4/K;MKQH\
M+ \K!D(!:0J$W3\9./ Z];/5*5?/U M69=D/,7-Y[9LOEA<7&QZG*+9$M>'.
M&XOK2>NZ(@TWJ;4Y24!-BMT\:\HB.F>Y7O1AYF^"B3GO!K/8Z;2.?*@O;X+*
M>>\&M]KP at 99N`@H9(R!N?).M7'E1[$@B$,DV;]?,\3MMXO0':!$?*UHI]KM3
MF"4;-!/[`9>#GE+0`'+$:)9*Q5:9M(?3N4?MHAVF9 at F4IED_(5L4Z1>G8)2K
M+30:<#RI&6YT(1AX,'Z7W*'R@AY1/H :;JUA4?@!1<ADW/?N5)1\%Q)^D*'U
M94.F<BA;+[X_.L7==6GFR J;6GV^C+".R +EREFU5 D4H2TR,:5+#[CP:G5H
MB(942UFHV:(:E0N5:M]^'YK1<F>Q<7&A^DHF=?12"+<78:V8U4/3GNZYS3E*
MFC;ACB>S$?!IO:G=I8!GRKP0JJ=5>:.K<<3S* YS0U7=(2T*"T_7%EU+L=8Q
MT&=O>.]9L=0- at UNAA'*EE=CPKKG<R@<92UHVI: P]&;[6J8Z:EFT&C?@;Y+L
M-QO>B/*[Z5N'W&:K4JO6C<T!,H/XYY-75C#*[S9:;K'N'M="!1LMCO%)>XC*
M1J0"- at Y&%)F[6&KCL6-0F%JU]_RKU#[I\*]VZ5?XD4^+2N=MBS\=5=]B)+*5
MED 3.M5Z]40:NT02/D!QURZXI=HO(#C at AD4U%1Y>0*_J=#*B0](], at 0\M#H=
M&3"2*\A$JP7NE;AU#*OY)[Z<;7;5RDB"L27!V+!HE3>]<VG@S=]J\NE%;3B1
ME1+3B5X">Y%<#*W6RE!JY0U'N.XUKNKU(Y]0&(XBE#?-6D%*N"A<XJM;%$GV
MQNUU9]ZJ*=H?-@*EFKG+UE042GG_0WZW\]:-]-W&#=CCTHWT':S>7D];[?(*
M;7%_5XC+!Y)<P7P$<=7;[FFS7I24I@0D<51JMW!#01T/6-V%:>541=#-BRZ-
MC1WN42 //"]_LB5W%&P*OKF*?* *"_W35JK(!ZMX:?VT9QE[7I)G:@,!&P&:
M($[TND/M`T4MFJH\K.3BXC7S+B#GQQ7V42_66VZS4TPD"B^-REHR.ZLMLI)N
ME*-5O=EIMA()^@. FB!AG9F0L +_: 8=6RG3GH7?7-L2O<EP.1I+RH]LHVV5
M&C613)J-1EE8_5;:[I_Z"WDY)A+RPQNK5(.UV;94#IA(;C%?KF*P*6C$3W=H
MPT_8A(=JPX.LM5*--1Q!_(46_2N/AUWV%-Q,K2;ATR$GO P1D,:>E22,GK#
M1H:A3&.\S^WP+P<+8%[#>%=LT;RP'&*TRC ^\W 7F&]%)'+:_.H"[./:P!EN
M,*^:!+6I8[Y9\2RP_&!3@('3IEX^Y,& :;:99@?3'#/-":;ES+3<HW"-;N6D
MWCAY7SIKZ3%46P[OSTHMC8+ N,F"O'V)PT9;;:5V?ON&_*!5%6AUE"I6@4]:
M0U[K\!DL=\*&/Q<7SZ*+YK'H2UDT?_>BQZ>U6KE9>T\;F.1AI([489]O:"[0
M-3H.TT;E2M<[;VO-([Q'.!^55CDA]_4PKF'%*YV5.K4]C6E0;=M#F!]':]NA
MRNP2FJ/3&*O1:8RV<%JU>51H5VJ$DW!:NU[B),>Z,S%0J5*G'8$02FIUVI$8
M<5CP?-?4<Y^9Q+IZ'#Q6"KW2M$!'7_6(WEBL^:Y5?G<2T4)*;=%(K[8PYQZ]
M:W5*>L1:>-J"]F;8+'K472P\&5LY7.Z$YQ3UBZ6(];E;Y5_=H_:O>GZP)T$#
MEGK?2S)4HOG>QT-+^;DE\8Z,.=_$]<Q^EHHH6,[IN5 >3$6;0^?K-3RB@!,Q
M">"S'8%,^&Q%(C*/UM"VHQ&)IUM[:\:+\]H1),\I5 at 3!4TJK&D'NE"(97)C<
M*:W<;D5TD),ZK8A.4M)9L58M1W:U(.=>;F6>%]>2J"KC1'1:I=D1W59I5D3'
M"W@`UYCGH8F9=TO-6KE5.5NY#IV2"WQ.E?K(R7++'CODG\B_?S3KV^*_%)P'
MC_]BY:R\C/]3V-NS]SC^2SZ.__(MGCC^2QS_)8[_\N\5_Z7@!.._?%7TEX*S
MR>@OT;%?H*&WQ'XI.''LES#BXM at OWRKV2QPL)0Z6$N1(<;"4,( X6,HMP5*^
M;7R4?[5X57^?>"\@$-TWW at N V$B\%P/._>*]^(#B>"]QO)<XWDL0.0\?[R4.
M]Q*'>_D;AGMYD&@O[6;U6T1[(79C\;SH?$3+)>AG'A^@'. QALF,K6>\:40G
M%CZ2I8KVUI^_$"MB"33<IMD]DEQN[@$GF?&*M)#+U%BPJ3V-=T=?>>KZ8(+'
MEGUJ$EFRQFQ>(%T4 at +-1%J at G*Z(>!!&'MS 801S>XO[/HSB\11S>(@YO$8>W
MN(5%Q.$MXO 6<7B+.+Q%'-XB#F\1A[>(PUNLKSP.;Q&'MUC?A3B\11S>(@YO
M$8>W",".8DMQ>(LXO,6:9L3A+8*F\CB\11S>(CQ''H9#!WL2A[>(PUO$X2WB
M\!9Q>(LXO$4<WB(.;W&G)PYOL5GQ[#N$MP@>TS:3\G'DBSCR11SY8C4UCGSQ
M\)$OFE6WU';MNP:_X.Q69/R+TY/3=J7\=PB P7/EI;6U%0? ^-XQ%/XW/Y'Q
M/Z:]46_0S7[,3M$;X-YUD *9SZ^)_V'9A;V<C/]AY1W;IO@?^3C^QS=Y0%(4
M)@UD)K/!Y0HA)!S+*F1L)V/O"MO>S_VT[[S,*ON%)3)6P;*V=G9VQ(WDA%!V
M,]9>QMH5ULO]PBX`"D !67'KYY]%)K>7!D5G!_\XXN>?M\260.^A'Y0#K)S]
MTO[:KC4Z;C$EGCZ],<=1"N!DU#$L=/V'I8Q..7ISVFWC7'@F*6-ZVTI0D!DT
ML':[6C(];XW46K5326WM1!2M-%_N[J;0$8Q^865SKJU(FH"N^!$4UTYI$7V\
M)?T(T[WAU[9=W(065))@%&ZJ'= 657FQW$YIE,.+D+ZV!A80Y]$MQ\(13:;(
M#[K!"+1X4A84KHBA&TTOWMKR(B1'57X<:#J^*;R@`MD5(SZ'A,!7"]-AQNNH
MQF.*8Z?^'LO6FOA/H]%T-NEM: 6XE?\[DO_CCH?C`/_?M>U"S/^_Q7,S__<)
MX7XK0! .KP$Y83O[N=R^[42N`7OI/;&#_T'^+Y[C/XYW1%&D4'[O#L;HES-;
M]A;+F<=&%73@GXVDQXP\K8*5+\?2CX;@8%-@[D(ZGK<;>\,YQB-"'XY2LZYU
M`W+L8'L->NE\[@Z&Z"RUE2%__MEDB:>RL +IZZH]/T;:^5Z&.1J,\/='WLV4
M88RV=C8"!M:3$&K(UU3CA\X;5NE,L$;(:(*.*VG:0*:S;>AR35"H^]UI]WPP
M'"R T4'%59'$$VU0!)WAT=$[Q6>8N_V^$9,`$(1GCKW?"0[R1ZS2ZP,$H+!R
M=TR#:CLO;1Q7^9>7]A?/GS\7PE^C`,#7/"]P>0^&TO%A!M;EU63S+(VY:$=_
M+SA2(NFO1NV!E.\]I>,G?N(G?N(G?N(G?N(G?N(G?N(G?N(G?N(G?N(G?N(G
2?N(G?N+GW_CY_\WG8K `" (`
`
end
^ permalink raw reply
* Re: Removing BROKEN scsi drivers
From: Christoph Hellwig @ 2006-07-07 12:44 UTC (permalink / raw)
To: Richard Hirst
Cc: Christoph Hellwig, Ingo Juergensmann, Kars de Jong,
Matthew Wilcox, Andi Kleen, linux-scsi, linux-m68k,
Geert Uytterhoeven
In-Reply-To: <20051115113225.GS5252@levanta.com>
On Tue, Nov 15, 2005 at 11:32:25AM +0000, Richard Hirst wrote:
> Between us it seems Kars and I have this driver working on Amiga, MVME,
> and BVME boards. That is everything that used the old 53c7xx driver. I
> don't believe there is a combined set of patches yet (at least, I havn't
> seen the patches for Amiga). One complication is that we're relying on
> some m68k-specific dma support patches from Roman Zippel that are not
> yet integrated.
After only half a year of waiting the m68k dma api bits finally made it in..
Could you please submit your patches again now that everything should be
in place?
^ permalink raw reply
* Re: Xilinx BSP for linux 2.6
From: Ameet Patil @ 2006-07-07 12:42 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F7612E5FEF57E56118641EB2740@phx.gbl>
Hi Ming,
Excellent News!
Don't worry... the problem you are facing could be because of missing
device files in your /dev folder.
Do as follows:
mount the CF card onto your PC and then goto the /dev folder on your
root filesystem in the card. Here run the following commands as root:
# mknod -m 660 console c 5 1
# mknod -m 660 xsa b 254 0
# mknod -m 660 xsa1 b 254 1
# mknod -m 660 xsa2 b 254 2
# mknod -m 660 xsa3 b 254 3
Now there should be a directory tts in your dev. If not create one
"mkdir tts". Then do this in the dev/tts folder,
# mknod -m 660 0 b 4 64
> Also, when I compile the kernel, there is a error. That's in adapter.c
> file, undefined reference to "XAssert". I checked the source code and
I think you have the old patch. If you download the new one, the
compilation problem should not occur. But you resolved it yourself,...
which is good.
Let me know if this works. I shall add this stuff in PART II of the article.
-Ameet
Ming Liu wrote:
> Dear Ameet,
> A good news is that now my 2.6 kernel is running in my ML403 board!
> According your guidance, first I made the kernel as simple as possible
> and it works well. Then I included the patch for SystemACE and here is
> the information shown on the hyper teminal:
>
>
> Linux/PPC load: console=ttyS0,9600 root=/dev/xsa3 [ 0.000148]
> Console: colour dummy device 80x25
> [ 0.000919] Dentry cache hash table entries: 16384 (order: 4, 65536
> bytes)
> [ 0.002277] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.012802] Memory: 63104k available (1340k kernel code, 384k data,
> 76k init,
> 0k highmem)
> [ 0.230310] Mount-cache hash table entries: 512
> [ 0.238305] VFS: Disk quotas dquot_6.5.1
> [ 0.238516] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [ 0.238817] JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> [ 0.239435] JFS: nTxBlock = 493, nTxLock = 3944
> [ 0.241883] Initializing Cryptographic API
> [ 0.241940] io scheduler noop registered (default)
> [ 0.322864] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
> sharing
> disabled
> [ 0.324759] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 1) is a 16550A
> [ 1.653644] RAMDISK driver initialized: 16 RAM disks of 65536K size
> 1024 bloc
> ksize
> [ 1.745079] loop: loaded (max 8 devices)
> [ 1.793392] xsa: xsa1 xsa2 xsa3
> [ 1.839262] mice: PS/2 mouse device common for all mice
> [ 1.935059] VFS: Mounted root (ext2 filesystem) readonly.
> [ 2.000037] Freeing unused kernel memory: 76k init
> [ 2.075656] Warning: unable to open an initial console.
>
> I use xsa3 as the partition to store the file system. Now the file
> system is the old one for my 2.4 kernel generated by busybox. Then I
> think that's why the problem "unable to open an initial console" is
> generated. Do you have some suggestion on how to solve it? Thanks for
> your opinion.
> Also, when I compile the kernel, there is a error. That's in adapter.c
> file, undefined reference to "XAssert". I checked the source code and
> found that the function of XAssert is defined in the file
> xbasic_types.c, not the xbasic_types.h. So it cannot be included into
> adapter.c. And also in the makefile there is no dependency on
> xbasic_types.c. So I added the defination for this function in
> adapter.c, copying it from xbasic_types.c. It then worked well.
> Waiting for your guidance. You know, an expert's opinion is always
> useful for a novice, like me. :)
>
> Regards
> Ming
>
> _________________________________________________________________
> 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
>
^ permalink raw reply
* RE: [patch 1/5] ACPI: Atlas ACPI driver
From: Yu, Luming @ 2006-07-07 12:43 UTC (permalink / raw)
To: akpm, jayakumar.acpi; +Cc: linux-acpi, dtor_core, Brown, Len
+ if (function == ACPI_WRITE) {
+ status = acpi_bus_generate_event(dev, 0x80, address);
+ atlas_input_report((u8) address);
+ } else {
Please don't use two mechanism to report one event.
For other part of code, I ACK.
Thanks
Luming
-----Original Message-----
From: akpm@osdl.org [mailto:akpm@osdl.org]
Sent: 2006年7月7日 14:53
To: Brown, Len
Cc: linux-acpi@vger.kernel.org; akpm@osdl.org;
jayakumar.acpi@gmail.com; dtor_core@ameritech.net; Yu, Luming
Subject: [patch 1/5] ACPI: Atlas ACPI driver
From: jayakumar.acpi@gmail.com
An ACPI driver for Atlas boards, including input support.
Signed-off-by: Jaya Kumar <jayakumar.acpi@gmail.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: "Yu, Luming" <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/acpi/Kconfig | 13 ++
drivers/acpi/Makefile | 1
drivers/acpi/atlas_acpi.c | 191 ++++++++++++++++++++++++++++++++++++
3 files changed, 204 insertions(+), 1 deletion(-)
diff -puN /dev/null drivers/acpi/atlas_acpi.c
--- /dev/null
+++ a/drivers/acpi/atlas_acpi.c
@@ -0,0 +1,191 @@
+/*
+ * atlas_acpi.c - Atlas Wallmount Touchscreen ACPI Extras
+ *
+ * Copyright (C) 2006 Jaya Kumar
+ * Based on Toshiba ACPI by John Belmonte and ASUS ACPI
+ * This work was sponsored by CIS(M) Sdn Bhd.
+ *
+ * This program is free software; you can redistribute it
and/or modify
+ * it under the terms of the GNU General Public License as
published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <asm/uaccess.h>
+#include <acpi/acpi_drivers.h>
+
+#define ACPI_ATLAS_NAME "Atlas ACPI"
+#define ACPI_ATLAS_CLASS "Atlas"
+#define ACPI_ATLAS_BUTTON_HID "ASIM0000"
+
+#ifdef CONFIG_INPUT
+static struct input_dev *input_dev;
+
+static void atlas_input_report(u8 address)
+{
+ int keycode;
+
+ keycode = KEY_F1 + (address & 0x0F);
+
+ if (address & 0x10)
+ input_report_key(input_dev, keycode, 0);
+ else
+ input_report_key(input_dev, keycode, 1);
+ input_sync(input_dev);
+}
+
+static int atlas_setup_input(void)
+{
+ int err;
+
+ input_dev = input_allocate_device();
+ if (!input_dev) {
+ printk(KERN_ERR "atlas: insufficient mem to
allocate input "
+ "device\n");
+ return -ENOMEM;
+ }
+
+ input_dev->name = "Atlas ACPI button driver";
+ input_dev->phys = "acpi/input0";
+ input_dev->id.bustype = BUS_HOST;
+ input_dev->evbit[LONG(EV_KEY)] = BIT(EV_KEY);
+ set_bit(KEY_F1, input_dev->keybit);
+ set_bit(KEY_F2, input_dev->keybit);
+ set_bit(KEY_F3, input_dev->keybit);
+ set_bit(KEY_F4, input_dev->keybit);
+ set_bit(KEY_F5, input_dev->keybit);
+ set_bit(KEY_F6, input_dev->keybit);
+ set_bit(KEY_F7, input_dev->keybit);
+ set_bit(KEY_F8, input_dev->keybit);
+ set_bit(KEY_F9, input_dev->keybit);
+
+ err = input_register_device(input_dev);
+ if (err) {
+ printk(KERN_ERR "atlas: couldn't register input
device\n");
+ input_free_device(input_dev);
+ return err;
+ }
+
+ return 0;
+}
+
+static void atlas_free_input(void)
+{
+ if (input_dev)
+ input_unregister_device(input_dev);
+
+}
+#else
+#define atlas_free_input(...)
+#define atlas_setup_input(...) 0
+#define atlas_input_report(...)
+#endif
+
+/* button handling code */
+static acpi_status acpi_atlas_button_setup(acpi_handle region_handle,
+ u32 function, void *handler_context, void
**return_context)
+{
+ *return_context =
+ (function != ACPI_REGION_DEACTIVATE) ?
handler_context : NULL;
+
+ return AE_OK;
+}
+
+static acpi_status acpi_atlas_button_handler(u32 function,
+ acpi_physical_address address,
+ u32 bit_width, acpi_integer *value,
+ void *handler_context, void *region_context)
+{
+ acpi_status status;
+ struct acpi_device *dev = handler_context;
+
+ if (function == ACPI_WRITE) {
+ status = acpi_bus_generate_event(dev, 0x80, address);
+ atlas_input_report((u8) address);
+ } else {
+ printk(KERN_WARNING "atlas: shrugged on
unexpected function"
+ ":function=%x,address=%lx,value=%x\n",
+ function, (unsigned long)address, (u32)*value);
+ status = -EINVAL;
+ }
+
+ return status;
+}
+
+static int atlas_acpi_button_add(struct acpi_device *device)
+{
+ int err;
+
+ err = atlas_setup_input();
+ if (err)
+ return err;
+
+ /* hookup button handler */
+ return acpi_install_address_space_handler(device->handle,
+ 0x81, &acpi_atlas_button_handler,
+ &acpi_atlas_button_setup, device);
+}
+
+static int atlas_acpi_button_remove(struct acpi_device
*device, int type)
+{
+ acpi_status status;
+
+ status = acpi_remove_address_space_handler(device->handle,
+ 0x81, &acpi_atlas_button_handler);
+ if (ACPI_FAILURE(status))
+ printk(KERN_ERR "Atlas: Error removing addr spc
handler\n");
+ atlas_free_input();
+ return status;
+}
+
+static struct acpi_driver atlas_acpi_driver = {
+ .name = ACPI_ATLAS_NAME,
+ .class = ACPI_ATLAS_CLASS,
+ .ids = ACPI_ATLAS_BUTTON_HID,
+ .ops = {
+ .add = atlas_acpi_button_add,
+ .remove = atlas_acpi_button_remove,
+ },
+};
+
+static int atlas_acpi_init(void)
+{
+ int result;
+
+ result = acpi_bus_register_driver(&atlas_acpi_driver);
+ if (result < 0) {
+ printk(KERN_ERR "Atlas ACPI: Unable to register
driver\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void atlas_acpi_exit(void)
+{
+ acpi_bus_unregister_driver(&atlas_acpi_driver);
+}
+
+module_init(atlas_acpi_init);
+module_exit(atlas_acpi_exit);
+
+MODULE_AUTHOR("Jaya Kumar");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Atlas ACPI");
+
diff -puN drivers/acpi/Kconfig~acpi-atlas-acpi-driver
drivers/acpi/Kconfig
--- a/drivers/acpi/Kconfig~acpi-atlas-acpi-driver
+++ a/drivers/acpi/Kconfig
@@ -198,7 +198,18 @@ config ACPI_ASUS
driver is still under development, so if your laptop
is unsupported or
something works not quite as expected, please use
the mailing list
available on the above page
(acpi4asus-user@lists.sourceforge.net)
-
+
+config ACPI_ATLAS
+ tristate "Atlas Wallmount Touchscreen Extras"
+ depends on X86
+ default n
+ ---help---
+ This driver is intended for Atlas wallmounted touchscreens.
+ The button events will show up in /proc/acpi/events and also
+ as scancodes F1 through F9, and in X if you use evdev.
+
+ If you have an Atlas wallmounted touchscreen, say Y
or M here.
+
config ACPI_IBM
tristate "IBM ThinkPad Laptop Extras"
depends on X86
diff -puN drivers/acpi/Makefile~acpi-atlas-acpi-driver
drivers/acpi/Makefile
--- a/drivers/acpi/Makefile~acpi-atlas-acpi-driver
+++ a/drivers/acpi/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ACPI_SYSTEM) += system.o ev
obj-$(CONFIG_ACPI_DEBUG) += debug.o
obj-$(CONFIG_ACPI_NUMA) += numa.o
obj-$(CONFIG_ACPI_ASUS) += asus_acpi.o
+obj-$(CONFIG_ACPI_ATLAS) += atlas_acpi.o
obj-$(CONFIG_ACPI_IBM) += ibm_acpi.o
obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o
obj-y += scan.o motherboard.o
_
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.