[1.3.3] breaks serial i/o?

[1.3.3] breaks serial i/o?

[William A. Gatliff]

Guys:


I was recently working with Cygwin 1.3.2, doing remote serial
debugging with an ARM Evaluator-7T board using gdb-5.0.  Everything
was just peachy.

Then I upgraded, and things got bad in a hurry.  :^(

Cygwin 1.3.3 seems less stable serialio-wise than 1.3.2.  After
several days of trying, I have yet to establish a complete serial
connection with the board.  And 1.3.3 also seems to require/support
only hardware flow control on the serial lines, where 1.3.2 did not.

I'm running on Win98SE, and can test on NT4 and 2000 if necessary.

At this point, I would be happy just to be able to get Cygwin 1.3.2
back, but alas, I haven't found an archive of it anywhere on the 'net.

To make matters worse, a magazine article I'm writing that describes
how to use Cygwin and GNU tools for arm-elf development is set to
appear in in the December issue of Circuit Cellar Ink magazine.  The
article was written for 1.3.2, and won't currently work with 1.3.3
unless I can figure out what's going on by next Wednesday.  I really
would rather avoid disappointing a new crop of Cygwin and GNU tool
users.

I'm developing patches for gdb-5.0, binutils-2.11.2 and gcc-2.95.3 to
make them build under 1.3.3 (to fix the new export conflicts), but I
haven't figured out what the problem with serial communications is.
If I can't fix the problem, then the article is basically doa.

A draft of the manuscript for the article is at:

http://billgatliff.com/articles/gnu/gnu-arm7t/index.html .

Suggestions, patches, signs of moral support, etc. would all be most
graciously accepted.  Thanks for the help,


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[Christopher Faylor]

On Thu, Oct 18, 2001 at 04:10:03PM -0500, William A. Gatliff wrote:
>I was recently working with Cygwin 1.3.2, doing remote serial
>debugging with an ARM Evaluator-7T board using gdb-5.0.  Everything
>was just peachy.
>
>Then I upgraded, and things got bad in a hurry.  :^(
>
>Cygwin 1.3.3 seems less stable serialio-wise than 1.3.2.  After
>several days of trying, I have yet to establish a complete serial
>connection with the board.  And 1.3.3 also seems to require/support
>only hardware flow control on the serial lines, where 1.3.2 did not.
>
>Suggestions, patches, signs of moral support, etc. would all be most
>graciously accepted.  Thanks for the help,

No suggestions, patches, or signs of moral support here.

You realize that you had 52 lines in your message and the majority of
your text dealt with the reason why you need to have your problem fixed,
right?

It is a curious phenomenon that people often seem to think that
describing the fact that they are having a problem (with the usual
accompanying sense of urgency!) is just the same thing as actually
describing the problem in some detail.  In the next expected step of
this ritual bug reporting technique, a cygwin guru is supoosed to
smack their heads and say "Serial I/O?!  You're right!  It's broken!
Here's a fix."  Unfortunately, that's not the way it works.

If you want this fixed in 1.3.4 then you'll have to provide a test case
which illustrates the problem or some kind of details that would help
someone track down the problem.  For instance, I believe that
http://www.sysinternals.com/ has a utility for monitoring serial I/O.
It might be useful to see what's going on with that utility to help
track down the cygwin problem.

Otherwise, if you can't provide details that would allow to debug this,
dropping back to 1.3.2 will be a short-term "solution" at best since
1.3.2 will disappear when 1.3.4 is released -- any day now.

cgf

Re: [1.3.3] breaks serial i/o?

[William A. Gatliff]

Christopher:


> >Suggestions, patches, signs of moral support, etc. would all be most
> >graciously accepted.  Thanks for the help,
> 
> No suggestions, patches, or signs of moral support here.
> 
> You realize that you had 52 lines in your message and the majority of
> your text dealt with the reason why you need to have your problem fixed,
> right?

Uh, I appreciate the time you spent analyzing the text of my email,
rather than its intent.  Note that my request began with the word
SUGGESTIONS.

> It is a curious phenomenon that people often seem to think that
> describing the fact that they are having a problem (with the usual
> accompanying sense of urgency!) is just the same thing as actually
> describing the problem in some detail.

At the moment, you're looking at all the detail I've got.  I've spent
the last day making sure that other stuff wasn't broken too, I was
hoping that someone would just say "oh yea, we know about that--- it
won't be fixed for a while."  Which would have given me all the
information I needed.

I did, in fact, get an answer like that.  And then I got yours.

> In the next expected step of this ritual bug reporting technique, a
> cygwin guru is supoosed to smack their heads and say "Serial I/O?!
> You're right!  It's broken!  Here's a fix."  Unfortunately, that's
> not the way it works.

I realize that.  You aren't dealing with your typical newbie here.

> If you want this fixed in 1.3.4 then you'll have to provide a test
> case which illustrates the problem or some kind of details that
> would help someone track down the problem.  For instance, I believe
> that http://www.sysinternals.com/ has a utility for monitoring
> serial I/O.  It might be useful to see what's going on with that
> utility to help track down the cygwin problem.

Hmmm, maybe you *did* read the intent of my email after all?  Perhaps
I misjudged you...  Nah.

> Otherwise, if you can't provide details that would allow to debug
> this, dropping back to 1.3.2 will be a short-term "solution" at best
> since 1.3.2 will disappear when 1.3.4 is released -- any day now.

Honestly, I'm actually thinking now that mingw would be a better
long-term solution.  I'm pulling all mention of Cygwin from the
article.


Thanks so much,


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[Grant Edwards]

On Thu, Oct 18, 2001 at 04:10:03PM -0500, William A. Gatliff wrote:

> At this point, I would be happy just to be able to get Cygwin
> 1.3.2 back, but alas, I haven't found an archive of it anywhere
> on the 'net.

I've got a Cygwin source distro snapshot from a few months back
that we're distributing to our customers (along with arm-elf
toolchain) so they can do arm-elf development for our hardware
platform.  I personally haven't done remote stuff under Cygwin,
but others tell me it works. If you like, I could mail you a
CD, or I could put it on my ftp site.  I don't have enough
space for the whole thing, so I'd have to put the "contrib"
packages up seperately after you've grabbed the other stuff.

> To make matters worse, a magazine article I'm writing that
> describes how to use Cygwin and GNU tools for arm-elf
> development is set to appear in in the December issue of
> Circuit Cellar Ink magazine.  The article was written for
> 1.3.2, and won't currently work with 1.3.3 unless I can figure
> out what's going on by next Wednesday.  I really would rather
> avoid disappointing a new crop of Cygwin and GNU tool users.
> 
> I'm developing patches for gdb-5.0, binutils-2.11.2 and
> gcc-2.95.3 to make them build under 1.3.3 (to fix the new
> export conflicts), but I haven't figured out what the problem
> with serial communications is. If I can't fix the problem, then
> the article is basically doa.

That's too bad.  Cygwin has had serial problems in the past,
and I remember people having to install specific Cygwin
versions to get serial ports to work under gdb (and I presume
other apps as well).

> A draft of the manuscript for the article is at:
> 
> http://billgatliff.com/articles/gnu/gnu-arm7t/index.html .
> 
> Suggestions, patches, signs of moral support, etc. would all be
> most graciously accepted.  Thanks for the help,

-- 
Grant Edwards
grante@visi.com

Re: [1.3.3] breaks serial i/o?

[Christopher Faylor]

On Fri, Oct 19, 2001 at 08:56:18AM -0500, William A. Gatliff wrote:
>> >Suggestions, patches, signs of moral support, etc. would all be most
>> >graciously accepted.  Thanks for the help,
>> 
>> No suggestions, patches, or signs of moral support here.
>> 
>> You realize that you had 52 lines in your message and the majority of
>> your text dealt with the reason why you need to have your problem fixed,
>> right?
>
>Uh, I appreciate the time you spent analyzing the text of my email,
>rather than its intent.  Note that my request began with the word
>SUGGESTIONS.

And, guess what? I actually lied.  I supplied some SUGGESTIONS.

>> It is a curious phenomenon that people often seem to think that
>> describing the fact that they are having a problem (with the usual
>> accompanying sense of urgency!) is just the same thing as actually
>> describing the problem in some detail.
>
>At the moment, you're looking at all the detail I've got.  I've spent
>the last day making sure that other stuff wasn't broken too, I was
>hoping that someone would just say "oh yea, we know about that--- it
>won't be fixed for a while."  Which would have given me all the
>information I needed.
>
>I did, in fact, get an answer like that.  And then I got yours.

Huh?  Who sent you an answer like that?  They were wrong.  If something
broke between 1.3.2 and 1.3.3 it should be fixed ASAP.  Right now there
is no knowing what is broken.  Apparently it is something to do with
serial I/O and hardware flow control.  That's all that I know.

>> In the next expected step of this ritual bug reporting technique, a
>> cygwin guru is supoosed to smack their heads and say "Serial I/O?!
>> You're right!  It's broken!  Here's a fix."  Unfortunately, that's
>> not the way it works.
>
>I realize that.  You aren't dealing with your typical newbie here.

Hmm.  It had all of the earmarks of a newbie question.  It had the
description of your life followed by an indication of how urgent your
problem was.

I would have expected that a non-newbie might have provided details
like "I'm connected to my board using a standard crossover serial cable.
The serial settings are 9600 BAUD, no parity.  From inspecting the
gdb code, it looks like the software flow control settings are being
set correctly."  Or, "I set the flow control using the 'mode' command."

I would especially have expected some details if you were in as urgent
need of assistance as you suggested.

>> If you want this fixed in 1.3.4 then you'll have to provide a test
>> case which illustrates the problem or some kind of details that
>> would help someone track down the problem.  For instance, I believe
>> that http://www.sysinternals.com/ has a utility for monitoring
>> serial I/O.  It might be useful to see what's going on with that
>> utility to help track down the cygwin problem.
>
>Hmmm, maybe you *did* read the intent of my email after all?  Perhaps
>I misjudged you...  Nah.

Ditto.

>> Otherwise, if you can't provide details that would allow to debug
>> this, dropping back to 1.3.2 will be a short-term "solution" at best
>> since 1.3.2 will disappear when 1.3.4 is released -- any day now.
>
>Honestly, I'm actually thinking now that mingw would be a better
>long-term solution.  I'm pulling all mention of Cygwin from the
>article.

Ok.  I'm glad that you found a solution that works for you.

And, I'm very glad that you aren't producing an article that instructs
people to search the internet for an old snapshot.  That could easily
have created a lot of confusion in the cygwin mailing list.

cgf

Re: [1.3.3] breaks serial i/o?

[Fernando Nasser]

Grant Edwards wrote:
> 
> That's too bad.  Cygwin has had serial problems in the past,
> and I remember people having to install specific Cygwin
> versions to get serial ports to work under gdb (and I presume
> other apps as well).
> 

Grant,

AFAIK this was a problem with a now very ancient version of Cygwin.
Since that was fixed, I have used several other Cygwin versions 
(after that one) and also know of many people who are using
the serial port without any problem.

If there is a problem now (in the latest Cygwin) it is a new one
and if it is reproducible they will fix it in no time.

Regards,
Fernando

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [1.3.3] breaks serial i/o?

[Grant Edwards]

Somebody in a bad mood wrote:

> >Suggestions, patches, signs of moral support, etc. would all be most
> >graciously accepted.  Thanks for the help,
> 
> No suggestions, patches, or signs of moral support here.

The why not just shut-the-hell-up?

Do you post snotty replies to every question for which you
don't know the answer?  Shit, man, are you trying to
single-handedly give open-source a bad name?

> You realize that you had 52 lines in your message and the
> majority of your text dealt with the reason why you need to
> have your problem fixed, right?

I've met Bill, and I'm pretty sure he was aware of what he
typed.

He's reporting a problem he's having with gdb on a particular
platform and asking if anybody knows anything about it.

There's nothing wrong with that.

-- 
Grant Edwards
grante@visi.com

Re: [1.3.3] breaks serial i/o?

[Christopher Faylor]

On Fri, Oct 19, 2001 at 11:47:16AM -0500, Grant Edwards wrote:
>Somebody in a bad mood wrote:
>>>Suggestions, patches, signs of moral support, etc.  would all be most
>>>graciously accepted.  Thanks for the help,
>>
>>No suggestions, patches, or signs of moral support here.
>
>The why not just shut-the-hell-up?

Ok.  A couple of people have told me in private email that I was out
of line.

I sincerely apologize for my remarks.

However, the suggestions that I offered should help track down the
problem.

If anyone is willing to look into them, then I'll try to help track
down what is going on.

cgf

Re: [1.3.3] breaks serial i/o?

[William A. Gatliff]

Christopher:


> Ok.  A couple of people have told me in private email that I was out
> of line.

Huh, you got those too? :^)

I apologize for sending a poorly-written posting in a moment of
fatigue and frustration.  And I apologize for being an ass in my
followup.

> However, the suggestions that I offered should help track down the
> problem.  If anyone is willing to look into them, then I'll try to
> help track down what is going on.

They are, along with several more that you and others have sent me in
private.  As I get more information on the problem, I'll post it here.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[William A. Gatliff]

Guys:


Here's some of the (apparently) relevant code in gdb's RDI support:



gdb-5.0/gdb/rdi-share/serdrv.c

static int SerialOpen(const char *name, const char *arg)
{
...
 
#ifdef COMPILING_ON_WINDOWS
    {
        int port = IsValidDevice(name);
        if (OpenSerial(port, FALSE) != COM_OK)
            return -1;
    }
#else
    if (Unix_OpenSerial(port_name) < 0)
      return -1;
#endif
...


Since I'm not a Win32 programmer, I don't really know the semantics of
the OpenSerial call.  Does anyone know how to set the flow control
strategy?


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[William A. Gatliff]

Guys (and gals too!):


> Here's some of the (apparently) relevant code in gdb's RDI support:

NOnonono, that was all wrong.  For starters, under Cygwin it doesn't
compile with COMPILING_FOR_WINDOWS at all.

I whipped out the oscilloscope, and confirmed that, in fact, I do get
serialio on com1 under Cygwin 1.3.3 whether CTS/RTS are tied together
or not.  This is news to me, as the problem seemed to follow
CTS/RTS...

I'm now running arm-elf-gdb under gdb under cygwin-1.3.3.  And from
what I've seen so far, there are just general instabilities everywhere
in the serial i/o related stuff.

It seems to frequently hang at line 307 of unixcomm.c, in the
Unix_ReadSerial() function.  It's as if it goes into read(), and never
returns.  Serpfd==3, err==1 in most cases.  It doesn't always hang
there, but it has hung there several times.

Here's the code:

gdb/rdi-share/unixcomm.c

extern int Unix_ReadSerial(unsigned char *buf, int n, bool block)
{
    fd_set fdset;
    struct timeval tv;
    int err;
 
    FD_ZERO(&fdset);
    FD_SET(serpfd, &fdset);
 
    tv.tv_sec = 0;
    tv.tv_usec = (block ? 10000 : 0);
 
    err = select(serpfd + 1, &fdset, NULL, NULL, &tv);
 
    if (err < 0 && errno != EINTR)
    {
#ifdef DEBUG
        perror("select");
#endif
        panic("select failure");
        return -1;
    }
    else if (err > 0 && FD_ISSET(serpfd, &fdset))
      {
        int s;
 
        s = read(serpfd, buf, n);
        if (s < 0)
          perror("read:");
        return s;
...


I'll try it under 1.3.2 and see if I can get any insights (pardon the pun).

Ideas?



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[Christopher Faylor]

On Fri, Oct 19, 2001 at 04:55:50PM -0500, William A. Gatliff wrote:
>I'll try it under 1.3.2 and see if I can get any insights (pardon the pun).

How about the test DLL that I sent you, Bill?  Same results?

cgf

Re: [1.3.3] breaks serial i/o?

[Robert Collins]

Somebody who thinks problems are fixed without details wrote:
>
> Somebody in a bad mood wrote:
>
> > >Suggestions, patches, signs of moral support, etc. would all be
most
> > >graciously accepted.  Thanks for the help,
> >
> > No suggestions, patches, or signs of moral support here.
>
> The why not just shut-the-hell-up?

That would *really* help someone who indicated they had a tight timeline
to solve their problem in. Getting an authoritative answer is the best
they could hope for - and they got it.

> Do you post snotty replies to every question for which you
> don't know the answer?  Shit, man, are you trying to
> single-handedly give open-source a bad name?

You didn't read Chris' email carefully did you. He knows the answer. He
gave it. For clarity the answer was (paraquoted)

1. No known fault here.
2. We cannot reproduce the fault (because the report gave almost NO
details).
3. If the fault is to be fixed pre 1.3.4 (which the report indicated was
a goal) then details are needed to reproduce it.

And not stated, but pretty obvious from a look at the website, and
previous activity on bugs - We *would* like to fix this so *please* go
and generate enough details so we can do that.

> I've met Bill, and I'm pretty sure he was aware of what he
> typed.
>
> He's reporting a problem he's having with gdb on a particular
> platform and asking if anybody knows anything about it.
>
> There's nothing wrong with that.

There's a lot wrong if you *expect* anything to *happen* as a result of
writing the report.

That's like saying "I have a problem with pthreads on linux kernel foo,
help." and expecting a useful reply. Ha!

You might like to read Eric S Raymonds essay on getting help from open
source groups.

Rob

Re: [1.3.3] breaks serial i/o?

[William A. Gatliff]

Robert:


> Somebody who thinks problems are fixed without details wrote:

Look, I really appreciate everyone's opinion on this whole thing.  But
like schoolyard children crowding around a scuffle, now that you're
all here the show is over.  Move along, nothing more to see.  It's a
dead parrot, Jim.  I've got his tricorder, Christoper took his wallet.

Christopher and I have already made nice, both in public *and*
private.  And we all get along just fine, now, thanks.  In fact, we're
both working closely to see what we can learn about this damned
repeatable problem on my setup.


> You might like to read Eric S Raymonds essay on getting help from
> open source groups.

Perhaps, but you may also like to hear why I posted the messaage I
did.  Grant was right--- I was fully aware of what I was writing.  It
wasn't a perfect posting, but if I had to do it all over again I
probably wouldn't change much.

I've been working with GNU stuff for ten years now, and I've learned
the hard way many times that I'm almost *never* the first person to
spot a bug, especially something that seems so obvious as what I'm
grappling with right now.  I'm getting more sophisticated in my use
and adaptation of GNU stuff, though, so I'm seeing new stuff
occasionally, but it's still the exception rather than the rule.

So I provided an open-ended question, in hopes that someone else had
already traveled the road I'm headed down, and already knows something
useful that I can build upon.  Failing that, I am more than happy to
roll up my sleeves and dig in, in hopes that (a) I'll find the
solution, and (b), I'll save someone else the trouble later on.  My
sleeves are rolled up as we speak, in fact.

Before I posted, I searched the mailing list archives and didn't find
anything at all, even by a broadly relevant term like "serial".  This
means two things: everybody knows it's broken so they've stopped
talking about it (which would be news to me), and/or it's a new
problem (which would be news to the Cygwin team *and* me).

So I posted a delibrately open-ended question, along the lines of, "Is
anyone else having problems with serial i/o and just not mentioning
it?  Is it known to be broken, or am I seeing something new here?"  At
the time, I didn't want or need any more detail than that.  The
response I got was just Christopher having a bad day, and my followup
was my having a bad day (which wasn't Christopher's fault btw).

In the meantime, I did get lots of help from people who apparently
caught on to the motivation of my posting.  Some said "here's a link
to 1.3.2, try that,", others said "serialio has been unstable under
Cygwin for some time," and still others said "I'm doing it, it seems
to work fine."  THIS WAS ALL THE DETAIL I WAS AFTER AT THE TIME.

Now that I know which fork in the road to take (yup, it's apparently
broken and nobody knows much about the problem), I can get to work
figuring out what to do about it.  That's exactly what I'm doing, and
Grant can verify that I'm fully capable of providing any level of
detail on this that you guys want to see.

But in the meantime, I also have to do damage control on the article
I'm working on.  I didn't need a detailed response to know what kind
of band-aid to apply to the manuscript, so I didn't spend much time
gathering details before writing the post.  I should have made that
clearer, but I didn't and some of you apparently have some problems
with that.

> That's like saying "I have a problem with pthreads on linux kernel
> foo, help." and expecting a useful reply. Ha!

Your example is a substantially different question, at least if that's
the only detail the poster provides.  Re-read my original posting, and
I think you'll see what I mean.

I don't know what Eric Raymond's essay says (can't find a URL,
actually), but keep in mind that the definition of "useful reply"
varies widely.  Read between the lines of any posting, try to match
the poster's intent in your response, and educate them on what they
need to do next in order to fully engage your services.


Now, let's move on now, ok?



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: [1.3.3] breaks serial i/o?

[Andrew Cagney]

I have a theory,

Dinosaurs are thin at one end, get fat in the middle, and er, sorry that 
is someone elses theory.

Lets try another theory:  GDB's corollary to Goodwin's Law.

``Every discussion about netiquette is reduced to quoting/referencing 
slabs of $GURU's latest manifest.''

As with Goodwin's law, at this point the thread is dead.  Oh, and as 
with Goodwin's law, the self referental nature of this corrolary means 
that invoking it is beyond debate ;-).

enjoy,
Andrew

Re: [1.3.3] breaks serial i/o?

[Robert Collins]

William (or do you prefer Bill as another poster referred to you by?)
I'll use William in the lack of better knowledge :].

Also, sorry for the missive length reply, but I figured that brevity
would not necessarily serve, I was brief before and that apparently
caused a defensive reaction, so I'll be verbose, and probably also
generate a defensive reaction, but *maybe* you'll understand *why* I
critiqued what I did.

Lastly, I'm not sure that this really belongs on gdb as well as cygwin,
but hey :}

----- Original Message -----
From: "William A. Gatliff" <bgat@saturn.billgatliff.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@cygwin.com>; <gdb@sources.redhat.com>
Sent: Sunday, October 21, 2001 6:08 AM
Subject: Re: [1.3.3] breaks serial i/o?


> Robert:
>
...
> all here the show is over.  Move along, nothing more to see.  It's a
> dead parrot, Jim.  I've got his tricorder, Christopher took his
wallet.

Is there such a thing as sol? That is snigger out loud?. Well I did.
Nice one.

> Christopher and I have already made nice, both in public *and*
> private.  And we all get along just fine, now, thanks.  In fact, we're
> both working closely to see what we can learn about this damned
> repeatable problem on my setup.

I can see. That's why I didn't jump in the main discussion. The reason
my response was so late was that I was reading three days worth of email
in one hit. I get a significant amount of mail, so that was a bit
taxing. It - is of course - my problem. However of all the responses,
only one stood out as moving from informative to abusive. I chose to
respond to that email, as I thought and still think it had it's fact's
wrong and a somewhat malicious intent.

> > You might like to read Eric S Raymonds essay on getting help from
> > open source groups.
>
> Perhaps, but you may also like to hear why I posted the messaage I
> did.  Grant was right--- I was fully aware of what I was writing.  It
> wasn't a perfect posting, but if I had to do it all over again I
> probably wouldn't change much.

I wouldn't ask you to change much. You got a sane response to a fairly
clear question. Changing the way you ask questions is something you will
choose or not choose to do. It's not my business to suggest that you
change.

> I've been working with GNU stuff for ten years now, and I've learned
> the hard way many times that I'm almost *never* the first person to
> spot a bug, especially something that seems so obvious as what I'm
> grappling with right now.  I'm getting more sophisticated in my use
> and adaptation of GNU stuff, though, so I'm seeing new stuff
> occasionally, but it's still the exception rather than the rule.

Like you, I've been using GNU and related stuff for a little over ten
years, and I'm consistently surprised by how robust and bug the 'thing'
is. I rarely find existing bugs in any project. Mind you I have one of
those 'oops did I push the limits?' knacks. Anyway, I treat every
potential bug as a potential bug, research it (as you did, via the
web/archives etc), and then - depending on the project - log a bug in a
bug database, check the source, or ask on a mailing list. From your
emails I presume you do much the same. All this paragraph is intended to
convey is that I do not have an issue with *your* behaviour. Some parts
(when you had a bad day ?) weren't optimal for achieving your stated
goals, but that is your issue, not mine.

> So I provided an open-ended question, in hopes that someone else had
> already traveled the road I'm headed down, and already knows something
> useful that I can build upon.  Failing that, I am more than happy to
> roll up my sleeves and dig in, in hopes that (a) I'll find the
> solution, and (b), I'll save someone else the trouble later on.  My
> sleeves are rolled up as we speak, in fact.

Good!.

>
....
>
> So I posted a delibrately open-ended question, along the lines of, "Is
> anyone else having problems with serial i/o and just not mentioning
> it?  Is it known to be broken, or am I seeing something new here?"  At
> the time, I didn't want or need any more detail than that.  The
> response I got was just Christopher having a bad day, and my followup
> was my having a bad day (which wasn't Christopher's fault btw).

I don't recall that email. The question I saw
( http://sources.redhat.com/ml/cygwin/2001-10/msg01064.html ) read
"Suggestions, patches, signs of moral support, etc. would all be most
graciously accepted." In the rest of the email (to avoid out-of-context
issues) there is no request about what other folks experience is or
whether your issue is new. Most (all?) of the statements made about the
bug you experience where made as generalised statements about cygwin
1.3.2 and 1.3.3.

As far as open ended questions go, to save you a little time, here is a
quote from the ESR essay I reference...

"Be explicit about the question you have
Open-ended questions tend to be perceived as open-ended time sinks. The
people most likely to be able to give you a useful answer are also the
busiest people (if only because they take on the most work themselves).
People like that are allergic to open-ended time sinks, thus they tend
to be allergic to open-ended questions.

You are more likely to get a useful response if you are explicit about
what you want respondents to do (provide pointers, send code, check your
patch, whatever). This will focus their effort and implicitly put an
upper bound on the time and energy a respondent has to put in to helping
you. This is good."

Now, looking at your question...
Patches require a known bug. You provided 0 details of the symptoms. Did
gdb hang? Did it crash? Did it send any traffic at all?
Suggestions - as to what I'm not clear.. you mention patching gcc & gdb
to build as well as your serial issue. I'd assume you mean as to the
likely hood of finding your serial fault and fixing it before the
article goes live... which is what Chris email told you the first steps
to doing (among his bad day wrappings )?
And moral support is I presume a throwaway humourous line :].

I considered actually analyzing your inital report and then the extra
info revealed during later discussions - stuff you did know and could
have included - like the fact you'd done a literature search. That sort
of effort makes a big difference in perception. However my intent here
is not to escalate an issue that as you point out has been laid to rest.
Point made.

> to work fine."  THIS WAS ALL THE DETAIL I WAS AFTER AT THE TIME.

Good. William - I'll reiterate. I had no 'issue' with your behaviour.
You and Chris were both striking sparks, but that was about all. Who
cares! If you got what you want, great.

> Grant can verify that I'm fully capable of providing any level of
> detail on this that you guys want to see.

I'll take your word for it. You are working with Chris on the problem,
'nuff said.

> But in the meantime, I also have to do damage control on the article
> I'm working on.  I didn't need a detailed response to know what kind
> of band-aid to apply to the manuscript, so I didn't spend much time
> gathering details before writing the post.  I should have made that
> clearer, but I didn't and some of you apparently have some problems
> with that.

To be clear:

"The reason I responded at all, and in the response critiqued the
original post was simply because Grant asserted that there was nothing
wrong with 'that', and that all you where doing was repoting a bug."

In fact Grant was wrong - you were reporting a bug *under a time
constraint*. That means that time is of the essence for you. Again,
'nuff said.

> > That's like saying "I have a problem with pthreads on linux kernel
> > foo, help." and expecting a useful reply. Ha!
>
> Your example is a substantially different question, at least if that's
> the only detail the poster provides.  Re-read my original posting, and
> I think you'll see what I mean.

I have done so. Let me rephrase myself (not intending parody).
"I recently upgraded my i686 linux kernel from 2.4.5 to 2.4.6 and now I
have a problem with pthreads and gdb. I've been trying for several days
but they don't work. I've got an Alpha and a RISC machine floating
around that I can test on if necessary... Suggestions, patches, signs of
moral support etc..."

> I don't know what Eric Raymond's essay says (can't find a URL,
> actually), but keep in mind that the definition of "useful reply"

http://tuxedo.org/~esr/faqs/smart-questions.html

> varies widely.  Read between the lines of any posting, try to match
> the poster's intent in your response, and educate them on what they
> need to do next in order to fully engage your services.

Hmm, in short, place the onus for *helping you* on *me*? (Or on the
person who actually answered.. Chris in this case.)

Does anything seem a little wrong there? I'll leave you to think about
what payment the respondent gets for his/her services in a volunteer
group and then we can discuss where the onus should be placed.

> Now, let's move on now, ok?

Done. Forgotten. Next thread needed.

Rob

Re: [1.3.3] breaks serial i/o?

[Fernando Nasser]

"William A. Gatliff" wrote:
> 
> Guys:
> 
> I was recently working with Cygwin 1.3.2, doing remote serial
> debugging with an ARM Evaluator-7T board using gdb-5.0.  Everything
> was just peachy.
> 
> (...)

Hi,

You shouldn't be using gdb 5.0 for ARM debugging.  There were many bugs
fixed after that version, including the RDI interface.  Although this
may not be related to your current problem (and yet it may be), it may
be worthy of a try to get a recent GDB snapshot.

Have you tried that?

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9