usio
how come MAKEDEV has a reference to usio (usb serial) but src doesnt have any references on creatign this device? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.3-RELEASE kernel freeze(message dumped by ahc driver?)
Thanks for your reply. On Sat, 28 Apr 2001 18:46:47 +0200 Thomas Seck <[EMAIL PROTECTED]> wrote: ; > > I used FreeBSD 4.3-RC(1), and cvsuped with RELENG_4_3_0_RELEASE on > > 27th Apr, did make world, make kernel, and then reboot on 28th. I > > thought there was no problem, but 1 day later, kernel logged following ; > I have a PR open (kern/26880, unexpected busfree errors), cocerning > similar problems with an Adaptec 19160 and Quantum Atlas V discs. > Let's see what Justin T. Gibbs says about it. I have checked your PR. Yes, my SCSI card is Adaptec AHA-2940U, but the HDD is made by IBM... Have you never seen such messages after updating HDD firmware ? If so, I will try to update HDD firmware(but I think it's dangerous for me...). - UEDA Hiroyuki <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
kernel PPP problem
Hello, I run a dial-in server on 4.3-STABLE machine with 2 Multicom cards. Actually, since I updated it two days ago,I get ' /kernel : sio28 : 1 more silo overflow (total ...)' every few seconds. I checked freebsd-questons@, found a lot of questions , some answers about DMA/USB stuff, nothing helped. So, I'm currious does it have something to do with the stable-changes in kernel ppp source/whatever, since I got this after updating. Thank in advance for any clue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.3-RELEASE kernel freeze(message dumped by ahc driver?)
On Apr 29 2001, ?$B?"EDM5G7?(B wrote: > Hello, stable-users. > > I used FreeBSD 4.3-RC(1), and cvsuped with RELENG_4_3_0_RELEASE on > 27th Apr, did make world, make kernel, and then reboot on 28th. I > thought there was no problem, but 1 day later, kernel logged following > message and freeze. > ... I have a PR open (kern/26880, unexpected busfree errors), cocerning similar problems with an Adaptec 19160 and Quantum Atlas V discs. Let's see what Justin T. Gibbs says about it. Regards, Thomas Seck To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
4.3-RELEASE kernel freeze(message dumped by ahc driver?)
Hello, stable-users. I used FreeBSD 4.3-RC(1), and cvsuped with RELENG_4_3_0_RELEASE on 27th Apr, did make world, make kernel, and then reboot on 28th. I thought there was no problem, but 1 day later, kernel logged following message and freeze. Apr 28 03:02:04 www /kernel: (da0:ahc0:0:0:0): SCB 0x4b - timed out in Data-in phase, SEQADDR == 0x7e Apr 28 03:02:05 www /kernel: STACK == 0x70, 0x192, 0x162, 0x0 Apr 28 03:02:05 www /kernel: SXFRCTL0 == 0xa0 Apr 28 03:02:05 www /kernel: ahc0: Dumping Card State at SEQADDR 0x7e Apr 28 03:02:05 www /kernel: SCSISEQ = 0x12, SBLKCTL = 0x2, SSTAT0 0x0 Apr 28 03:02:05 www /kernel: SCB count = 130 Apr 28 03:02:05 www /kernel: Kernel NEXTQSCB = 0 Apr 28 03:02:05 www /kernel: Card NEXTQSCB = 20 Apr 28 03:02:05 www /kernel: QINFIFO entries: 20 123 63 128 Apr 28 03:02:05 www /kernel: Waiting Queue entries: Apr 28 03:02:05 www /kernel: Disconnected Queue entries: Apr 28 03:02:05 www /kernel: QOUTFIFO entries: Apr 28 03:02:05 www /kernel: Sequencer Free SCB List: 6 10 5 9 0 7 2 14 15 3 8 12 1 13 4 Apr 28 03:02:05 www /kernel: Pending list: 128 63 123 20 75 Apr 28 03:02:05 www /kernel: Kernel Free SCB list: 50 49 60 44 52 34 43 7 88 19 127 55 80 70 54 40 1 107 67 31 36 30 105 76 97 12 58 15 51 102 99 65 103 9 10 56 47 5 116 84 2 101 106 129 71 4 111 29 38 87 42 32 115 93 89 78 110 90 48 126 41 14 109 22 119 125 98 96 64 69 6 79 82 45 11 81 61 108 59 16 68 92 73 23 122 118 113 124 46 85 24 37 18 27 117 74 72 8 114 35 94 57 86 53 104 62 120 66 95 83 25 121 100 112 33 17 77 21 3 39 28 91 26 13 Apr 28 03:02:05 www /kernel: sg[0] - Addr 0x670fc00 : Length 1024 Apr 28 03:02:06 www /kernel: (da0:ahc0:0:0:0): BDR message in message buffer Apr 28 03:02:06 www /kernel: (da0:ahc0:0:0:0): SCB 0x4b - timed out in Data-in phase, SEQADDR == 0x7d Apr 28 03:02:06 www /kernel: STACK == 0x70, 0x192, 0x162, 0x0 Apr 28 03:02:06 www /kernel: SXFRCTL0 == 0xa0 Apr 28 03:02:06 www /kernel: ahc0: Dumping Card State at SEQADDR 0x7d Apr 28 03:02:06 www /kernel: SCSISEQ = 0x12, SBLKCTL = 0x2, SSTAT0 0x0 Apr 28 03:02:06 www /kernel: SCB count = 130 Apr 28 03:02:06 www /kernel: Kernel NEXTQSCB = 0 Apr 28 03:02:06 www /kernel: Card NEXTQSCB = 20 Apr 28 03:02:06 www /kernel: QINFIFO entries: 20 123 63 128 Apr 28 03:02:06 www /kernel: Waiting Queue entries: Apr 28 03:02:06 www /kernel: Disconnected Queue entries: Apr 28 03:02:06 www /kernel: QOUTFIFO entries: Apr 28 03:02:06 www /kernel: Sequencer Free SCB List: 6 10 5 9 0 7 2 14 15 3 8 12 1 13 4 Apr 28 03:02:06 www /kernel: Pending list: 128 63 123 20 75 Apr 28 03:02:06 www /kernel: Kernel Free SCB list: 50 49 60 44 52 34 43 7 88 19 127 55 80 70 54 40 1 107 67 31 36 30 105 76 97 12 58 15 51 102 99 65 103 9 10 56 47 5 116 84 2 101 106 129 71 4 111 29 38 87 42 32 115 93 89 78 110 90 48 126 41 14 109 22 119 125 98 96 64 69 6 79 82 45 11 81 61 108 59 16 68 92 73 23 122 118 113 124 46 85 24 37 18 27 117 74 72 8 114 35 94 57 86 53 104 62 120 66 95 83 25 121 100 112 33 17 77 21 3 39 28 91 26 13 Apr 28 03:02:06 www /kernel: sg[0] - Addr 0x670fc00 : Length 1024 Apr 28 03:02:06 www /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 34b Apr 28 03:02:06 www /kernel: ahc0: Issued Channel A Bus Reset. 5 SCBs aborted Maybe there is no relation between this message and kernel freeze, but I have no idea what these messages means. If you have any idea, please teach me what these messages means and how I should do. # To tell the truth, I saw these messages before. But I thought # it was a some problem because of H/W(the SCSI chip is ServeRAID). # But now I have a question because the SCSI card is AHA-2940U # in this time... It's very popular card in FreeBSD users, isn't it? Thanks for your attention and forgive my poor english. UEDA Hiroyuki <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Trouble with 4.3-RELEASE compiler
On Sat, 28 Apr 2001 06:10:00 -0400 Donn Miller <[EMAIL PROTECTED]> wrote: DM> Steve O'Hara-Smith wrote: DM> > It makes me wonder just how safe -O is :( DM> DM> I think Window Maker compiles parts of its code with -O0. Must be for DM> good reason. I think the only time you're going to see a huge DM> you want to make a program run faster, you've got to write implement DM> better algorithms, and its as simple as that. Beyond that, you'll just Couldn't agree more, the part that was worrying me was that there seem to be indications of problems even with -O, and FreeBSD depends on -O to compile. Hence my wondering above ... -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: g++ bug in FreeBSD-4.3
Dimitry Andric writes:
> >Anyway, I came across the following bug report:
> >http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00707.html>. This
> >looks pretty serious.
>
> Sorry, but this is not a bug. The expression:
>
> cout << f(d) << "\t" << d << endl;
>
> is equivalent to:
>
> (((cout << f(d)) << "\t") << d) << endl;
>
> which is equivalent to:
>
>
> (((cout.operator<<(f(d))).operator<<("\t")).operator<<(d)).operator<<(
> endl);
>
> And then you come to the nice part of the story: operator '.' is NOT
> required to evaluate its operands in any particular order! What most
> compilers do with this type of code is produce something like the
> following (in pseudo-assembly):
>
> // push arguments back-to-front:
> push endl;
> push d; // (*) here the value is still 5
> push "\t";
> push d; // still 5
> call f; // here d's value is modified to 1
> // call operator<<'s, popping stack as you go
> call operator<<(double); // for f(d)
> call operator<<(const char*); // for "\t"
> call operator<<(double); // for d, which is 5, see (*)
> call operator<<(endl); // for endl
>
> And this will lead to the results from the bug report. It not only
> happens with g++, but also with VC++ under Win32, for example.
>
> The problem is that you should not put code with side effects (such
> as calling f() in this case) in cout << ... expressions. This will
> lead only to unexpected results. :)
Damn :-) I was hoping I had found the reason that my code had
stopped working, but that does not appear to be the case. Oh well,
I guess I'll have to get back to debugging again, then.
Thanks to you, and to Erik Trulsson, for putting me straight
on this.
//Raymond.
--
Raymond Wiker
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: g++ bug in FreeBSD-4.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2001-04-28 at 14:12 Raymond Wiker wrote:
> Anyway, I came across the following bug report:
>http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00707.html>. This
>looks pretty serious.
Sorry, but this is not a bug. The expression:
cout << f(d) << "\t" << d << endl;
is equivalent to:
(((cout << f(d)) << "\t") << d) << endl;
which is equivalent to:
(((cout.operator<<(f(d))).operator<<("\t")).operator<<(d)).operator<<(
endl);
And then you come to the nice part of the story: operator '.' is NOT
required to evaluate its operands in any particular order! What most
compilers do with this type of code is produce something like the
following (in pseudo-assembly):
// push arguments back-to-front:
push endl;
push d; // (*) here the value is still 5
push "\t";
push d; // still 5
call f; // here d's value is modified to 1
// call operator<<'s, popping stack as you go
call operator<<(double); // for f(d)
call operator<<(const char*); // for "\t"
call operator<<(double); // for d, which is 5, see (*)
call operator<<(endl); // for endl
And this will lead to the results from the bug report. It not only
happens with g++, but also with VC++ under Win32, for example.
The problem is that you should not put code with side effects (such
as calling f() in this case) in cout << ... expressions. This will
lead only to unexpected results. :)
Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP key: http://www.xs4all.nl/~dim/dim.asc
KeyID: 4096/1024-0x2E2096A3
Fingerprint: 7AB4 62D2 CE35 FC6D 4239 4FCD B05E A30A 2E20 96A3
-BEGIN PGP SIGNATURE-
Version: Encrypted with PGP Plugin for Calypso
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm
iQA/AwUBOurBPrBeowouIJajEQJ2TACg1+b4J3OjTEFqpBT747nEcZhr1aUAoJCC
ZRXzJYLt1Ig9MFY4yLNfiNF+
=HO0F
-END PGP SIGNATURE-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: g++ bug in FreeBSD-4.3
On Sat, Apr 28, 2001 at 02:12:51PM +0200, Raymond Wiker wrote:
> I just had a look at the gcc-bugs mailing list archive, at
> http://gcc.gnu.org/ml/gcc-bugs/>. The reason for this is that I
> spent a few hours yesterday on some code that worked about a month
> ago, but now misbehaves in odd ways. I suspect that if I had been a
> less experienced programmer, I would have suspected the compiler
> earlier :-)
>
> Anyway, I came across the following bug report:
> http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00707.html>. This looks
> pretty serious. The code from that bug report is reproduced below; I
> have verified that on my machine (4.3-STABLE FreeBSD 4.3-STABLE #0:
> Fri Apr 27 09:58:39 CEST 2001), the bug occurs with -O0, -O and -O2.
>
> #include
> using namespace std;
> double f(double& x)
> {
> x=1;
> return 2;
> }
> int main()
> {
>double d=5;
>cout << f(d) << "\t" << d << endl;
>// the line below produces correct output of "21"
>// double y=f(d); cout << y << "\t" << d << endl;
> }
>
> This one is *bad* :-(
>
> I don't know how this should be handled; one option might be
> to have a port for gcc 2.95.2.
>
> //Raymond.
I am fairly certain that the bug is in the program, not the compiler.
I am not an expert on C++ but in C at least the order of evaluation of
the different parts of an expression is, in most cases, not specified.
What happens in the program above is almost certainly that 'd' is
evaluated first and then 'f(d)' is evaluated.
Thus the value that is printed for 'd' is the value it had *before* f(d)
was called.
Note that if you change output line to the following it prints "2 1"
cout << f(d) << "t" ; cout << d << endl;
In this case f(d) is guaranteed to be called before d is evaluated.
--
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
g++ bug in FreeBSD-4.3
I just had a look at the gcc-bugs mailing list archive, at
http://gcc.gnu.org/ml/gcc-bugs/>. The reason for this is that I
spent a few hours yesterday on some code that worked about a month
ago, but now misbehaves in odd ways. I suspect that if I had been a
less experienced programmer, I would have suspected the compiler
earlier :-)
Anyway, I came across the following bug report:
http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00707.html>. This looks
pretty serious. The code from that bug report is reproduced below; I
have verified that on my machine (4.3-STABLE FreeBSD 4.3-STABLE #0:
Fri Apr 27 09:58:39 CEST 2001), the bug occurs with -O0, -O and -O2.
#include
using namespace std;
double f(double& x)
{
x=1;
return 2;
}
int main()
{
double d=5;
cout << f(d) << "\t" << d << endl;
// the line below produces correct output of "21"
// double y=f(d); cout << y << "\t" << d << endl;
}
This one is *bad* :-(
I don't know how this should be handled; one option might be
to have a port for gcc 2.95.2.
//Raymond.
--
Raymond Wiker
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Trouble with 4.3-RELEASE compiler
On Sat, 28 Apr 2001, Donn Miller wrote: >If > you want to make a program run faster, you've got to write implement > better algorithms, and its as simple as that. Beyond that, you'll just > have to get faster HW. This in general is true, but back in the days when GCC was a good C compiler that also had a C++ like frontend, -O2 was safe, and if you saw bugs at -O2, 99 out of a hundred times it was an actual bug in the code that was exposed by the optimisation (usually an uninitialised variable). > I think most compilers have optimization bugs, > because you use them with the understanding that they generate > faster/smaller code at the expense of potential side effects. There is no excuse for generating buggy code. The compiler has to take valid C and produce object code that faithfully implements what the source code describes. If the compiler does not do that, it's broken. BSD/OS for the longest time shipped with two C compilers: gcc 1.42 and gcc 2.x, and to this date, BSD/OS ships with a patched gcc in order to take some broken optimisations out. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Trouble with 4.3-RELEASE compiler
On Fri, Apr 27, 2001 at 06:08:34PM -0700, Kris Kennaway wrote: > On Fri, Apr 27, 2001 at 08:38:30PM -0400, User Witr wrote: > > > > [EMAIL PROTECTED] said: > > :-As far as I know FreeBSD doesn't support nor recommened compiling > > :-things (especially large mission critical programs) with anything > > :-higher than -O. > > > > Out of curiosity, how much potential performance is FreeBSD throwing > > away by banning -O2 and -O3? To my naive eyes it would seem better > > to light that candle (try fix the -O2 bug) than curse the darkness. > > Assuming there is significant performance gain and there truly is only > > one major -O2 bug. -O2 used to be considered "safe" didn't it? > > It's not that significant in many cases, it's mostly just useful to > make you feel studly about how massively optimized your system must > be. > > Kris Also, compiling with -O3 can sometimes actually make your code *slower*. This is probably due to the fact that -O3 causes inlining to take place which can easily make the code larger which in turn make the code not fit in the CPU-cache any longer. Generally I would say that one shouldn't use -O3 unless some measurements have been made and -O3 can be shown to actually have a positive effect on the code in question. Compiling with -O2 is usually not worth the bother unless your program is fairly CPU-intensive. Many programs (like text-editors or the kernel) spend most of their time waiting for I/O. In these cases the improvements that -O2 might create are barely measurable. The best way is usually to try to compile a program with different optimization levels and try to measure what difference it makes. For some programs -O2 can cause much better performance than -O. For others the difference is very small and for some -O2 might even generate worse code than -O. The difference between -O and no optimization is usually significant though if only because the code generated by gcc without any optimization being done is fairly inefficient. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Trouble with 4.3-RELEASE compiler
On Sat, Apr 28, 2001 at 09:38:02AM +0200, Steve O'Hara-Smith wrote: > On Sat, 28 Apr 2001 01:27:33 +0200 > "Dimitry Andric" <[EMAIL PROTECTED]> wrote: > > DA> Squid with gcc 2.95.2 and optimization (both -O, -O2 and -O666), and > DA> I can assure you it bombed out with inexplicable null pointer > DA> accesses. Yet when you compile with -O0, no such thing happens... > > I have been working getting swish++ set up as a port (4.3-STABLE) and > I've found that the search program only works if compiled with no -O setting, > -O3 (the original) and -O cause segmentation violation, while -O2 gave an > illegal instruction trap. The index program OTOH appears to work with all > optimisations settings. > > It makes me wonder just how safe -O is :( > Although it is quite possible that gcc generates incorrect code in some cases when invoked with -O it is not very likely. I would say that it is much more likely that the code which is being compiled contains a bug that is exposed by the optimization and that the code just happens to work when comiled with -O0. Generally I would say that -O is *safer* than -O0 for the simple reason that it is used more and therefore gets more testing. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
