Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS

[Pete Zaitcev]

On Tue, 12 Feb 2008 10:46:12 +0900, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:

> On a serious note, it seems that two scatter lists per request leaded
> to this bug. Can the scatter list in struct ub_request be removed?

Good question. It's an eyesore to be sure. The duplication exists
for the sake of retries combined with the separation of requests
from commands.

Please bear with me, if you're curious: commands can be launched
without requests (at probe time, for instance, or when sense is
requested). So, they need an s/g table. But then, the lifetime of
a request is greater than than of a command, in case of a retry
especially. Therefore a request needs the s/g table too.

So, one way to kill this duplication is to mandate that a
request existed for every command. It seemed like way more code
than just one memcpy() when I wrote it.

Another way would be to make commands flexible, e.g. sometimes with
just a virtual address and size, sometimes with an s/g table.
If you guys make struct scatterlist illegal to copy with memcpy
one day, this is probably what I'll do.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Huawei E220 and usb storage

[Pete Zaitcev]

On Fri, 16 Nov 2007 14:22:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:

> > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero 
> > > length.
> > > Can you try zero length with the kernel? It's the second argument to the 
> > > last.
> > 
> > I tried with the git patch plus changing the penultimage argument from
> > 0x1 to 0.
> 
> Ok, did new tests with 2.6.24-rc2:
> - with plain kernel the usb-storage modules attaches and detaches
>   permanently a virtual cd drive, I stopped after 30+ iterations.

It looks like between Dave Russel and I, we hit the same problem
that you did, after taking care of detection and initialization.
Look at his dmesg in comment #44 in this:
 https://bugzilla.redhat.com/show_bug.cgi?id=253096#c44

> - changing the penultimage argument in the usb_stor_huawei_e220_init
>   function from 0x1 to 0 stopped this misbehaviour, but
> 
> - with the change from 0x1 to 0 the initialization works automatically.

I may be able to test this.

As you recall, Huawei people themselves suggested nonzero length,
this is why we didn't want to change it. But perhaps they are
mistaken about the operation of their own hardware. Stranger
things happened...

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS

[Pete Zaitcev]

On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:

> Looks like you deadlocked in ub_request_fn().  I assume that you were using
> ub.c in 2.6.23 and that it worked OK?  If so, we broke it, possibly via
> changes to the core block layer.
> 
> I think ub.c is basically abandoned in favour of usb-storage.  If so,
> perhaps we should remove or disble ub.c?

Actually I think it may be an argument for keeping ub, if ub exposes
a bug in the __blk_end_request. I'll look at the head of the thread
and see if Mr. Pinter has hit anything related to Mr. Ueda's work.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS

[Pete Zaitcev]

On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:

> > > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/

> I think ub.c is basically abandoned in favour of usb-storage.
> If so, perhaps we should remove or disble ub.c?

Looks like it's just Tomo or Jens made a mistake when converting to
the new s/g API. Nothing to be too concerned about. I know I should've
reviewed their patch closer, but it seemed too simple...

-- Pete

Fix up the conversion to sg_init_table().

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

--- a/drivers/block/ub.c
+++ b/drivers/block/ub.c
@@ -657,7 +657,6 @@ static int ub_request_fn_1(struct ub_lun *lun, struct 
request *rq)
if ((cmd = ub_get_cmd(lun)) == NULL)
return -1;
memset(cmd, 0, sizeof(struct ub_scsi_cmd));
-   sg_init_table(cmd->sgv, UB_MAX_REQ_SG);
 
blkdev_dequeue_request(rq);
 
@@ -668,6 +667,7 @@ static int ub_request_fn_1(struct ub_lun *lun, struct 
request *rq)
/*
 * get scatterlist from block layer
 */
+   sg_init_table(&urq->sgv[0], UB_MAX_REQ_SG);
n_elem = blk_rq_map_sg(lun->disk->queue, rq, &urq->sgv[0]);
if (n_elem < 0) {
/* Impossible, because blk_rq_map_sg should not hit ENOMEM. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Huawei E220 and usb storage

[Pete Zaitcev]

On Wed, 20 Feb 2008 07:57:23 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:

> > that you did, after taking care of detection and initialization.
> > Look at his dmesg in comment #44 in this:
> 
> Yes, that looks very similar.

Someone reported on the bug that a firmware update exists to resolve
the issue (version 11.117.07.00.67). Probably they started to comply
with the spec and return 12 bytes of sense according to the allocation
length in the SCSI command.
  https://bugzilla.redhat.com/show_bug.cgi?id=253096#c51

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sk->state_chage is not called for listening sockets

[Pete Zaitcev]

Hello:

Suppose for a moment, that I have an in-kernel daemon, listening
on a TCP socket, and that the said daemon is interested to
know when connection becomes established. To that end it
puts something into sk->state_change. However, when connection
is established, state_chenge is not called (in 2.4.3).

With that in mind, would the following chage have any ill effects?
It does not seem to break anything obvious, but I am worried about
a performance degradation for some retarded benchmark.

diff -u -U 4 linux-2.4.3/net/ipv4/tcp_input.c linux-2.4.3-nfs/net/ipv4/tcp_input.c
--- linux-2.4.3/net/ipv4/tcp_input.cFri Feb  9 11:34:13 2001
+++ linux-2.4.3-nfs/net/ipv4/tcp_input.cThu Apr 12 23:23:59 2001
@@ -3712,16 +3712,16 @@
if (acceptable) {
tp->copied_seq = tp->rcv_nxt;
mb();
tcp_set_state(sk, TCP_ESTABLISHED);
+   sk->state_change(sk);
 
/* Note, that this wakeup is only for marginal
 * crossed SYN case. Passively open sockets
 * are not waked up, because sk->sleep == NULL
 * and sk->socket == NULL.
 */
if (sk->socket) {
-   sk->state_change(sk);
sk_wake_async(sk,0,POLL_OUT);
}
 
tp->snd_una = TCP_SKB_CB(skb)->ack_seq;


Thanks,
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb-uhci.c problems in latest kernels?

[Pete Zaitcev]

> usb-uhci.c: interrupt, status 3, frame# 1876 

This is a known problem, here is the discussion that I initiated
on linux-usb-devel:

 http://marc.theaimsgroup.com/?t=9860950851&w=2&r=1

The right fix is to comment that printout out.
In fact, that is what I commited for Red Hat 7.1 release.

Some people suggest to switch to uhci instead of usb-uhci,
which helps precisely because it does not have a corresponding
printk.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

So, what about kwhich on RH6.2?

[Pete Zaitcev]

Are we going to use Miquel's patch? I cannot build fresh 2.2.x
on plain RH6.2 without it. The 2.2.19-pre6 comes out without it.
Or is "install new bash" the official answer? Alan?

-- Pete

--- linux-2.2.19-pre3/scripts/kwhichSun Dec 10 16:49:45 2000
+++ linux-2.2.19-pre3-p3/scripts/kwhich Sat Dec 23 21:10:33 2000
@@ -7,7 +7,7 @@
 exit 1
 fi
 
-IFS=:
+IFS=":$IFS"
 for cmd in $*
 do
 for path in $PATH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: So, what about kwhich on RH6.2?

[Pete Zaitcev]

>Date:Wed, 03 Jan 2001 22:08:33 -0800
>From: Pete Zaitcev <[EMAIL PROTECTED]>
> 
>Are we going to use Miquel's patch? I cannot build fresh 2.2.x on
>plain RH6.2 without it. The 2.2.19-pre6 comes out without it.  Or
>is "install new bash" the official answer? Alan?
> 
> I do not understand, I just got a working 2.2.19-pre6 build on one of
> my 6.2 Sparc64 systems, what kind of failure do you see?

Oops. I cannot reproduce it anymore. Since I am quite sure
in my recollection of this problem, I conclude that there
was a kernel (perhaps 2.2.19-pre3), that called kwhich with
several arguments. No problem now on the pre6.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre7

[Pete Zaitcev]

> o Fix kwhich versus old bash (Pete Zaitcev) 

A small clarification may be in order here.

First, this patch comes from Miquel Smoorenburg, not from me.

Second, DaveM pointed out that it fixes a non-problem.
I stepped on a bug with an obscure kernel, I think it
was 2.2.18-pre3, which called kwhich with several arguments.
Current kernels call kwhich with one argument at a time,
so they are not affected.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Loud screech after reboot of 2.2.18-pre22

[Pete Zaitcev]

Hi,

I have a Sony VAIO Z505JE with ymfpci sound and built-in microphone
and speaker. Everything worked fine with 2.2.17 plus ymfpci patch,
but the 2.2.18-pre22 produces a loud screech starting as sound
initializes and ending when startup scrips load mixer settings.
This happens because of audio loop between microphone and speakers.

I found that the culprit is the change to values of array
mixer_defaults[] in ac97_codec.c, that happened in 2.2.18-pre.

Currently I run the following patch:

--- linux-2.2.18-pre22/drivers/sound/ac97_codec.c   Sat Nov 18 19:04:34 2000
+++ linux-2.2.18-pre22-p3/drivers/sound/ac97_codec.cSun Nov 19 15:37:44 2000
@@ -131,7 +131,7 @@
{SOUND_MIXER_PCM,   0x4343},
{SOUND_MIXER_SPEAKER,   0x4343},
{SOUND_MIXER_LINE,  0x4343},
-   {SOUND_MIXER_MIC,   0x4343},
+   {SOUND_MIXER_MIC,   0x},/* P3 - audio loop */
{SOUND_MIXER_CD,0x4343},
{SOUND_MIXER_ALTPCM,0x4343},
{SOUND_MIXER_IGAIN, 0x4343},

I wonder if there is a better way?

In the interests of full disclosure let me mention that YMFxxx do have
internal loopbacks that may produce the same effect and that I checked
to the best of my ability that those loopbacks are muted. Therefore
I conclude that the loopback happens inside the AC97 (if such a thing
is possible).

--Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: YMF PCI - thanks, glitches, patches (fwd)

[Pete Zaitcev]

> Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> From: Pavel Roskin <[EMAIL PROTECTED]>
> cc: Jaroslav Kysela <[EMAIL PROTECTED]>, Pete Zaitcev <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

> The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:

I did not have a chance to look at whatever is in 2.4, but from
reading Linus's e-mails I understand that Jaroslav made a new
port, which is probably unrelated to the stuff that I hastily
cooked up for 2.2 (I really wanted to play Doom on my new Sony).
I am sorry for the lack of communication.

I'll see what 2.2 does about 1) playing at 5512 Hz, 2) compiling
as modules together (non-modules are made to be exclusive),
3) compiling if CONFIG_PCI is not enabled, 4) has Configure.help
update.

I am not sure what to do about CONFIG_EXPERIMENTAL.
My current plan is to discard "(EXPERIMENTAL)" and forget
about it until the next case.

Ioctl 0x5401 is a mystery. I do not know what it is
(looks like SNDCTL_TMR_TIMEBASE without uppper bits).

Please send fewer attachements to the lists. Your sound fragment
is very useful, but I'd prefer to have it sent separately to me
upon a request (in uuencode :).

BTW, Legacy driver (ymf_sb) uses PC/DMA or whatever the name is,
which requires the north bridge support and, sometimes, additional
connections on the motherboard. This is not reflected in _any_
kernel documentation. I have spent numerous hours trying to make
it work on my laptop until I understood that even though my
chipset supports PC/DMA, necessary connections are missing.
At first glance, it looked as if IRQ does not come.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: YMF PCI - thanks, glitches, patches (fwd)

[Pete Zaitcev]

> Date: Wed, 6 Dec 2000 15:00:38 -0500 (EST)
> From: Pavel Roskin <[EMAIL PROTECTED]>
> To: Pete Zaitcev <[EMAIL PROTECTED]>
> Subject: Re: YMF PCI - thanks, glitches, patches (fwd)

> > > Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> > > From: Pavel Roskin <[EMAIL PROTECTED]>
> > > cc: Jaroslav Kysela <[EMAIL PROTECTED]>, Pete Zaitcev <[EMAIL PROTECTED]>,
> > > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> >
> > > The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
> >
> > I did not have a chance to look at whatever is in 2.4, but from
> > reading Linus's e-mails I understand that Jaroslav made a new
> > port, which is probably unrelated to the stuff that I hastily
> > cooked up for 2.2 (I really wanted to play Doom on my new Sony).
> 
> :-)))

I just found a message from Linus that says:

  The other change is that I forward-ported the ymfpci driver from 2.2.18,
  as it works better than the ALSA one on my now-to-be-main-laptop ;) 

(in http://boudicca.tux.org/hypermail/linux-kernel/2000week50/0200.html)

Now I know why error messages looked so familiar. :)
In other words, Jaroslav was not involved.

I'll see what Linus did and send him updates, if any.

> But please note that opl3 is not enabled by the new driver, so people do
> lose some functionality they used to have.

I'll try to understand what this is all about. Honestly,
I do not know how OPL3 works and who uses it (it's a MIDI
thing, isn't it?)

--Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch to DECODER_SET_NORM invocations

[Pete Zaitcev]

Hi,

In the recent 2.2.x I discovered that saa7xxx driver expects norm
to be an int, while struct video_channel defines it as __u16.
This bombs if video_channel has something dirty next to it
on the stack.

Only one file is touched by the patch: drivers/char/buz.c, but
some more code is related. The unofficial patch for capture on
Netwinder (drivers/char/video-cyberpro.c) is broken. The bttv.c
is not affected (it has on-chip decoder instead of saa7xxx).
Pauline's Zoran patch is not affected (is uses int).

I am expiriencing difficulties identifying the maintainer of the code.
Alan, would you look at it please?

Greetings,
--Pete

diff -ur linux-2.2.18-pre19/drivers/char/buz.c linux-2.2.18-pre19-p3/drivers/char/buz.c
--- linux-2.2.18-pre19/drivers/char/buz.c   Wed May  3 17:16:33 2000
+++ linux-2.2.18-pre19-p3/drivers/char/buz.cTue Nov  7 08:43:58 2000
@@ -2389,7 +2389,7 @@
case VIDIOCSCHAN:
{
struct video_channel v;
-   int input;
+   int input, norm;
int on, res;
 
if (copy_from_user(&v, arg, sizeof(v))) {
@@ -2421,9 +2421,10 @@
if (on)
zr36057_overlay(zr, 0);
 
+   norm = zr->params.norm;
i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_INPUT, &input);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_NORM, &zr->params.norm);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, 
ENCODER_SET_NORM, &zr->params.norm);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
+DECODER_SET_NORM, &norm);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, 
+ENCODER_SET_NORM, &norm);
 
if (on)
zr36057_overlay(zr, 1);
@@ -2781,7 +2782,7 @@
case BUZIOC_S_PARAMS:
{
struct zoran_params bp;
-   int input, on;
+   int input, on, norm;
 
if (zr->codec_mode != BUZ_MODE_IDLE) {
return -EINVAL;
@@ -2808,9 +2809,10 @@
zr36057_overlay(zr, 0);
 
input = zr->params.input == 0 ? 3 : 7;
+   norm = zr->params.norm;
i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_INPUT, &input);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_NORM, &zr->params.norm);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, 
ENCODER_SET_NORM, &zr->params.norm);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
+DECODER_SET_NORM, &norm);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, 
+ENCODER_SET_NORM, &norm);
 
if (on)
zr36057_overlay(zr, 1);
@@ -2939,8 +2941,9 @@
 
/* restore previous input and norm */
input = zr->params.input == 0 ? 3 : 7;
+   norm = zr->params.norm;
i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_INPUT, &input);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
DECODER_SET_NORM, &zr->params.norm);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, 
+DECODER_SET_NORM, &norm);
 
if (copy_to_user(arg, &bs, sizeof(bs))) {
return -EFAULT;
@@ -3252,8 +3255,9 @@
 
j = zr->params.input == 0 ? 3 : 7;
i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, DECODER_SET_INPUT, &j);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, DECODER_SET_NORM, 
&zr->params.norm);
-   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, ENCODER_SET_NORM, 
&zr->params.norm);
+   j = zr->params.norm;
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEODECODER, DECODER_SET_NORM, &j);
+   i2c_control_device(&zr->i2c, I2C_DRIVERID_VIDEOENCODER, ENCODER_SET_NORM, &j);
 
/* set individual interrupt enables (without GIRQ0)
   but don't global enable until zoran_open() */


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for YMF PCI sound cards

[Pete Zaitcev]

> Date: Fri, 8 Dec 2000 11:41:07 -0500 (EST)
> From: Pavel Roskin <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> cc: <[EMAIL PROTECTED]>, Pete Zaitcev <[EMAIL PROTECTED]>,
> Jaroslav Kysela <[EMAIL PROTECTED]>

> --- ./drivers/sound/Config.in Thu Dec  7 10:59:06 2000
> +++ ./drivers/sound/Config.in Fri Dec  8 11:25:08 2000

No problem here.

> --- ./drivers/sound/ymfpci.c  Thu Dec  7 10:59:06 2000
> +++ ./drivers/sound/ymfpci.c  Fri Dec  8 11:33:51 2000

The idea of the patch looks good but there is a small problem.
I have an open/close fix queued with Alan for post-2.2.18,
which changes the enumeration scheme for ymfcpi to make it
more friendly to other sound cards (Bug from Abhijit Menon-Sen).
This is a conflict because you use instance number to find
what card goes in first. In fact I plan to send the same
thing to Linus for 2.4 (if he have not fixed that already).

Would you please to hold on to your patch for couple of weeks
and then resync and redo it? Alternatively, I'll keep your
patch and will reapply it in the way I see sane, but you will
have to retest it before I issue it.

> --- ./drivers/sound/ac97_codec.c  Thu Dec  7 10:59:06 2000
> +++ ./drivers/sound/ac97_codec.c  Thu Dec  7 11:00:44 2000
> @@ -61,6 +61,7 @@
>  } ac97_codec_ids[] = {
>   {0x414B4D00, "Asahi Kasei AK4540 rev 0", NULL},
>   {0x414B4D01, "Asahi Kasei AK4540 rev 1", NULL},
> + {0x41445303, "Yamaha YMF"  , NULL},

Are you sure it's correct? I am almost certain that no YMFxxx
has on-chip AC97. I'd like to see a document that allows you
the change quoted above.

--Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch for ymfpci in test12-pre7

[Pete Zaitcev]

Hi, Linus:

The attached patch fixes the following problems with ymfpci in 2.4 tree:

1. Enumeration was wrong, this bit people with several soundcards
   (Abhijit Menon-Sen).
2. Must use semaphore to guard open/close.
3. Old ymfpci locks up if compiled with CONFIG_SMP due to
   recursive calls to spin_lock_irqsave().
4. Endianness buglet with ''rev'' (same as in ALSA).

Also, The patch removes P3 tagged messages that I do not
anticipate to use soon.

More improvements are in my queue (bugs from Pavel Roskin,
Simon Higgins, etc.), which I would like to put in later.

Thanks in advance,
--Pete

--- linux-2.4.0-pre12-test7/drivers/sound/ymfpci.h  Fri Dec  8 22:45:29 2000
+++ linux-2.4.0-test12-pre7-p3/drivers/sound/ymfpci.h   Sat Dec  9 23:36:14 2000
@@ -247,7 +247,7 @@
 };
 
 struct ymf_unit {
-   unsigned int rev;   /* PCI revision */
+   u8 rev; /* PCI revision */
void *reg_area_virt;
void *work_ptr; // +
 
@@ -275,13 +275,13 @@
u16 ac97_features;
 
struct pci_dev *pci;
-   int inst;   /* Unit number (instance) */
 
spinlock_t reg_lock;
spinlock_t voice_lock;
 
/* soundcore stuff */
int dev_audio;
+   struct semaphore open_sem;
 
struct list_head ymf_devs;
struct ymf_state *states[1];// *
@@ -331,10 +331,6 @@
 
 struct ymf_state {
struct ymf_unit *unit;  /* backpointer */
-
-   /* single open lock mechanism, only used for recording */
-   struct semaphore open_sem;
-   wait_queue_head_t open_wait;
 
/* virtual channel number */
int virt;   // * unused a.t.m.
--- linux-2.4.0-pre12-test7/drivers/sound/ymfpci.c  Fri Dec  8 22:45:29 2000
+++ linux-2.4.0-test12-pre7-p3/drivers/sound/ymfpci.c   Sun Dec 10 12:55:35 2000
@@ -32,6 +32,9 @@
  *  ? merge ymf_pcm and state
  *  ? pcm interrupt no pointer
  *  ? underused structure members
+ *  - Remove remaining P3 tags (debug messages).
+ *  - Resolve XXX tagged questions.
+ *  - Cannot play 5133Hz.
  */
 
 #include 
@@ -59,7 +62,7 @@
 int pair, ymfpci_voice_t **rvoice);
 static int ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
 static int ymf_playback_prepare(ymfpci_t *codec, struct ymf_state *state);
-static int ymf_state_alloc(ymfpci_t *unit, int nvirt, int instance);
+static int ymf_state_alloc(ymfpci_t *unit, int nvirt);
 
 static LIST_HEAD(ymf_devs);
 
@@ -602,11 +605,9 @@
char silence;
 
if ((ypcm = voice->ypcm) == NULL) {
-/* P3 */ printk("ymf_pcm_interrupt: voice %d: no ypcm\n", voice->number);
return;
}
if ((state = ypcm->state) == NULL) {
-/* P3 */ printk("ymf_pcm_interrupt: voice %d: no state\n", voice->number);
ypcm->running = 0;  // lock it
return;
}
@@ -628,7 +629,7 @@
if (pos < 0 || pos >= dmabuf->dmasize) {/* ucode bug */
printk(KERN_ERR
"ymfpci%d: %d: runaway: hwptr %d dmasize %d\n",
-   codec->inst, voice->number,
+   codec->dev_audio, voice->number,
dmabuf->hwptr, dmabuf->dmasize);
pos = 0;
}
@@ -645,7 +646,7 @@
 
if (dmabuf->count == 0) {
printk("ymfpci%d: %d: strain: hwptr %d\n",
-   codec->inst, voice->number, dmabuf->hwptr);
+   codec->dev_audio, voice->number, dmabuf->hwptr);
ymf_playback_trigger(codec, ypcm, 0);
}
 
@@ -664,7 +665,7 @@
 */
printk("ymfpci%d: %d: lost: delta %d"
" hwptr %d swptr %d distance %d count %d\n",
-   codec->inst, voice->number, delta,
+   codec->dev_audio, voice->number, delta,
dmabuf->hwptr, swptr, distance, dmabuf->count);
} else {
/*
@@ -672,7 +673,7 @@
 */
 // printk("ymfpci%d: %d: done: delta %d"
 // " hwptr %d swptr %d distance %d count %d\n",
-// codec->inst, voice->number, delta,
+// codec->dev_audio, voice->number, delta,
 // dmabuf->hwptr, swptr, distance, dmabuf->count);
}
played = dmabuf->count;
@@ -738,7 +739,6 @@
 {
 
if (ypcm->voices[0] == NULL) {
-/* P3 */ printk("ymfpci: trigger %d no voice\n", cmd);
return -EINVAL;
}
if (cmd != 0) {
@@ -911,7 +911,7 @@
if ((err = ymfp

Re: test1[12] + sparc + bind 9.1.0b1 == bad things

[Pete Zaitcev]

> Is this the first OOPS it prints out? I don't think so. I am 
> very sure it printed out messages from die_if_kernel first and 
> we need that initial OOPS to diagnose this bug and fix it. 
> 
> All the rest of the OOPS messages are useless and won't tell 
> us what the real problem is. 

> Later, 
> David S. Miller 

Bad news about recursive Oops is that too often the system
cannot continue and oopsen never reach /var/log/messages.

This problem was so common on sparc(32) that I run all my
kernels with the attached patch. I think an application
of a similar change should be mandatory if you are insterested
in any sort of debugging.

The alternative is to use a serial console, captured at all times.

--Pete

diff -u -r1.63 traps.c
--- arch/sparc/kernel/traps.c   2000/06/04 06:23:52 1.63
+++ arch/sparc/kernel/traps.c   2000/06/26 18:19:10
@@ -114,18 +116,23 @@
 * bound in case our stack is trashed and we loop.
 */
while(rw&&
- count++ < 30  &&
+ count++ < 10  && /* P3 30 */
   (((unsigned long) rw) >= PAGE_OFFSET)&&
  !(((unsigned long) rw) & 0x7)) {
printk("Caller[%08lx]\n", rw->ins[7]);
rw = (struct reg_window *)rw->ins[6];
}
}
+#if 0
printk("Instruction DUMP:");
instruction_dump ((unsigned long *) regs->pc);
if(regs->psr & PSR_PS)
do_exit(SIGKILL);
do_exit(SIGSEGV);
+#else
+   printk("Looping...");
+   for (;;) { }
+#endif
 }
 
 void do_hw_interrupt(unsigned long type, unsigned long psr, unsigned long pc)
Index: arch/sparc/mm/fault.c
===
RCS file: /vger-cvs/linux/arch/sparc/mm/fault.c,v
retrieving revision 1.116
diff -u -r1.116 fault.c
--- arch/sparc/mm/fault.c   2000/05/03 06:37:03 1.116
+++ arch/sparc/mm/fault.c   2000/06/26 18:19:11
@@ -146,11 +146,15 @@
printk(KERN_ALERT "Unable to handle kernel paging request "
"at virtual address %08lx\n", address);
}
+   if (tsk->active_mm == NULL) {
+   printk(KERN_ALERT "tsk->active_mm = NULL\n");
+   } else {
printk(KERN_ALERT "tsk->{mm,active_mm}->context = %08lx\n",
(tsk->mm ? tsk->mm->context : tsk->active_mm->context));
printk(KERN_ALERT "tsk->{mm,active_mm}->pgd = %08lx\n",
(tsk->mm ? (unsigned long) tsk->mm->pgd :
(unsigned long) tsk->active_mm->pgd));
+   }
die_if_kernel("Oops", regs);
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to write patches

[Pete Zaitcev]

Jeff's descriprion is very informative, but his emphasis
is somewhat different from what I find difficult with patches.
First, for the life of me I was unable to remeber which
argument goes first (DaveM was mad every time). Second, I kept
forgetting to keep the base tree a diff against that instead of
the latest tree.

So, here is the patch release cycle in my view, with all
small details.

1. I pick a "base" tree which I will hack on. Suppose that
we start with 2.2.17-pre22. So, I download linux-2.2.16.tar.bz2
from Linus place and patch-pre22.bz2 from Alan's place.
THESE MUST BE SAVED after I unpack them.

2. I unpack. Note that I have base release in the directory name.

bzip -d < linux-2.2.16.tar.bz2| tar xf -
mv linux linux-2.2.17-pre22
bzip -d < patch-pre22.bz2| patch -d linux-2.2.17-pre22 -p1

3. One way or another, I make two trees, one of which is "base"
and another is "work".

mkdir linux-2.2.17-pre22-p3
(cd linux-2.2.17-pre22 && tar cf - .)| (cd linux-2.2.17-pre22-p3 && tar xf -)

4. Hack

cd linux-2.2.17-pre22-p3
make oldconfig
(make dep && make bzImage) > build.out 2>&1
... etc.

The step #4 will take some time, and kernel will get developed
while we sit on it. Normally it takes me anywhere from 3 weeks
to 3 months to come up with something useable.

5. Time to diff and submit, but Oops, Linus published 2.2.17!
Now you will see how it all REALLY works.

5a. Unpack

bzip -d < linux-2.2.17.tar.bz2| tar xf -
mv linux linux-2.2.17

6. Diff your base tree and your changed tree. Do not settle
for .orig files! Diff whole thing!

6a. Get dontdiff from Tigran, it's helpful
wget http://www.moses.uklinux.net/patches/dontdiff

6b. Diff, but notice the argument order!!

diff -urN --exclude-from=dontdiff \
  linux-2.2.17-pre22 linux-2.2.17-pre22-p3 > linux-2.2.17-pre22-p3.diff

6c. In most cases you need to remove junk from your diff,
even with dontdiff.

7. Apply your diff to the new tree (remember,
never touch the base tree):

mkdir linux-2.2.17-p3
(cd linux-2.2.17 && tar cf - .)| (cd linux-2.2.17-p3 && tar xf -)
patch -d linux-2.2.17-p3 -p1 < linux-2.2.17-pre22-p3.diff

If I am lucky, my patch applies cleanly or with a small
fuzz factor. But otherwise there may be a conflict that I
shall resolve by hand:

find linux-2.2.17-p3 -name '*.rej'
# perhaps  cat something.rej >> something && vi something

This part is actually important. If I sent linux-2.2.17-pre22-p3.diff
to Alan, he would try to apply it against then-current 2.2.17
(if not 2.2.18-pre2), get the same conflict, and dump the patch
into the void. Always resolve yourself, do not ride the maintainer.

8. Now I can send the patch to Alan and wait.

9. Once my patch is tentatively applied, say, in 2.2.18-pre2,
I re-download it, and do the whole thing again to make sure
that it was applied right. Alan has a habit of editing patches
on the fly, so I must keep tabs on it.

10. By this time 2.2.17-pre22 base are obsolete so we may
delete them (but evacuate good .config first or you'd start
from defconfig again):

cp linux-2.2.17-pre22-p3/.config linux-2.2.18-pre3/
rm -rf linux-2.2.17-pre22 linux-2.2.17-pre22-p3
# Sometimes I keep linux-2.2.17-pre22-p3.diff a little longer
# after the base moved on, for the sake of slower paced collegues.

And the ball just keeps rolling.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SparcLinux on Sun E10000

[Pete Zaitcev]

Is it a coincidence that E1 is officially declared obsolete today?
Sun never allows us to use the latest and greatest hardware.

--Pete

> Date: Wed, 27 Sep 2000 17:28:49 +1100
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> From: Anton Blanchard <[EMAIL PROTECTED]>

> Patches for Sun E1 are in the current vger cvs, details for accessing
> this can be found at . You too can have a linux box
> that compiles kernels in 20 seconds.
> 
> I have set up some information at:
> 
> 
> 
> Thanks to Craig Armour <[EMAIL PROTECTED]>, Tony Jago
> <[EMAIL PROTECTED]> and Mark Suter <[EMAIL PROTECTED]> from the
> University of Queensland for arranging access to such a machine.
>[...]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Q. about oops backtrace

[Pete Zaitcev]

Hello:

I was investigating an oops and the trace looked like this:

>>EIP; c01c54a9<=
Trace; c01c3654 
Trace; c01c0f0f 
Trace; c015e7e2 
Trace; c01155a6 
Trace; c01272a9 
Trace; c0127414 
Trace; c0136a2d 
Trace; c012722e 
Trace; c0127290 
Trace; c0127414 
Trace; c014cdec 
Trace; c0143f80 
Trace; c0144aae 
Trace; c014cdec 
Trace; c01392c9 
Trace; c0138130 
Trace; c013805d 
Trace; c0148b97 
Trace; c01091c7 

What is with those recursive handle_mm_fault calls?
That does not look quite right. I _assume_ that the
stack would collapse properly upon return, but still...
I would appreciate a suggestion about what .S file to read
for the explanation.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

[Pete Zaitcev]

> Date: Fri, 09 Mar 2001 10:29:22 -0800
> From: David Brownell <[EMAIL PROTECTED]>

> > > extern void *
> > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > 
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
> 
> Some hardware (like OHCI) talks to drivers using those dma handles.

I wonder if it may be feasible to allocate a bunch of contiguous
pages. Then, whenever the hardware returns a bus address, subtract
the remembered bus address of the zone start, add the offset to
the virtual and voila.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

[Pete Zaitcev]

> Date: Fri, 09 Mar 2001 13:14:03 -0800
> From: David Brownell <[EMAIL PROTECTED]>

>[...]
> It feels to me like you're being inconsistent here, objecting
> to a library API for some functionality (mapping) yet not for
> any of the other functionality (alignment, small size, poisoning
> and so on).  And yet when Pete Zaitcev described what that
> mapping code actually involved, you didn't object.  So you've
> succeeded in confusing me.  Care to unconfuse?

I did not propose an API or library which would be equal amond equals
with first rate citizens of pci_alloc_xxx and friends. I pointed out
that driver can do tracking of reverse mappings at very little cost
by using offset [Alan remarked to that how hash can use page number];
so, one may say that I supported DaveM's viewpoint. No wonder he did
not object.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fix to khubd oops, hellooo?

[Pete Zaitcev]

Is my fix to khubd going anywhere? Randy, David?
I have an actual, reproducible bug that I need to close.
Here's my message to linux-usb-devel with explanations:
  http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98411157628404&w=2

-- Pete

diff -ur -X ../dontdiff linux-2.4.2-ac12/drivers/usb/hub.c 
linux-2.4.2-ac12-p3/drivers/usb/hub.c
--- linux-2.4.2-ac12/drivers/usb/hub.c  Wed Mar  7 12:17:02 2001
+++ linux-2.4.2-ac12-p3/drivers/usb/hub.c   Thu Mar  8 19:43:14 2001
@@ -357,6 +357,7 @@
 
INIT_LIST_HEAD(&hub->event_list);
hub->dev = dev;
+   init_MUTEX(&hub->khubd_sem);
 
/* Record the new hub's existence */
spin_lock_irqsave(&hub_event_lock, flags);
@@ -400,6 +399,9 @@
 
spin_unlock_irqrestore(&hub_event_lock, flags);
 
+   down(&hub->khubd_sem);  /* Wait for khubd to leave this hub alone. */
+   up(&hub->khubd_sem);
+
if (hub->urb) {
usb_unlink_urb(hub->urb);
usb_free_urb(hub->urb);
@@ -709,7 +717,7 @@
spin_lock_irqsave(&hub_event_lock, flags);
 
if (list_empty(&hub_event_list))
-   goto he_unlock;
+   break;
 
/* Grab the next entry from the beginning of the list */
tmp = hub_event_list.next;
@@ -720,6 +728,7 @@
list_del(tmp);
INIT_LIST_HEAD(tmp);
 
+   down(&hub->khubd_sem);  /* never blocks, we were on list */
spin_unlock_irqrestore(&hub_event_lock, flags);
 
if (hub->error) {
@@ -728,6 +737,7 @@
if (usb_hub_reset(hub)) {
err("error resetting hub %d - disconnecting", 
dev->devnum);
usb_hub_disconnect(dev);
+   up(&hub->khubd_sem);
continue;
}
 
@@ -742,6 +752,7 @@
ret = usb_get_port_status(dev, i + 1, &portsts);
if (ret < 0) {
err("get_port_status failed (err = %d)", ret);
+   up(&hub->khubd_sem);
continue;
}
 
@@ -803,9 +814,9 @@
usb_hub_power_on(hub);
}
}
+   up(&hub->khubd_sem);
 } /* end while (1) */
 
-he_unlock:
spin_unlock_irqrestore(&hub_event_lock, flags);
 }
 
diff -ur -X ../dontdiff linux-2.4.2-ac12/drivers/usb/hub.h 
linux-2.4.2-ac12-p3/drivers/usb/hub.h
--- linux-2.4.2-ac12/drivers/usb/hub.h  Wed Mar  7 12:17:02 2001
+++ linux-2.4.2-ac12-p3/drivers/usb/hub.h   Thu Mar  8 19:17:38 2001
@@ -134,6 +134,8 @@
struct list_head event_list;
 
struct usb_hub_descriptor *descriptor;
+
+   struct semaphore khubd_sem;
 };
 
 #endif /* __LINUX_HUB_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scsi_scan problem.

[Pete Zaitcev]

> Date: Wed, 14 Mar 2001 21:28:14 -0500
> From: Doug Ledford <[EMAIL PROTECTED]>
 
> A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> sees multiple identical luns in different scenarios) was not a bug in the
> qla2x00 driver.  [...]
>  The bug is that we were detecting offline devices and linking
> them into the device list.

Why is this a bug? What would happen when I telnet into the
the RAID box and enable my volumes on those LUNs?

>  But, some devices (at least the Clariion raid
> chassis) report luns that don't currently have any device bound to them as
> present but offline.  This meant if we truly scanned all luns then we got
> something like 100+ devices on one ID from this chassis when only 1 might be
> valid:-(

16384 LUNs for Fibre Channel. As you see, scanning is out of the
question. You must issue REPORT LUNs and fall back on scanning
if the device reports a check condition. I did that when I worked
in Sun Storage with A5000/A3500/T3 arrays couple of years ago.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine

[Pete Zaitcev]

> From: Andree Leidenfrost ([EMAIL PROTECTED])

> I am experiencing problems with a USB mouse: The machine boots, X 
> starts, I log on, everything works as expected. When I restart X or just 
> change to an alpha terminal and back to x the mouse does not work any 
> more.  [...]
> Hardware is an ASUS K7V motherboard (VIA chip set), [...]
> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 

I am working on something similar. 
After a device reset a hub drops PORT_CONNECTION
flag from wPortStatus. The reason is unknown.

Unfortunately, I do not have a hardware that exibits this.
If would be invaluable someone enabled
dbg() in devices/usb/hub.c only, run the test with
BOTH working (2.2) and not working (2.4) kernels
then sent me dmesg. If you do, please tell me precisely what
you were doing to trip this.

Here is an example of a change:

--- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001
+++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Tue Mar 13 13:49:32 2001
@@ -29,6 +29,10 @@

 #include "hub.h"

+/* P3 #23670 run01 */
+#undef dbg
+#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg)
+
 /* Wakes up khubd */
 static spinlock_t hub_event_lock = SPIN_LOCK_UNLOCKED;
 static DECLARE_MUTEX(usb_address0_sem);

Example output of broken kernel:

ub.c: enabling power on all ports
hub.c: port 1 connection change
hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x458/0x3) is not claimed by any active driver.
usb.c: registered new driver hid
input0: USB HID v1.00 Mouse [KYE Genius USB Wheel Mouse] on usb1:2.0
mouse0: PS/2 mouse device for input0
mice: PS/2 mouse device common for all mice
  [ok, works, pulling the cable]
hub.c: port 1 connection change
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
usb.c: USB disconnect on device 2
hub.c: port 1 enable change, status 100
  [cable pulled, putting it back]
hub.c: port 1 connection change
hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s
hub.c: port 1, portstatus 100, change 0, 12 Mb/s
hub.c: port 1 of hub 1 not enabled, trying reset again...
hub.c: port 1, portstatus 100, change 0, 12 Mb/s
hub.c: port 1 of hub 1 not enabled, trying reset again...
hub.c: port 1, portstatus 100, change 0, 12 Mb/s
hub.c: port 1 of hub 1 not enabled, trying reset again...
hub.c: port 1, portstatus 100, change 0, 12 Mb/s
hub.c: port 1 of hub 1 not enabled, trying reset again...
hub.c: port 1, portstatus 100, change 0, 12 Mb/s
hub.c: port 1 of hub 1 not enabled, trying reset again...
hub.c: Cannot enable port 1 of hub 1, disabling port.
hub.c: Maybe the USB cable is bad?

Now I need something like that for a working kernel
on the same hardware.

I'll let folks know if I find anything. If anyone wants
to investigate in parallel, it would be appreciated too.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine

[Pete Zaitcev]

> From: Andree Leidenfrost <[EMAIL PROTECTED]>
> To: Pete Zaitcev <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: 18 Mar 2001 22:50:32 +1100
> 
> > > I am experiencing problems with a USB mouse: The machine boots, X 
> > > starts, I log on, everything works as expected. When I restart X or just 
> > > change to an alpha terminal and back to x the mouse does not work any 
> > > more.  [...]
> > > Hardware is an ASUS K7V motherboard (VIA chip set), [...]
> > > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 

> > Unfortunately, I do not have a hardware that exibits this.
> > If would be invaluable someone enabled
> > dbg() in devices/usb/hub.c only, [...]

> >   [cable pulled, putting it back]
> > hub.c: port 1 connection change
> > hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s
> > hub.c: port 1, portstatus 100, change 0, 12 Mb/s
> > hub.c: port 1 of hub 1 not enabled, trying reset again...

> Here is the output of a 2.2.18 kernel with the above patch:
> 
>   [cable pulled, putting it back]
> Mar 18 22:41:53 aurich kernel: hub.c: port 3 connection change
> Mar 18 22:41:53 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s
> Mar 18 22:41:54 aurich kernel: hub.c: portstatus 303, change 10, 1.5 Mb/s

The following patch reverts the code path to that of 2.2 and fixes
the condition on the Andree's box:

--- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001
+++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Mon Mar 19 12:03:42 2001
@@ -583,6 +583,12 @@
return;
}
 
+   /* zaitcev RHbug #23670 - 1.5Mb/s mice die when switching VCs */
+   if (portstatus & USB_PORT_STAT_LOW_SPEED) {
+   wait_ms(400);
+   delay = HUB_LONG_RESET_TIME;
+   }
+
down(&usb_address0_sem);
 
tempstr = kmalloc(1024, GFP_KERNEL);

I asked USB maintainers to consider it.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Some strange patch to drivers/input/keybdev.c

[Pete Zaitcev]

Some guy sent me the attached patch. He says it allows
him to use 2 additional keys on the 106 key USB keyboard.
I never saw a 106 key keyboard before, USB or not.
Does anyone understand what is going on? Vojtech?

-- Pete

--- drivers/input/keybdev.c.orig  Sat Sep  2 19:01:55 2000
+++ drivers/input/keybdev.c   Sat Sep  2 20:21:07 2000
@@ -49,11 +49,11 @@
 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
 80, 81, 82, 83, 43, 85, 86, 87, 88,115,119,120,121,375,123, 90,
284,285,309,298,312, 91,327,328,329,331,333,335,336,337,338,339,
-   367,294,293,286,350, 92,334,512,116,377,109,111,373,347,348,349,
+   367,294,293,286,350, 92,334,512,116,377,109,111,115,347,348,349,
360, 93, 94, 95, 98,376,100,101,357,316,354,304,289,102,351,355,
103,104,105,275,281,272,306,106,274,107,288,364,358,363,362,361,
291,108,381,290,287,292,279,305,280, 99,112,257,258,113,270,114,
-   118,117,125,374,379,259,260,261,262,263,264,265,266,267,268,269,
+   118,117,125,374,125,259,260,261,262,263,264,265,266,267,268,269,
271,273,276,277,278,282,283,295,296,297,299,300,301,302,303,307,
308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Please review patchlet for ov511 (2.4.2-ac19)

[Pete Zaitcev]

Here is the deal:

we have a guy here with a webcam and the following scenario:
1. ov511 disconnects, everything dies/releases/closes fine,
2. webcam soft starts polling open/sleep/open/sleep/...
3. ov511_probe works and reaches ov511_configure,
   calls video_register_device().
4. Webcam software opens and oopses on the semafore
   that was not initialized yet.

I think video_register_device needs to be done last, when
everything else is ready to accept appliction requests.

Someone please review. The error handling style
of ov511 spins my head. I may be missing a code path somewhere.

Thanks in advance,
-- Pete

--- linux-2.4.2-ac19/drivers/usb/ov511.cThu Jan  4 13:15:32 2001
+++ linux-2.4.2-ac19-p3/drivers/usb/ov511.c Thu Mar 22 19:55:59 2001
@@ -3141,11 +3141,6 @@
 
init_waitqueue_head(&ov511->wq);
 
-   if (video_register_device(&ov511->vdev, VFL_TYPE_GRABBER) < 0) {
-   err("video_register_device failed");
-   return -EBUSY;
-   }
-
if (ov511_write_regvals(dev, aRegvalsInit)) goto error;
if (ov511_write_regvals(dev, aRegvalsNorm511)) goto error;
 
@@ -3214,7 +3209,6 @@
return 0;

 error:
-   video_unregister_device(&ov511->vdev);
usb_driver_release_interface(&ov511_driver,
&dev->actconfig->interface[ov511->iface]);
 
@@ -3323,6 +3317,11 @@
ov511->buf_state = BUF_NOT_ALLOCATED;
} else {
err("Failed to configure camera");
+   goto error;
+   }
+
+   if (video_register_device(&ov511->vdev, VFL_TYPE_GRABBER) < 0) {
+   err("video_register_device failed");
goto error;
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Possible patch for Dell keyboard lockup

[Pete Zaitcev]

Hello, All:

I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event. Which we do not (in case
a USB mouse is used, for instance).

I may do what BIOS ought to do upon suspend, but it
does not feel right. So... do we need anything like that?
If yes, I may polish it up w.r.t. non-x86 etc.

-- Pete

diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/keyboard.c 
linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c
--- linux-2.4.2-0.1.32/drivers/char/keyboard.c  Mon Mar 26 16:59:28 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c   Wed Mar 28 15:33:47 2001
@@ -162,6 +162,14 @@
 
 static struct pm_dev *pm_kbd;
 
+static int pm_kbd_request(struct pm_dev *dev, pm_request_t req, void *data)
+{
+   if (req == PM_RESUME) {
+   kbd_pm_resume();
+   }
+   return 0;
+}
+
 /*
  * Many other routines do put_queue, but I think either
  * they produce ASCII, or they produce some user-assigned
@@ -934,7 +942,7 @@
tasklet_enable(&keyboard_tasklet);
tasklet_schedule(&keyboard_tasklet);

-   pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, NULL);
+   pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, pm_kbd_request);
 
return 0;
 }
diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/pc_keyb.c 
linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.c
--- linux-2.4.2-0.1.32/drivers/char/pc_keyb.c   Mon Mar 26 17:00:03 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.cWed Mar 28 15:41:06 2001
@@ -530,6 +530,31 @@
}
 }
 
+void pckbd_pm_resume(void)
+{
+   unsigned int flags;
+
+/* P3 */ printk("pckbd_pm_resume: queue %p aux_count %d\n", queue, aux_count);
+   if (queue) {/* Aux port detected */
+   if (aux_count == 0) {   /* Mouse not in use */
+   spin_lock_irqsave(&kbd_controller_lock, flags);
+   /*
+* Dell Lat. C600 A06 enables mouse after resume.
+* When user touches the pad, it posts IRQ 12
+* (which we do not process), thus holding keyboard.
+*/
+   kbd_write_command(KBD_CCMD_MOUSE_DISABLE);
+   /* kbd_write_cmd(AUX_INTS_OFF); */ /* Config & lock */
+   kb_wait();
+   kbd_write_command(KBD_CCMD_WRITE_MODE);
+   kb_wait();
+   kbd_write_output(AUX_INTS_OFF);
+   spin_unlock_irqrestore(&kbd_controller_lock, flags);
+/* P3 */ printk("pckbd_pm_resume: done\n");
+   }
+   }
+}
+
 /*
  * In case we run on a non-x86 hardware we need to initialize both the
  * keyboard controller and the keyboard.  On a x86, the BIOS will
diff -ur -X dontdiff linux-2.4.2-0.1.32/include/asm-i386/keyboard.h 
linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h
--- linux-2.4.2-0.1.32/include/asm-i386/keyboard.h  Wed Feb 21 19:11:45 2001
+++ linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h   Wed Mar 28 15:11:13 2001
@@ -26,6 +26,7 @@
   char raw_mode);
 extern char pckbd_unexpected_up(unsigned char keycode);
 extern void pckbd_leds(unsigned char leds);
+extern void pckbd_pm_resume(void);
 extern void pckbd_init_hw(void);
 extern unsigned char pckbd_sysrq_xlate[128];
 
@@ -34,6 +35,7 @@
 #define kbd_translate  pckbd_translate
 #define kbd_unexpected_up  pckbd_unexpected_up
 #define kbd_leds   pckbd_leds
+#define kbd_pm_resume  pckbd_pm_resume
 #define kbd_init_hwpckbd_init_hw
 #define kbd_sysrq_xlatepckbd_sysrq_xlate
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in uhci.c running 2.4.2-ac28

[Pete Zaitcev]

> Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
> From: Ketil Froyn <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>

> While running kernel 2.4.2-ac28, I switched on spinlock debugging and
> verbose BUG() reporting (I always use sysrq). Anyway, while running this I
> got an oops after about 2 or 3 minutes running, several times, exact same
> place each time, which I traced back to rh_int_timer_do().
> This was in uhci.c (I used CONFIG_USB_UHCI_ALT).  [...]  I
> recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get
> the oops any more.

I am behind usb-uhci for a reason. Alan bounced your report
to me but I do not see a case for action...

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

patchlet for cs46xx

[Pete Zaitcev]

Sorry for the nitpicking, bust since 2.4 is now "stable"...
-- Pete

diff -ur -X dontdiff linux-2.4.0-ac9/drivers/sound/cs46xx.c 
linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c
--- linux-2.4.0-ac9/drivers/sound/cs46xx.c  Sun Jan 14 15:27:58 2001
+++ linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c   Wed Jan 24 21:28:30 2001
@@ -2726,7 +2726,7 @@
cinfo.blocks = dmabuf->count/dmabuf->divisor >> 
dmabuf->fragshift;
cinfo.ptr = dmabuf->hwptr/dmabuf->divisor;
spin_unlock_irqrestore(&state->card->lock, flags);
-   return copy_to_user((void *)arg, &cinfo, sizeof(cinfo));
+   return copy_to_user((void *)arg, &cinfo, sizeof(cinfo)) ? 
+-EFAULT : 0;
}
return -ENODEV;
 
@@ -2757,7 +2757,7 @@
"cs46xx: GETOPTR bytes=%d blocks=%d ptr=%d\n",
cinfo.bytes,cinfo.blocks,cinfo.ptr) );
spin_unlock_irqrestore(&state->card->lock, flags);
-   return copy_to_user((void *)arg, &cinfo, sizeof(cinfo));
+   return copy_to_user((void *)arg, &cinfo, sizeof(cinfo)) ? 
+-EFAULT : 0;
}
return -ENODEV;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch to run IrDA with no modules in 2.4.x

[Pete Zaitcev]

A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.

-- Pete

diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c 
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat Nov 11 18:11:23 2000
+++ linux-2.4.1-pre11-p3/net/irda/af_irda.c Sun Jan 28 21:31:16 2001
@@ -2409,6 +2409,7 @@
 #endif
return 0;
 }
+module_init(irda_proto_init);
 
 /*
  * Function irda_proto_cleanup (void)
@@ -2429,11 +2430,9 @@

 return;
 }
-module_init(irda_proto_init);
 module_exit(irda_proto_cleanup);
  
 MODULE_AUTHOR("Dag Brattli <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("The Linux IrDA Protocol Subsystem"); 
 MODULE_PARM(irda_debug, "1l");
 #endif /* MODULE */
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Maxwell strikes the heart (ECN: Clearing the air)

[Pete Zaitcev]

> From: Gregory Maxwell ([EMAIL PROTECTED])
> Date: Sun Jan 28 2001 - 14:42:04 EST 
> 
> On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote: 
> > > There is nothing silly with the decision, davem is simply a modern day 
> > > internet hero. 
> > 
> > No. If it were something essential, perhaps, but it's just a minor 
> > performance tweak to cut packet loss over congested links. It's not 
> > IPv6. It's not PMTU. It's not even very useful right now! 
> 
> No. ECN is essential to the continued stability of the Internet. Without 
> probabilistic queuing (i.e. RED) and ECN the Internet will continue to have 
> retransmit synchronization and once congested stay congested until people get 
> frustrated and give it up for a little bit. 
> 
> It's a real issue, and it's actually important to have it implemented. It's 
> not just a performance hack. 

I always "knew" that the stability of the Internet is secured by the
exponential backoff in TCP. A small packet loss on uncongested links
is a part of this technique, and it existed long before ATM studies
produced RED (which infiltrated backwards). It also requires sending
stacks to "give up for a little bit" (actually to give up a lot, and
together with the slow start it produced the well known "saw" of the
window size).

So far I fail to see how a repainted NAK, kludged into a NAKless protocol,
would improve stability of the Internet. If anything, it is going to
exaggerate traffic oscillations. I would appreciate couple of links
to reputable studies or discussions on the subject.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Ymfpci 724

[Pete Zaitcev]

> From: Simon Cahuk ([EMAIL PROTECTED])
> Date: Tue Jan 30 2001 - 14:22:26 EST 
> 
> I have a ymfpci sound chip on my motherboard. I'm using ymfpci module. 
> Under Q3A I get this: 
> sound inilializations: 
> Sorry but your soundcard can't do this 

Probably an mmap-ed sound problem or some ioctl is not implemented.
Q3A is on my YMF list, behind power management. Please feel free
to investigate it yourself and send any patches.

Another thing that you can do is to try to use ALSA. I think
that ALSA driver is superior for most cases because
my ymfpci code is based on Jaroslav's ALSA code and
will be replaced by ALSA eventually.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch for ymfpci and xmms

[Pete Zaitcev]

Courtesy of Manish Singh, little bit extended
(I hope I did not break it too badly).
Supposedly it fixes bad skipping with xmms.

-- Pete

diff -ur -X dontdiff linux-2.4.1/drivers/sound/ymfpci.c 
linux-2.4.1-p3/drivers/sound/ymfpci.c
--- linux-2.4.1/drivers/sound/ymfpci.c  Fri Jan 26 23:31:16 2001
+++ linux-2.4.1-p3/drivers/sound/ymfpci.c   Thu Feb  8 11:29:45 2001
@@ -370,16 +370,14 @@
 
/*
 * Create fake fragment sizes and numbers for OSS ioctls.
+* Import what Doom might have set with SNDCTL_DSP_SETFRAGMENT.
 */
bufsize = PAGE_SIZE << dmabuf->buforder;
-   if (dmabuf->ossfragshift) {
-   if ((1000 << dmabuf->ossfragshift) < bytepersec)
-   dmabuf->fragshift = ld2(bytepersec/1000);
-   else
-   dmabuf->fragshift = dmabuf->ossfragshift;
-   } else {
-   /* lets hand out reasonable big ass buffers by default */
-   dmabuf->fragshift = (dmabuf->buforder + PAGE_SHIFT -2);
+   /* lets hand out reasonable big ass buffers by default */
+   dmabuf->fragshift = (dmabuf->buforder + PAGE_SHIFT -2);
+   if (dmabuf->ossfragshift > 3 &&
+   dmabuf->ossfragshift < dmabuf->fragshift) {
+   dmabuf->fragshift = dmabuf->ossfragshift;
}
dmabuf->numfrag = bufsize >> dmabuf->fragshift;
while (dmabuf->numfrag < 4 && dmabuf->fragshift > 3) {
@@ -389,9 +387,6 @@
dmabuf->fragsize = 1 << dmabuf->fragshift;
dmabuf->dmasize = dmabuf->numfrag << dmabuf->fragshift;
 
-   /*
-* Import what Doom might have set with SNDCTL_DSD_SETFRAGMENT.
-*/
if (dmabuf->ossmaxfrags >= 2 && dmabuf->ossmaxfrags < dmabuf->numfrag) {   
 dmabuf->numfrag = dmabuf->ossmaxfrags;
dmabuf->dmasize = dmabuf->numfrag << dmabuf->fragshift;
@@ -1718,21 +1713,13 @@
case SNDCTL_DSP_SETFRAGMENT:
if (get_user(val, (int *)arg))
return -EFAULT;
-   /* P3: these frags are for Doom. Amasingly, it sets [2,2**11]. */
-   /* P3 */ // printk("ymfpci: ioctl SNDCTL_DSP_SETFRAGMENT 0x%x\n", val);
-
dmabuf = &state->wpcm.dmabuf;
dmabuf->ossfragshift = val & 0x;
dmabuf->ossmaxfrags = (val >> 16) & 0x;
-   switch (dmabuf->ossmaxfrags) {
-   case 1:
-   dmabuf->ossfragshift = 12;
-   return 0;
-   default:
-   /* Fragments must be 2K long */
-   dmabuf->ossfragshift = 11;
-   dmabuf->ossmaxfrags = 2;
-   }
+   if (dmabuf->ossfragshift < 4)
+   dmabuf->ossfragshift = 4;
+   if (dmabuf->ossfragshift > 15)
+   dmabuf->ossfragshift = 15;
return 0;
 
case SNDCTL_DSP_GETOSPACE:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] RCU in kernel/intermodule.c

[Pete Zaitcev]

On Sat, 02 Apr 2005 11:28:12 + Luca Falavigna <[EMAIL PROTECTED]> wrote:

> This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
> intermodule functions.

This sounds like a pure and unmitigated insanity to me. Please tell us
why in the world you wanted to do this.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.30: pwc pwc_isoc_handler() called with status -84

[Pete Zaitcev]

On Tue, 5 Apr 2005 10:55:52 -0300 Marcelo Tosatti <[EMAIL PROTECTED]> wrote:

> CCing Pete.
> 
> On Mon, Apr 04, 2005 at 08:59:57PM +0200, Gabor Z. Papp wrote:

> > It was working fine with 2.4.29 and earlier kernels, often with
> > 100-150 days uptime.
> > 
> > As I upgraded to 2.4.30-rc kernels, started getting such error in my
> > kernel log:
> > 
> > pwc Too many ISOC errors, bailing out.
> > pwc pwc_isoc_handler() called with status -84 [CRC/Timeout (could be 
> > anything)].

There is no other way but to start splitting patches and diff-ing.
We can narrow this down a little by looking at what _might_ be involved.
Is this device driven by EHCI? A snapshot of /proc/bus/usb/devices
would be useful (BTW, Gabor, please do it on both 2.4.28 and 2.4.30-rc).

Thanks,
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 design philosophy heads-up

[Pete Zaitcev]

> > As for the language CML2 is written in, surely C would work just as well as
> > Python if the config-ruleset file is in a known format.  GCC is required
> > for the kernel to build, I don't see why anything else should be required
> > simply to configure it.
> 
> Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
> a configurator which doesn't require something more than gcc is there?

I always do "vi .config", then "make oldconfig", because it is very
convinient, simple, and flexible way to do it. For instance, it is
very easy to store a pile of configs for different kernels, very
easy do diff them (with -u and without).

I do not have Python installed on any of my machines.

The right way to handle the CML2 problem, IMHO, is to have a
C implementation of Python part without curses, tcl, and other crap.
Half of ESR's justification is "dynatic loading of components and
recovery from failure to load them", which goes away if we
do not support extras like curses. Another half was GC, which
is just a convinience for a project of CML's size.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 design philosophy heads-up

[Pete Zaitcev]

>[about Aunt Tullie]
> Because, for example, a kernel compile can be a part of the standard 
> install now, and you will end up with a kernel built specifically for 
> your machine that doesn't print 50 initialization failed messages on boot.
>[...]
> And you can also now run a kernel built for your shiny new Athlon, not 
> the old piece of shit that was hot stuff in '92.

It is way too easy to crush your example, by pointing out that
Red Hat ships and automatically installs an Athlon-optimized kernel.

However, the argument above is wrong even if Red Hat did not.
We are talking about CML2 and interaction with Aunt Tullie.
This has nothing to do with automated rebuild at install time.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops on booting 2.4.4

[Pete Zaitcev]

> May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
> stackpage=c7845000)
> May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
> c73aa000 c122a060 c122a05c c122a058 c88fbb20
> May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
> c73aa3f1 c7845f9c  0400 ffea
> May 23 02:46:24 localhost kernel:c7f43f60 0400 b4b8
> c7f2e220 c12607e0   c73aa000
> May 23 02:46:24 localhost kernel: Call Trace: []
> [proc_file_read+184/464] [sys_read+142/196] [system_call+51/56]
> May 23 02:46:24 localhost kernel: Call Trace: [] []
> [] []

A module deregistered incorrectly, or has a race between
post-load activities and unload. One way or another it left
a dangling proc entry.

The oops does not provide off-stack information, so it's impossible
to tell what particular modules is the culprit.

> May 23 02:46:24 localhost kernel: hub.c: USB new device connect on
> bus1/2, assigned device number 2
> May 23 02:46:24 localhost kernel: usb.c: USB device 2 (vend/prod
> 0x4a9/0x2204) is not claimed by any active driver.

What is this thing you have on USB? Try to run without it.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch for PM in ymfpci (against 2.4.5-pre3)

[Pete Zaitcev]

I am sorry to be a poor maintainer, people were sending me patches
to enable PM support for a long time. I took most of this from
Paul Stewart, fixed a buglet, and factored common parts into
a function.

-- Pete

* PM support for suspend/resume (without pm_register, proper PCI API);
* Killed some P3's;
* Removed unused unit.error;
* Removed access_ok (we do copy_[to|from]_user);

diff -ur -X dontdiff linux-2.4.5-pre3/drivers/sound/ymfpci.c 
linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c
--- linux-2.4.5-pre3/drivers/sound/ymfpci.c Fri May 18 14:09:46 2001
+++ linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c  Thu May 24 20:58:27 2001
@@ -23,10 +23,8 @@
  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  * TODO:
- *  - Use P44Slot for 44.1 playback.
+ *  - Use P44Slot for 44.1 playback (beware of idle buzzing in P44Slot).
  *  - 96KHz playback for DVD - use pitch of 2.0.
- *  - uLaw for Sun apps.
- * : Alan says firmly "no software format conversion in kernel".
  *  - Retain DMA buffer on close, do not wait the end of frame.
  *  - Cleanup
  *  ? underused structure members
@@ -55,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -66,14 +65,19 @@
 #endif
 #include "ymfpci.h"
 
-static int ymf_playback_trigger(ymfpci_t *codec, struct ymf_pcm *ypcm, int cmd);
+static int ymf_playback_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
 static void ymf_capture_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
-static void ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
+static void ymfpci_voice_free(ymfpci_t *unit, ymfpci_voice_t *pvoice);
 static int ymf_capture_alloc(struct ymf_unit *unit, int *pbank);
 static int ymf_playback_prepare(struct ymf_state *state);
 static int ymf_capture_prepare(struct ymf_state *state);
 static struct ymf_state *ymf_state_alloc(ymfpci_t *unit);
 
+static void ymfpci_aclink_reset(struct pci_dev * pci);
+static void ymfpci_disable_dsp(ymfpci_t *unit);
+static void ymfpci_download_image(ymfpci_t *codec);
+static void ymf_memload(ymfpci_t *unit);
+
 static LIST_HEAD(ymf_devs);
 
 /*
@@ -330,7 +334,7 @@
spin_lock_irqsave(&state->unit->reg_lock, flags);
dmabuf->hwptr = dmabuf->swptr = 0;
dmabuf->total_bytes = 0;
-   dmabuf->count = dmabuf->error = 0;
+   dmabuf->count = 0;
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
 
/* allocate DMA buffer if not allocated yet */
@@ -810,8 +814,6 @@
end >>= 1;
if (w_16)
end >>= 1;
-/* P3 */ // printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 
0x%x\n",
-//  voice->number, rate, format, delta, end);
for (nbank = 0; nbank < 2; nbank++) {
bank = &voice->bank[nbank];
bank->format = format;
@@ -907,7 +909,7 @@
 
if ((err = ymfpci_pcm_voice_alloc(ypcm, state->format.voices)) < 0) {
/* Somebody started 32 mpg123's in parallel? */
-   /* P3 */ printk("ymfpci%d: cannot allocate voice\n",
+   printk(KERN_INFO "ymfpci%d: cannot allocate voice\n",
state->unit->dev_audio);
return err;
}
@@ -1178,6 +1180,7 @@
 {
struct ymf_state *state = (struct ymf_state *)file->private_data;
struct ymf_dmabuf *dmabuf = &state->rpcm.dmabuf;
+   struct ymf_unit *unit = state->unit;
DECLARE_WAITQUEUE(waita, current);
ssize_t ret;
unsigned long flags;
@@ -1190,18 +1193,26 @@
return -ENXIO;
if (!dmabuf->ready && (ret = prog_dmabuf(state, 1)))
return ret;
-   if (!access_ok(VERIFY_WRITE, buffer, count))
-   return -EFAULT;
ret = 0;
 
add_wait_queue(&dmabuf->wait, &waita);
while (count > 0) {
-   spin_lock_irqsave(&state->unit->reg_lock, flags);
+   spin_lock_irqsave(&unit->reg_lock, flags);
+   if (unit->suspended) {
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   if (signal_pending(current)) {
+   if (!ret) ret = -EAGAIN;
+   break;
+   }
+   continue;
+   }
swptr = dmabuf->swptr;
cnt = dmabuf->dmasize - swptr;
if (dmabuf->count < cnt)
cnt = dmabuf->count;
-   spin_unlock_irqrestore(&state->unit->reg_lock, flags);
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
 
if (cnt > count)
cnt = count;
@@ -1240,7 +1254,7 @@
}
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
if (signal_pending(current)) {
-   ret = ret ? ret : -

Re: Patch for PM in ymfpci (against 2.4.5-pre3)

[Pete Zaitcev]

> From: Jeff Garzik <[EMAIL PROTECTED]>

> Looks ok, only a small nit:  an include and 'pmdev' are left over from
> the older PM implementation, and can be removed.

Oops, here's a better one.

-- Pete

-

PM support for suspend/resume (without pm_register, proper PCI API);
Killed some P3's;
Removed unused unit.error;
Removed access_ok;

diff -ur -X dontdiff linux-2.4.5-pre3/drivers/sound/ymfpci.c 
linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c
--- linux-2.4.5-pre3/drivers/sound/ymfpci.c Fri May 18 14:09:46 2001
+++ linux-2.4.5-pre3-p3/drivers/sound/ymfpci.c  Thu May 24 22:12:27 2001
@@ -23,10 +23,8 @@
  *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  * TODO:
- *  - Use P44Slot for 44.1 playback.
+ *  - Use P44Slot for 44.1 playback (beware of idle buzzing in P44Slot).
  *  - 96KHz playback for DVD - use pitch of 2.0.
- *  - uLaw for Sun apps.
- * : Alan says firmly "no software format conversion in kernel".
  *  - Retain DMA buffer on close, do not wait the end of frame.
  *  - Cleanup
  *  ? underused structure members
@@ -66,14 +64,19 @@
 #endif
 #include "ymfpci.h"
 
-static int ymf_playback_trigger(ymfpci_t *codec, struct ymf_pcm *ypcm, int cmd);
+static int ymf_playback_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
 static void ymf_capture_trigger(ymfpci_t *unit, struct ymf_pcm *ypcm, int cmd);
-static void ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
+static void ymfpci_voice_free(ymfpci_t *unit, ymfpci_voice_t *pvoice);
 static int ymf_capture_alloc(struct ymf_unit *unit, int *pbank);
 static int ymf_playback_prepare(struct ymf_state *state);
 static int ymf_capture_prepare(struct ymf_state *state);
 static struct ymf_state *ymf_state_alloc(ymfpci_t *unit);
 
+static void ymfpci_aclink_reset(struct pci_dev * pci);
+static void ymfpci_disable_dsp(ymfpci_t *unit);
+static void ymfpci_download_image(ymfpci_t *codec);
+static void ymf_memload(ymfpci_t *unit);
+
 static LIST_HEAD(ymf_devs);
 
 /*
@@ -330,7 +333,7 @@
spin_lock_irqsave(&state->unit->reg_lock, flags);
dmabuf->hwptr = dmabuf->swptr = 0;
dmabuf->total_bytes = 0;
-   dmabuf->count = dmabuf->error = 0;
+   dmabuf->count = 0;
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
 
/* allocate DMA buffer if not allocated yet */
@@ -810,8 +813,6 @@
end >>= 1;
if (w_16)
end >>= 1;
-/* P3 */ // printk("ymf_pcm_init_voice: %d: Rate %d Format 0x%08x Delta 0x%x End 
0x%x\n",
-//  voice->number, rate, format, delta, end);
for (nbank = 0; nbank < 2; nbank++) {
bank = &voice->bank[nbank];
bank->format = format;
@@ -907,7 +908,7 @@
 
if ((err = ymfpci_pcm_voice_alloc(ypcm, state->format.voices)) < 0) {
/* Somebody started 32 mpg123's in parallel? */
-   /* P3 */ printk("ymfpci%d: cannot allocate voice\n",
+   printk(KERN_INFO "ymfpci%d: cannot allocate voice\n",
state->unit->dev_audio);
return err;
}
@@ -1178,6 +1179,7 @@
 {
struct ymf_state *state = (struct ymf_state *)file->private_data;
struct ymf_dmabuf *dmabuf = &state->rpcm.dmabuf;
+   struct ymf_unit *unit = state->unit;
DECLARE_WAITQUEUE(waita, current);
ssize_t ret;
unsigned long flags;
@@ -1190,18 +1192,26 @@
return -ENXIO;
if (!dmabuf->ready && (ret = prog_dmabuf(state, 1)))
return ret;
-   if (!access_ok(VERIFY_WRITE, buffer, count))
-   return -EFAULT;
ret = 0;
 
add_wait_queue(&dmabuf->wait, &waita);
while (count > 0) {
-   spin_lock_irqsave(&state->unit->reg_lock, flags);
+   spin_lock_irqsave(&unit->reg_lock, flags);
+   if (unit->suspended) {
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   if (signal_pending(current)) {
+   if (!ret) ret = -EAGAIN;
+   break;
+   }
+   continue;
+   }
swptr = dmabuf->swptr;
cnt = dmabuf->dmasize - swptr;
if (dmabuf->count < cnt)
cnt = dmabuf->count;
-   spin_unlock_irqrestore(&state->unit->reg_lock, flags);
+   spin_unlock_irqrestore(&unit->reg_lock, flags);
 
if (cnt > count)
cnt = count;
@@ -1240,7 +1250,7 @@
}
spin_unlock_irqrestore(&state->unit->reg_lock, flags);
if (signal_pending(current)) {
-   ret = ret ? ret : -ERESTARTSYS;
+   if (!ret) ret = 

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Pete Zaitcev]

> From: "Adam J. Richter" <[EMAIL PROTECTED]>
> Date: Sun, 22 Apr 2001 12:53:48 -0700
> To: [EMAIL PROTECTED]
> Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

>[...]
>   I believe this infringinges the copyrights of the authors
> of the code used in these drivers who released their code under GPL.
> Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
> and insists that I bring in the lawyers to prove him otherwise.  I
> really do not want to take this step, but he is forcing my hand.  Note
> that Yggdrasil is a copyright owner in this case.

Translation: Adam was soundly beaten on linux-usb-devel and is sore.

>   To simplify removal of the offending code, I have provided
> a separate user level facility that can use the USB "hot plugging"
> system to automatically load that "firmware" or any other. [...]

A good thing for many reasons, if it works. Personally, I do not
care why Adam writes right code as long as he does. :)

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] USB oops on SMP, 2.4.5 kernel, and other problems

[Pete Zaitcev]

> From: Oleg Drokin <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Date: Sat, 26 May 2001 14:37:24 +0400

> >>EIP; c01a3162<=
> Trace; c01a42fc 
> Trace; c01a5f9c 
> Trace; c01a42e0 
> Trace; c019f19f 
> Trace; c0118a9e 
> Trace; c0117e62 
> Trace; c0106e0b 

This is a relatively known problem, on SMP. My old patch for that
sort of thing fixed it, and the replacement that Johannes rolled
did not fix it completely. Linus did not like my fix, because
the kindest apprisal that he used was "idiocy".

For the moment I in Red Hat ship a patch that backs out the
Johannes' fix and reinstalls my fix, because I would rather
have things working than get Linus pleased (even if such
a thing was possible...). Johannes is generally on the right
track here and will fix it compeltely in time, one way or
another (e.g. perhaps adding one more refcounting somewhere :)

If someone needs a resolution until Johannes completes it,
use my attached patch, or use Red Hat kernels.

-- Pete

--- linux-2.4.5/drivers/usb/hub.h   Tue Apr 17 17:23:06 2001
+++ linux-2.4.5-tr5/drivers/usb/hub.h   Sat May 26 07:39:34 2001
@@ -109,7 +109,7 @@
 
struct usb_hub_descriptor *descriptor;
 
-   atomic_t refcnt;
+   struct semaphore khubd_sem;
 };
 
 #endif
--- linux-2.4.5/drivers/usb/hub.c   Wed Apr 25 14:10:47 2001
+++ linux-2.4.5-tr5/drivers/usb/hub.c   Sat May 26 07:44:10 2001
@@ -289,7 +289,7 @@
 
INIT_LIST_HEAD(&hub->event_list);
hub->dev = dev;
-   atomic_set(&hub->refcnt, 1);
+   init_MUTEX(&hub->khubd_sem);
 
/* Record the new hub's existence */
spin_lock_irqsave(&hub_event_lock, flags);
@@ -318,34 +318,11 @@
return NULL;
 }
 
-static void hub_get(struct usb_hub *hub)
-{
-   atomic_inc(&hub->refcnt);
-}
-
-static void hub_put(struct usb_hub *hub)
-{
-   if (atomic_dec_and_test(&hub->refcnt)) {
-   if (hub->descriptor) {
-   kfree(hub->descriptor);
-   hub->descriptor = NULL;
-   }
-
-   kfree(hub);
-   }
-}
-
 static void hub_disconnect(struct usb_device *dev, void *ptr)
 {
struct usb_hub *hub = (struct usb_hub *)ptr;
unsigned long flags;
 
-   if (hub->urb) {
-   usb_unlink_urb(hub->urb);
-   usb_free_urb(hub->urb);
-   hub->urb = NULL;
-   }
-
spin_lock_irqsave(&hub_event_lock, flags);
 
/* Delete it and then reset it */
@@ -356,7 +333,22 @@
 
spin_unlock_irqrestore(&hub_event_lock, flags);
 
-   hub_put(hub);
+   down(&hub->khubd_sem); /* Wait for khubd to leave this hub alone. */
+   up(&hub->khubd_sem);
+
+   if (hub->urb) {
+   usb_unlink_urb(hub->urb);
+   usb_free_urb(hub->urb);
+   hub->urb = NULL;
+   }
+
+   if (hub->descriptor) {
+   kfree(hub->descriptor);
+   hub->descriptor = NULL;
+   }
+
+   /* Free the memory */
+   kfree(hub);
 }
 
 static int hub_ioctl(struct usb_device *hub, unsigned int code, void *user_data)
@@ -668,7 +660,7 @@
list_del(tmp);
INIT_LIST_HEAD(tmp);
 
-   hub_get(hub);
+   down(&hub->khubd_sem); /* never blocks, we were on list */
spin_unlock_irqrestore(&hub_event_lock, flags);
 
if (hub->error) {
@@ -676,8 +668,8 @@
 
if (usb_hub_reset(hub)) {
err("error resetting hub %d - disconnecting", 
dev->devnum);
+   up(&hub->khubd_sem);
usb_hub_disconnect(dev);
-   hub_put(hub);
continue;
}
 
@@ -753,7 +745,7 @@
usb_hub_power_on(hub);
}
}
-   hub_put(hub);
+   up(&hub->khubd_sem);
 } /* end while (1) */
 
spin_unlock_irqrestore(&hub_event_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Plain 2.4.5 VM...

[Pete Zaitcev]

> Ouch!  When compiling MySql, building sql_yacc.cc results in a ~300M
> cc1plus process size.  Unfortunately this leads the machine with 380M of
> RAM deeply into swap:
> 
> Mem:   381608K av,  248504K used,  133104K free,   0K shrd, 192K buff
> Swap:  255608K av,  255608K used,   0K free  215744K cached
> 
> Vanilla 2.4.5 VM.

I noticed that too and there is no way around it. If we assume
a 2.5xRAM target, you must add about 704MB. In my case I had no
spare partition so I added a swapfile, as undoubtedly many
2.4 sufferers did.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)

[Pete Zaitcev]

> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR).  Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.

Looks interesting. Seemingly literate use of spinlocks.

Off-hand I see old style initialization. Is it right for new driver?

i2c framework is not used, I wonder why. Someone thought that
it was too heavy perhaps? If so, I disagree.

Also, I am curious
if any alignment with lm-sensors is possible, for the sake of
common userland tools? If we managed that, PSARC would eat their
hearts out - they tried to do it since E-250 shipped.

lcd_read bounces reads with -EINVAL when another read is in
progress. Gross.

Nitpicking:

1.:
p = head;
while (p) {
p = p->next;
}

It is what for(;;) does.

2. Spaces and tabs are mixed in funny ways, makes to cute effects
when quoting diffs.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)

[Pete Zaitcev]

> From: Tim Hockin <[EMAIL PROTECTED]>
> Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)

> > i2c framework is not used, I wonder why. Someone thought that
> > it was too heavy perhaps? If so, I disagree.
> 
> i2c is only in our stuff because the i2c core is not in the standard kernel
> yet.  As soon as it is, I will make cobalt_i2c* go away.

I am puzzled by this comment. Did you look into drivers/i2c/?
It certainly is a part of a stock kernel. The main user is
the V4L, in drivers/media/video, but I think LM sensors use it too.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)

[Pete Zaitcev]

> But, each time a user cats this proc file, the user is banging the
> hardware.  What happens when a malicious user forks off 100 processes to
> continually cat this file?  :)

Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).

> Security: don't you want CAP_RAW_IO or something before executing any of
> these ioctls?

Perhaps it's mode 600 in their distro...

> bug: you can't hold a spinlock while you are sleeping in copy_from_user

Yep... I meant to check for it but forgot.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac7

[Pete Zaitcev]

> AC> 2.4.5-ac7
> AC> o   Make USB require PCI(me)

> How about people from StrongArm sa11x0 port, who have USB host controller
> (in sa companion chip) but do not have PCI?
> Probably there are more such embedded architectures with USB controllers,
> but not PCI bus.

There is nothing that would bind USB to PCI architecturally.
OHCI and UHCI are PCI based, but that's just a matter of
implementation. I think that Alan was unwise at this point.

I know that some small Motorola parts (relatives of 860, perhaps)
do have USB controllers, but I have no idea if PCI is involved.

> How about ISA USB host controllers?

Those, unfortunately, do not exist. I was shopping for one
in vain for a long time. One formiddable difficulty is that
USB bandwidth is larger than ISA, so the only feasible way
to make a HC is to have all TD's in its onboard memory,
as in VGA.

In other follow-up Alan argued in favor of CONFIG_PCI for
a PCI-less machine. It may be a reasonable approach, for
instance JavaStation-1 has no PCI but requires CONFIG_PCI.
It adds a little of useless bloat, that I considered a
necessary evil in the abovementioned case.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5-ac7 SMP crash (hotplug race?)

[Pete Zaitcev]

>I told device to go to sleep, it reported (over serial console that I
>looked at with minicom), that it turned off internal devices
>(including USB client), reported it is going to sleep, and turned
>serial and itself off.

What does it mean "I told device to go to sleep"?
What device? How (what command line)?

> wait_on_irq, CPU 1
> irq: 1 [1 0]
> bh:  1 [0 1]
> CPU 0: 
> CPU 1: c167fe68 c01d805d ... (not recorded full stack)
> Call Trace: [] [] [] [] [] 
>[] [] [] [] [] [] 
>[] [] [] [] []
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> Trace; c0108522 <__global_cli+e2/170>
> Trace; c0170f97 
> Trace; c0170f60 
> Trace; c011d706 
> Trace; c011a56c 
> Trace; c011a423 
> Trace; c011a2ab 
> Trace; c0108935 
> Trace; c0108525 <__global_cli+e5/170>
> Trace; c01617e8 
> Trace; c011a67d <__run_task_queue+5d/70>
> Trace; c0121c35 
> Trace; c0121670 
> Trace; c0105000 
> Trace; c0105556 
> Trace; c0121670 

Curious. What host controller driver do you use?

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB bugs in 2.6.11.8, 2.6.11.10 and 2.6.12.2

[Pete Zaitcev]

On Mon, 11 Jul 2005 17:06:28 +0300, [EMAIL PROTECTED] (Markus   Törnqvist) 
wrote:

> Sorry about the bother, enabling K8 IOMMU fixed the issues.
> At least that's the most relevant change I made to the conf
> to fix it.

This is not a good reason for crashes though. All is well that ends
well, but perhaps Andi wants to make a mental note.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb mass storage bug

[Pete Zaitcev]

On Mon, 11 Jul 2005 13:30:47 -0700 (PDT), Joe Sevy <[EMAIL PROTECTED]> wrote:

> Sorry, no logs or dmesg to report; just performance.
> Using kernel 2.6.12: USB flash drive (san-disk cruzer
> micro) Copy FROM drive is normal and quick; copy TO
> drive is amazingly slow. (30 minutes for 50K file).
> Used same configuration as for 2.6.11.11. Cured by
> going back to old kernel.

Symptoms seem similar to this:
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159269

Try 2.6.13-rc2, it would be a valuable data point.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb mass storage bug

[Pete Zaitcev]

On Mon, 11 Jul 2005 20:09:58 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 11, 2005 at 01:30:47PM -0700, Joe Sevy wrote:
> > Sorry, no logs or dmesg to report; just performance.
> > Using kernel 2.6.12: USB flash drive (san-disk cruzer
> > micro) Copy FROM drive is normal and quick; copy TO
> > drive is amazingly slow. (30 minutes for 50K file).
> > Used same configuration as for 2.6.11.11. Cured by
> > going back to old kernel.
> 
> Are you using CONFIG_UB or CONFIG_USB_STORAGE?

Please, Greg. I knew that someone will try to implicate ub here, but you?
Consider two things:
 #1 Joe's kernel reads and writes and sharply different speeds,
while ub is uniformly slow
 #2 It's a regression in 2.6.12

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb mass storage bug

[Pete Zaitcev]

On Wed, 13 Jul 2005 13:53:16 -0700, Greg KH <[EMAIL PROTECTED]> wrote:

> You are right, ub isn't _that_ slow at all, I use it all the time on
> some of my devices just fine.

Ub actually gets terribly slow when partition size is odd (for both
reading and writing). I even have a patch for it, but it's yucky.
Here's the original discussion:
 
http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/f11b7721d7ed6d1f&hl=en

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pc_keyb: controller jammed (0xA7)

[Pete Zaitcev]

On Thu, 14 Jul 2005 18:27:01 +0200, Thoralf Will <[EMAIL PROTECTED]> wrote:

> I didn't find any useful answer anywhere so far, hope it's ok to ask here.
> I'm currently trying to get a 2.4.31 up and running on an IBM
> BladeCenter HS20/8843. (base system is a stripped down RH9)
> 
> When booting the kernel the console is spammmed with:
>pc_keyb: controller jammed (0xA7)
> But it seems there are no further consequences and the keyboard is
> working.

I saw a patch for it by Brian Maly, and yes, it was for 2.4.x.
Maybe he can send you a rediff against current Marcelo's tree.

However, is there a reason you're running 2.4.31 in Summer of 2005?
Did you try 2.6, does that one do the same thing? It has a rather
different infrastructure with the serio.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch for ub and blank CDs in 2.6.12

[Pete Zaitcev]

This patch fixes a microcode lockup in my CD-ROM adapters when a blank
CD is inserted. However, do not try to burn CDs yet! I'm pretty sure
that trying it will end in coasters.

 - Fix a few cases where we were unable to resynchronize with replies
   for previous commands. The main thing is to keep reading replies
   in case of a stall. This is done with the new state CLRRS.
 - Since I am forgetting the basic state machine already, document it.
 - Move counter increments in the looping path in its own function.
 - Fix a harmless buglet in case CSW read fails to submit: do not
   override state.
 - Implement the Alan Stern's idea for adaptive signature checking.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

diff -urp -X dontdiff linux-2.6.12/drivers/block/ub.c 
linux-2.6.12-lem/drivers/block/ub.c
--- linux-2.6.12/drivers/block/ub.c 2005-06-21 12:58:18.0 -0700
+++ linux-2.6.12-lem/drivers/block/ub.c 2005-07-14 21:25:03.0 -0700
@@ -23,6 +23,7 @@
  *  -- Exterminate P3 printks
  *  -- Resove XXX's
  *  -- Redo "benh's retries", perhaps have spin-up code to handle them. V:D=?
+ *  -- CLEAR, CLR2STS, CLRRS seem to be ripe for refactoring.
  */
 #include 
 #include 
@@ -38,6 +39,73 @@
 #define UB_MAJOR 180
 
 /*
+ * The command state machine is the key model for understanding of this driver.
+ *
+ * The general rule is that all transitions are done towards the bottom
+ * of the diagram, thus preventing any loops.
+ *
+ * An exception to that is how the STAT state is handled. A counter allows it
+ * to be re-entered along the path marked with [C].
+ *
+ *   ++
+ *   ! INIT   !
+ *   ++
+ *   !
+ *ub_scsi_cmd_start fails ->--\
+ *   !!
+ *   V!
+ *   ++   !
+ *   ! CMD!   !
+ *   ++   !
+ *   !++  !
+ * was -EPIPE -->>! CLEAR  !  !
+ *   !++  !
+ *   !!   !
+ * was error -->- ! ->\
+ *   !!   !
+ *  /--<-- cmd->dir == NONE ? !   !
+ *  !!!   !
+ *  !V!   !
+ *  !++   !   !
+ *  !! DATA   !   !   !
+ *  !++   !   !
+ *  !!   +-+  !   !
+ *  !  was -EPIPE -->--->! CLR2STS !  !   !
+ *  !!   +-+  !   !
+ *  !!!   !   !
+ *  !!  was error --> ! ->\
+ *  !  was error -->- ! - ! ->\
+ *  !!!   !   !
+ *  !V!   !   !
+ *  \--->++   !   !   !
+ *   ! STAT   !<--/   !   !
+ *  /--->++   !   !
+ *  !!!   !
+ * [C] was -EPIPE -->---\ !   !
+ *  !!  ! !   !
+ *  +< len == 0 ! !   !
+ *  !!  ! !   !
+ *  !  was error -->--!-->\
+ *  !!  ! !   !
+ *  +< bad CSW  ! !   !
+ *  +< bad tag  ! !   !
+ *  !!  V !   !
+ *  !

Fw: Oops in hidinput_hid_event

[Pete Zaitcev]

I think this patch is rather obvious, so maybe I should ask Andrew to
apply it to -mm for now, to get some testing. Would that help to verify
it for acceptance?

-- Pete

Begin forwarded message:

Date: Tue, 28 Jun 2005 15:00:23 -0700
From: Pete Zaitcev <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
Subject: Oops in hidinput_hid_event

Hi, Vojtech:

Someone reported a bug in Fedora, which runs a largely unmodified upstream
kernel in this area. Whenever the user hits a key which switches LED,
the system oopses. Here's a trace:

Unable to handle kernel NULL pointer dereference at virtual address 00c8
EFLAGS: 00010006   (2.6.11-1.1369_FC4smp)
EIP is at hidinput_hid_event+0x2d/0x292   
Call Trace:   
 [] hid_process_event+0x57/0x5f
 [] hid_input_field+0x2a2/0x2ac
 [] hid_input_report+0x9e/0xb8
 [] hid_ctrl+0x14c/0x151
 [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
 [] usb_hcd_giveback_urb+0x24/0x67
 [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
 [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
 [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
 [] i8042_interrupt+0x121/0x234
 [] uhci_irq+0x47/0x10d [uhci_hcd]

Full trace at
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709

Any ideas?

By the way, it seems that I see a bug in hidinput_hid_event.
The check for NULL can never work, becaue &hidinput->input
is nonzero at all times. How about this?

--- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 12:58:47.0 
-0700
+++ linux-2.6.12-lem/drivers/usb/input/hid-input.c  2005-06-28 
14:57:22.0 -0700
@@ -397,11 +397,12 @@
 
 void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
struct hid_usage *usage, __s32 value, struct pt_regs *regs)
 {
-   struct input_dev *input = &field->hidinput->input;
+   struct input_dev *input;
int *quirks = &hid->quirks;
 
-   if (!input)
+   if (!field->hidinput)
return;
+   input = &field->hidinput->input;
 
input_regs(input, regs);
 

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Oops in hidinput_hid_event

[Pete Zaitcev]

On Tue, 19 Jul 2005 03:31:12 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote:

> >  void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
> > struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> >  {
> > -   struct input_dev *input = &field->hidinput->input;
> > +   struct input_dev *input;
> > int *quirks = &hid->quirks;
> > 
> > -   if (!input)
> > +   if (!field->hidinput)
> 
> How about
>  if (!field || !field->hdinput)
> instead?
> 
> > return;
> > +   input = &field->hidinput->input;

It would be more reliable, certainly. However, this is likely not what
Vojtech has intended. I do not understand how this code functions,
and I would be ashamed just adding NULL checks all over the place.
Also, the original oops happens after a certain field was accessed,
not at an argument. It's not quite clear to me what happened, because
of optimizations, but I suspect this may be it.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB debouncing?

[Pete Zaitcev]

On Tue, 19 Jul 2005 18:24:25 +0200, DervishD <[EMAIL PROTECTED]> wrote:

> I have a new MP3 player, and when I disconnect it from the USB
> port, my logs says:
> 
> <30>Jul 19 18:11:05 kernel: usb.c: USB disconnect on device 00:07.3-1 
> address 2
> <27>Jul 19 18:11:06 kernel: hub.c: connect-debounce failed, port 1 
> disabled
> 
> What is that 'connect-debounce' for? Is the port damaged? Am I
> doing anything wrong?

The ports are not getting completely disabled. The wording is poor.
If you plug something else, hub gets a connect change, khubd will
allow another debounce cycle and accept whatever happens.

In this case, when you're pulling the plug the hub receives a
momentary reconnect, so the software things something else was plugged.
I think perhaps the resistor harness is not good in the device,
or perhaps something is wrong with the connector.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

usb: printer double up()

[Pete Zaitcev]

Doing a double up() is actually safe in Linux, but still, it's a bug.
This fix is present in 2.6.13-rc3.

By Domen Puncer <[EMAIL PROTECTED]>
up(&usblp->sem) was called twice in a row in this code path.

--- linux-2.4.31/drivers/usb/printer.c  2004-08-10 13:43:36.0 -0700
+++ linux-2.4.31-usb/drivers/usb/printer.c  2005-06-05 11:21:12.0 
-0700
@@ -740,6 +740,7 @@ static ssize_t usblp_read(struct file *f
schedule();
} else {
set_current_state(TASK_RUNNING);
+   down (&usblp->sem);
break;
}
down (&usblp->sem);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fw: Re: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

On Sat, 6 Aug 2005 11:49:05 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:

> When asked what went wrong, the device says it didn't understand the 
> INQUIRY command.  This is a fatal error; if a device can't identify itself 
> there's no way for Linux to use it.
> 
> In short, your mp3stick is worthless.  Trade it in for one that works.

This is only true if usb-storage is used. The stick may work with ub.

Martin, please apply the attached patch and enable CONFIG_BLK_DEV_UB.
If you do not run a userland with udev, do this:

mknod /dev/uba b 180 0
mknod /dev/uba1 b 180 1

Let me know how it went.

-- Pete

diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/usb.c 
linux-2.6.12-lem/drivers/usb/storage/usb.c
--- linux-2.6.12/drivers/usb/storage/usb.c  2005-06-17 12:48:29.0 
-0700
+++ linux-2.6.12-lem/drivers/usb/storage/usb.c  2005-07-25 22:12:53.0 
-0700
@@ -150,7 +150,9 @@ static struct usb_device_id storage_usb_
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_BULK) },
+#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) },
+#endif
 
/* Terminating entry */
{ }
@@ -224,8 +226,10 @@ static struct us_unusual_dev us_unusual_
  .useTransport = US_PR_BULK},
{ .useProtocol = US_SC_8070,
  .useTransport = US_PR_BULK},
+#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
{ .useProtocol = US_SC_SCSI,
  .useTransport = US_PR_BULK},
+#endif
 
/* Terminating entry */
{ NULL }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

On Sun, 7 Aug 2005 02:22:53 +0200, Martin Maurer <[EMAIL PROTECTED]> wrote:

> when i delete the files which are on the stick and do an umount/mount
> cycle, the files are there again. 
> Copying files to the stick gives wrong results too.

Curious. First of all, I have a request: do not call this device a "stick".
It is terribly misleading word with which to call a fully-featured MP3
player. DNT uses it in a specific context, as a product name.

I'd like to have a usbmon trace of a session, from plugging, through
copying, through unplugging. Do not send it to the whole cc: list.
Do you need instructions?

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Logitech Quickcam Express USB Address Aquisition Issues

[Pete Zaitcev]

On Sun, 7 Aug 2005 16:11:12 +0900, Chris White <[EMAIL PROTECTED]> wrote:

> > Did it work OK under a previous kernel version?  If so, which?
> 
> I haven't attempted that, but I'll probably give a 2.6.9/2.4 series
> kernel a shot later on tommorow night.

Does that thing work with Windows?

I strongly suspect that it's simply broken at this point.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

> when i delete the files which are on the stick and do an umount/mount cycle, 
> the files are there again. 
>[... other mail ...]

> I did the usbmon thing (hopefully correctly). Attached is the output.

Yes, that was perfect, thanks a lot. Unfortunately, I do not see a lot
of interesting things. The last write before the disconnect is a FAT
update:

c31650b8 1617078003 S Bo:006:01 -115 31 = 55534243 c600 0002 0a2a 
 3001  00
c31650b8 1617078987 C Bo:006:01 0 31 >
c31650b8 1617078997 S Bo:006:01 -115 512 = f8ff    
   
c31650b8 1617080988 C Bo:006:01 0 512 >
c31650b8 1617080998 S Bi:006:02 -115 13 <
c31650b8 1617084987 C Bi:006:02 0 13 = 55534253 c600  00

Only one cluster was taken, when compared with the FAT that was read.
Everything seems to be in order. But the next trace (after replug -
see the device number changing from 6 to 7) shows FAT with old contents
being read (same block number 0x30):

> cd6960b8 1874976301 S Bo:007:01 -115 31 = 55534243 0b00 0002 8a28 
>  3001  00
> cd6960b8 1874977274 C Bo:007:01 0 31 >
> cd6960b8 1874977288 S Bi:007:02 -115 512 <
> cd6960b8 1874979271 C Bi:007:02 0 512 = f8ff    
>    
> cd6960b8 1874979282 S Bi:007:02 -115 13 <
> cd6960b8 1874981271 C Bi:007:02 0 13 = 55534253 0b00  00

So, the device replies that writes were successful, but does not
actually commit them to the stable storage.

I suspect that this device may require some delays. I seem to recall
that we added delayes to usb-storage when we worked with Genesys
Logic. But ub contains no delays.

How about this:

--- linux-2.6.13-rc4/drivers/block/ub.c 2005-07-29 19:51:00.0 -0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-08-07 13:48:11.0 
-0700
@@ -1209,6 +1279,8 @@
return;
}
 
+   udelay(125);// XXX for Martin Maurer <[EMAIL PROTECTED]> 
+
UB_INIT_COMPLETION(sc->work_done);
 
if (cmd->dir == UB_DIR_READ)

Please try this patchlet and let us know how it went.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: Elitegroup K7S5A + usb_storage problem

[Pete Zaitcev]

On Sun, 7 Aug 2005 22:47:40 +0200, Martin Maurer <[EMAIL PROTECTED]> wrote:

> > Just out of curiosity, if you plug the player into a Windows system
> > without installing any special drivers first, will Windows be able to read
> > and write files okay?  If it can, a USB packet trace may give Pete a clue
> > as to where to look.

> as far as i recall i didnt install any special drivers for my win 2k and win 
> xp systems. (i got this mp3 player quite a while now...)
> How would I do such an packet trace ?

I have never run Snoopy on Windows myself and I did not want to subject
you to it. Let's try my delay patch first. If that fails, I guess we
have to get instructions from someone who knows how to run Snoopy.
Maybe Windows issues some cache synchronization command when it
commits FAT. Then the packet trace should show it.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <[EMAIL PROTECTED]> wrote:

> I'm not using hotplug currently so... how can I make the USB
> subsystem to assign always the same /dev/sd? entry to my USB Mass
> storage devices? [...]

You cannot. Just mount by label or something... Better yet, install
something like Fedora Core 4, which uses HAL, and forget about it.
The fstab-sync takes care of the rest.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <[EMAIL PROTECTED]> wrote:

> Which label will a random USB stick have?

GUID, I presume. Ask Andries Brouwer, he hacked on that, IIRC.
Actually msdos has on-disk format for user-settable labels in
the way analoguous to tune2fs -L label. I just do not know if
our implementation recognizes them.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Sat, 13 Aug 2005 12:06:16 +0200 (CEST), Bodo Eggert <[EMAIL PROTECTED]> 
wrote:
> On Fri, 12 Aug 2005, Pete Zaitcev wrote:
> > On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > 
> > > Which label will a random USB stick have?
> > 
> > GUID, I presume.
> 
> A global unique ID won't work out to make all USB mass storage devices
> appear under a common mountpoint, especially if it is recreated while
> "formating" it.

That is correct, but not what Dervish wanted. He wanted to mount them
on separate pre-assigned mount points. If you want all of them to mount
on the same place, just use /dev/sda1!

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb camera failing in 2.6.13-rc6

[Pete Zaitcev]

On Sun, 14 Aug 2005 17:12:06 +1000, Con Kolivas <[EMAIL PROTECTED]> wrote:

> A digital camera which was working fine in 2.6.11/12 now fails on 2.6.13-rc6 
> (not sure when it started failing).

Does it continue to work on an older kernel? I saw a USB device breaking
right in the moment of reboot into a new kernel (thus prompting a week
of diffing an head-scratching).

> +usbmon: debugs is not available

Deconfigure CONFIG_USB_MON. It's useless without debugfs anyway.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb camera failing in 2.6.13-rc6

[Pete Zaitcev]

On Sun, 14 Aug 2005 18:42:12 +1000, Con Kolivas <[EMAIL PROTECTED]> wrote:
> On Sun, 14 Aug 2005 18:00, Pete Zaitcev wrote:
> > On Sun, 14 Aug 2005 17:12:06 +1000, Con Kolivas <[EMAIL PROTECTED]> wrote:

> Yes all those dmesgs etc were redone after it failed in rc6 as I needed it 
> working. Oh and all other usb devices - mouse, printer, scanner, keyboard are 
> working fine in rc6; it's just the camera.

This should be diffable. You caught this regression relatively early.
But I'm afraid you have to go through the divide-by-half excercise.

If I were a betting man, I'd bet on this:

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -579,7 +582,7 @@ static int proc_control(struct dev_state
if ((i > 0) && ctrl.wLength) {
if (usbfs_snoop) {
dev_info(&dev->dev, "control read: data ");
-   for (j = 0; j < ctrl.wLength; ++j)
+   for (j = 0; j < i; ++j)
printk ("%02x ", (unsigned 
char)(tbuf)[j]);
printk("\n");
}
@@ -784,16 +790,16 @@ static int proc_setconfig(struct dev_sta
for (i = 0; i < actconfig->desc.bNumInterfaces; ++i) {
if (usb_interface_claimed(actconfig->interface[i])) {
dev_warn (&ps->dev->dev,
-   "usbfs: interface %d claimed "
+   "usbfs: interface %d claimed by %s "
"while '%s' sets config #%d\n",
actconfig->interface[i]
->cur_altsetting
->desc.bInterfaceNumber,
+   actconfig->interface[i]
+   ->dev.driver->name,
current->comm, u);
-#if 0  /* FIXME:  enable in 2.6.10 or so */
status = -EBUSY;
break;
-#endif
}
}
}

Remember that dmesg diff you sent? That's the one. If you strace
the digikamcameracl, it probably keels over after EBUSY.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: usb camera failing in 2.6.13-rc6

[Pete Zaitcev]

On Mon, 15 Aug 2005 09:29:20 +1000, Con Kolivas <[EMAIL PROTECTED]> wrote:

> > Remember that dmesg diff you sent? That's the one. If you strace
> > the digikamcameracl, it probably keels over after EBUSY.
> 
> Nice shot! Got it in one. bugzilla updated with confirmation.
> 
> So how do we proceed with this one? Do I need to file a digikam bug
> report too?

Since I never encountered it, I'm not versed in the switching of
the current altsetting. I suppose, this has to be discussed between
digikam developers and linux-usb-devel (Alan Stern probably knows
how that has to be done). It's very likely that all digikam needs
is to claim the interface after the altsetting was switched...
But I really do not know.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13 ub 4: Zaitcev's quasi-S/G

[Pete Zaitcev]

Back out Axboe-style quasi-S/G and replace it with one command and
repeated URBs. This is similar to what usb-storage does, only instead
of a few URBs allocated together, one URB is reused.

Jens's idea was very nice, but it collapsed when I had to support
packet commads for CD burning. I cannot issue two or more packet
commands where application expected only one.

However, burning does not work completely yet. The cdrecord starts,
recognizes the device, then aborts without writing a TOC.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

--- linux-2.6.13-rc6-gregkh/drivers/block/ub.c  2005-08-14 21:02:39.0 
-0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-08-14 20:45:52.0 
-0700
@@ -235,27 +235,16 @@ struct ub_scsi_cmd {
 
int stat_count; /* Retries getting status. */
 
-   /*
-* We do not support transfers from highmem pages
-* because the underlying USB framework does not do what we need.
-*/
-   char *data; /* Requested buffer */
unsigned int len;   /* Requested length */
+   unsigned int current_sg;
+   unsigned int nsg;   /* sgv[nsg] */
+   struct scatterlist sgv[UB_MAX_REQ_SG];
 
struct ub_lun *lun;
void (*done)(struct ub_dev *, struct ub_scsi_cmd *);
void *back;
 };
 
-struct ub_request {
-   struct request *rq;
-   unsigned char dir;
-   unsigned int current_block;
-   unsigned int current_sg;
-   unsigned int nsg;   /* sgv[nsg] */
-   struct scatterlist sgv[UB_MAX_REQ_SG];
-};
-
 /*
  */
 struct ub_capacity {
@@ -351,8 +340,6 @@ struct ub_lun {
int readonly;
int first_open; /* Kludge. See ub_bd_open. */
 
-   struct ub_request urq;
-
/* Use Ingo's mempool if or when we have more than one command. */
/*
 * Currently we never need more than one command for the whole device.
@@ -410,19 +397,16 @@ static void ub_cleanup(struct ub_dev *sc
 static int ub_request_fn_1(struct ub_lun *lun, struct request *rq);
 static int ub_cmd_build_block(struct ub_dev *sc, struct ub_lun *lun,
 struct ub_scsi_cmd *cmd, struct request *rq);
-static void ub_scsi_build_block(struct ub_lun *lun,
-struct ub_scsi_cmd *cmd, struct ub_request *urq);
 static int ub_cmd_build_packet(struct ub_dev *sc, struct ub_lun *lun,
 struct ub_scsi_cmd *cmd, struct request *rq);
 static void ub_rw_cmd_done(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_end_rq(struct request *rq, int uptodate);
-static int ub_request_advance(struct ub_dev *sc, struct ub_lun *lun,
-struct ub_request *urq, struct ub_scsi_cmd *cmd);
 static int ub_submit_scsi(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_urb_complete(struct urb *urb, struct pt_regs *pt);
 static void ub_scsi_action(unsigned long _dev);
 static void ub_scsi_dispatch(struct ub_dev *sc);
 static void ub_scsi_urb_compl(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
+static void ub_data_start(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_state_done(struct ub_dev *sc, struct ub_scsi_cmd *cmd, int rc);
 static int __ub_state_stat(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_state_stat(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
@@ -793,8 +777,6 @@ static int ub_request_fn_1(struct ub_lun
return 0;
}
 
-   if (lun->urq.rq != NULL)
-   return -1;
if ((cmd = ub_get_cmd(lun)) == NULL)
return -1;
memset(cmd, 0, sizeof(struct ub_scsi_cmd));
@@ -813,7 +795,7 @@ static int ub_request_fn_1(struct ub_lun
cmd->state = UB_CMDST_INIT;
cmd->lun = lun;
cmd->done = ub_rw_cmd_done;
-   cmd->back = &lun->urq;
+   cmd->back = rq;
 
cmd->tag = sc->tagcnt++;
if (ub_submit_scsi(sc, cmd) != 0) {
@@ -828,22 +810,20 @@ static int ub_request_fn_1(struct ub_lun
 static int ub_cmd_build_block(struct ub_dev *sc, struct ub_lun *lun,
 struct ub_scsi_cmd *cmd, struct request *rq)
 {
-   struct ub_request *urq;
int ub_dir;
int n_elem;
-
-   urq = &lun->urq;
-   memset(urq, 0, sizeof(struct ub_request));
+   unsigned int block, nblks;
 
if (rq_data_dir(rq) == WRITE)
ub_dir = UB_DIR_WRITE;
else
ub_dir = UB_DIR_READ;
+   cmd->dir = ub_dir;
 
/*
 * get scatterlist from block layer
 */
-   n_elem = blk_rq_map_sg(lun->disk->queue, rq, &urq->sgv[0]);
+   n_elem = blk_rq_map_sg(lun->disk->queue, rq, &cmd->sgv[0]);
if (n_elem <= 0) {
printk(KERN_INFO "%s: failed request map (%d)\n",
sc->name, n_elem); /* P3 */
@@ -854,7 +834,7 @@ static int ub_cmd_build_block(struct ub_
sc->name, n_elem);
   

usbmon in 2.6.13: peeking into DMA areas

[Pete Zaitcev]

I am not completely confident in this patch, so while the fix is being
requested by users, I would like to have it postponed until 2.6.13.

This code looks at urb->transfer_dma, maps the page and takes the data.
I am looking for volunteers to contribute architectures other than i386
or to develop an architecure-neutral API for it (or point me that it
was done already).

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/Makefile 
linux-2.6.13-rc6-lem/drivers/usb/mon/Makefile
--- linux-2.6.13-rc6/drivers/usb/mon/Makefile   2005-08-14 20:57:43.0 
-0700
+++ linux-2.6.13-rc6-lem/drivers/usb/mon/Makefile   2005-08-15 
11:25:32.0 -0700
@@ -2,7 +2,7 @@
 # Makefile for USB Core files and filesystem
 #
 
-usbmon-objs:= mon_main.o mon_stat.o mon_text.o
+usbmon-objs:= mon_main.o mon_stat.o mon_text.o mon_dma.o
 
 # This does not use CONFIG_USB_MON because we want this to use a tristate.
 obj-$(CONFIG_USB)  += usbmon.o
diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/mon_dma.c 
linux-2.6.13-rc6-lem/drivers/usb/mon/mon_dma.c
--- linux-2.6.13-rc6/drivers/usb/mon/mon_dma.c  1969-12-31 16:00:00.0 
-0800
+++ linux-2.6.13-rc6-lem/drivers/usb/mon/mon_dma.c  2005-08-15 
16:11:51.0 -0700
@@ -0,0 +1,55 @@
+/*
+ * The USB Monitor, inspired by Dave Harding's USBMon.
+ * 
+ * mon_dma.c: Library which snoops on DMA areas.
+ *
+ * Copyright (C) 2005 Pete Zaitcev ([EMAIL PROTECTED])
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include  /* Only needed for declarations in usb_mon.h */
+#include "usb_mon.h"
+
+#ifdef __i386__/* CONFIG_ARCH_I386 does not exit */
+#define MON_HAS_UNMAP 1
+
+#define phys_to_page(phys) pfn_to_page((phys) >> PAGE_SHIFT)
+
+char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len)
+{
+   struct page *pg;
+   unsigned long flags;
+   unsigned char *map;
+   unsigned char *ptr;
+
+   /*
+* On i386, a DMA handle is the "physical" address of a page.
+* In other words, the bus address is equal to physical address.
+* There is no IOMMU.
+*/
+   pg = phys_to_page(dma_addr);
+
+   /*
+* We are called from hardware IRQs in case of callbacks.
+* But we can be called from softirq or process context in case
+* of submissions. In such case, we need to protect KM_IRQ0.
+*/
+   local_irq_save(flags);
+   map = kmap_atomic(pg, KM_IRQ0);
+   ptr = map + (dma_addr & (PAGE_SIZE-1));
+   memcpy(dst, ptr, len);
+   kunmap_atomic(map, KM_IRQ0);
+   local_irq_restore(flags);
+   return 0;
+}
+#endif /* __i386__ */
+
+#ifndef MON_HAS_UNMAP
+char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len)
+{
+   return 'D';
+}
+#endif
diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/mon_text.c 
linux-2.6.13-rc6-lem/drivers/usb/mon/mon_text.c
--- linux-2.6.13-rc6/drivers/usb/mon/mon_text.c 2005-08-14 20:57:43.0 
-0700
+++ linux-2.6.13-rc6-lem/drivers/usb/mon/mon_text.c 2005-08-15 
11:44:13.0 -0700
@@ -91,25 +91,11 @@ static inline char mon_text_get_data(str
 int len, char ev_type)
 {
int pipe = urb->pipe;
-   unsigned char *data;
-
-   /*
-* The check to see if it's safe to poke at data has an enormous
-* number of corner cases, but it seems that the following is
-* more or less safe.
-*
-* We do not even try to look transfer_buffer, because it can
-* contain non-NULL garbage in case the upper level promised to
-* set DMA for the HCD.
-*/
-   if (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP)
-   return 'D';
 
if (len <= 0)
return 'L';
-
-   if ((data = urb->transfer_buffer) == NULL)
-   return 'Z'; /* '0' would be not as pretty. */
+   if (len >= DATA_MAX)
+   len = DATA_MAX;
 
/*
 * Bulk is easy to shortcut reliably. 
@@ -126,8 +112,21 @@ static inline char mon_text_get_data(str
}
}
 
-   if (len >= DATA_MAX)
-   len = DATA_MAX;
+   /*
+* The check to see if it's safe to poke at data has an enormous
+* number of corner cases, but it seems that the following is
+* more or less safe.
+*
+* We do not even try to look transfer_buffer, because it can
+* contain non-NULL garbage in case the upper level promised to
+* set DMA for the HCD.
+*/
+   if (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP)
+   return mon_dmapeek(ep->data, urb->transfer_dma, len);
+
+   if (urb->transfer_buffer == NULL)
+   return 'Z'; /* '0' would be not as pretty. */
+
memcpy(ep->dat

Re: [Patch] Support UTF-8 scripts

[Pete Zaitcev]

On Mon, 15 Aug 2005 00:55:54 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sul, 2005-08-14 at 15:59 -0400, Lee Revell wrote:

> > I know the alternatives are available.  That doesn't make it any less
> > idiotic to use non ASCII characters as operators.  I think it's a very
> > slippery slope.  We write code in ASCII, dammit.
> 
> Its a trivial patch and there is a lot to be said for UTF-8 scripts. As
> to writing code in ascii, the kernel regularly has outbreaks of either
> UTF-8 or ISO-8859-* especially in the docs directory. Standardising
> these on UTF-8 would be helpful.
> 
> Yes the kernel code is C so ASCII except for the odd abuser of the ©
> symbol.

We write kernel code in ASCII because of patches in e-mail. When a patch
is saved (often by a script), it is divorced of the encoding in which
e-mail was done. Forwarding of patches then causes them to fail to apply.
Everything else can be worked around.

In my experience, the most common case of such patch rejects has to do
with a European using a non-UTF-8 encoding for his name, rather than
with the copyright symbol.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.13-rc6-latest] SCSI disk registration msgs repeat themselves

[Pete Zaitcev]

On Tue, 16 Aug 2005 21:39:33 -0700, Patrick Mansfield <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote:

> >   I just added some usb-storage devices to my system and got the below.

> > Why do the first four lines repeat for each device?  (Not sure if
> > this is a SCSI or USB problem.)
> 
> It is in the partition code. I posted twice before about this with no
> response.

It's not an important problem, presumably. I observe dual revalidations
as well, but they are not that bothersome. Add to it that your patch
appears wrong (see below). If you offered an acceptable solution, I would
expect a warmer welcome... But even then getting a reply from linux-scsi
folks is like pulling a tooth (if my own little CD-ROM sizing patch is
any indication). So, steel yourself for challenges of this life, Patrick!

> The changelog said it was a workaround for a borken device, but not what
> device it was or any other details.

Here's what it was in 2.6.9, as documented in drivers/block/ub.c:

+   /*
+* This is a workaround for a specific problem in our block layer.
+* In 2.6.9, register_disk duplicates the code from rescan_partitions.
+* However, if we do add_disk with a device which persistently reports
+* a changed media, add_disk calls register_disk, which does do_open,
+* which will call rescan_paritions for changed media. After that,
+* register_disk attempts to do it all again and causes double kobject
+* registration and a eventually an oops on module removal.
+*
+* The bottom line is, Al Viro says that we should not allow
+* bdev->bd_invalidated to be set when doing add_disk no matter what.
+*/
+   if (sc->first_open) {
+   if (sc->changed) {
+   sc->first_open = 0;
+   rc = -ENOMEDIUM;
+   goto err_open;
+   }
+   }

Users were hitting it with oopses like these:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0011.html

The ub alone was not suffient to motivate Al for the fix, so I added
this silly "first_open" thingie, which papered over it. It was thought
that sd was miraclously immune.

However, over time users hit it with usb-storage and sd, like this:
 http://lkml.org/lkml/2004/2/21/19
This prompted Al's action. He simply dropped all the extra code like
this:

--- linux-2.6.9-11.5.EL/fs/partitions/check.c   2004-10-18 14:55:07.0 
-0700
+++ linux-2.6.12/fs/partitions/check.c  2005-06-17 12:48:29.0 -0700
@@ -358,24 +357,9 @@ void register_disk(struct gendisk *disk)
if (!bdev)
return;
 
+   bdev->bd_invalidated = 1;
if (blkdev_get(bdev, FMODE_READ, 0) < 0)
return;
-   state = check_partition(disk, bdev);
-   if (state) {
-   for (j = 1; j < state->limit; j++) {
-   sector_t size = state->parts[j].size;
-   sector_t from = state->parts[j].from;
-   if (!size)
-   continue;
-   add_partition(disk, j, from, size);
-#ifdef CONFIG_BLK_DEV_MD
-   if (!state->parts[j].flags)
-   continue;
-   md_autodetect_dev(bdev->bd_dev+j);
-#endif
-   }
-   kfree(state);
-   }
blkdev_put(bdev);
 }
 

I was just about to remove "first_open" from ub, because it's unnecessary
with Al's fix and it was getting on my nerves.

> --- linux-2.6.11-rc1/fs/partitions/check.cFri Dec 24 13:35:28 2004
> +++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c   Fri Jan 21 
> 11:19:00 2005
> @@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
>   bdev->bd_invalidated = 0;
>   for (p = 1; p < disk->minors; p++)
>   delete_partition(disk, p);
> - if (disk->fops->revalidate_disk)
> - disk->fops->revalidate_disk(disk);

As for your proposed fix, it may be problematic. The ->revalidate
method has to be called at least once for a new device, because
that's when drivers fetch the capacities. But ->open only calls
check_disk_change() for removable devices. Who is going to call
->revalidate inside add_disk() for non-removable devices?

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Oops in hidinput_hid_event

[Pete Zaitcev]

On Mon, 25 Jul 2005 20:52:26 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

> Do you expect this patch:
> 
> > --- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 
> > 12:58:47.0 -0700
> > -   struct input_dev *input = &field->hidinput->input;
> > +   struct input_dev *input;
> > -   if (!input)
> > +   if (!field->hidinput)
> > return;
> > +   input = &field->hidinput->input;

> To actually fix the above oops?  It sure looks like it will.
> But I worry whether it is the correct fix?

It is a correct fix, safe to apply. However, Vojtech wrote me that he
will look how exactly an event can be reported without associated
infrastructure. Personally, I suspect that this has something to do
with the motherboard in question. Perhas the PS/2 port is disabled
somehow...

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13 ub 1/3: Axboe's quasi-S/G

[Pete Zaitcev]

This the quasi-S/G patch for ub as suggested by Jens Axboe at OLS and
implemented that night before 4 a.m. Surprisingly, it worked right away...
Alas, I had to skip some OLS partying, but it was for the good cause.
Now the speed of ub is quite acceptable even on partitions with small
block size.

The ub does not really support S/G. Instead, it just tells the block
layer that it does. Then, most of the time, the block layer merges
requests and passes single-segmnent requests down to ub; everything
works as before. Very rarely ub gets an unmerged S/G request. In such
case, it issues several commands to the device.

I added a small array of counters to monitor the merging (sg_stat).
This may be dropped later.

This patch is intended to be merged with 2.6.13 when that is available.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

diff -urp -X dontdiff linux-2.6.13-rc4/drivers/block/ub.c 
linux-2.6.13-rc4-4seg/drivers/block/ub.c
--- linux-2.6.13-rc4/drivers/block/ub.c 2005-07-29 19:51:00.0 -0700
+++ linux-2.6.13-rc4-4seg/drivers/block/ub.c2005-07-30 22:19:55.0 
-0700
@@ -16,9 +16,10 @@
  *  -- verify the 13 conditions and do bulk resets
  *  -- kill last_pipe and simply do two-state clearing on both pipes
  *  -- verify protocol (bulk) from USB descriptors (maybe...)
- *  -- highmem and sg
+ *  -- highmem
  *  -- move top_sense and work_bcs into separate allocations (if they survive)
  * for cache purists and esoteric architectures.
+ *  -- Allocate structure for LUN 0 before the first ub_sync_tur, avoid NULL. ?
  *  -- prune comments, they are too volumnous
  *  -- Exterminate P3 printks
  *  -- Resove XXX's
@@ -171,7 +172,7 @@ struct bulk_cs_wrap {
  */
 struct ub_dev;
 
-#define UB_MAX_REQ_SG  1
+#define UB_MAX_REQ_SG  4
 #define UB_MAX_SECTORS 64
 
 /*
@@ -240,13 +241,21 @@ struct ub_scsi_cmd {
 */
char *data; /* Requested buffer */
unsigned int len;   /* Requested length */
-   // struct scatterlist sgv[UB_MAX_REQ_SG];
 
struct ub_lun *lun;
void (*done)(struct ub_dev *, struct ub_scsi_cmd *);
void *back;
 };
 
+struct ub_request {
+   struct request *rq;
+   unsigned char dir;
+   unsigned int current_block;
+   unsigned int current_sg;
+   unsigned int nsg;   /* sgv[nsg] */
+   struct scatterlist sgv[UB_MAX_REQ_SG];
+};
+
 /*
  */
 struct ub_capacity {
@@ -342,6 +351,8 @@ struct ub_lun {
int readonly;
int first_open; /* Kludge. See ub_bd_open. */
 
+   struct ub_request urq;
+
/* Use Ingo's mempool if or when we have more than one command. */
/*
 * Currently we never need more than one command for the whole device.
@@ -389,6 +400,7 @@ struct ub_dev {
struct bulk_cs_wrap work_bcs;
struct usb_ctrlrequest work_cr;
 
+   int sg_stat[UB_MAX_REQ_SG+1];
struct ub_scsi_trace tr;
 };
 
@@ -398,10 +410,14 @@ static void ub_cleanup(struct ub_dev *sc
 static int ub_bd_rq_fn_1(struct ub_lun *lun, struct request *rq);
 static int ub_cmd_build_block(struct ub_dev *sc, struct ub_lun *lun,
 struct ub_scsi_cmd *cmd, struct request *rq);
-static int ub_cmd_build_packet(struct ub_dev *sc, struct ub_scsi_cmd *cmd,
-struct request *rq);
+static void ub_scsi_build_block(struct ub_lun *lun,
+struct ub_scsi_cmd *cmd, struct ub_request *urq);
+static int ub_cmd_build_packet(struct ub_dev *sc, struct ub_lun *lun,
+struct ub_scsi_cmd *cmd, struct request *rq);
 static void ub_rw_cmd_done(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_end_rq(struct request *rq, int uptodate);
+static int ub_request_advance(struct ub_dev *sc, struct ub_lun *lun,
+struct ub_request *urq, struct ub_scsi_cmd *cmd);
 static int ub_submit_scsi(struct ub_dev *sc, struct ub_scsi_cmd *cmd);
 static void ub_urb_complete(struct urb *urb, struct pt_regs *pt);
 static void ub_scsi_action(unsigned long _dev);
@@ -523,6 +539,13 @@ static ssize_t ub_diag_show(struct devic
cnt += sprintf(page + cnt,
"qlen %d qmax %d\n",
sc->cmd_queue.qlen, sc->cmd_queue.qmax);
+   cnt += sprintf(page + cnt,
+   "sg %d %d %d %d %d\n",
+   sc->sg_stat[0],
+   sc->sg_stat[1],
+   sc->sg_stat[2],
+   sc->sg_stat[3],
+   sc->sg_stat[4]);
 
list_for_each (p, &sc->luns) {
lun = list_entry(p, struct ub_lun, link);
@@ -769,14 +792,15 @@ static int ub_bd_rq_fn_1(struct ub_lun *
return 0;
}
 
+   if (lun->urq.rq != NULL)
+   return -1;
if ((cmd = ub_get_cmd(lun)) == NULL)
return -1;
memset(cmd, 0, sizeof(struct ub_scsi_cmd));
 
blkdev_dequeue_request(rq);
-
if (blk_pc_request(rq)) {
-   rc = ub_cmd_build_packet(sc, cmd, rq);
+   rc = ub_cmd_

2.6.13 ub 2/3: Fold one line

[Pete Zaitcev]

Evidently, Yani Ioannou's display is wider than mine.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

--- linux-2.6.13-rc4-4seg/drivers/block/ub.c2005-07-30 22:19:55.0 
-0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-07-29 22:42:00.0 
-0700
@@ -516,7 +516,8 @@ static void ub_cmdtr_sense(struct ub_dev
}
 }
 
-static ssize_t ub_diag_show(struct device *dev, struct device_attribute *attr, 
char *page)
+static ssize_t ub_diag_show(struct device *dev, struct device_attribute *attr,
+char *page)
 {
struct usb_interface *intf;
struct ub_dev *sc;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.13 ub 3/3: death to ub_bd_rq_fn_1

[Pete Zaitcev]

When Al Viro saw the ub.c, he observed that it was a proof positive of
Linus not reading patches anymore: names like fo_ob_ar_ba_2 used to
cause serious fireworks. In my defence, any good scheme can be pushed
to the realm of absurd if pushed far enough.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

--- linux-2.6.13-rc4-4seg/drivers/block/ub.c2005-07-30 22:19:55.0 
-0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-07-29 22:42:00.0 
-0700
@@ -407,7 +407,7 @@ struct ub_dev {
 /*
  */
 static void ub_cleanup(struct ub_dev *sc);
-static int ub_bd_rq_fn_1(struct ub_lun *lun, struct request *rq);
+static int ub_request_fn_1(struct ub_lun *lun, struct request *rq);
 static int ub_cmd_build_block(struct ub_dev *sc, struct ub_lun *lun,
 struct ub_scsi_cmd *cmd, struct request *rq);
 static void ub_scsi_build_block(struct ub_lun *lun,
@@ -767,20 +768,20 @@ static struct ub_scsi_cmd *ub_cmdq_pop(s
  * The request function is our main entry point
  */
 
-static void ub_bd_rq_fn(request_queue_t *q)
+static void ub_request_fn(request_queue_t *q)
 {
struct ub_lun *lun = q->queuedata;
struct request *rq;
 
while ((rq = elv_next_request(q)) != NULL) {
-   if (ub_bd_rq_fn_1(lun, rq) != 0) {
+   if (ub_request_fn_1(lun, rq) != 0) {
blk_stop_queue(q);
break;
}
}
 }
 
-static int ub_bd_rq_fn_1(struct ub_lun *lun, struct request *rq)
+static int ub_request_fn_1(struct ub_lun *lun, struct request *rq)
 {
struct ub_dev *sc = lun->udev;
struct ub_scsi_cmd *cmd;
@@ -2356,7 +2357,7 @@ static int ub_probe_lun(struct ub_dev *s
disk->driverfs_dev = &sc->intf->dev;/* XXX Many to one ok? */
 
rc = -ENOMEM;
-   if ((q = blk_init_queue(ub_bd_rq_fn, &sc->lock)) == NULL)
+   if ((q = blk_init_queue(ub_request_fn, &sc->lock)) == NULL)
goto err_blkqinit;
 
disk->queue = q;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Question about usb-storage: Sometimes partitions are not recognized.

[Pete Zaitcev]

On Thu, 25 Aug 2005 15:26:27 +0200, Manuel Schneider <[EMAIL PROTECTED]> wrote:

> When I plug them in, they will be recognized by hotplug (I'm using udev), the 
> module usb-storage will be loaded and the device nodes are created.
> 
> BUT: There is normally just ONE device node for the disc block device.
> Partitions are not available.
> I can "solve" this by just starting fdisk (and shutting it down again without 
> changing anything) on the given block device - after that, all the partitions 
> are available. [...]

We need more data. First, "Kernel 2.6.x" is not good enough.
Give us a precise version on which you observe this.
Second, running with CONFIG_USB_STORAGE_DEBUG may yield a useful trace.
I am not quite sure about that though, as this seems to be some
misunderstanding between the block level and SCSI.

Problems with block device open() not working right fall squarely
into purview of Al Viro, but he's quite busy right now. Someone
has to identify the exact scenario. I suppose adding a few printks
around fs/block_dev.c may be more beneficial than any USB debugging.

-- Pete

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB EHCI Problem with Low Speed Devices on kernel 2.6.11+

[Pete Zaitcev]

On Sat, 27 Aug 2005 15:43:11 +0200, Dominik Wezel <[EMAIL PROTECTED]> wrote:

Forwarding to linux-usb-devel with comments.

> Kernel
> ==
> - 2.6.8, 2.6.11.10 and 2.6.12.4, all show same problem

> Problem
> ===
> When turning on the laptop and during POST and GrUB loading, all ports 
> on the hub are enabled.  During the USB initialization phase, when the 
> hub is detected, shortly all ports become disabled, then turn on again 
> (uhci_hcd detects the lo-speed ports).  Upon initialization of ehci_hcd 
> however, the ports are disconnected again (for good):
> 
> ---8<
> Aug 27 14:29:50 solaris kernel: ehci_hcd :00:1d.7: USB 2.0 
> initialized, EHCI 1.00, driver 10 Dec 2004
> Aug 27 14:29:50 solaris kernel: hub 4-0:1.0: USB hub found
> Aug 27 14:29:50 solaris kernel: hub 4-0:1.0: 6 ports detected
> Aug 27 14:29:50 solaris kernel: usb 2-1: USB disconnect, address 2
> Aug 27 14:29:50 solaris kernel: usb 2-1.5: USB disconnect, address 3
> Aug 27 14:29:50 solaris kernel: usb 2-1.6: USB disconnect, address 4
> ---8<
> 
> Addresses 2, 3 and 4 are a keyboard, mouse and palm sync cable respectively.
> 
> and afterwards the log becomes cluttered with:
> 
> ---8<
> Aug 27 14:30:31 solaris kernel: usb 4-3: new high speed USB device using 
> ehci_hcd and address 79
> Aug 27 14:30:31 solaris kernel: usb 4-3: device not accepting address 
> 79, error -71
> Aug 27 14:30:32 solaris kernel: usb 4-3: new high speed USB device using 
> ehci_hcd and address 81
> Aug 27 14:30:32 solaris kernel: usb 4-3: device not accepting address 
> 81, error -71
> Aug 27 14:30:33 solaris kernel: usb 4-3: new high speed USB device using 
> ehci_hcd and address 86
> Aug 27 14:30:34 solaris kernel: usb 4-3: device not accepting address 
> 86, error -71
> Aug 27 14:30:34 solaris kernel: usb 4-3: new high speed USB device using 
> ehci_hcd and address 89
> Aug 27 14:30:35 solaris kernel: usb 4-3: device not accepting address 
> 89, error -71
> Aug 27 14:30:35 solaris kernel: usb 4-3: new high speed USB device using 
> ehci_hcd and address 90
> Aug 27 14:30:35 solaris kernel: usb 4-3: device not accepting address 
> 90, error -71
> ---8<
> 
> first address to be assigned was 30 in all logs, but the number raises 
> mostly in increments of 2 till about 120, then restarts with 12.
> 
> Interestlingly, the keyboard and mouse have been detected immediately 
> before the intialization of ehcihcd:
> 
> ---8<---
> Aug 27 14:29:50 solaris kernel: uhci_hcd :00:1d.2: Intel Corp. 
> 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
> Aug 27 14:29:50 solaris kernel: PCI: Setting latency timer of device 
> :00:1d.2 to 64
> Aug 27 14:29:50 solaris kernel: uhci_hcd :00:1d.2: irq 11, io base 
> 0x1840
> Aug 27 14:29:50 solaris kernel: uhci_hcd :00:1d.2: new USB bus 
> registered, assigned bus number 3
> Aug 27 14:29:50 solaris kernel: hub 3-0:1.0: USB hub found
> Aug 27 14:29:50 solaris kernel: hub 3-0:1.0: 2 ports detected
> /* These are the 2 ports on the laptop */
> Aug 27 14:29:50 solaris kernel: usb 2-1: new full speed USB device using 
> uhci_hcd and address 2
> Aug 27 14:29:50 solaris kernel: hub 2-1:1.0: USB hub found
> Aug 27 14:29:50 solaris kernel: hub 2-1:1.0: 7 ports detected
> /* These are the 7 ports of the external hub */
> Aug 27 14:29:50 solaris kernel: usb 2-1.5: new low speed USB device 
> using uhci_hcd and address 3
> Aug 27 14:29:50 solaris kernel: usb 2-1.6: new low speed USB device 
> using uhci_hcd and address 4
> Aug 27 14:29:50 solaris kernel: usbcore: registered new driver hiddev
> Aug 27 14:29:50 solaris kernel: input: USB HID v1.10 Mouse [Logitech 
> Trackball] on usb-:00:1d.1-1.5
> Aug 27 14:29:50 solaris kernel: input: USB HID v1.10 Keyboard [CHICONY 
> USB Keyboard] on usb-:00:1d.1-1.6
> Aug 27 14:29:50 solaris kernel: input,hiddev96: USB HID v1.10 Device 
> [CHICONY USB Keyboard] on usb-:00:1d.1-1.6
> Aug 27 14:29:50 solaris kernel: usbcore: registered new driver usbhid
> Aug 27 14:29:50 solaris kernel: drivers/usb/input/hid-core.c: v2.0:USB 
> HID core driver
> ---8<---
> 
> which means the ehci_hcd has afterwards superseded uhci_hcd.
> 
> Even more interestingly: in about 5% of the boot cases, ehci_hcd manages 
> to detect the ports correctly (or at least doesn't interfere with uhci). 

Curious.

> Measures taken
> ==
> I've found an article suggesting to
>  echo Y > /sys/module/usbcore/parameters/old_scheme_first

Very funny.

> ---
> I've also found articles suggesting to throw away the hub and get 
> another one, which of course I can't take plain seriously, because now I 
> know the problem of this hub, and I'm not going to change it for a hub 
> whose problem I even don't know yet... =;)

Borrow one for testing.

Also, plug Palm directly into computer. Surely it has more than one
USB connector.

> Measures not taken
> ==
> I didn't test the hub on Microsoft Windows, because I assume that 
> wouldn't add to the solution s

Re: [linux-usb-devel] Re: USB EHCI Problem with Low Speed Devices on kernel 2.6.11+

[Pete Zaitcev]

On Sat, 27 Aug 2005 22:57:45 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 27 Aug 2005, Pete Zaitcev wrote:

> > > Kernel
> > > ==
> > > - 2.6.8, 2.6.11.10 and 2.6.12.4, all show same problem

> > Actually, I suspected that this may be a poorly working Transaction
> > Tranlating (TT) hub. Which then may work on certain versions of
> > Windows.

> It looks to me more like a timing problem with initialization of the
> external high-speed hub.  Try this patch:
> 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112439094723976&w=2

Yes, Dominik, please do. The TT was a poor guess, because IIRC 2.6.8
did not have the support for TT, so it could not get it wrong.

But testing this hub elsewhere _and_ replacing it with a borrowed
hub would be a good idea, IMHO.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel status, "Elitegroup K7S5A"

[Pete Zaitcev]

On Mon, 5 Sep 2005 13:55:46 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

> Re: Elitegroup K7S5A + usb_storage problem
> [linux-usb-devel] Fw: Re: Elitegroup K7S5A + usb_storage problem

This appears to be stuck. It has to have someone with a lot of patience
to play with the device.

Martin collected me a good USB trace from Windows, but I was unable
to figure out what we do differently. The device accepts writes,
everything looks fine, but if unplugged and plugged back, it returns
old data. All commands appear basically the same.

The device, BTW, is called "Fun" and "Stick". Has nothing to do with
memory sticks, of course. Stupid DNT. Anyway, a European Linux hacker
has to get his hands on one of these before any progress can be made:
 
http://www.dnt.de/index.php?dir=details&pid=53038&cat=mp3-128&m_id=mp3-128&h_curr=

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/30] blk_end_request: changing ub (take 4)

[Pete Zaitcev]

On Tue, 11 Dec 2007 17:46:47 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]> 
wrote:

>   if (scsi_status == 0) {
> - uptodate = 1;
> + error = 0;
>   } else {
> - uptodate = 0;
> + error = -EIO;
>   rq->errors = scsi_status;
>   }
> - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> - end_that_request_last(rq, uptodate);
> + if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
> + BUG();

Acked-by: Pete Zaitcev <[EMAIL PROTECTED]>

I follow the discussion, actually, and wanted to ask someone to look
closer if it's appropriate to use __blk_end_request() here.
My understanding was, blk_end_request() is the same thing, only
takes the queue lock. But then, should I refactor ub so that it
calls __blk_end_request if request function ends with an error
and blk_end_request if the end-of-IO even is processed? If not,
and the above is sufficient, why have blk_end_request at all?

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/30] blk_end_request: changing ub (take 4)

[Pete Zaitcev]

On Wed, 12 Dec 2007 15:38:15 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]> 
wrote:
> On Tue, 11 Dec 2007 15:48:03 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:

> > > - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> > > - end_that_request_last(rq, uptodate);
> > > + if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
> > > + BUG();

> > My understanding was, blk_end_request() is the same thing, only
> > takes the queue lock. But then, should I refactor ub so that it
> > calls __blk_end_request if request function ends with an error
> > and blk_end_request if the end-of-IO even is processed?

> I'm using __blk_end_request() here and I think it's sufficient, because:
>   o end_that_request_last() must be called with the queue lock held
>   o ub_end_rq() calls end_that_request_last() without taking
> the queue lock in itself.
> So the queue lock must have been taken outside ub_end_rq().

> But, if ub is calling end_that_request_last() without the queue lock,
> it is a bug in the original code and we should use blk_end_request()
> to fix that.

So, I have to rewrite ub to split the paths after all, right?
Let's do this then: I'll wait until your patch gets to Linus and
then update it with the split. The reason is, I need the whole
enchilada applied and I don't want to bother tracking iterations
and all the little segments (of which you already have 30).
Until then, ub will have a race by using your original small patch.

Best wishes,
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] usb: libusual: locking cleanup

[Pete Zaitcev]

On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:

> I converted the usu_init_notify semaphore to normal mutex usage, and it 
> should still prevent the request_module before the init routine is
> complete. Before it acted more like a complete, now the mutex protects
> two distinct section from running at the same time..

Let's see.

> @@ -178,10 +179,7 @@ static int usu_probe_thread(void *arg)
>   int rc;
>   unsigned long flags;
>  
> - /* A completion does not work here because it's counted. */
> - down(&usu_init_notify);
> - up(&usu_init_notify);
> -
> + mutex_lock(&usu_probe_mutex);
>   rc = request_module(bias_names[type]);

When I tried it, usb-storage would not load with unresolved symbols.
It happens if child (usu_probe_thread) runs ahead of its parent
(usb_usual_init -> usb_register -> usu_probe). It's entirely possible,
depending on your scheduler.

I hate this down-up trick too, so if you have a better idea, I'm all ears.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] usb: libusual: locking cleanup

[Pete Zaitcev]

On Sat, 22 Dec 2007 09:01:50 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:

> Then in usu_probe_thread() your basically stopping it at the start of
> the function with a down(), and the up() is just ancillary .. So you
> could easily move the up() further down in the function and still have
> the same level of exclusion.. 

The unfortunate complication here is request_module. I didn't want to
keep a semaphore locked across it, in case child waits for something.
I wonder if there may be some deadlock that we cannot foresee.
But I guess it won't hurt to try.

I tested the patch and it seems to work ok.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] usb: libusual: locking cleanup

[Pete Zaitcev]

On Sun, 23 Dec 2007 08:46:37 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:

> I noticed you also have a spinlock held in usu_probe_thread(), the
> usu_lock.. That spinlock would preclude anything inside request_module()
> from sleeping..

The usu_lock is not held across request_module. In fact, it can be
easily taken from inside request_module, when it invokes modprobe.
Stop scaring me :-)

> One thing that has bothered me is that I don't see a reason why this
> couldn't become a complete, yet you have a comment which says that it
> can't be a complete.. I honestly didn't understand the comment.. I would
> imagine that you tried a complete , and it didn't work?

Yes, it was a completition initially. But suppose you have two storage
devices, plugged in across a reboot. Two threads are created and have to
wait until the libusual's init function ends. Since we post one completion,
only one thread continues.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Add the infamous Huawei E220 to option.c

[Pete Zaitcev]

Hi, All:

It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.

The problem stems from the fact that both option and usb-storage can bind
to the modem when in storage mode: the former binds because of the storage
class, the latter binds because of VID/PID match. The modprobe loads both,
it's random which wins. If usb-storage wins, everything is fine. If option
wins, it binds to modem still in storage mode and does not work.

I propose we add the same initializer that usb-storage has to the option.
This way no matter which driver wins the modem gets initialized. The
patch is tested on David's modem, but I would like someone give it more
testing.

I dunno, do we want some kind of code sharing between storage and option?
They both could use the normal usb_control_msg, I think.

Also, from archives it looks like Johann may need PID 0x1004 added.

Since we're on topic, David's modem has exactly same IDs as Norbert's,
but works fine with the length of 1. Although it's possible that the
firmware is different without different firmware reported in USB desc-
riptors. Does anyone know a magic AT command? ATI or something?
Norbert, please try my patch, maybe it'll work this time.

And finally, pleas stop using that script from the polish website and
above all quit using the generic serial subdriver. The option must
work now with the patch. Please let me know if it fails.

Thanks in advance,
-- Pete

diff -urp -X dontdiff linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c 
linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c
--- linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c   2007-10-09 
13:31:38.0 -0700
+++ linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c2007-11-27 
21:36:11.0 -0800
@@ -448,7 +448,7 @@ static void option_indat_callback(struct
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err)
printk(KERN_ERR "%s: resubmit read urb failed. "
-   "(%d)", __FUNCTION__, err);
+   "(%d)\n", __FUNCTION__, err);
}
}
return;
@@ -728,6 +728,35 @@ static int option_send_setup(struct usb_
return 0;
 }
 
+static void option_start_huawei(struct usb_serial *serial)
+{
+   struct usb_device *dev = serial->dev;
+   char *buf;
+   int rc;
+
+   if (!(le16_to_cpu(dev->descriptor.idVendor) == HUAWEI_VENDOR_ID &&
+   le16_to_cpu(dev->descriptor.idProduct) == HUAWEI_PRODUCT_E220))
+   return;
+
+   if ((buf = kmalloc(1, GFP_KERNEL)) == 0)
+   goto err_buf;
+
+   buf[0] = 0x1;
+   rc = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+   USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+   0x01, 0x0, buf, 1, 1000);
+   if (rc) {
+   printk(KERN_ERR "%s: HUAWEI E220 setup failed (%d)\n",
+   __FUNCTION__, rc);
+   }
+
+   kfree(buf);
+   return;
+
+err_buf:
+   ;
+}
+
 static int option_startup(struct usb_serial *serial)
 {
int i, err;
@@ -736,6 +765,8 @@ static int option_startup(struct usb_ser
 
dbg("%s", __FUNCTION__);
 
+   option_start_huawei(serial);
+
/* Now setup per port private data */
for (i = 0; i < serial->num_ports; i++) {
port = serial->port[i];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add the infamous Huawei E220 to option.c

[Pete Zaitcev]

On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:

> Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > The problem stems from the fact that both option and usb-storage can bind
> > to the modem when in storage mode: the former binds because of the storage
> > class, the latter binds because of VID/PID match. The modprobe loads both,
> 
> Isn't it possible to fix this in option's module table?

At first thought it'll need adding a field to struct usb_serial to save
the driver_info from the ID table in usb_serial_probe. It's something I'd
like to discuss actually. I hate fields which store information this
way: filled in one place, used in another place... From the perspective
of code prettiness I would rather add another method for usb_serial_probe
to call. But I'm not sure really.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add the infamous Huawei E220 to option.c

[Pete Zaitcev]

On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:

> 3. Make sure usbcore doesn't probe the devices in the wrong mode with the 
> option driver

This fixes duplication. And to take it further, why don't we turn this
idea around and let usb-storage fail to attach with some "ignore" quirk?
I suspect that someone put the initializer into usb-storage in order
to let the generic usb serial to work, but this simply was a bad idea.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add the infamous Huawei E220 to option.c

[Pete Zaitcev]

On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:

> > > Isn't it possible to fix this in option's module table?
> >
> > At first thought it'll need adding a field to struct usb_serial to save
> > the driver_info from the ID table in usb_serial_probe. It's something I'd
> 
> Why? It is passed to the subdrivers in their probe().
> Maybe it should simply be passed in attach(), too?

My bad, you're right. I'm just mentally dead now.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

[Pete Zaitcev]

On Sat, 1 Dec 2007 09:07:38 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:

> is this the only addition that should be needed, ortogether with the
> changes in option to call the huawei init function?

The only one.

> I tried 2.6.24-rc3 with this patch only and it I again got the infinite
> loop of connect/disconnect events instantiating cdroms.

Your problem is something else. Neither my patch nor Jaime's patch
address it. Honestly, I'm not even sure how to tackle it. I seem to
recall that I had a usbmon trace from you but I'm unable to find it now.
Gettin it (again?) probably would be a good place to restart that
investigation.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 12/18] usb: mon nopage

[Pete Zaitcev]

On Wed, 05 Dec 2007 18:15:59 +1100, [EMAIL PROTECTED] wrote:

> Convert USB mon driver from nopage to fault.

>   if (offset >= rp->b_size)
> - return NOPAGE_SIGBUS;
> + return VM_FAULT_SIGBUS;
>   chunk_idx = offset / CHUNK_SIZE;
>   pageptr = rp->b_vec[chunk_idx].pg;
>   get_page(pageptr);
> - if (type)
> - *type = VM_FAULT_MINOR;
> - return pageptr;
> + vmf->page = pageptr;
> + return 0;

Looks like a trivial change, I ack this. It's a rarely used API, I have
to run tests to see how it works. I'll collect any failing pieces later
if any.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

[Pete Zaitcev]

On Wed, 5 Dec 2007 19:23:14 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:

> > Looks good to me, shorter than my patch, has no duplication, allows to
> > use the storage, looks like a winner. Unfortunately, it leaves ub for dead,
> 
> Is that new? How could ub do this up to now?

No, it's not a regression. A user-mode initializer was always required
to use E220 with ub. So, the patch is good.

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

[Pete Zaitcev]

On Fri, 30 Nov 2007 16:30:11 +, Jaime Velasco Juan <[EMAIL PROTECTED]> 
wrote:

> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> - { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
> - { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
> + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
> 0xff, 0xff, 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
> HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },

Looks good to me, shorter than my patch, has no duplication, allows to
use the storage, looks like a winner. Unfortunately, it leaves ub for dead,
because ub cannot invoke the necessary initializer unless we move it to
libusual. But oh well, I'll think about it.

Took me this long to test because I had to ask kind people in England
to replug the modem.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mct232: speed, new termios and compliance cleanups

[Pete Zaitcev]

On Mon, 19 Nov 2007 15:22:11 +, Alan Cox <[EMAIL PROTECTED]> wrote:

> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>

This looks good, but have a couple of comments. Maybe I can fix it up.

>   * we do not know how to support. We ignore them for the moment.
>   * XXX Rate-limit the error message, it's user triggerable.

This XXX item is fixed by this patch, so should be removed.

> + /* FIXME: Can we use any divider - should we do
> +divider = 115200/value;
> +real baud = 115200/divider */
>   switch (value) {
>   case 300: break;

I do not understand this FIXME comment. What is wrong with current
code? The result of the function is given to the device's sequencer.
Do you want to get rid of the switch? Please unconfuse me.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/30] blk_end_request: changing ub (take 4)

[Pete Zaitcev]

On Fri, 14 Dec 2007 12:04:54 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]> 
wrote:

> I have investigated all code paths which call ub_end_rq() in ub.c,
> and confirmed that ub_end_rq() is always called with the queue lock
> held.  (sc->lock is registered as a queue lock.)

Thanks for reminding me about blk_init_queue, I forgot. Sorry for the
confusion.

Greetings,
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/block/ub.c and multiple LUNs

[Pete Zaitcev]

On Mon, 21 Mar 2005 12:42:45 +0100 Jan Kasprzak <[EMAIL PROTECTED]> wrote:

> is the ub.c USB storage driver supposed to work with multi-LUN(?) devices?

There's no reason why it won't, see the attached patch. I just need to
send the patch to Greg Kroah one day.

> PS.: There is no MAINTAINERS file entry for the ub.c driver, and Pete Zaitcev
>   is not even listed in the CREDITS file.

I didn't think it was important, but I see now that if it helps to prevent
the ub traffic from going to Matt, it ought to be done. I'll send a patch.

-- Pete

diff -urp -X dontdiff linux-2.6.12-rc1/drivers/block/ub.c 
linux-2.6.12-rc1-lem/drivers/block/ub.c
--- linux-2.6.12-rc1/drivers/block/ub.c 2005-03-02 16:40:28.0 -0800
+++ linux-2.6.12-rc1-lem/drivers/block/ub.c 2005-03-18 17:31:40.0 
-0800
@@ -8,13 +8,12 @@
  * and is not licensed separately. See file COPYING for details.
  *
  * TODO (sorted by decreasing priority)
+ *  -- Kill first_open (Al Viro fixed the block layer now)
  *  -- Do resets with usb_device_reset (needs a thread context, use khubd)
  *  -- set readonly flag for CDs, set removable flag for CF readers
  *  -- do inquiry and verify we got a disk and not a tape (for LUN mismatch)
- *  -- support pphaneuf's SDDR-75 with two LUNs (also broken capacity...)
  *  -- special case some senses, e.g. 3a/0 -> no media present, reduce retries
  *  -- verify the 13 conditions and do bulk resets
- *  -- normal pool of commands instead of cmdv[]?
  *  -- kill last_pipe and simply do two-state clearing on both pipes
  *  -- verify protocol (bulk) from USB descriptors (maybe...)
  *  -- highmem and sg
@@ -49,7 +48,14 @@
 #define US_SC_SCSI 0x06/* Transparent */
 
 /*
+ * This many LUNs per USB device.
+ * Every one of them takes a host, see UB_MAX_HOSTS.
  */
+#define UB_MAX_LUNS   4
+
+/*
+ */
+
 #define UB_MINORS_PER_MAJOR8
 
 #define UB_MAX_CDB_SIZE  16/* Corresponds to Bulk */
@@ -65,7 +71,7 @@ struct bulk_cb_wrap {
u32 Tag;/* unique per command id */
__le32  DataTransferLength; /* size of data */
u8  Flags;  /* direction in bit 0 */
-   u8  Lun;/* LUN normally 0 */
+   u8  Lun;/* LUN */
u8  Length; /* of of the CDB */
u8  CDB[UB_MAX_CDB_SIZE];   /* max command */
 };
@@ -168,6 +174,7 @@ struct ub_scsi_cmd {
unsigned int len;   /* Requested length */
// struct scatterlist sgv[UB_MAX_REQ_SG];
 
+   struct ub_lun *lun;
void (*done)(struct ub_dev *, struct ub_scsi_cmd *);
void *back;
 };
@@ -252,25 +259,47 @@ struct ub_scsi_cmd_queue {
 };
 
 /*
- * The UB device instance.
+ * The block device instance (one per LUN).
+ */
+struct ub_lun {
+   struct ub_dev *udev;
+   struct list_head link;
+   struct gendisk *disk;
+   int id; /* Host index */
+   int num;/* LUN number */
+   char name[16];
+
+   int changed;/* Media was changed */
+   int removable;
+   int readonly;
+   int first_open; /* Kludge. See ub_bd_open. */
+
+   /* Use Ingo's mempool if or when we have more than one command. */
+   /*
+* Currently we never need more than one command for the whole device.
+* However, giving every LUN a command is a cheap and automatic way
+* to enforce fairness between them.
+*/
+   int cmda[1];
+   struct ub_scsi_cmd cmdv[1];
+
+   struct ub_capacity capacity; 
+};
+
+/*
+ * The USB device instance.
  */
 struct ub_dev {
spinlock_t lock;
-   int id; /* Number among ub's */
atomic_t poison;/* The USB device is disconnected */
int openc;  /* protected by ub_lock! */
/* kref is too implicit for our taste */
unsigned int tagcnt;
-   int changed;/* Media was changed */
-   int removable;
-   int readonly;
-   int first_open; /* Kludge. See ub_bd_open. */
-   char name[8];
+   char name[12];
struct usb_device *dev;
struct usb_interface *intf;
 
-   struct ub_capacity capacity; 
-   struct gendisk *disk;
+   struct list_head luns;
 
unsigned int send_bulk_pipe;/* cached pipe values */
unsigned int recv_bulk_pipe;
@@ -279,10 +308,6 @@ struct ub_dev {
 
struct tasklet_struct tasklet;
 
-   /* XXX Use Ingo's mempool (once we have more than one) */
-   int cmda[1];
-   struct ub_scsi_cmd cmdv[1];
-
struct ub_scsi_cmd_queue cmd_queue;
struct ub_scsi_cmd top_rqs_cmd; /* REQUEST SENSE */
unsigned char top_sense[UB_SENSE_SIZE];
@@ -300,9 +325,9 @@ s

Re: USB ioctl problem in 2.4.28

[Pete Zaitcev]

On Wed, 1 Dec 2004 14:57:41 +0200 (EET), Kaupo Arulo <[EMAIL PROTECTED]> wrote:

> We can use a macro, if it is really necessary

No, I prefer it explicit. See the attached patch. I changed Sergey's patch
just a little, so the invalid ioctls are detected outside the lock.

> IMHO it is correct to return -ENOIOCTLCMD right away, not waiting for 
> freeing a mutex.

Returning ENOIOCTLCMD is never correct, BTW, so I fixed that too.

Someone please test this patch with modem_run and let me know if it works.
I think it should be correct, but I would prefer a confirmation before
this goes to Marcelo.

Thank you in advance,
-- Pete

diff -urp -X dontdiff linux-2.4.29/drivers/usb/devio.c 
linux-2.4.29-usb/drivers/usb/devio.c
--- linux-2.4.29/drivers/usb/devio.c2004-11-22 23:04:18.0 -0800
+++ linux-2.4.29-usb/drivers/usb/devio.c2005-01-31 17:57:45.342576912 
-0800
@@ -1132,6 +1132,8 @@ static int proc_ioctl (struct dev_state 
/* ifno might usefully be passed ... */
retval = driver->ioctl (ps->dev, ctrl.ioctl_code, buf);
/* size = min_t(int, size, retval)? */
+   if (retval == -ENOIOCTLCMD)
+   retval = -ENOTTY;
}
}
 
@@ -1146,24 +1148,10 @@ static int proc_ioctl (struct dev_state 
return retval;
 }
 
-static int usbdev_ioctl(struct inode *inode, struct file *file, unsigned int 
cmd, unsigned long arg)
+static int usbdev_ioctl_exclusive(struct dev_state *ps, struct inode *inode,
+ unsigned int cmd, unsigned long arg)
 {
-   struct dev_state *ps = (struct dev_state *)file->private_data;
-   int ret = -ENOIOCTLCMD;
-
-   if (!(file->f_mode & FMODE_WRITE))
-   return -EPERM;
-   down_read(&ps->devsem);
-   if (!ps->dev) {
-   up_read(&ps->devsem);
-   return -ENODEV;
-   }
-
-   /*
-* grab device's exclusive_access mutex to prevent its driver from
-* using this device while it is being accessed by us.
-*/
-   down(&ps->dev->exclusive_access);
+   int ret;
 
switch (cmd) {
case USBDEVFS_CONTROL:
@@ -1194,14 +1182,6 @@ static int usbdev_ioctl(struct inode *in
inode->i_mtime = CURRENT_TIME;
break;
 
-   case USBDEVFS_GETDRIVER:
-   ret = proc_getdriver(ps, (void *)arg);
-   break;
-
-   case USBDEVFS_CONNECTINFO:
-   ret = proc_connectinfo(ps, (void *)arg);
-   break;
-
case USBDEVFS_SETINTERFACE:
ret = proc_setintf(ps, (void *)arg);
break;
@@ -1220,6 +1200,53 @@ static int usbdev_ioctl(struct inode *in
ret = proc_unlinkurb(ps, (void *)arg);
break;
 
+   case USBDEVFS_CLAIMINTERFACE:
+   ret = proc_claiminterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_RELEASEINTERFACE:
+   ret = proc_releaseinterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_IOCTL:
+   ret = proc_ioctl(ps, (void *) arg);
+   break;
+
+   default:
+   ret = -ENOTTY;
+   }
+   return ret;
+}
+
+static int usbdev_ioctl(struct inode *inode, struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   struct dev_state *ps = file->private_data;
+   int ret;
+
+   if (!(file->f_mode & FMODE_WRITE))
+   return -EPERM;
+   down_read(&ps->devsem);
+   if (!ps->dev) {
+   up_read(&ps->devsem);
+   return -ENODEV;
+   }
+
+   /*
+* Some ioctls don't touch the device and can be called without
+* grabbing its exclusive_access mutex; they are handled in this
+* switch.  Other ioctls which need exclusive_access are handled in
+* usbdev_ioctl_exclusive().
+*/
+   switch (cmd) {
+   case USBDEVFS_GETDRIVER:
+   ret = proc_getdriver(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_CONNECTINFO:
+   ret = proc_connectinfo(ps, (void *)arg);
+   break;
+
case USBDEVFS_REAPURB:
ret = proc_reapurb(ps, (void *)arg);
break;
@@ -1232,19 +1259,28 @@ static int usbdev_ioctl(struct inode *in
ret = proc_disconnectsignal(ps, (void *)arg);
break;
 
+   case USBDEVFS_CONTROL:
+   case USBDEVFS_BULK:
+   case USBDEVFS_RESETEP:
+   case USBDEVFS_RESET:
+   case USBDEVFS_CLEAR_HALT:
+   case USBDEVFS_SETINTERFACE:
+   case USBDEVFS_SETCONFIGURATION:
+   case USBDEVFS_SUBMITURB:
+   case USBDEVFS_DISCARDURB:
case USBDEVFS_CLAIMINTERFACE:
-   ret = proc_claiminterface(ps, (void *)arg);
-   break;
-
case USBDEVFS_RELEASEINTERFACE:
-   ret = proc_releasein