All of lore.kernel.org
 help / color / mirror / Atom feed
* SCSI Bidirectional data transfer
From: Maze Maze @ 2006-04-06  7:34 UTC (permalink / raw)
  To: linux-kernel

Hi,

I am using redhate linux (kernel 2.4.20)

SCSI supports bidirectional data transfer. However, the two variants
request_bufflen and bufflen of a scsi_cmd are set to be the same in
the scsi_init_cmd_from_req(). I am wondering if i want to send and
receive data with different lengths, how do i pass the lengths to SCSI
layer? The scsi_wait_req() accepts only one length.... Can I make use
of extended CDB? Thanks!

Maze

^ permalink raw reply

* Re: [PATCH/RFC] libata-dev: make the returned err_mask more accurate
From: Albert Lee @ 2006-04-06  7:34 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Jeff Garzik, IDE Linux, Doug Maxey
In-Reply-To: <20060406071442.GF31998@htj.dyndns.org>

Tejun Heo wrote:
 > 
> I don't think putting these two functions into libata.h as inlines is
> a good idea.  As currently there are no users, it would be better to
> put them where they are used as static functions and export it later
> as necessary.
> 

You are right. Will revise it.




^ permalink raw reply

* The future of patch-o-matic-ng
From: Harald Welte @ 2006-04-06  7:35 UTC (permalink / raw)
  To: Grzegorz Janoszka; +Cc: Netfilter Development Mailinglist, Patrick McHardy
In-Reply-To: <Pine.GSO.4.63.0604052144350.1472@galaxy.agh.edu.pl>

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Wed, Apr 05, 2006 at 09:52:48PM +0200, Grzegorz Janoszka wrote:
> On Wed, 5 Apr 2006, Harald Welte wrote:
> 
> >So unless somebody actually wants to become patch-o-matic maintainer
> >(yes, we once had somebody for that job), I think it's going to die.
> 
> I can try. 

Well, as it seems I should have read netfilter-devel in chronological
order rather than backwards.  Patrick has already posted on how to
proceed with patch-o-matic-ng a couple of days ago:  Have the original
authors (or other people who want to maintain patchlets) host their own
repositories.  Patch-o-matic-ng would then mostly only contain a list of
URL's to such remote repositories.  This way there is no need for the
netfilter developers themselves to maintain patchsets.

> Pom is used by many people, please don't let it die. If you have
> nobody to take care of it, give it to me.

As indicated in Patricks mail, there's a 30 day grace period.  Until
then the original authors (if they care) or other people can take
maintenance for individual patchlets and send us URL's to those
repositories.  We will add them to our list file, and distribute a
'runme' script which downloads those repositories off the net.

If you want to help, I suggest to wait for those patchlets that nobody
takes care of, and run a repository for them.

Also, I assume that there is a lot that can be done to improve that
patchlet-handling script, i.e. add suport for GPG signature checking and
the like.  I suggest you coordinate with Patrick on this.

If any of the 'patchlet maintainers' require a place where they can put
repositories online via http/ftp, please let me know, we have
people.netfilter.org accounts exactly for this purpose.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply

* Re: Bug in vga16fb?
From: Ondrej Zajicek @ 2006-04-06  7:37 UTC (permalink / raw)
  To: linux-fbdev-devel
In-Reply-To: <44344950.9090703@vc.cvut.cz>

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

On Thu, Apr 06, 2006 at 12:48:48AM +0200, Petr Vandrovec wrote:
> Ondrej Zajicek wrote:
> >Hello
> >
> >I tried vga16fb driver in 320x200x4 nonstd mode (on i386 - little endian). 
> >In
> >this mode framebuffer reports PACKED PIXELS type. Drawing through 
> >framebuffer
> >is OK, but console is broken - it looks like that even and odd columns are
> >exchanged.
> >
> >Framebuffer structure of this mode is that even pixel is in high nibble and
> >odd pixel is in low nibble.
> >
> >It looks like vga16fb use cfbimgblt.c/slow_imageblit in this mode for
> >image-blit and this function in CFB4 writes even pixel in low nibble and
> >odd pixel in high nibble.
> >
> >What is correct framebuffer structure for CFB4 mode?
> 
> Unfortunately there is no standard, as CFB4 itself is quite non-standard 
> VGA mode.  Some videocards first output low nibble, followed by high, and 
> some do otherwise.  I've experimented with this back in 2000, and I've 
> found that Matrox Millennium does exactly opposite than some ATI Mach64 
> card I had in another box at that time.
> 
> So your only option is providing two CFB4 modes.  Unfortunately I have no 
> idea how to autodetect what your hardware actually does without adding 
> camera to the system...

Even if we find some possibility to autodetect what hardware does (or in
case of another, non-VGA hardware using CFB4 mode) there would be
problem that driver cannot say it to userspace (or generic kernel
functions like cfb_imageblit). Maybe there should be some flag in
type_aux specifying whether given packed pixel mode is LSB-first or
MSB-first (relevant only for bpp % 8 != 0) ?

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-06  7:37 UTC (permalink / raw)
  To: Darren Hart
  Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
	Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604052025.05679.darren@dvhart.com>


* Darren Hart <darren@dvhart.com> wrote:

> My last mail specifically addresses preempt-rt, but I'd like to know 
> people's thoughts regarding this issue in the mainline kernel.  Please 
> see my previous post "realtime-preempt scheduling - rt_overload 
> behavior" for a testcase that produces unpredictable scheduling 
> results.

the rt_overload feature i intend to push upstream-wards too, i just 
didnt separate it out of -rt yet.

"RT overload scheduling" is a totally orthogonal mechanism to the SMP 
load-balancer (and this includes smpnice too) that is more or less 
equivalent to having a 'global runqueue' for real-time tasks, without 
the SMP overhead associated with that. If there is no "RT overload" [the 
common case even on Linux systems that _do_ make use of RT tasks 
occasionally], the new mechanism is totally inactive and there's no 
overhead. But once there are more RT tasks than CPUs, the scheduler will 
do "global" decisions for what RT tasks to run on which CPU. To put even 
less overhead on the mainstream kernel, i plan to introduce a new 
SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt 
make much sense to extend SCHED_RR in that direction.]

my gut feeling is that it would be wrong to integrate this feature into 
smpnice: SCHED_FIFO is about determinism, and smpnice is a fundamentally 
statistical approach. Also, smpnice doesnt have to try as hard to pick 
the right task as rt_overload does, so there would be constant 
'friction' between "overhead" optimizations (dont be over-eager) and 
"latency" optimizations (dont be _under_-eager). So i'm quite sure we 
want this feature separate. [nevertheless i'd happy to be proven wrong 
via some good and working smpnice based solution]

in any case, i'll check your -rt testcase to see why it fails.

	Ingo

^ permalink raw reply

* [PATCH/RFC] libata-dev: make the returned err_mask more accurate (revised)
From: Albert Lee @ 2006-04-06  7:43 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Tejun Heo, IDE Linux, Doug Maxey
In-Reply-To: <20060406071442.GF31998@htj.dyndns.org>

make the returned err_mask more accurate
Changes:
- add ac_err_drq() and ac_err_idle() to map err_mask from drv_status for data xfer and idle states.
- fix ata_hsm_move() to use the functions for err_mask mapping.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
(revised to not inline per Tejun's comments.)

The current err_mask returned by HSM doesn't look right.
e.g. When we found DRQ=0 when data transfer is expected, AC_ERR_HSM is returned.
However, DRQ=0 maybe caused by device error. So, during data transfer,
if we see DRQ=0 and ERR=1, returning AC_ERR_DEV should be more accurate.

e.g. In HSM_ST_LAST state, AC_ERR_OTHER is returned for BSY=0 DRQ=1 currently.
AC_ERR_HSM shoule be more accurate.

Patch against irq-pio (79fa1b677be3a985cc66b9218a4dd09818f1051b).
For your review, thanks.


--- irq-pio0/drivers/scsi/libata-core.c	2006-04-06 10:08:44.000000000 +0800
+++ irq-pio1/drivers/scsi/libata-core.c	2006-04-06 15:29:47.000000000 +0800
@@ -3838,6 +3838,62 @@ err_out:
 }
 
 /**
+ *	ac_err_drq - check status when PIO data transfer expected.
+ *	@status: device status
+ *
+ *	RETURNS:
+ *	0 if status looks good, err_mask otherwise.
+ */
+
+static unsigned int ac_err_drq(u8 status)
+{
+	/* BSY = 1*/
+	if (status & ATA_BUSY)
+		return AC_ERR_HSM;
+
+	/* BSY = 0, DRQ = 1 */
+	if (status & ATA_DRQ)
+		return 0;
+
+	/* BSY = 0, DRQ = 0, device err */
+	if (status & (ATA_ERR | ATA_DF))
+		return AC_ERR_DEV;
+
+	/* BSY = 0, DRQ = 0, no device err.
+	 * but we are expecting data transfer...
+	 */
+	return AC_ERR_HSM;
+}
+
+/**
+ *	ac_err_idle - check status when the transaction is finished.
+ *	@status: device status
+ *
+ *	RETURNS:
+ *	0 if status looks good, err_mask otherwise.
+ */
+
+static unsigned int ac_err_idle(u8 status)
+{
+	/* BSY = 1 or DRQ = 1 */
+	if (status & (ATA_BUSY | ATA_DRQ))
+		return AC_ERR_HSM;
+
+	/* BSY = 0, DRQ = 0, device err */
+	if (status & (ATA_ERR | ATA_DF))
+		return AC_ERR_DEV;
+
+	/* BSY = 0, DRQ = 0, no device err. DRDY = 1 */
+	if (status & ATA_DRDY)
+		return 0;
+
+	/* thing looks good.
+	 * don't know why DRDY not set.
+	 */
+	return AC_ERR_OTHER;
+}
+
+/**
  *	ata_hsm_ok_in_wq - Check if the qc can be handled in the workqueue.
  *	@ap: the target ata_port
  *	@qc: qc on going
@@ -3906,7 +3962,7 @@ fsm_start:
 		/* check device status */
 		if (unlikely((status & (ATA_BUSY | ATA_DRQ)) != ATA_DRQ)) {
 			/* Wrong status. Let EH handle this */
-			qc->err_mask |= AC_ERR_HSM;
+			qc->err_mask |= ac_err_drq(status);
 			ap->hsm_task_state = HSM_ST_ERR;
 			goto fsm_start;
 		}
@@ -3920,7 +3976,7 @@ fsm_start:
 		if (unlikely(status & (ATA_ERR | ATA_DF))) {
 			printk(KERN_WARNING "ata%d: DRQ=1 with device error, dev_stat 0x%X\n",
 			       ap->id, status);
-			qc->err_mask |= AC_ERR_DEV;
+			qc->err_mask |= AC_ERR_HSM;
 			ap->hsm_task_state = HSM_ST_ERR;
 			goto fsm_start;
 		}
@@ -3976,7 +4032,7 @@ fsm_start:
 			if (unlikely(status & (ATA_ERR | ATA_DF))) {
 				printk(KERN_WARNING "ata%d: DRQ=1 with device error, dev_stat 0x%X\n",
 				       ap->id, status);
-				qc->err_mask |= AC_ERR_DEV;
+				qc->err_mask |= AC_ERR_HSM;
 				ap->hsm_task_state = HSM_ST_ERR;
 				goto fsm_start;
 			}
@@ -3991,7 +4047,7 @@ fsm_start:
 			/* ATA PIO protocol */
 			if (unlikely((status & ATA_DRQ) == 0)) {
 				/* handle BSY=0, DRQ=0 as error */
-				qc->err_mask |= AC_ERR_HSM;
+				qc->err_mask |= ac_err_drq(status);
 				ap->hsm_task_state = HSM_ST_ERR;
 				goto fsm_start;
 			}
@@ -4007,13 +4063,16 @@ fsm_start:
 			 * transferred to the device.
 			 */
 			if (unlikely(status & (ATA_ERR | ATA_DF))) {
-				/* data might be corrputed */
-				qc->err_mask |= AC_ERR_DEV;
 
-				if (!(qc->tf.flags & ATA_TFLAG_WRITE)) {
+				if (qc->tf.flags & ATA_TFLAG_WRITE)
+					qc->err_mask |= AC_ERR_HSM;
+				else {
+					/* data might be corrputed */
+					qc->err_mask |= AC_ERR_DEV;
 					ata_pio_sectors(qc);
 					ata_altstatus(ap);
 					status = ata_wait_idle(ap);
+					qc->err_mask |= ac_err_idle(status);
 				}
 
 				/* ata_pio_sectors() might change the
@@ -4041,7 +4100,7 @@ fsm_start:
 
 	case HSM_ST_LAST:
 		if (unlikely(!ata_ok(status))) {
-			qc->err_mask |= __ac_err_mask(status);
+			qc->err_mask |= ac_err_idle(status);
 			ap->hsm_task_state = HSM_ST_ERR;
 			goto fsm_start;
 		}



^ permalink raw reply

* Re: [MIPS] MT: Improved multithreading support.
From: Yoichi Yuasa @ 2006-04-06  7:55 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <4955666b0604060047x42cdc3e3kefb1d95737cc08e7@mail.gmail.com>

Hi Ralf,

> Subject: [MIPS] MT: Improved multithreading support.
> To: git-commits@linux-mips.org
> 
> 
> Author: Ralf Baechle <ralf@linux-mips.org> Wed Apr 5 09:45:47 2006 +0100
> Commit: 79cc8007b93838a670b164b8a55ab3e735a12a8b
> Gitweb: http://www.linux-mips.org/g/linux/79cc8007
> Branch: master
> 
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

I think it's maybe typo.

Yoichi

Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>

diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/Kconfig mips/arch/mips/Kconfig
--- mips-orig/arch/mips/Kconfig	2006-04-06 11:26:26.460425500 +0900
+++ mips/arch/mips/Kconfig	2006-04-06 16:44:56.935829750 +0900
@@ -1617,7 +1617,7 @@ source "mm/Kconfig"
 
 config SMP
 	bool "Multi-Processing support"
-	depends on CPU_RM9000 || ((SIBYTE_BCM1x80 || SIBYTE_BCM1x55 || SIBYTE_SB1250 || QEMU) && !SIBYTE_STANDALONE) || SGI_IP27 || MIPS_MT_SMP || MIPS_MT_SMP
+	depends on CPU_RM9000 || ((SIBYTE_BCM1x80 || SIBYTE_BCM1x55 || SIBYTE_SB1250 || QEMU) && !SIBYTE_STANDALONE) || SGI_IP27 || MIPS_MT_SMP || MIPS_MT_SMTC
 	---help---
 	  This enables support for systems with more than one CPU. If you have
 	  a system with only one CPU, like most personal computers, say N. If

^ permalink raw reply

* [ALSA - lib 0001971]: Some elements incorrectly have capture flags
From: bugtrack @ 2006-04-06  7:44 UTC (permalink / raw)
  To: alsa-devel


A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1971> 
======================================================================
Reported By:                pzad
Assigned To:                
======================================================================
Project:                    ALSA - lib
Issue ID:                   1971
Category:                   simple mixer
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             03-28-2006 12:16 CEST
Last Modified:              04-06-2006 09:44 CEST
======================================================================
Summary:                    Some elements incorrectly have capture flags
Description: 
Some elemnts have capture flags even they have nothing to do with capture.
This will duplicate control in alsamixer - view ALL.

On VIA8233A + ALC650:

Simple mixer control '3D Control - Center',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 1 [7%]
Simple mixer control '3D Control - Depth',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 0 [0%]

On Audigy 1:
Simple mixer control 'Bass',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 40
  Front Left: 23 [58%]
  Front Right: 23 [58%]
Simple mixer control 'Treble',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 40
  Front Left: 27 [68%]
  Front Right: 27 [68%]


======================================================================

----------------------------------------------------------------------
 Raymond - 04-05-06 18:50 
----------------------------------------------------------------------
I can group the lower 4 bands to implement the bass control and the upper 6
bands to implement the treble control. 

The new "Bass" and "Treble" will appear in kmix.

how can I add the surround of STAC9708 into kmix ?

cat /proc/asound/au8830/oss_mixer
VOLUME "Master" 0
BASS "Tone Control - Bass" 0
TREBLE "Tone Control - Treble" 0
SYNTH "" 0
PCM "PCM" 0
SPEAKER "PC Speaker" 0
LINE "Line" 0
MIC "Mic" 0
CD "CD" 0
IMIX "" 0
ALTPCM "" 0
RECLEV "" 0
IGAIN "Capture" 0
OGAIN "" 0
LINE1 "Aux" 0
LINE2 "" 0
LINE3 "" 0
DIGITAL1 "" 0
DIGITAL2 "" 0
DIGITAL3 "" 0
PHONEIN "Phone" 0
PHONEOUT "Master Mono" 0
VIDEO "Video" 0
RADIO "" 0
MONITOR "" 0


/*
	Bass control - the lower 4 bands
*/
static int
snd_vortex_bass_treble_info(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_info *uinfo)
{
	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
	uinfo->count = 2;
	uinfo->value.integer.min = 0x0000;
	uinfo->value.integer.max = 0x7fff;
	return 0;
}

static int
snd_vortex_bass_get(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	ucontrol->value.integer.value[0] = vortex->bass[0];
	ucontrol->value.integer.value[1] = vortex->bass[1];
	return 0;
}

static int
snd_vortex_bass_put(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	int changed = 0, i;
	if ( vortex->bass[0] != ucontrol->value.integer.value[0]) {
		vortex->bass[0] = ucontrol->value.integer.value[0];
		changed = 1;
	};
	if ( vortex->bass[1] != ucontrol->value.integer.value[1]) {
		vortex->bass[1] = ucontrol->value.integer.value[1];
		changed = 1;
	};
	for (i=0; i<4; i++)  {
		vortex_Eqlzr_SetLeftGain(vortex, i, vortex->bass[0]);
		vortex_Eqlzr_SetRightGain(vortex, i, vortex->bass[1]);
	}
	return changed;
}

static struct snd_kcontrol_new vortex_bass_kcontrol __devinitdata = {
	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
	.name = "Tone Control - Bass",
	.access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
	.info = snd_vortex_bass_treble_info,
	.get = snd_vortex_bass_get,
	.put = snd_vortex_bass_put
};

/*
	Treble control - the upper 6 bands
*/
static int
snd_vortex_treble_get(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	ucontrol->value.integer.value[0] = vortex->treble[0];
	ucontrol->value.integer.value[1] = vortex->treble[1];
	return 0;
}

static int
snd_vortex_treble_put(struct snd_kcontrol *kcontrol, struct
snd_ctl_elem_value *ucontrol)
{
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	int changed = 0, i;
	if ( vortex->treble[0] != ucontrol->value.integer.value[0]) {
		vortex->treble[0] = ucontrol->value.integer.value[0];
		changed = 1;
	}
	if ( vortex->treble[1] != ucontrol->value.integer.value[1]) {
		vortex->treble[1] = ucontrol->value.integer.value[1];
		changed = 1;
	}
	for (i=4; i<10; i++)  {
		vortex_Eqlzr_SetLeftGain(vortex, i, vortex->treble[0]);
		vortex_Eqlzr_SetRightGain(vortex, i, vortex->treble[1]);
	};
	return changed;
}

static struct snd_kcontrol_new vortex_treble_kcontrol __devinitdata = {
	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
	.name = "Tone Control - Treble",
	.access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
	.info = snd_vortex_bass_treble_info,
	.get = snd_vortex_treble_get,
	.put = snd_vortex_treble_put
};









	for (i=0; i<2; i++) {
		vortex->bass[i] = 0x3e96;
		vortex->treble[i] = 0x3e96;
	};

	if ((kcontrol =  snd_ctl_new1(&vortex_bass_kcontrol, vortex)) == NULL)
		return -ENOMEM;
	if ((err = snd_ctl_add(vortex->card, kcontrol)) < 0)
		return err;
	if ((kcontrol =  snd_ctl_new1(&vortex_treble_kcontrol, vortex)) == NULL)
		return -ENOMEM;
	if ((err = snd_ctl_add(vortex->card, kcontrol)) < 0)
		return err;



----------------------------------------------------------------------
 Raymond - 04-06-06 09:44 
----------------------------------------------------------------------
It's easy to implement a switch which route either one of the following 

1) Front Playback Channels
2) Capture Channels
3) Rear Playback Channels (Only for au8810/au8830 with 4 channels codec)

to the 10-bands stereo equalizer.


static void
vortex_connect_codecplay(vortex_t * vortex, int en, unsigned char
mixers[])
{
#ifdef CHIP_AU8820
	vortex_connection_mix_adb(vortex, en, 0x11, mixers[0], ADB_CODECOUT(0));
	vortex_connection_mix_adb(vortex, en, 0x11, mixers[1], ADB_CODECOUT(1));
#else
	switch(vortex->eq_route){
	case 0:
		// Connect front channels through EQ.
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[0], ADB_EQIN(0));
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[1], ADB_EQIN(1));
		/* Lower volume, since EQ has some gain. */
		vortex_mix_setvolumebyte(vortex, mixers[0], 0);
		vortex_mix_setvolumebyte(vortex, mixers[1], 0);
		vortex_route(vortex, en, 0x11, ADB_EQOUT(0), ADB_CODECOUT(0));
		vortex_route(vortex, en, 0x11, ADB_EQOUT(1), ADB_CODECOUT(1));
		/* Check if reg 0x28 has SDAC bit set. */
		if (VORTEX_IS_QUAD(vortex)) {
			/* Rear channel. Note: ADB_CODECOUT(0+2) and (1+2) is for AC97 modem
*/
			vortex_connection_mix_adb(vortex, en, 0x11, mixers[2],
ADB_CODECOUT(4));
			vortex_connection_mix_adb(vortex, en, 0x11, mixers[3],
ADB_CODECOUT(5));
		}
		break;
	case 1:
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[0],
ADB_CODECOUT(0));
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[1],
ADB_CODECOUT(1));
		if (VORTEX_IS_QUAD(vortex)) {
			vortex_connection_mix_adb(vortex, en, 0x11, mixers[2],
ADB_CODECOUT(4));
			vortex_connection_mix_adb(vortex, en, 0x11, mixers[3],
ADB_CODECOUT(5));
		}
		break;
	case 2:
		// Connect front channels
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[0],
ADB_CODECOUT(0));
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[1],
ADB_CODECOUT(1));
		// Connect rear channels through EQ.
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[2], ADB_EQIN(0));
		vortex_connection_mix_adb(vortex, en, 0x11, mixers[3], ADB_EQIN(1));
		/* Lower volume, since EQ has some gain. */
		vortex_mix_setvolumebyte(vortex, mixers[2], 0);
		vortex_mix_setvolumebyte(vortex, mixers[3], 0);
		vortex_route(vortex, en, 0x11, ADB_EQOUT(0), ADB_CODECOUT(4));
		vortex_route(vortex, en, 0x11, ADB_EQOUT(1), ADB_CODECOUT(5));
		break;
	};
#endif
}

static void
vortex_connect_codecrec(vortex_t * vortex, int en, unsigned char mixin0,
			unsigned char mixin1)
{
	/*
	   Enable: 0x1, 0x1
	   Channel: 0x11, 0x11
	   ADB Source address: 0x48, 0x49
	   Destination Asp4Topology_0x9c,0x98
	 */
	if ( vortex->eq_route == 1 ) {
		// Connect rear channels through EQ.
		vortex_connection_mix_adb(vortex, en, 0x11, ADB_CODECIN(0),
ADB_EQIN(0));
		vortex_connection_mix_adb(vortex, en, 0x11, ADB_CODECIN(1),
ADB_EQIN(1));
		/* Lower volume, since EQ has some gain. */
		vortex_mix_setvolumebyte(vortex, mixin0, 0);
		vortex_mix_setvolumebyte(vortex, mixin1, 0);
		vortex_route(vortex, en, 0x11, ADB_EQOUT(0), mixin0);
		vortex_route(vortex, en, 0x11, ADB_EQOUT(1), mixin1));
	}
	else {
		vortex_connection_adb_mixin(vortex, en, 0x11, ADB_CODECIN(0), mixin0);
		vortex_connection_adb_mixin(vortex, en, 0x11, ADB_CODECIN(1), mixin1);
	};
}


It's OK to implement eq_route as a module switch since we can change the
name of the kcontrol when the driver is loaded.

Is it possible to implmenet eq_route as a kcontrol which allow the user to
change the eq_route dynamically after the driver is loaded ?

Will the alsamixer able to detect this change ?

Please note the that above code is not complete, we still need to adjust
the gain of the hardware mixers when a substream is open.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
03-28-06 12:16 pzad           New Issue                                    
03-30-06 11:01 Raymond        Note Added: 0009028                          
03-30-06 12:50 pzad           Note Added: 0009031                          
03-30-06 13:13 pzad           Note Added: 0009032                          
03-30-06 13:22 Raymond        Note Added: 0009033                          
03-30-06 13:29 Raymond        Note Edited: 0009033                         
03-30-06 13:41 Raymond        Note Edited: 0009033                         
03-31-06 04:36 Raymond        Note Added: 0009041                          
03-31-06 04:50 Raymond        Note Edited: 0009041                         
04-01-06 01:13 Raymond        Note Edited: 0009033                         
04-03-06 19:08 Raymond        Note Added: 0009103                          
04-05-06 18:42 Raymond        Note Added: 0009121                          
04-05-06 18:46 Raymond        Note Edited: 0009121                         
04-05-06 18:50 Raymond        Note Edited: 0009121                         
04-06-06 09:11 Raymond        Note Deleted: 0009103                        
04-06-06 09:44 Raymond        Note Added: 0009124                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: can anybody check that the attached patch eliminates reiser4 compilation warnings on 64bit platforms?
From: Brian Uhrain @ 2006-04-06  7:51 UTC (permalink / raw)
  To: Alexander Zarochentsev; +Cc: reiserfs-list
In-Reply-To: <200604061120.37578.zam@namesys.com>

Hello,

Alexander Zarochentsev wrote:
> would you please help to check the attached patch (for 2.6.17-rc1-mm1) 
> because our Alpha does not want to boot now.

I'm not sure what the last kernel version you had booting was (or what 
the error is now the your Alpha system does not want to boot), but I 
recently discovered a problem with kernels booting on my Alpha that was 
introduced in one of the 2.6.16-rc's.  Yesterday I was able to track 
down and squash the bug, and submitted my patch (two versions, one for 
2.6.16.1 and the other for 2.6.17-rc1) to the LKML.  After fixing the 
issue with CPU initialization, which looks like it would affect any 
Alpha system as it was a case of things changing/being added in all of 
the other architectures but not for the Alpha architecture, the system 
has been running fine with a 2.6.16.1 kernel and reiser4 root 
filesystem. :)  You can find my email with the patch at 
http://lkml.org/lkml/mbox/2006/4/5/69

  - Brian


BTW, your patch to silence the printf-style format string argument 
warnings looks fine to me. :)

^ permalink raw reply

* va_copy() support for powerpc
From: HappyPhot @ 2006-04-06  7:59 UTC (permalink / raw)
  To: linuxppc-embedded

Hello,
  I am trying use "ELDK 4" to build "xorp" for ppc 8xx, but it shows
"configure: error: cannot run test program while cross compiling"
when it checks whether the build environment has va_copy() support.

  How to make the va_copy() be supported by powerpc or ELDK ?
Does anybody know this ?

thank you,
Phot 

^ permalink raw reply

* Re: Bonnie++ Burps on XFS
From: David Greaves @ 2006-04-06  7:59 UTC (permalink / raw)
  To: Nathan Scott; +Cc: Kurt Wall, LKML, linux-xfs
In-Reply-To: <20060406151301.I1110920@wobbly.melbourne.sgi.com>

Nathan Scott wrote:

>On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott wrote:
>  
>
>>On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote:
>>    
>>
>>>I've been using bonnie++ off and on for a long time. Suddenly, it has
>>>started failing when run against an XFS filesystem situated on a SATA
>>>drive. Here's the output of a run:
>>>      
>>>
>>[ Please report these things to linux-xfs@oss.sgi.com... ]
>>
>>    
>>
>>>Delete files in sequential order...Bonnie: drastic I/O error (rmdir):
>>>      
>>>
>>Anything in your system log?
>>    
>>
>
>Lemme answer that for you - "no".  I've reproduced the problem,
>I'll get back to you once I've nutted out whats gone wrong.
>
>Thanks for reporting it.
>
>cheers.
>
>  
>
Me too.

2.6.16

I had filesystem corruption and needed ran xfs_repair.

After I finished I removed most of the lost and found bits but was left
with:

haze:/scratch/lost+found# ll
total 28
drwxr-xr-x   4 root root   38 2006-04-02 08:29 ./
drwxrwxrwx  26 root root 4096 2006-04-04 18:25 ../
drwxrwxr-x   2 1046 1046 8192 2006-04-02 08:30 658616481/
drwxrwxr-x   2 1046 1046 8192 2006-04-02 08:22 823441168/
haze:/scratch/lost+found# rmdir *
rmdir: `658616481': Directory not empty
rmdir: `823441168': Directory not empty
haze:/scratch/lost+found# ll *
658616481:
total 12
drwxrwxr-x  2 1046 1046 8192 2006-04-02 08:30 ./
drwxr-xr-x  4 root root   38 2006-04-02 08:29 ../

823441168:
total 12
drwxrwxr-x  2 1046 1046 8192 2006-04-02 08:22 ./
drwxr-xr-x  4 root root   38 2006-04-02 08:29 ../

Obviously I had an fs corruption (due to raid failure due to some bogus
libata errors) so this may not be the same thing.

David

-- 


^ permalink raw reply

* Re: [patch 1/3] mm: An enhancement of OVERCOMMIT_GUESS
From: KAMEZAWA Hiroyuki @ 2006-04-06  8:08 UTC (permalink / raw)
  To: Hideo AOKI; +Cc: akpm, linux-kernel, linux-mm
In-Reply-To: <4434C12A.4000108@redhat.com>

On Thu, 06 Apr 2006 03:20:10 -0400
Hideo AOKI <haoki@redhat.com> wrote:

> Hi Kamezawa-san,
> 
> Thank you for your comments.
> 
> KAMEZAWA Hiroyuki wrote:
> > Hi, AOKI-san
> I like your idea. But, in the function, I think we need to care
> lowmem_reserve too.
> 
Ah, I see.

> Since __vm_enough_memory() doesn't know zone and cpuset information,
> we have to guess proper value of lowmem_reserve in each zone
> like I did in calculate_totalreserve_pages() in my patch.
> Do you think that we can do this calculation every time?
> 
> If it is good enough, I'll make revised patch.
> 
I just thought to show "how to calculate" in unified way is better.
But if things goes ugly, please ignore my comment.

Do you have a detailed comparison of test result with and without this patch ?
I'm interested in.
I'm sorry if I missed your post of result.


Cheers!
-Kame

^ permalink raw reply

* Re: [patch 1/3] mm: An enhancement of OVERCOMMIT_GUESS
From: KAMEZAWA Hiroyuki @ 2006-04-06  8:08 UTC (permalink / raw)
  To: Hideo AOKI; +Cc: akpm, linux-kernel, linux-mm
In-Reply-To: <4434C12A.4000108@redhat.com>

On Thu, 06 Apr 2006 03:20:10 -0400
Hideo AOKI <haoki@redhat.com> wrote:

> Hi Kamezawa-san,
> 
> Thank you for your comments.
> 
> KAMEZAWA Hiroyuki wrote:
> > Hi, AOKI-san
> I like your idea. But, in the function, I think we need to care
> lowmem_reserve too.
> 
Ah, I see.

> Since __vm_enough_memory() doesn't know zone and cpuset information,
> we have to guess proper value of lowmem_reserve in each zone
> like I did in calculate_totalreserve_pages() in my patch.
> Do you think that we can do this calculation every time?
> 
> If it is good enough, I'll make revised patch.
> 
I just thought to show "how to calculate" in unified way is better.
But if things goes ugly, please ignore my comment.

Do you have a detailed comparison of test result with and without this patch ?
I'm interested in.
I'm sorry if I missed your post of result.


Cheers!
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: Re: [Bluez-devel] SCO transparent transmission
From: Israel Guío @ 2006-04-06  8:10 UTC (permalink / raw)
  To: bluez-devel

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Hi Sowmya.

I don't use /dev/dsp to get audio samples. I use ALSA project library and it
works (I suggest you should look for code samples about it, specially those
regarding to headsets).

CVSD is the default on-the-air coding for SCO packets but you can change it
by means of "hciconfig".

For SCO transmission, just open a socket as in scotest.c (bluez-utils/test)
and use write and read on it.

There is no documentation about BlueZ and, if you want to use it, you must
read and undestand the code.

Bye!



>Hey Israel,
>How did u use CVSD when transmitting over sco?? U mean u used some sort of
>function to convert the voice you input from /dev/dsp into CVSD codec??
>Can u also throw some light on CVSD and SCO... I mean how are u
transmittin=
>g
>the packets over SCO??

>Soumya

[-- Attachment #2: Type: text/html, Size: 1072 bytes --]

^ permalink raw reply

* [PATCH] trivial: spelling (2.6.17-rc1)
From: Andreas Mohr @ 2006-04-06  8:19 UTC (permalink / raw)
  To: trivial; +Cc: linux-kernel

Hello all,

patch against 2.6.17-rc1:

acquired (aquired)
contiguous (contigious)
successful (succesful, succesfull)
surprise (suprise)
whether (weather)
some other misspellings

k/M/Gb -> k/M/GB (bits vs. Bytes)

Signed-off-by: Andreas Mohr <andi@lisas.de>


diff -urN linux-2.6.17-rc1.orig/arch/i386/kernel/cpu/cyrix.c linux-2.6.17-rc1/arch/i386/kernel/cpu/cyrix.c
--- linux-2.6.17-rc1.orig/arch/i386/kernel/cpu/cyrix.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/i386/kernel/cpu/cyrix.c	2006-04-06 09:47:43.000000000 +0200
@@ -353,7 +353,7 @@
 	 * This function only handles the GX processor, and kicks every
 	 * thing else to the Cyrix init function above - that should
 	 * cover any processors that might have been branded differently
-	 * after NSC aquired Cyrix.
+	 * after NSC acquired Cyrix.
 	 *
 	 * If this breaks your GX1 horribly, please e-mail
 	 * info-linux@ldcmail.amd.com to tell us.
diff -urN linux-2.6.17-rc1.orig/arch/i386/kernel/i8259.c linux-2.6.17-rc1/arch/i386/kernel/i8259.c
--- linux-2.6.17-rc1.orig/arch/i386/kernel/i8259.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/i386/kernel/i8259.c	2006-04-06 09:47:43.000000000 +0200
@@ -175,7 +175,7 @@
 	 * Lightweight spurious IRQ detection. We do not want
 	 * to overdo spurious IRQ handling - it's usually a sign
 	 * of hardware problems, so we only do the checks we can
-	 * do without slowing down good hardware unnecesserily.
+	 * do without slowing down good hardware unnecessarily.
 	 *
 	 * Note that IRQ7 and IRQ15 (the two spurious IRQs
 	 * usually resulting from the 8259A-1|2 PICs) occur
diff -urN linux-2.6.17-rc1.orig/arch/mips/momentum/ocelot_g/gt-irq.c linux-2.6.17-rc1/arch/mips/momentum/ocelot_g/gt-irq.c
--- linux-2.6.17-rc1.orig/arch/mips/momentum/ocelot_g/gt-irq.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/mips/momentum/ocelot_g/gt-irq.c	2006-04-06 09:47:43.000000000 +0200
@@ -59,7 +59,7 @@
  * bit_num   - Indicates which bit number in the cause register
  *
  * Outputs :
- * 1 if succesful, 0 if failure
+ * 1 if successful, 0 if failure
  */
 int enable_galileo_irq(int int_cause, int bit_num)
 {
@@ -83,7 +83,7 @@
  * bit_num   - Indicates which bit number in the cause register
  *
  * Outputs :
- * 1 if succesful, 0 if failure
+ * 1 if successful, 0 if failure
  */
 int disable_galileo_irq(int int_cause, int bit_num)
 {
diff -urN linux-2.6.17-rc1.orig/arch/powerpc/platforms/cell/spufs/switch.c linux-2.6.17-rc1/arch/powerpc/platforms/cell/spufs/switch.c
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/cell/spufs/switch.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/powerpc/platforms/cell/spufs/switch.c	2006-04-06 09:47:43.000000000 +0200
@@ -2081,7 +2081,7 @@
  * @spu: pointer to SPU iomem structure.
  *
  * Perform harvest + restore, as we may not be coming
- * from a previous succesful save operation, and the
+ * from a previous successful save operation, and the
  * hardware state is unknown.
  */
 int spu_restore(struct spu_state *new, struct spu *spu)
diff -urN linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_cache.c linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_cache.c
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_cache.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_cache.c	2006-04-06 09:47:43.000000000 +0200
@@ -287,7 +287,7 @@
  * find the pci device that corresponds to a given address.
  * This routine scans all pci busses to build the cache.
  * Must be run late in boot process, after the pci controllers
- * have been scaned for devices (after all device resources are known).
+ * have been scanned for devices (after all device resources are known).
  */
 void __init pci_addr_cache_build(void)
 {
diff -urN linux-2.6.17-rc1.orig/arch/s390/kernel/vtime.c linux-2.6.17-rc1/arch/s390/kernel/vtime.c
--- linux-2.6.17-rc1.orig/arch/s390/kernel/vtime.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/s390/kernel/vtime.c	2006-04-06 09:47:43.000000000 +0200
@@ -356,7 +356,7 @@
 
 	set_vtimer(event->expires);
 	spin_unlock_irqrestore(&vt_list->lock, flags);
-	/* release CPU aquired in prepare_vtimer or mod_virt_timer() */
+	/* release CPU acquired in prepare_vtimer or mod_virt_timer() */
 	put_cpu();
 }
 
diff -urN linux-2.6.17-rc1.orig/arch/um/drivers/ubd_kern.c linux-2.6.17-rc1/arch/um/drivers/ubd_kern.c
--- linux-2.6.17-rc1.orig/arch/um/drivers/ubd_kern.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/um/drivers/ubd_kern.c	2006-04-06 09:47:43.000000000 +0200
@@ -1222,7 +1222,7 @@
 		}
 	}
 
-	/* Succesful return case! */
+	/* Successful return case! */
 	if(backing_file_out == NULL)
 		return(fd);
 
diff -urN linux-2.6.17-rc1.orig/arch/x86_64/kernel/i8259.c linux-2.6.17-rc1/arch/x86_64/kernel/i8259.c
--- linux-2.6.17-rc1.orig/arch/x86_64/kernel/i8259.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/arch/x86_64/kernel/i8259.c	2006-04-06 09:47:43.000000000 +0200
@@ -278,7 +278,7 @@
 	 * Lightweight spurious IRQ detection. We do not want
 	 * to overdo spurious IRQ handling - it's usually a sign
 	 * of hardware problems, so we only do the checks we can
-	 * do without slowing down good hardware unnecesserily.
+	 * do without slowing down good hardware unnecessarily.
 	 *
 	 * Note that IRQ7 and IRQ15 (the two spurious IRQs
 	 * usually resulting from the 8259A-1|2 PICs) occur
diff -urN linux-2.6.17-rc1.orig/block/as-iosched.c linux-2.6.17-rc1/block/as-iosched.c
--- linux-2.6.17-rc1.orig/block/as-iosched.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/block/as-iosched.c	2006-04-06 09:47:43.000000000 +0200
@@ -902,7 +902,7 @@
 }
 
 /*
- * as_can_anticipate indicates weather we should either run arq
+ * as_can_anticipate indicates whether we should either run arq
  * or keep anticipating a better request.
  */
 static int as_can_anticipate(struct as_data *ad, struct as_rq *arq)
diff -urN linux-2.6.17-rc1.orig/block/ll_rw_blk.c linux-2.6.17-rc1/block/ll_rw_blk.c
--- linux-2.6.17-rc1.orig/block/ll_rw_blk.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/block/ll_rw_blk.c	2006-04-06 09:47:43.000000000 +0200
@@ -2729,7 +2729,7 @@
 		return 0;
 
 	/*
-	 * not contigious
+	 * not contiguous
 	 */
 	if (req->sector + req->nr_sectors != next->sector)
 		return 0;
@@ -3397,7 +3397,7 @@
  *
  * Description:
  *     Ends all I/O on a request. It does not handle partial completions,
- *     unless the driver actually implements this in its completionc callback
+ *     unless the driver actually implements this in its completion callback
  *     through requeueing. Theh actual completion happens out-of-order,
  *     through a softirq handler. The user must have registered a completion
  *     callback through blk_queue_softirq_done().
diff -urN linux-2.6.17-rc1.orig/drivers/atm/firestream.c linux-2.6.17-rc1/drivers/atm/firestream.c
--- linux-2.6.17-rc1.orig/drivers/atm/firestream.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/atm/firestream.c	2006-04-06 09:47:43.000000000 +0200
@@ -951,7 +951,7 @@
 		   it most likely that the chip will notice it. It also prevents us
 		   from having to wait for completion. On the other hand, we may
 		   need to wait for completion anyway, to see if it completed
-		   succesfully. */
+		   successfully. */
 
 		switch (atm_vcc->qos.aal) {
 		case ATM_AAL2:
diff -urN linux-2.6.17-rc1.orig/drivers/char/agp/amd-k7-agp.c linux-2.6.17-rc1/drivers/char/agp/amd-k7-agp.c
--- linux-2.6.17-rc1.orig/drivers/char/agp/amd-k7-agp.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/agp/amd-k7-agp.c	2006-04-06 09:47:43.000000000 +0200
@@ -118,7 +118,7 @@
 	return retval;
 }
 
-/* Since we don't need contigious memory we just try
+/* Since we don't need contiguous memory we just try
  * to get the gatt table once
  */
 
diff -urN linux-2.6.17-rc1.orig/drivers/char/agp/ati-agp.c linux-2.6.17-rc1/drivers/char/agp/ati-agp.c
--- linux-2.6.17-rc1.orig/drivers/char/agp/ati-agp.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/agp/ati-agp.c	2006-04-06 09:47:43.000000000 +0200
@@ -261,7 +261,7 @@
 #endif
 
 /*
- *Since we don't need contigious memory we just try
+ *Since we don't need contiguous memory we just try
  * to get the gatt table once
  */
 
diff -urN linux-2.6.17-rc1.orig/drivers/char/agp/efficeon-agp.c linux-2.6.17-rc1/drivers/char/agp/efficeon-agp.c
--- linux-2.6.17-rc1.orig/drivers/char/agp/efficeon-agp.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/agp/efficeon-agp.c	2006-04-06 09:47:43.000000000 +0200
@@ -171,7 +171,7 @@
 
 
 /*
- * Since we don't need contigious memory we just try
+ * Since we don't need contiguous memory we just try
  * to get the gatt table once
  */
 
diff -urN linux-2.6.17-rc1.orig/drivers/char/rio/riointr.c linux-2.6.17-rc1/drivers/char/rio/riointr.c
--- linux-2.6.17-rc1.orig/drivers/char/rio/riointr.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/rio/riointr.c	2006-04-06 09:47:43.000000000 +0200
@@ -546,7 +546,7 @@
 	 ** run out of space it will be set to the offset of the
 	 ** next byte to copy from the packet data area. The packet
 	 ** length field is decremented by the number of bytes that
-	 ** we succesfully removed from the packet. When this reaches
+	 ** we successfully removed from the packet. When this reaches
 	 ** zero, we reset the offset pointer to be zero, and free
 	 ** the packet from the front of the queue.
 	 */
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/asb100.c linux-2.6.17-rc1/drivers/hwmon/asb100.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/asb100.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/asb100.c	2006-04-06 09:47:43.000000000 +0200
@@ -341,7 +341,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 				size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/lm78.c linux-2.6.17-rc1/drivers/hwmon/lm78.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/lm78.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/lm78.c	2006-04-06 09:47:43.000000000 +0200
@@ -358,7 +358,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 	size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/lm80.c linux-2.6.17-rc1/drivers/hwmon/lm80.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/lm80.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/lm80.c	2006-04-06 09:47:43.000000000 +0200
@@ -253,7 +253,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 	size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/lm87.c linux-2.6.17-rc1/drivers/hwmon/lm87.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/lm87.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/lm87.c	2006-04-06 09:47:43.000000000 +0200
@@ -421,7 +421,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan clock divider.  This follows the principle
-   of least suprise; the user doesn't expect the fan minimum to change just
+   of least surprise; the user doesn't expect the fan minimum to change just
    because the divider changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 		size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/sis5595.c linux-2.6.17-rc1/drivers/hwmon/sis5595.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/sis5595.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/sis5595.c	2006-04-06 09:47:43.000000000 +0200
@@ -380,7 +380,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 	size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/smsc47m1.c linux-2.6.17-rc1/drivers/hwmon/smsc47m1.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/smsc47m1.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/smsc47m1.c	2006-04-06 09:47:43.000000000 +0200
@@ -207,7 +207,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan clock divider.  This follows the principle
-   of least suprise; the user doesn't expect the fan minimum to change just
+   of least surprise; the user doesn't expect the fan minimum to change just
    because the divider changed. */
 static ssize_t set_fan_div(struct device *dev, const char *buf,
 		size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/w83627hf.c linux-2.6.17-rc1/drivers/hwmon/w83627hf.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/w83627hf.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/w83627hf.c	2006-04-06 09:47:43.000000000 +0200
@@ -781,7 +781,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t
 store_fan_div_reg(struct device *dev, const char *buf, size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/w83781d.c linux-2.6.17-rc1/drivers/hwmon/w83781d.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/w83781d.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/w83781d.c	2006-04-06 09:47:43.000000000 +0200
@@ -630,7 +630,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t
 store_fan_div_reg(struct device *dev, const char *buf, size_t count, int nr)
diff -urN linux-2.6.17-rc1.orig/drivers/hwmon/w83792d.c linux-2.6.17-rc1/drivers/hwmon/w83792d.c
--- linux-2.6.17-rc1.orig/drivers/hwmon/w83792d.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/hwmon/w83792d.c	2006-04-06 09:47:43.000000000 +0200
@@ -462,7 +462,7 @@
 
 /* Note: we save and restore the fan minimum here, because its value is
    determined in part by the fan divisor.  This follows the principle of
-   least suprise; the user doesn't expect the fan minimum to change just
+   least surprise; the user doesn't expect the fan minimum to change just
    because the divisor changed. */
 static ssize_t
 store_fan_div(struct device *dev, struct device_attribute *attr,
diff -urN linux-2.6.17-rc1.orig/drivers/ide/ide-disk.c linux-2.6.17-rc1/drivers/ide/ide-disk.c
--- linux-2.6.17-rc1.orig/drivers/ide/ide-disk.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ide/ide-disk.c	2006-04-06 09:47:43.000000000 +0200
@@ -37,7 +37,7 @@
  * Version 1.15		convert all calls to ide_raw_taskfile
  *				since args will return register content.
  * Version 1.16		added suspend-resume-checkpower
- * Version 1.17		do flush on standy, do flush on ATA < ATA6
+ * Version 1.17		do flush on standby, do flush on ATA < ATA6
  *			fix wcache setup.
  */
 
diff -urN linux-2.6.17-rc1.orig/drivers/ide/ide-io.c linux-2.6.17-rc1/drivers/ide/ide-io.c
--- linux-2.6.17-rc1.orig/drivers/ide/ide-io.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ide/ide-io.c	2006-04-06 09:47:43.000000000 +0200
@@ -1595,7 +1595,7 @@
  *	Initialize a request before we fill it in and send it down to
  *	ide_do_drive_cmd. Commands must be set up by this function. Right
  *	now it doesn't do a lot, but if that changes abusers will have a
- *	nasty suprise.
+ *	nasty surprise.
  */
 
 void ide_init_drive_cmd (struct request *rq)
diff -urN linux-2.6.17-rc1.orig/drivers/ieee1394/hosts.c linux-2.6.17-rc1/drivers/ieee1394/hosts.c
--- linux-2.6.17-rc1.orig/drivers/ieee1394/hosts.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ieee1394/hosts.c	2006-04-06 09:47:43.000000000 +0200
@@ -102,7 +102,7 @@
  * driver specific parts, enable the controller and make it available
  * to the general subsystem using hpsb_add_host().
  *
- * Return Value: a pointer to the &hpsb_host if succesful, %NULL if
+ * Return Value: a pointer to the &hpsb_host if successful, %NULL if
  * no memory was available.
  */
 static DECLARE_MUTEX(host_num_alloc);
diff -urN linux-2.6.17-rc1.orig/drivers/ieee1394/ieee1394_core.h linux-2.6.17-rc1/drivers/ieee1394/ieee1394_core.h
--- linux-2.6.17-rc1.orig/drivers/ieee1394/ieee1394_core.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/ieee1394/ieee1394_core.h	2006-04-06 09:47:43.000000000 +0200
@@ -139,7 +139,7 @@
 
 /*
  * Hand over received selfid packet to the core.  Complement check (second
- * quadlet is complement of first) is expected to be done and succesful.
+ * quadlet is complement of first) is expected to be done and successful.
  */
 void hpsb_selfid_received(struct hpsb_host *host, quadlet_t sid);
 
diff -urN linux-2.6.17-rc1.orig/drivers/isdn/divert/isdn_divert.c linux-2.6.17-rc1/drivers/isdn/divert/isdn_divert.c
--- linux-2.6.17-rc1.orig/drivers/isdn/divert/isdn_divert.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/isdn/divert/isdn_divert.c	2006-04-06 09:47:43.000000000 +0200
@@ -592,7 +592,7 @@
 } /* put_address */
 
 /*************************************/
-/* report a succesfull interrogation */
+/* report a successful interrogation */
 /*************************************/
 static int interrogate_success(isdn_ctrl *ic, struct call_struc *cs)
 { char *src = ic->parm.dss1_io.data;
diff -urN linux-2.6.17-rc1.orig/drivers/media/video/bt8xx/bttv-cards.c linux-2.6.17-rc1/drivers/media/video/bt8xx/bttv-cards.c
--- linux-2.6.17-rc1.orig/drivers/media/video/bt8xx/bttv-cards.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/media/video/bt8xx/bttv-cards.c	2006-04-06 09:48:34.000000000 +0200
@@ -4846,7 +4846,7 @@
  *
  * The IVC120G security card has 4 i2c controlled TDA8540 matrix
  * swichers to provide 16 channels to MUX0. The TDA8540's have
- * 4 indepedant outputs and as such the IVC120G also has the
+ * 4 independent outputs and as such the IVC120G also has the
  * optional "Monitor Out" bus. This allows the card to be looking
  * at one input while the monitor is looking at another.
  *
diff -urN linux-2.6.17-rc1.orig/drivers/mtd/nand/nand_base.c linux-2.6.17-rc1/drivers/mtd/nand/nand_base.c
--- linux-2.6.17-rc1.orig/drivers/mtd/nand/nand_base.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/mtd/nand/nand_base.c	2006-04-06 09:48:34.000000000 +0200
@@ -1023,7 +1023,7 @@
 					if (oobdata[idx] != oob_buf[oobofs + idx] ) {
 						DEBUG (MTD_DEBUG_LEVEL0,
 					       	"%s: Failed ECC write "
-						"verify, page 0x%08x, " "%6i bytes were succesful\n", __FUNCTION__, page, i);
+						"verify, page 0x%08x, " "%6i bytes were successful\n", __FUNCTION__, page, i);
 						goto out;
 					}
 				}
diff -urN linux-2.6.17-rc1.orig/drivers/net/3c501.c linux-2.6.17-rc1/drivers/net/3c501.c
--- linux-2.6.17-rc1.orig/drivers/net/3c501.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/net/3c501.c	2006-04-06 09:48:34.000000000 +0200
@@ -508,11 +508,11 @@
  * speak of. We simply pull the packet out of its PIO buffer (which is slow)
  * and queue it for the kernel. Then we reset the card for the next packet.
  *
- * We sometimes get suprise interrupts late both because the SMP IRQ delivery
+ * We sometimes get surprise interrupts late both because the SMP IRQ delivery
  * is message passing and because the card sometimes seems to deliver late. I
  * think if it is part way through a receive and the mode is changed it carries
  * on receiving and sends us an interrupt. We have to band aid all these cases
- * to get a sensible 150kbytes/second performance. Even then you want a small
+ * to get a sensible 150kBytes/second performance. Even then you want a small
  * TCP window.
  */
 
diff -urN linux-2.6.17-rc1.orig/drivers/net/irda/irport.c linux-2.6.17-rc1/drivers/net/irda/irport.c
--- linux-2.6.17-rc1.orig/drivers/net/irda/irport.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/net/irda/irport.c	2006-04-06 09:48:34.000000000 +0200
@@ -386,7 +386,7 @@
 	/* Locking notes : this function may be called from irq context with
 	 * spinlock, via irport_write_wakeup(), or from non-interrupt without
 	 * spinlock (from the task timer). Yuck !
-	 * This is ugly, and unsafe is the spinlock is not already aquired.
+	 * This is ugly, and unsafe is the spinlock is not already acquired.
 	 * This will be fixed when irda-task get rewritten.
 	 * Jean II */
 	if (!spin_is_locked(&self->lock)) {
diff -urN linux-2.6.17-rc1.orig/drivers/net/pcmcia/smc91c92_cs.c linux-2.6.17-rc1/drivers/net/pcmcia/smc91c92_cs.c
--- linux-2.6.17-rc1.orig/drivers/net/pcmcia/smc91c92_cs.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/net/pcmcia/smc91c92_cs.c	2006-04-06 09:48:34.000000000 +0200
@@ -1883,7 +1883,7 @@
     /* Set the Window 1 control, configuration and station addr registers.
        No point in writing the I/O base register ;-> */
     SMC_SELECT_BANK(1);
-    /* Automatically release succesfully transmitted packets,
+    /* Automatically release successfully transmitted packets,
        Accept link errors, counter and Tx error interrupts. */
     outw(CTL_AUTO_RELEASE | CTL_TE_ENABLE | CTL_CR_ENABLE,
 	 ioaddr + CONTROL);
diff -urN linux-2.6.17-rc1.orig/drivers/net/wan/sdla_x25.c linux-2.6.17-rc1/drivers/net/wan/sdla_x25.c
--- linux-2.6.17-rc1.orig/drivers/net/wan/sdla_x25.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/net/wan/sdla_x25.c	2006-04-06 09:48:34.000000000 +0200
@@ -261,7 +261,7 @@
 	unsigned long i_timeout_sofar;  /* # of sec's we've been idle */
 	unsigned hold_timeout;		/* sec, before re-connecting */
 	unsigned long tick_counter;	/* counter for transmit time out */
-	char devtint;			/* Weather we should dev_tint() */
+	char devtint;			/* Whether we should dev_tint() */
 	struct sk_buff* rx_skb;		/* receive socket buffer */
 	struct sk_buff* tx_skb;		/* transmit socket buffer */
 
diff -urN linux-2.6.17-rc1.orig/drivers/net/wireless/ipw2100.c linux-2.6.17-rc1/drivers/net/wireless/ipw2100.c
--- linux-2.6.17-rc1.orig/drivers/net/wireless/ipw2100.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/net/wireless/ipw2100.c	2006-04-06 09:48:34.000000000 +0200
@@ -1485,7 +1485,7 @@
 		 *
 		 * Sending the PREPARE_FOR_POWER_DOWN will restrict the
 		 * hardware from going into standby mode and will transition
-		 * out of D0-standy if it is already in that state.
+		 * out of D0-standby if it is already in that state.
 		 *
 		 * STATUS_PREPARE_POWER_DOWN_COMPLETE will be sent by the
 		 * driver upon completion.  Once received, the driver can
diff -urN linux-2.6.17-rc1.orig/drivers/pci/pci.c linux-2.6.17-rc1/drivers/pci/pci.c
--- linux-2.6.17-rc1.orig/drivers/pci/pci.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/pci/pci.c	2006-04-06 09:48:34.000000000 +0200
@@ -368,7 +368,7 @@
 
 	/*
 	 * Give firmware a chance to be called, such as ACPI _PRx, _PSx
-	 * Firmware method after natice method ?
+	 * Firmware method after native method ?
 	 */
 	if (platform_pci_set_power_state)
 		platform_pci_set_power_state(dev, state);
diff -urN linux-2.6.17-rc1.orig/drivers/s390/scsi/zfcp_erp.c linux-2.6.17-rc1/drivers/s390/scsi/zfcp_erp.c
--- linux-2.6.17-rc1.orig/drivers/s390/scsi/zfcp_erp.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/s390/scsi/zfcp_erp.c	2006-04-06 09:48:34.000000000 +0200
@@ -177,7 +177,7 @@
  *		initiates adapter recovery which is done
  *		asynchronously
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 int
@@ -213,7 +213,7 @@
  * purpose:	Wrappper for zfcp_erp_adapter_reopen_internal
  *              used to ensure the correct locking
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 int
@@ -503,7 +503,7 @@
  *		initiates Forced Reopen recovery which is done
  *		asynchronously
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 static int
@@ -543,7 +543,7 @@
  * purpose:	Wrappper for zfcp_erp_port_forced_reopen_internal
  *              used to ensure the correct locking
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 int
@@ -570,7 +570,7 @@
  *		initiates Reopen recovery which is done
  *		asynchronously
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 static int
@@ -639,7 +639,7 @@
  *		initiates Reopen recovery which is done
  *		asynchronously
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 static int
@@ -1901,7 +1901,7 @@
  * purpose:	Wrappper for zfcp_erp_port_reopen_all_internal
  *              used to ensure the correct locking
  *
- * returns:	0	- initiated action succesfully
+ * returns:	0	- initiated action successfully
  *		<0	- failed to initiate action
  */
 int
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/aacraid/comminit.c linux-2.6.17-rc1/drivers/scsi/aacraid/comminit.c
--- linux-2.6.17-rc1.orig/drivers/scsi/aacraid/comminit.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/aacraid/comminit.c	2006-04-06 09:48:34.000000000 +0200
@@ -103,7 +103,7 @@
 	 * This assumes the memory is mapped zero->n, which isnt
 	 * always true on real computers. It also has some slight problems
 	 * with the GART on x86-64. I've btw never tried DMA from PCI space
-	 * on this platform but don't be suprised if its problematic.
+	 * on this platform but don't be surprised if its problematic.
 	 */
 #ifndef CONFIG_GART_IOMMU
 	if ((num_physpages << (PAGE_SHIFT - 12)) <= AAC_MAX_HOSTPHYSMEMPAGES) {
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/advansys.c linux-2.6.17-rc1/drivers/scsi/advansys.c
--- linux-2.6.17-rc1.orig/drivers/scsi/advansys.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/advansys.c	2006-04-06 09:48:34.000000000 +0200
@@ -12374,7 +12374,7 @@
                 ASC_PRINT1(
 "AscInitFromEEP: Failed to re-write EEPROM with %d errors.\n", i);
         } else {
-                ASC_PRINT("AscInitFromEEP: Succesfully re-wrote EEPROM.");
+                ASC_PRINT("AscInitFromEEP: Successfully re-wrote EEPROM.\n");
         }
     }
     return (warn_code);
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/dc395x.c linux-2.6.17-rc1/drivers/scsi/dc395x.c
--- linux-2.6.17-rc1.orig/drivers/scsi/dc395x.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/dc395x.c	2006-04-06 09:48:34.000000000 +0200
@@ -3747,7 +3747,7 @@
  * @target: The target for the new device.
  * @lun: The lun for the new device.
  *
- * Return the new device if succesfull or NULL on failure.
+ * Return the new device if successful or NULL on failure.
  **/
 static struct DeviceCtlBlk *device_alloc(struct AdapterCtlBlk *acb,
 		u8 target, u8 lun)
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/ibmmca.c linux-2.6.17-rc1/drivers/scsi/ibmmca.c
--- linux-2.6.17-rc1.orig/drivers/scsi/ibmmca.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/ibmmca.c	2006-04-06 09:48:34.000000000 +0200
@@ -760,7 +760,7 @@
 		while (!got_interrupt(host_index))
 			barrier();
 
-		/*if command succesful, break */
+		/*if command successful, break */
 		if ((stat_result(host_index) == IM_SCB_CMD_COMPLETED) || (stat_result(host_index) == IM_SCB_CMD_COMPLETED_WITH_RETRIES))
 			return 1;
 	}
@@ -885,7 +885,7 @@
 		while (!got_interrupt(host_index))
 			barrier();
 
-		/*if command succesful, break */
+		/*if command successful, break */
 		if (stat_result(host_index) == IM_IMMEDIATE_CMD_COMPLETED)
 			return 1;
 	}
@@ -921,7 +921,7 @@
 			return 2;
 		} else
 			global_command_error_excuse = 0;
-		/*if command succesful, break */
+		/*if command successful, break */
 		if (stat_result(host_index) == IM_IMMEDIATE_CMD_COMPLETED)
 			return 1;
 	}
@@ -959,7 +959,7 @@
 			/* did not work, finish */
 			return 1;
 		}
-		/*if command succesful, break */
+		/*if command successful, break */
 		if (stat_result(host_index) == IM_IMMEDIATE_CMD_COMPLETED)
 			return 1;
 	}
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/ips.c linux-2.6.17-rc1/drivers/scsi/ips.c
--- linux-2.6.17-rc1.orig/drivers/scsi/ips.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/ips.c	2006-04-06 09:48:34.000000000 +0200
@@ -6438,7 +6438,7 @@
 		/* VPP failure */
 		return (1);
 
-	/* check for succesful flash */
+	/* check for successful flash */
 	if (status & 0x30)
 		/* sequence error */
 		return (1);
@@ -6550,7 +6550,7 @@
 		/* VPP failure */
 		return (1);
 
-	/* check for succesful flash */
+	/* check for successful flash */
 	if (status & 0x30)
 		/* sequence error */
 		return (1);
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/NCR5380.c linux-2.6.17-rc1/drivers/scsi/NCR5380.c
--- linux-2.6.17-rc1.orig/drivers/scsi/NCR5380.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/NCR5380.c	2006-04-06 09:48:34.000000000 +0200
@@ -500,7 +500,7 @@
 /* 
  * Function : int should_disconnect (unsigned char cmd)
  *
- * Purpose : decide weather a command would normally disconnect or 
+ * Purpose : decide whether a command would normally disconnect or 
  *      not, since if it won't disconnect we should go to sleep.
  *
  * Input : cmd - opcode of SCSI command
diff -urN linux-2.6.17-rc1.orig/drivers/scsi/st.c linux-2.6.17-rc1/drivers/scsi/st.c
--- linux-2.6.17-rc1.orig/drivers/scsi/st.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/st.c	2006-04-06 09:48:34.000000000 +0200
@@ -2818,7 +2818,7 @@
 		    (cmdstatp->sense_hdr.sense_key == NO_SENSE ||
 		     cmdstatp->sense_hdr.sense_key == RECOVERED_ERROR) &&
 		    undone == 0) {
-			ioctl_result = 0;	/* EOF written succesfully at EOM */
+			ioctl_result = 0;	/* EOF written successfully at EOM */
 			if (fileno >= 0)
 				fileno++;
 			STps->drv_file = fileno;
diff -urN linux-2.6.17-rc1.orig/fs/9p/mux.c linux-2.6.17-rc1/fs/9p/mux.c
--- linux-2.6.17-rc1.orig/fs/9p/mux.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/fs/9p/mux.c	2006-04-06 09:48:34.000000000 +0200
@@ -713,7 +713,7 @@
  * v9fs_send_request - send 9P request
  * The function can sleep until the request is scheduled for sending.
  * The function can be interrupted. Return from the function is not
- * a guarantee that the request is sent succesfully. Can return errors
+ * a guarantee that the request is sent successfully. Can return errors
  * that can be retrieved by PTR_ERR macros.
  *
  * @m: mux data
diff -urN linux-2.6.17-rc1.orig/fs/aio.c linux-2.6.17-rc1/fs/aio.c
--- linux-2.6.17-rc1.orig/fs/aio.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/fs/aio.c	2006-04-06 09:48:35.000000000 +0200
@@ -641,7 +641,7 @@
  *	invoked both for initial i/o submission and
  *	subsequent retries via the aio_kick_handler.
  *	Expects to be invoked with iocb->ki_ctx->lock
- *	already held. The lock is released and reaquired
+ *	already held. The lock is released and reacquired
  *	as needed during processing.
  *
  * Calls the iocb retry method (already setup for the
diff -urN linux-2.6.17-rc1.orig/fs/jffs2/summary.c linux-2.6.17-rc1/fs/jffs2/summary.c
--- linux-2.6.17-rc1.orig/fs/jffs2/summary.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/fs/jffs2/summary.c	2006-04-06 09:48:35.000000000 +0200
@@ -42,7 +42,7 @@
 		return -ENOMEM;
 	}
 
-	dbg_summary("returned succesfully\n");
+	dbg_summary("returned successfully\n");
 
 	return 0;
 }
diff -urN linux-2.6.17-rc1.orig/fs/jfs/jfs_extent.c linux-2.6.17-rc1/fs/jfs/jfs_extent.c
--- linux-2.6.17-rc1.orig/fs/jfs/jfs_extent.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/fs/jfs/jfs_extent.c	2006-04-06 09:48:35.000000000 +0200
@@ -126,7 +126,7 @@
 
 	/* allocate the disk blocks for the extent.  initially, extBalloc()
 	 * will try to allocate disk blocks for the requested size (xlen). 
-	 * if this fails (xlen contigious free blocks not avaliable), it'll
+	 * if this fails (xlen contiguous free blocks not avaliable), it'll
 	 * try to allocate a smaller number of blocks (producing a smaller
 	 * extent), with this smaller number of blocks consisting of the
 	 * requested number of blocks rounded down to the next smaller
@@ -493,7 +493,7 @@
  *
  *		initially, we will try to allocate disk blocks for the
  *		requested size (nblocks).  if this fails (nblocks 
- *		contigious free blocks not avaliable), we'll try to allocate
+ *		contiguous free blocks not avaliable), we'll try to allocate
  *		a smaller number of blocks (producing a smaller extent), with
  *		this smaller number of blocks consisting of the requested
  *		number of blocks rounded down to the next smaller power of 2
@@ -529,7 +529,7 @@
 
 	/* get the number of blocks to initially attempt to allocate.
 	 * we'll first try the number of blocks requested unless this
-	 * number is greater than the maximum number of contigious free
+	 * number is greater than the maximum number of contiguous free
 	 * blocks in the map. in that case, we'll start off with the 
 	 * maximum free.
 	 */
@@ -586,7 +586,7 @@
  *		in place.  if this fails, we'll try to move the extent
  *		to a new set of blocks. if moving the extent, we initially
  *		will try to allocate disk blocks for the requested size
- *		(nnew).  if this fails 	(nnew contigious free blocks not
+ *		(nnew).  if this fails 	(new contiguous free blocks not
  *		avaliable), we'll try  to allocate a smaller number of
  *		blocks (producing a smaller extent), with this smaller
  *		number of blocks consisting of the requested number of
diff -urN linux-2.6.17-rc1.orig/include/asm-i386/mmzone.h linux-2.6.17-rc1/include/asm-i386/mmzone.h
--- linux-2.6.17-rc1.orig/include/asm-i386/mmzone.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/include/asm-i386/mmzone.h	2006-04-06 09:48:42.000000000 +0200
@@ -49,11 +49,11 @@
 /*
  * generic node memory support, the following assumptions apply:
  *
- * 1) memory comes in 256Mb contigious chunks which are either present or not
- * 2) we will not have more than 64Gb in total
+ * 1) memory comes in 256Mb contiguous chunks which are either present or not
+ * 2) we will not have more than 64GB in total
  *
- * for now assume that 64Gb is max amount of RAM for whole system
- *    64Gb / 4096bytes/page = 16777216 pages
+ * for now assume that 64GB is max amount of RAM for whole system
+ *    64GB / 4096Bytes/page = 16777216 pages
  */
 #define MAX_NR_PAGES 16777216
 #define MAX_ELEMENTS 256
diff -urN linux-2.6.17-rc1.orig/include/asm-i386/system.h linux-2.6.17-rc1/include/asm-i386/system.h
--- linux-2.6.17-rc1.orig/include/asm-i386/system.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/include/asm-i386/system.h	2006-04-06 09:48:42.000000000 +0200
@@ -428,7 +428,7 @@
  * does not enforce ordering, since there is no data dependency between
  * the read of "a" and the read of "b".  Therefore, on some CPUs, such
  * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()
- * in cases like thiswhere there are no data dependencies.
+ * in cases like this where there are no data dependencies.
  **/
 
 #define read_barrier_depends()	do { } while(0)
diff -urN linux-2.6.17-rc1.orig/include/asm-m32r/system.h linux-2.6.17-rc1/include/asm-m32r/system.h
--- linux-2.6.17-rc1.orig/include/asm-m32r/system.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/include/asm-m32r/system.h	2006-04-06 09:48:42.000000000 +0200
@@ -344,7 +344,7 @@
  * does not enforce ordering, since there is no data dependency between
  * the read of "a" and the read of "b".  Therefore, on some CPUs, such
  * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()
- * in cases like thiswhere there are no data dependencies.
+ * in cases like this where there are no data dependencies.
  **/
 
 #define read_barrier_depends()	do { } while (0)
diff -urN linux-2.6.17-rc1.orig/include/linux/sunrpc/gss_api.h linux-2.6.17-rc1/include/linux/sunrpc/gss_api.h
--- linux-2.6.17-rc1.orig/include/linux/sunrpc/gss_api.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/include/linux/sunrpc/gss_api.h	2006-04-06 09:48:42.000000000 +0200
@@ -126,7 +126,7 @@
 /* Just increments the mechanism's reference count and returns its input: */
 struct gss_api_mech * gss_mech_get(struct gss_api_mech *);
 
-/* For every succesful gss_mech_get or gss_mech_get_by_* call there must be a
+/* For every successful gss_mech_get or gss_mech_get_by_* call there must be a
  * corresponding call to gss_mech_put. */
 void gss_mech_put(struct gss_api_mech *);
 
diff -urN linux-2.6.17-rc1.orig/lib/kernel_lock.c linux-2.6.17-rc1/lib/kernel_lock.c
--- linux-2.6.17-rc1.orig/lib/kernel_lock.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/lib/kernel_lock.c	2006-04-06 09:48:42.000000000 +0200
@@ -14,7 +14,7 @@
  * The 'big kernel semaphore'
  *
  * This mutex is taken and released recursively by lock_kernel()
- * and unlock_kernel().  It is transparently dropped and reaquired
+ * and unlock_kernel().  It is transparently dropped and reacquired
  * over schedule().  It is used to protect legacy code that hasn't
  * been migrated to a proper locking design yet.
  *
@@ -92,7 +92,7 @@
  * The 'big kernel lock'
  *
  * This spinlock is taken and released recursively by lock_kernel()
- * and unlock_kernel().  It is transparently dropped and reaquired
+ * and unlock_kernel().  It is transparently dropped and reacquired
  * over schedule().  It is used to protect legacy code that hasn't
  * been migrated to a proper locking design yet.
  *
diff -urN linux-2.6.17-rc1.orig/mm/page_alloc.c linux-2.6.17-rc1/mm/page_alloc.c
--- linux-2.6.17-rc1.orig/mm/page_alloc.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/mm/page_alloc.c	2006-04-06 09:48:43.000000000 +0200
@@ -260,7 +260,7 @@
  * satisfies the following equation:
  *     P = B & ~(1 << O)
  *
- * Assumption: *_mem_map is contigious at least up to MAX_ORDER
+ * Assumption: *_mem_map is contiguous at least up to MAX_ORDER
  */
 static inline struct page *
 __page_find_buddy(struct page *page, unsigned long page_idx, unsigned int order)
diff -urN linux-2.6.17-rc1.orig/mm/readahead.c linux-2.6.17-rc1/mm/readahead.c
--- linux-2.6.17-rc1.orig/mm/readahead.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/mm/readahead.c	2006-04-06 09:48:43.000000000 +0200
@@ -394,8 +394,8 @@
  * Read 'nr_to_read' pages starting at page 'offset'. If the flag 'block'
  * is set wait till the read completes.  Otherwise attempt to read without
  * blocking.
- * Returns 1 meaning 'success' if read is succesfull without switching off
- * readhaead mode. Otherwise return failure.
+ * Returns 1 meaning 'success' if read is successful without switching off
+ * readahead mode. Otherwise return failure.
  */
 static int
 blockable_page_cache_readahead(struct address_space *mapping, struct file *filp,
diff -urN linux-2.6.17-rc1.orig/net/sunrpc/auth_gss/gss_krb5_mech.c linux-2.6.17-rc1/net/sunrpc/auth_gss/gss_krb5_mech.c
--- linux-2.6.17-rc1.orig/net/sunrpc/auth_gss/gss_krb5_mech.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/net/sunrpc/auth_gss/gss_krb5_mech.c	2006-04-06 09:48:43.000000000 +0200
@@ -169,7 +169,7 @@
 	}
 
 	ctx_id->internal_ctx_id = ctx;
-	dprintk("RPC:      Succesfully imported new context.\n");
+	dprintk("RPC:      Successfully imported new context.\n");
 	return 0;
 
 out_err_free_key2:
diff -urN linux-2.6.17-rc1.orig/net/sunrpc/auth_gss/gss_spkm3_mech.c linux-2.6.17-rc1/net/sunrpc/auth_gss/gss_spkm3_mech.c
--- linux-2.6.17-rc1.orig/net/sunrpc/auth_gss/gss_spkm3_mech.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/net/sunrpc/auth_gss/gss_spkm3_mech.c	2006-04-06 09:48:43.000000000 +0200
@@ -201,7 +201,7 @@
 
 	ctx_id->internal_ctx_id = ctx;
 
-	dprintk("Succesfully imported new spkm context.\n");
+	dprintk("Successfully imported new spkm context.\n");
 	return 0;
 
 out_err_free_key2:
diff -urN linux-2.6.17-rc1.orig/sound/core/seq/seq_memory.h linux-2.6.17-rc1/sound/core/seq/seq_memory.h
--- linux-2.6.17-rc1.orig/sound/core/seq/seq_memory.h	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/sound/core/seq/seq_memory.h	2006-04-06 09:48:43.000000000 +0200
@@ -31,7 +31,7 @@
 	struct snd_seq_event_cell *next;	/* next cell */
 };
 
-/* design note: the pool is a contigious block of memory, if we dynamicly
+/* design note: the pool is a contiguous block of memory, if we dynamicly
    want to add additional cells to the pool be better store this in another
    pool as we need to know the base address of the pool when releasing
    memory. */
diff -urN linux-2.6.17-rc1.orig/sound/oss/sb_ess.c linux-2.6.17-rc1/sound/oss/sb_ess.c
--- linux-2.6.17-rc1.orig/sound/oss/sb_ess.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/sound/oss/sb_ess.c	2006-04-06 09:48:43.000000000 +0200
@@ -97,19 +97,19 @@
  *
  * The documentation is an adventure: it's close but not fully accurate. I
  * found out that after a reset some registers are *NOT* reset, though the
- * docs say the would be. Interresting ones are 0x7f, 0x7d and 0x7a. They are
- * related to the Audio 2 channel. I also was suprised about the consequenses
+ * docs say the would be. Interesting ones are 0x7f, 0x7d and 0x7a. They are
+ * related to the Audio 2 channel. I also was surprised about the consequences
  * of writing 0x00 to 0x7f (which should be done by reset): The ES1887 moves
  * into ES1888 mode. This means that it claims IRQ 11, which happens to be my
  * ISDN adapter. Needless to say it no longer worked. I now understand why
  * after rebooting 0x7f already was 0x05, the value of my choice: the BIOS
  * did it.
  *
- * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is decribed
- * as if it's exactly the same as register 0xa1. This is *NOT* true. The
- * description of 0x70 in ES1869 docs is accurate however.
+ * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is
+ * described as if it's exactly the same as register 0xa1. This is *NOT* true.
+ * The description of 0x70 in ES1869 docs is accurate however.
  * Well, the assumption about ES1869 was wrong: register 0x70 is very much
- * like register 0xa1, except that bit 7 is allways 1, whatever you want
+ * like register 0xa1, except that bit 7 is always 1, whatever you want
  * it to be.
  *
  * When using audio 2 mixer register 0x72 seems te be meaningless. Only 0xa2
@@ -117,10 +117,10 @@
  *
  * Software reset not being able to reset all registers is great! Especially
  * the fact that register 0x78 isn't reset is great when you wanna change back
- * to single dma operation (simplex): audio 2 is still operation, and uses the
- * same dma as audio 1: your ess changes into a funny echo machine.
+ * to single dma operation (simplex): audio 2 is still operational, and uses
+ * the same dma as audio 1: your ess changes into a funny echo machine.
  *
- * Received the new that ES1688 is detected as a ES1788. Did some thinking:
+ * Received the news that ES1688 is detected as a ES1788. Did some thinking:
  * the ES1887 detection scheme suggests in step 2 to try if bit 3 of register
  * 0x64 can be changed. This is inaccurate, first I inverted the * check: "If
  * can be modified, it's a 1688", which lead to a correct detection
@@ -135,7 +135,7 @@
  * About recognition of ESS chips
  *
  * The distinction of ES688, ES1688, ES1788, ES1887 and ES1888 is described in
- * a (preliminary ??) datasheet on ES1887. It's aim is to identify ES1887, but
+ * a (preliminary ??) datasheet on ES1887. Its aim is to identify ES1887, but
  * during detection the text claims that "this chip may be ..." when a step
  * fails. This scheme is used to distinct between the above chips.
  * It appears however that some PnP chips like ES1868 are recognized as ES1788
@@ -156,9 +156,9 @@
  *
  * The existing ES1688 support didn't take care of the ES1688+ recording
  * levels very well. Whenever a device was selected (recmask) for recording
- * it's recording level was loud, and it couldn't be changed. The fact that
+ * its recording level was loud, and it couldn't be changed. The fact that
  * internal register 0xb4 could take care of RECLEV, didn't work meaning until
- * it's value was restored every time the chip was reset; this reset the
+ * its value was restored every time the chip was reset; this reset the
  * value of 0xb4 too. I guess that's what 4front also had (have?) trouble with.
  *
  * About ES1887 support:
@@ -169,9 +169,9 @@
  * the latter case the recording volumes are 0.
  * Now recording levels of inputs can be controlled, by changing the playback
  * levels. Futhermore several devices can be recorded together (which is not
- * possible with the ES1688.
+ * possible with the ES1688).
  * Besides the separate recording level control for each input, the common
- * recordig level can also be controlled by RECLEV as described above.
+ * recording level can also be controlled by RECLEV as described above.
  *
  * Not only ES1887 have this recording mixer. I know the following from the
  * documentation:
diff -urN linux-2.6.17-rc1.orig/sound/pci/cs5535audio/cs5535audio_pcm.c linux-2.6.17-rc1/sound/pci/cs5535audio/cs5535audio_pcm.c
--- linux-2.6.17-rc1.orig/sound/pci/cs5535audio/cs5535audio_pcm.c	2006-04-03 05:22:10.000000000 +0200
+++ linux-2.6.17-rc1/sound/pci/cs5535audio/cs5535audio_pcm.c	2006-04-06 09:48:43.000000000 +0200
@@ -142,7 +142,7 @@
 	if (dma->periods == periods && dma->period_bytes == period_bytes)
 		return 0;
 
-	/* the u32 cast is okay because in snd*create we succesfully told
+	/* the u32 cast is okay because in snd*create we successfully told
    	   pci alloc that we're only 32 bit capable so the uppper will be 0 */
 	addr = (u32) substream->runtime->dma_addr;
 	desc_addr = (u32) dma->desc_buf.addr;

^ permalink raw reply

* Re: [PATCHSET] sata_sil24: fixes, errata workaround and reset updates
From: Tejun Heo @ 2006-04-06  8:20 UTC (permalink / raw)
  To: Tejun Heo; +Cc: jgarzik, Carlos.Pardo, linux-ide
In-Reply-To: <11442437413563-git-send-email-htejun@gmail.com>

Tejun Heo wrote:
> Hello, Jeff, Carlos.
> 
> This patchset updates sata_sil24 and is composed eight patches.
> 
> #01	libata prep
> #02-03	bug fix and errata workaround
> #04	sil24 prep
> #05	enable 64bit
> #05-06	update softreset
> #07	reimplement hardreset
> 
> This patchset is against...
>   upstream [1]
>   + libata reset updates patchset [2]
> 

Further testing shows more delay's are needed during hardreset and I've 
found more bugs in sata_sil24.  Will add those and repost this whole 
set.  Please ignore this patchset.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: The future of patch-o-matic-ng
From: Patrick McHardy @ 2006-04-06  8:22 UTC (permalink / raw)
  To: Harald Welte; +Cc: Netfilter Development Mailinglist, Grzegorz Janoszka
In-Reply-To: <20060406073514.GE6887@sunbeam.de.gnumonks.org>

Harald Welte wrote:
> As indicated in Patricks mail, there's a 30 day grace period.  Until
> then the original authors (if they care) or other people can take
> maintenance for individual patchlets and send us URL's to those
> repositories.  We will add them to our list file, and distribute a
> 'runme' script which downloads those repositories off the net.
> 
> If you want to help, I suggest to wait for those patchlets that nobody
> takes care of, and run a repository for them.

As a side-note: anyone who decides to take maintanance for some
patchlet, please drop me a short note, so I can keep a list
of unmaintained patches.

> Also, I assume that there is a lot that can be done to improve that
> patchlet-handling script, i.e. add suport for GPG signature checking and
> the like.  I suggest you coordinate with Patrick on this.

Definitely. The code is very basic, it only makes sure a patchlet
1) doesn't overwrite anything outside of its patchlet directory
2) can only overwrite "Repository: external" patchlets

But doensn't do any signature verification. I'll add it today,
patches are welcome.

^ permalink raw reply

* script binding for reiserfs?
From: Dongxu Ma @ 2006-04-06  8:23 UTC (permalink / raw)
  To: reiserfs-list

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Hi all,

As reiserfs more and more popular, is there any binding package for use in
script languages? I did a search on Google and nothing found.
Curently I am thinking about writing a binding for Perl, which can offer:
1) script-level operation against reiserfs
2) DBI && DBD for reiserfs binding to treat the fs as a database. My aim is
constructing a mid-and-small wiki directly on reiserfs without employing any
real database

However, after some seeking on source. I got several issues:
1) is there any so-called official userspace api exported?
On gentoo there is a package named progsreiserfs introducing an api set
under /usr/include/reiserfs, but I am not very sure if it is stable and the
project is still alive.

2) regarding reiser3, where could I start to port? since exporting something
in kernelspace is quite risky.

Any advice and hint?

--
Cheers, Dongxu
__END__
dongxu.wordpress.com
search.cpan.org/~dongxu

[-- Attachment #2: Type: text/html, Size: 1102 bytes --]

^ permalink raw reply

* [linux-lvm] Problem enquiry
From: Sreevidya@tsm.ac.in @ 2006-04-06  8:30 UTC (permalink / raw)
  To: linux-lvm



Respected Sir/Madam,

I am working as a lecturer in TSM,Madurai. We have a problem in our linux
system and we are unable to resolve the same.I request you to kindly help
me to resolve this.

We had an 18GB HDD previously in our institution on which the mail server
for our institution was configured. Due to the increased strength of mail
usage we had to extend the HDD to a larger one. We have a scussi HDD. We
then bought another HDD of 40GB capacity and with the ghost process we
transferred to the newer HDD.But still in that 40GB HDD we were able to
use only that 18GB  partition the rest of 22GB is still unusable.
Kindly tell us the way in which we can extend that 22GB with that of 18GB
so that the entire HDD can be used for this purpose.

Awaiting your response.

Thanking you,

Yours faithfully,
Sreevidya S
Faculty MCA
Thiagarajar School of Management,
Madurai

^ permalink raw reply

* [U-Boot-Users] Linux with U-Boot
From: Ganesh Ramachandran @ 2006-04-06  8:30 UTC (permalink / raw)
  To: u-boot

I am using U-Boot loader 1.1.4 and I am using IntegratorCP ARM Boards.
I am facing the problems while booting, I debugged my Kernel with Low
Level Debugging.I think My problem is in 'Call_Kernel' Function in
head.S and I am using kernel 2.6.16.

## Checking Image at 00007fc0 ...
   Image Name:   Linux 2.6.16
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1152816 Bytes =  1.1 MB
   Load Address: 00007fc0
   Entry Point:  00008000
   Verifying Checksum ... OK
Integrator-CP # setenv bootargs root=/dev/mtdblock2 mem=128M
console=ttyAM0,38400n8
Integrator-CP #
Integrator-CP # bootm
## Booting image at 00007fc0 ...
   Image Name:   Linux 2.6.16
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1152816 Bytes =  1.1 MB
   Load Address: 00007fc0
   Entry Point:  00008000
   XIP Kernel Image ... OK

Starting kernel ...

Uncompressing Linux............................................................................
done, booting the kernel
.

410FB760:00000113:00050078
^^^^^^^^^^^^_________________________Processor ID seeems to be OK
               ^^^^^^^^^^^_________________Architecture ID is also ok
                               ^^^^^^^^^^^________What is Control
Register? Is this related with Params? If it is Param my param is
wrong here.

0013AB68-0037EF68>00008000
                                ^^^^^^^^^^^_______Kernel Execution Address is Ok

This is my print statement in head.S in 'call_kernel'.

:00000000%00000000 at 00000040*00008000
 ^^^^^^^^^^^__________________________r0 is 0 Perfect
                  ^^^^^^^^^^^^________________Here the machine ID is
wrong. I want to get as 0x113. But I am getting 0.
                                   ^^^^^^^^^^^^______HOw to check the
ATAG ID. Is it related with Params?
                                                  ^^^^^^^^_ Kernel
Execution ID seems to be Ok.


Please anybody help me. I am new to u-boot and kernel.

Thanks & Regards,

Ganesh Ramachandran.

^ permalink raw reply

* [U-Boot-Users] Linux with U-Boot
From: Wolfgang Denk @ 2006-04-06  8:36 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <21c86c970604060130u5b44c042w3af80c4b54b9a6f1@mail.gmail.com>

In message <21c86c970604060130u5b44c042w3af80c4b54b9a6f1@mail.gmail.com> you wrote:
> I am using U-Boot loader 1.1.4 and I am using IntegratorCP ARM Boards.
> I am facing the problems while booting, I debugged my Kernel with Low
> Level Debugging.I think My problem is in 'Call_Kernel' Function in
> head.S and I am using kernel 2.6.16.

Then you are on the wrong mailing list. Please  post  kernel  related
issues on the arm-linux list instead.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cleverness and Style have no place in getting a project completed.
                                                  -- Tom Christiansen

^ permalink raw reply

* Re: No CONFIG_DEBUG_INFO on x86_64 Xen; why not?
From: Keir Fraser @ 2006-04-06  8:51 UTC (permalink / raw)
  To: Stephen C. Tweedie; +Cc: xen-devel
In-Reply-To: <1144282621.3447.5.camel@orbit.scot.redhat.com>


On 6 Apr 2006, at 01:17, Stephen C. Tweedie wrote:

> neither of which are particularly helpful.  I've just completed a build
> with this change reverted and -g enabled and it built fine (although 
> I'm
> remote from the box right now so can't boot it yet); and gdb on the
> vmlinux shows symbolic info is present.
>
> Anyone remember, or object to reenabling CONFIG_DEBUG_INFO?

Well, it builds and boots fine, and we leave it disabled by default 
anyway, so I'll remove our patch to Kconfig.debug. I think maybe there 
was a problem with our port of debug code in entry-xen.S, but I see 
that file forcibly disables CONFIG_DEBUG_INFO when it builds, which is 
probably the better 'fix' for the time being.

  -- Keir

^ permalink raw reply

* Re: tcf_generic_walker(): what's going on?
From: Patrick McHardy @ 2006-04-06  8:50 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: linux-kernel, netdev, kuznet, David S. Miller
In-Reply-To: <200604060911.01140.vda@ilport.com.ua>

Denis Vlasenko wrote:
> While hunting down oversized inlines
> I stumbled on tcf_generic_walker().
> 
> It is defined in two separate files:
> once as an inline in include/net/pkt_act.h
> (really big one, ~750 bytes of code)
> and once as a static function in net/sched/act_police.c
> 
> These two instances are not identical.
> Second one has one extra parameter (int type)
> and it uses it like this:
> 
>         for (i = 0; i < MY_TAB_SIZE; i++) {
>                 p = tcf_police_ht[tcf_police_hash(i)];
> 
>                 for (; p; p = p->next) {
>                         index++;
>                         if (index < s_i)
>                                 continue;
>                         a->priv = p;
>                         a->order = index;
>                         r = (struct rtattr*) skb->tail;
>                         RTA_PUT(skb, a->order, 0, NULL);
> +                       if (type == RTM_DELACTION)
> +                               err = tcf_action_dump_1(skb, a, 0, 1);
> +                       else
> +                               err = tcf_action_dump_1(skb, a, 0, 0);
> 
> Having two functions with same name is rather confusing.
> Worse, they are both are called via five different
> tc_action_ops structs: 
> 
> static struct tc_action_ops act_ipt_ops = {
> ...
>         .walk           =       tcf_generic_walker
> 
> and I fail to understand how it is supposed to work,
> considering the fact that these two tcf_generic_walker's
> have different prototypes.

This code is a lazy hack to achieve "genericness" by using
a "generic" inline functions and #defines to create
specialized instances.

> 1) What should I do with tcf_generic_walker?
> 2) Should I deinline huge inlines in include/net/pkt_act.h?
>    If yes, to which .c file should I move them?

Unforunately you can't do this without further restructuring,
look at how the tc actions use that file:

/* use generic hash table */
#define MY_TAB_SIZE     8
#define MY_TAB_MASK     (MY_TAB_SIZE - 1)
static u32 idx_gen;
static struct tcf_mirred *tcf_mirred_ht[MY_TAB_SIZE];
static DEFINE_RWLOCK(mirred_lock);

/* ovewrride the defaults */
#define tcf_st          tcf_mirred
#define tc_st           tc_mirred
#define tcf_t_lock      mirred_lock
#define tcf_ht          tcf_mirred_ht

#define CONFIG_NET_ACT_INIT 1
#include <net/pkt_act.h>

What needs to be done is to put a pointer to the hash, its size
and its lock in struct tc_action_ops and move the "generic"
functions to a seperate .c file and make them work on a struct
tcf_act_common.


^ permalink raw reply

* [Qemu-devel] Patch for sending large (>4k) packets through qemu/slirp
From: Kenneth Duda @ 2006-04-06  8:53 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <6fe044190604060145k53bdde3br925d884d7db08efa@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

In qemu-0.8.0.20060327, there are three problems with sending large
packets from guest to host:

 (1) the code in slirp's ip_reass() reads a next pointer out an mbuf
after freeing it via m_cat().

 (2) the code in slirp's m_inc() calls realloc() on a large mbuf, but
fails to adjust m_data to point to the new allocation (see
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00228.html).

 (3) there are many places within ip_input(), ip_reass(),
udp_input(), etc., that treat ip_len and ip_off as though they were
declared unsigned, when in fact they have been declared signed.

Patches fixing these problems are attached. I hope they can be
applied.  Please let me know what I can do to make the patches more
likely to be accepted.

Thanks,

   -Ken

[-- Attachment #2: qemu-slirp-reassembly-bug.patch --]
[-- Type: text/plain, Size: 464 bytes --]

diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c	2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c	2006-04-06 06:02:52.000000000 +0000
@@ -344,8 +344,8 @@
 	while (q != (struct ipasfrag *)fp) {
 	  struct mbuf *t;
 	  t = dtom(q);
-	  m_cat(m, t);
 	  q = (struct ipasfrag *) q->ipf_next;
+	  m_cat(m, t);
 	}
 
 	/*


[-- Attachment #3: qemu-slirp-mbuf-bug.patch --]
[-- Type: text/plain, Size: 885 bytes --]

diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c	2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c	2006-04-05 13:03:03.000000000 +0000
@@ -146,18 +146,19 @@
         struct mbuf *m;
         int size;
 {
+	int datasize;
+
 	/* some compiles throw up on gotos.  This one we can fake. */
         if(m->m_size>size) return;
 
         if (m->m_flags & M_EXT) {
-	  /* datasize = m->m_data - m->m_ext; */
+	  datasize = m->m_data - m->m_ext;
 	  m->m_ext = (char *)realloc(m->m_ext,size);
 /*		if (m->m_ext == NULL)
  *			return (struct mbuf *)NULL;
  */		
-	  /* m->m_data = m->m_ext + datasize; */
+	  m->m_data = m->m_ext + datasize;
         } else {
-	  int datasize;
 	  char *dat;
 	  datasize = m->m_data - m->m_dat;
 	  dat = (char *)malloc(size);


[-- Attachment #4: qemu-slirp-32k-packets.patch --]
[-- Type: text/plain, Size: 4431 bytes --]

diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h	2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h	2006-04-06 00:28:49.000000000 -0700
@@ -79,6 +79,11 @@
  * We declare ip_len and ip_off to be short, rather than u_short
  * pragmatically since otherwise unsigned comparisons can result
  * against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
  */
 struct ip {
 #ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
 	struct	in_addr ip_src,ip_dst;	/* source and dest address */
 };
 
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
 #define	IP_MAXPACKET	65535		/* maximum packet size */
 
 /*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c	2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c	2006-04-06 00:32:19.000000000 -0700
@@ -111,7 +111,7 @@
 	 * Convert fields to host representation.
 	 */
 	NTOHS(ip->ip_len);
-	if (ip->ip_len < hlen) {
+	if (IP_LEN(ip) < hlen) {
 		ipstat.ips_badlen++;
 		goto bad;
 	}
@@ -124,13 +124,13 @@
 	 * Trim mbufs if longer than we expect.
 	 * Drop packet if shorter than we expect.
 	 */
-	if (m->m_len < ip->ip_len) {
+	if (m->m_len < IP_LEN(ip)) {
 		ipstat.ips_tooshort++;
 		goto bad;
 	}
 	/* Should drop packet if mbuf too long? hmmm... */
-	if (m->m_len > ip->ip_len)
-	   m_adj(m, ip->ip_len - m->m_len);
+	if (m->m_len > IP_LEN(ip))
+	   m_adj(m, IP_LEN(ip) - m->m_len);
 
 	/* check ip_ttl for a correct ICMP reply */
 	if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
 		 * or if this is not the first fragment,
 		 * attempt reassembly; if it succeeds, proceed.
 		 */
-		if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+		if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
 			ipstat.ips_fragments++;
 			ip = ip_reass((struct ipasfrag *)ip, fp);
 			if (ip == 0)
@@ -281,7 +281,7 @@
 	 */
 	for (q = (struct ipasfrag *)fp->ipq_next; q != (struct ipasfrag *)fp;
 	    q = (struct ipasfrag *)q->ipf_next)
-		if (q->ip_off > ip->ip_off)
+		if (IP_OFF(q) > IP_OFF(ip))
 			break;
 
 	/*
@@ -290,10 +290,10 @@
 	 * segment.  If it provides all of our data, drop us.
 	 */
 	if (q->ipf_prev != (ipasfragp_32)fp) {
-		i = ((struct ipasfrag *)(q->ipf_prev))->ip_off +
-		  ((struct ipasfrag *)(q->ipf_prev))->ip_len - ip->ip_off;
+		i = IP_OFF((struct ipasfrag *)(q->ipf_prev)) +
+		  IP_LEN((struct ipasfrag *)(q->ipf_prev)) - IP_OFF(ip);
 		if (i > 0) {
-			if (i >= ip->ip_len)
+			if (i >= IP_LEN(ip))
 				goto dropfrag;
 			m_adj(dtom(ip), i);
 			ip->ip_off += i;
@@ -305,9 +305,9 @@
 	 * While we overlap succeeding segments trim them or,
 	 * if they are completely covered, dequeue them.
 	 */
-	while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) {
-		i = (ip->ip_off + ip->ip_len) - q->ip_off;
-		if (i < q->ip_len) {
+	while (q != (struct ipasfrag *)fp && IP_OFF(ip) + IP_LEN(ip) > IP_OFF(q)) {
+		i = (IP_OFF(ip) + IP_LEN(ip)) - IP_OFF(q);
+		if (i < IP_LEN(q)) {
 			q->ip_len -= i;
 			q->ip_off += i;
 			m_adj(dtom(q), i);
@@ -327,9 +327,9 @@
 	next = 0;
 	for (q = (struct ipasfrag *) fp->ipq_next; q != (struct ipasfrag *)fp;
 	     q = (struct ipasfrag *) q->ipf_next) {
-		if (q->ip_off != next)
+		if (IP_OFF(q) != next)
 			return (0);
-		next += q->ip_len;
+		next += IP_LEN(q);
 	}
 	if (((struct ipasfrag *)(q->ipf_prev))->ipf_mff & 1)
 		return (0);
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/udp.c qemu-snapshot-2006-03-27_23/slirp/udp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/udp.c	2006-04-06 00:24:30.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/udp.c	2006-04-06 00:32:55.000000000 -0700
@@ -111,12 +111,12 @@
 	 */
 	len = ntohs((u_int16_t)uh->uh_ulen);
 
-	if (ip->ip_len != len) {
-		if (len > ip->ip_len) {
+	if (IP_LEN(ip) != len) {
+		if (len > IP_LEN(ip)) {
 			udpstat.udps_badlen++;
 			goto bad;
 		}
-		m_adj(m, len - ip->ip_len);
+		m_adj(m, len - IP_LEN(ip));
 		ip->ip_len = len;
 	}
 	


^ permalink raw reply

* [Qemu-devel] Patch for minor qemu heap corruption bug when the console is zero width
From: Kenneth Duda @ 2006-04-06  8:53 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <6fe044190604060146i4377f13eub00639e764074f2e@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

This patch fixes a minor bug that mcheck picked up.  I don't know if
it ever causes problems in practice.

   -Ken

[-- Attachment #2: qemu-zero-width-console.patch --]
[-- Type: text/plain, Size: 663 bytes --]

diff -burN qemu-snapshot-2006-03-27_23.orig/console.c qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c	2006-03-11 07:35:30.000000000 -0800
+++ qemu-snapshot-2006-03-27_23/console.c	2006-04-06 00:25:41.000000000 -0700
@@ -407,7 +407,8 @@
     if (s->width < w1)
         w1 = s->width;
 
-    cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+    cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+    /* Add one extra in case s->width is 0, so we can still store one character. */
     for(y = 0; y < s->total_height; y++) {
         c = &cells[y * s->width];
         if (w1 > 0) {


^ permalink raw reply


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.