Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Mitsuru IWASAKI
Hi, On Mon, Aug 26, 2002 at 10:32:58PM +0900, Mitsuru IWASAKI wrote: Any volunteers to solve this problem? Well yes, me. Like I said, I don't have experience with ACPI yet, but basicly I need to get this working so that makes me a good candidate ;) Thanks, very cool! Am I correct in

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Mitsuru IWASAKI
Hi, Could you put the following lines into /boot/loader.conf and send dmesg output again? debug.acpi.layer=ACPI_ALL_COMPONENTS debug.acpi.level=ACPI_LV_ERROR [sent privately to not spam the lists with my dump files] On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: FYI, I

Re: cvs/network problems ?

2002-08-27 Thread M. Warner Losh
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Hellmuth Michaelis) writes: : For some days i'm not able to cvs checkout from a stable to a current : machine anymore. The stable machine runs a stable as of today, the current : a currect as of yesterday or the day before. : : On the

Re: cvs/network problems ?

2002-08-27 Thread Hellmuth Michaelis
From the keyboard of M. Warner Losh: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Hellmuth Michaelis) writes: : For some days i'm not able to cvs checkout from a stable to a current : machine anymore. The stable machine runs a stable as of today, the current : a currect as of

cbb module build failure

2002-08-27 Thread David W. Chapman Jr.
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I@/. ./include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/pccard/../.. /dev/pccard/pccard.c /usr/src/sys/modules/pccard/../../dev/pccard/pccard_cis.c /

Re: cbb module build failure

2002-08-27 Thread M. Warner Losh
pccbb is what you want to compile, not cbb. I'll have to pick one of these to keep on. For the moment, I've fixed this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Compaq Notebook Giveaway

2002-08-27 Thread CompaqNotebookGiveaway
We are Giving Away a Compaq EVO Notebook on Aug. 31 2002! Complete the form below to opt-in. Name: Email:

USB slowdown on recent -current

2002-08-27 Thread Maksim Yevmenkin
Hackers, I'm currently testing my Bluetooth code for FreeBSD on recent -current. After i upgraded to recent current from current-DP1 i'm experiencing a major slowdown in USB device speed. On current-DP1 the USB device was able to handle about 50-60 KBytes/sec. On recent -current _the_same_

Re: USB slowdown on recent -current

2002-08-27 Thread Julian Elischer
make sure you have all the debugging turned off. there is a LOT of debugging.. at the moment. On Tue, 27 Aug 2002, Maksim Yevmenkin wrote: Hackers, I'm currently testing my Bluetooth code for FreeBSD on recent -current. After i upgraded to recent current from current-DP1 i'm experiencing

Re: USB slowdown on recent -current

2002-08-27 Thread Maksim Yevmenkin
Julian Elischer wrote: make sure you have all the debugging turned off. there is a LOT of debugging.. at the moment. well, this was my first attempt. it did not work. even if i disable INVARIANTS, WITNESS and USB_DEBUG completely it is still slow as hell :( PC-CARD driver works just fine

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Moore, Robert
This looks like the (in)famous implicit return problem that is in some Toshiba ASL files. Method(_CRS) { CRS_(0x10) } This does NOT actually return a value and the ASL code is incorrect. It has to be: Method(_CRS) {

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Yann Berthier
On Tue, 27 Aug 2002, Mitsuru IWASAKI wrote: Hi, Could you put the following lines into /boot/loader.conf and send dmesg output again? debug.acpi.layer=ACPI_ALL_COMPONENTS debug.acpi.level=ACPI_LV_ERROR Of course, here we go :) [sent privately to not spam the lists

Re: USB slowdown on recent -current

2002-08-27 Thread Maksim Yevmenkin
Hackers, Replying to myself and -current. Strange, but commenting out #define USB_USE_SOFTINTR in /sys/dev/usb_ports.h fixed my problem. USB device back to full speed and now i'm getting solid ~60 KBytes/sec. Note: this is _the_only_ change i made. the rest of the code has not been changed.

Re: USB slowdown on recent -current

2002-08-27 Thread Terry Lambert
Maksim Yevmenkin wrote: Julian Elischer wrote: make sure you have all the debugging turned off. there is a LOT of debugging.. at the moment. well, this was my first attempt. it did not work. even if i disable INVARIANTS, WITNESS and USB_DEBUG completely it is still slow as hell :(

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Terry Lambert
Moore, Robert wrote: This looks like the (in)famous implicit return problem that is in some Toshiba ASL files. Method(_CRS) { CRS_(0x10) } This does NOT actually return a value and the ASL code is incorrect. It has to be:

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Moore, Robert
Well, the *real* problem is that there is no Return AML opcode in the control method and the interpreter therefore does not return a value. However, to answer your question with a question: Would you ask a C compiler, or any other compiler for that matter, to actually *GUESS* at what you had

next panic on current

2002-08-27 Thread Michael Reifenberger
Hi, the panic which belongs to the attached backtrace occured during a normal shutdown. Maybe it might be related to the fact that some time (two hours) before a USB-Disk where inserted and later on ejected. Any clues? Some left over stale pointers? The machine where my IBM A30p Notebook, btw.

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Terry Lambert
Moore, Robert wrote: Well, the *real* problem is that there is no Return AML opcode in the control method and the interpreter therefore does not return a value. However, to answer your question with a question: Would you ask a C compiler, or any other compiler for that matter, to

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Moore, Robert
I think you are missing something: 1) BIOS vendor writes ASL 2) BIOS vendor compiles ASL to AML byte-code 3) BIOS vendor puts AML into BIOS 4) OS gets AML from the BIOS 5) OS interprets AML The error you are experiencing is in (5). There is no return statement in the original ASL, so there is

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Yann Berthier
On Tue, 27 Aug 2002, Moore, Robert wrote: This looks like the (in)famous implicit return problem that is in some Toshiba ASL files. Method(_CRS) { CRS_(0x10) } This does NOT actually return a value and the ASL code is incorrect. It

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Terry Lambert
Moore, Robert wrote: I think you are missing something: 1) BIOS vendor writes ASL 2) BIOS vendor compiles ASL to AML byte-code 3) BIOS vendor puts AML into BIOS 4) OS gets AML from the BIOS 5) OS interprets AML The error you are experiencing is in (5). There is no return statement in

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Moore, Robert
We have to look at each of these on a case-by-case basis. It turns out that it is purely an accident that the code works on windows; by some fluke of their AML interpreter, the value gets returned. Because of architectural differences, the CA interpreter deletes everything that isn't needed

RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Moore, Robert
1) Fix the ASL so that it compiles without errors or warnings 2) Override the BIOS version of the table with your new one. (I don't know how this is done on FreeBSD, someone else will have to help you. Bob -Original Message- From: Yann Berthier [mailto:[EMAIL PROTECTED]] Sent:

RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Grover, Andrew
From: Moore, Robert [mailto:[EMAIL PROTECTED]] 1) Fix the ASL so that it compiles without errors or warnings 2) Override the BIOS version of the table with your new one. (I don't know how this is done on FreeBSD, someone else will have to help you. ISTR someone (Iwasaki-san?) had a patch

Re: [acpi-jp 1744] RE: Call for testers: acpica-unix-20020815

2002-08-27 Thread Mitsuru IWASAKI
Hi, This looks like the (in)famous implicit return problem that is in some Toshiba ASL files. Method(_CRS) { CRS_(0x10) } No, this is not implicit return problem. We have a workaround in ACPI CA code in FreeBSD locally, and it is

gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Alexander Langer
Hi! What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: alex@zerogravity ~ $ cat test.cc using namespace std; #include iostream #include strstream alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31,

panic: mutex inp not owned at ../../../netinet/tcp_output.c:131

2002-08-27 Thread Jun Kuriyama
I don't know why but I cannot get core for this panic. But Dumping 2047 MB message didn't count down and printed next line ata0: resetting devices .. soon. - panic: mutex inp not owned at ../../../netinet/tcp_output.c:131 cpuid = 0; lapic.id = Debugger(panic) Stopped at

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Alexander Kabaev
On Wed, 28 Aug 2002 02:10:06 +0200 Alexander Langer [EMAIL PROTECTED] wrote: alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32,

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Craig Rodrigues
On Tue, Aug 27, 2002 at 08:24:28PM -0400, Alexander Kabaev wrote: On Wed, 28 Aug 2002 02:10:06 +0200 Alexander Langer [EMAIL PROTECTED] wrote: alex@zerogravity ~ $ c++ -pipe -g -fpic -DPIC -Wall -c test.cc In file included from /usr/include/g++/iostream.h:31, from

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Alexander Kabaev
There are, but they are in: /usr/include/g++/backward/iostream.h /usr/include/g++/backward/strstream.h They are in different place = they are different. Alexander, remove /usr/include/g++ before your next installworld. This is FAQ. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Terry Lambert
Alexander Langer wrote: What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. In general, though, the answer is that

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Alexander Langer
Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE -

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Steve Kargl
On Wed, Aug 28, 2002 at 03:21:39AM +0200, Alexander Langer wrote: I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. rm -rf /usr/include/g++ Now, build your new world. -- Steve To Unsubscribe: send mail

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread Terry Lambert
Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous

Re: gcc 3.1 / streambuf.h broken with using namespace std;

2002-08-27 Thread David Leimbach
sstream is the correct header. This is not a bug On Tuesday, August 27, 2002, at 08:21 PM, Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread David Schultz
Thus spake Terry Lambert [EMAIL PROTECTED]: FWIW, there's historical precedent for this: the DEC VAX/VMS C compiler would imply semicolons for the programmer that forgot them, and a couple of other similar fixups, issue a warning, but the resulting code would run as the programmer most

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread Terry Lambert
David Schultz wrote: So the worst possible outcome in the failure case is that it fails -- which it already does, without the assumption -- and the best possible outcome is that it succeeds when it wouldn't have. Anything that works is better than anything that doesn't Sometimes.

[] current ? ! TAPE !

2002-08-27 Thread
Title: Untitled Document

Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

2002-08-27 Thread David Schultz
Thus spake Terry Lambert [EMAIL PROTECTED]: Sometimes. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html I understand, but having a different failure is no worse than having a failure, I think. In either case, it doesn't work, even if it doesn't work in an entirely different