Re: Call for testers: acpica-unix-20020815
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 stating that I should extend your vga_pci driver to do the correct actions on suspend/resume or are there also other places that need changes? For starting, I think just extending vga_pci would be OK. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ -
AE_BAD_DATA with acpica-unix-20020815 during boot.
I'd like to make sure if AE_BAD_DATA error occurred w/ previous
versions (acpica-unix-20020725, 20020611, 20020404...) ?
Or first time w/ acpica-unix-20020815 ?
This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1content-type=text/x-cvsweb-markupcvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs/network problems ?
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 current machine, i start (to a fresh,clean,empty src tree) : : cvs -d stable.machine:/var/cvs/os checkout -P src ... : cvs server: Updating src/bin/csh/USD.doc : : and hangs here. I've seen this problem with older versions of CVS. Do you have sufficient disk space (in terms of inodes and free blocks) on your /tmp file system on stable.machine to hold an entire cvs tree? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs/network problems ?
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 yesterday or the day before. : : On the current machine, i start (to a fresh,clean,empty src tree) : : cvs -d stable.machine:/var/cvs/os checkout -P src ... : cvs server: Updating src/bin/csh/USD.doc : : and hangs here. I've seen this problem with older versions of CVS. Do you have sufficient disk space (in terms of inodes and free blocks) on your /tmp file system on stable.machine to hold an entire cvs tree? I'm quite shure now that this problem is a result of a bug somewhere in the ste(4) driver. I already mailed Doug Ambrisko about it. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cbb module build failure
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 / usr/src/sys/modules/pccard/../../dev/pccard/pccard_cis_quirks.c === cbb @ - /usr/src/sys machine - /usr/src/sys/i386/include make: don't know how to make pccbb.c. Stop *** Error code 2 -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cbb module build failure
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
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
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_ device driver can only do 11-12 KBytes/sec :( Another driver (PC-CARD) connected to my Bluetooth stack can do 50-60 KBytes/sec (sending/receiving) - so it is not a Bluetooth stack itself. Also the same USB device connected to Linux box can do 50-60 KBytes/sec - so it is not a USB device itself. The problem only exists when i connect USB device to -current FreeBSD box. I suspect that problem could be in: a) USB device driver b) USB stack itself c) someplace else? Does anyone have a similar problems? I'm slowly going though the diff's between DP1 USB code and -current USB code, but may be someone can give me a clue. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB slowdown on recent -current
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 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_ device driver can only do 11-12 KBytes/sec :( Another driver (PC-CARD) connected to my Bluetooth stack can do 50-60 KBytes/sec (sending/receiving) - so it is not a Bluetooth stack itself. Also the same USB device connected to Linux box can do 50-60 KBytes/sec - so it is not a USB device itself. The problem only exists when i connect USB device to -current FreeBSD box. I suspect that problem could be in: a) USB device driver b) USB stack itself c) someplace else? Does anyone have a similar problems? I'm slowly going though the diff's between DP1 USB code and -current USB code, but may be someone can give me a clue. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB slowdown on recent -current
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 and get 50-60 KBytes/sec even with all debug stuff enabled. so there should be another explanation. 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 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_ device driver can only do 11-12 KBytes/sec :( Another driver (PC-CARD) connected to my Bluetooth stack can do 50-60 KBytes/sec (sending/receiving) - so it is not a Bluetooth stack itself. Also the same USB device connected to Linux box can do 50-60 KBytes/sec - so it is not a USB device itself. The problem only exists when i connect USB device to -current FreeBSD box. I suspect that problem could be in: a) USB device driver b) USB stack itself c) someplace else? Does anyone have a similar problems? I'm slowly going though the diff's between DP1 USB code and -current USB code, but may be someone can give me a clue. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Bob
-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_
-
AE_BAD_DATA with acpica-unix-20020815 during boot.
I'd like to make sure if AE_BAD_DATA error occurred w/ previous
versions (acpica-unix-20020725, 20020611, 20020404...) ?
Or first time w/ acpica-unix-20020815 ?
This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1con
tent-type=text/x-cvsweb-markupcvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 with my dump files] On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: FYI, I have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA with acpica-unix-20020815 during boot. I'd like to make sure if AE_BAD_DATA error occurred w/ previous versions (acpica-unix-20020725, 20020611, 20020404...) ? Or first time w/ acpica-unix-20020815 ? This error did not happened with previous versions of acpi Hmmm... OK, I put your full ASL at: http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1content-type=text/x-cvsweb-markupcvsroot=freebsd-jp Thanks a lot. I must apologize though, I had the same error with previous versions of acpi (I should have checked, sorry, I confounded 2 laptops) Thanks, - yann Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #29: Tue Aug 27 21:35:25 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAZ Preloaded elf kernel /boot/kernel/kernel at 0xc06a7000. Preloaded elf module /boot/kernel/usb.ko at 0xc06a70a8. Preloaded elf module /boot/kernel/ums.ko at 0xc06a7150. Preloaded elf module /boot/kernel/vga_pci.ko at 0xc06a71f8. Preloaded elf module /boot/kernel/acpi.ko at 0xc06a72a4. ACPI_DEBUG: set 'ACPI_ALL_COMPONENTS' ACPI_DEBUG: set 'ACPI_LV_ERROR' ACPI debug layer 0xfff debug level 0x8 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 847427840 Hz CPU: Pentium III/Pentium III Xeon/Celeron (847.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 267780096 (261504K bytes) avail memory = 252694528 (246772K bytes) Pentium Pro MTRR support enabled netsmb_dev: loaded Using $PIR table, 9 entries at 0xc00f0300 npx0: math processor on motherboard npx0: INT 16 interface acpi0: TOSHIB 750 on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib1: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib2 vga_pci0: Generic PCI VGA mem 0xf7ff8000-0xf7ff,0xf800-0xf9ff,0xfbc0-0xfbff,0xfc00-0xfdff irq 11 at device 0.0 on pci1 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib3 pcm0: Yamaha DS-1E (YMF754) port 0xdf3c-0xdf3f,0xdf40-0xdf7f mem 0xf7df8000-0xf7df irq 11 at device 7.0 on pci2 fxp0: Intel Pro/100 Ethernet port 0xdec0-0xdeff mem 0xf7df7000-0xf7df7fff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:00:39:ee:60:38 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: device is routed to IRQ 11 pcic0: TI PCI-1410 PCI-CardBus Bridge irq 11 at device 12.0 on pci2 pcic0: PCI Memory allocated: 0xf7d0 pcic0: TI12XX PCI Config Reg: [pwr save][pci only] pccard0: PC Card 16-bit bus (classic) on pcic0 pcic1: Toshiba ToPIC95B PCI-CardBus Bridge irq 11 at device 13.0 on pci2 pcic1: PCI Memory allocated: 0xf7d01000 pccard1: PC Card 16-bit bus (classic) on pcic1 pcic2: Toshiba ToPIC95B PCI-CardBus Bridge irq 11 at device 13.1 on pci2 pcic2: PCI Memory allocated: 0xf7d02000 pccard2: PC Card 16-bit bus (classic) on pcic2 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xcff0-0xcfff at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xcf80-0xcf9f irq 11 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xcf60-0xcf7f irq 11 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: simple comms at device 31.6 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID
Re: USB slowdown on recent -current
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. Hmmm Anyone care to comment? 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 :( PC-CARD driver works just fine and get 50-60 KBytes/sec even with all debug stuff enabled. so there should be another explanation. 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 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_ device driver can only do 11-12 KBytes/sec :( Another driver (PC-CARD) connected to my Bluetooth stack can do 50-60 KBytes/sec (sending/receiving) - so it is not a Bluetooth stack itself. Also the same USB device connected to Linux box can do 50-60 KBytes/sec - so it is not a USB device itself. The problem only exists when i connect USB device to -current FreeBSD box. I suspect that problem could be in: a) USB device driver b) USB stack itself c) someplace else? Does anyone have a similar problems? I'm slowly going though the diff's between DP1 USB code and -current USB code, but may be someone can give me a clue. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB slowdown on recent -current
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 :( PC-CARD driver works just fine and get 50-60 KBytes/sec even with all debug stuff enabled. so there should be another explanation. Do a cvs diff by date of the Developer's pre-release 1 for the driver and the code areas ou are interested in, and the changes causing the problem will just display (along with other changes, sorry). The easiest approach is usually a bsearch of the code, which is less than 9 compiles to find the day of the change out of a year and a quarter. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Is there any way to add a -s for strict option to the iASL compiler,
in which it generates warnings for this code... but in the absence
of the option, simply pretends it saw the Return, since it knows
that that's the problem anyway, and is just being bitchy by warning
about it instead of warning, but also taking the appropriate corrective
action for this case?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 intended to be the return value of a
function?
Bob
-Original Message-
From: Terry Lambert [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 2:05 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Is there any way to add a -s for strict option to the iASL compiler,
in which it generates warnings for this code... but in the absence
of the option, simply pretends it saw the Return, since it knows
that that's the problem anyway, and is just being bitchy by warning
about it instead of warning, but also taking the appropriate corrective
action for this case?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
next panic on current
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.
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc017a571
stack pointer = 0x10:0xd2fe9ac4
frame pointer = 0x10:0xd2fe9adc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1 (init)
trap number = 12
panic: page fault
Uptime: 4h26m40s
Dumping 1023 MB
ata0: resetting devices ..
(cd0:ata0:0:1:0): lost device
(cd0:ata0:0:1:0): removing device entry
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at ../../../kern/kern_shutdown.c:214
214 dumpsys(dumper);
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:214
#1 0xc01b364e in boot (howto=256) at ../../../kern/kern_shutdown.c:345
#2 0xc01b3bad in panic (fmt=0xc03347e0 page fault)
at ../../../kern/kern_shutdown.c:493
#3 0xc02a9e60 in trap_fatal (frame=0x100, eva=0)
at ../../../i386/i386/trap.c:846
#4 0xc02a9aea in trap_pfault (frame=0xd2fe9a84, usermode=0, eva=40)
at ../../../i386/i386/trap.c:760
#5 0xc02a95e9 in trap (frame=
{tf_fs = -755105768, tf_es = -1071710192, tf_ds = -1021116400, tf_edi =
-1027090432, tf_esi = 0, tf_ebp = -755066148, tf_isp = -755066192, tf_ebx =
-755065992, tf_edx = -102728, tf_ecx = 0, tf_eax = -755065992, tf_trapno = 12,
tf_err = 0, tf_eip = -1072192143, tf_cs = 8, tf_eflags = 66118, tf_esp = -755065992,
tf_ss = 104}) at ../../../i386/i386/trap.c:446
#6 0xc029aba8 in calltrap () at {standard input}:98
#7 0xc02035de in vflush (mp=0xc2c7d800, rootrefs=1, flags=2) at vnode_if.h:309
#8 0xc017a147 in devfs_unmount (mp=0xc2c7d800, mntflags=524288, td=0xc22cdf00)
at ../../../fs/devfs/devfs_vfsops.c:130
#9 0xc01fee42 in dounmount (mp=0xc2c7d800, flags=-1027090432, td=0xc22cdf00)
at ../../../kern/vfs_mount.c:1296
#10 0xc02051ae in vfs_unmountall () at ../../../kern/vfs_subr.c:2923
#11 0xc01b3929 in boot (howto=0) at ../../../kern/kern_shutdown.c:330
#12 0xc01b321c in reboot () at ../../../kern/kern_shutdown.c:154
#13 0xc02aa152 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134875309, tf_esi = -1077936616,
tf_ebp = -1077936856, tf_isp = -755065484, tf_ebx = -1077936696, tf_edx = -1, tf_ecx =
4, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 134547099, tf_cs = 31, tf_eflags
= 583, tf_esp = -1077937060, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#14 0xc029abfd in Xint0x80_syscall () at {standard input}:140
(kgdb) up
#1 0xc01b364e in boot (howto=256) at ../../../kern/kern_shutdown.c:345
345 doadump();
(kgdb)
#2 0xc01b3bad in panic (fmt=0xc03347e0 page fault)
at ../../../kern/kern_shutdown.c:493
493 boot(bootopt);
(kgdb)
#3 0xc02a9e60 in trap_fatal (frame=0x100, eva=0)
at ../../../i386/i386/trap.c:846
846 panic(%s, trap_msg[type]);
(kgdb)
#4 0xc02a9aea in trap_pfault (frame=0xd2fe9a84, usermode=0, eva=40)
at ../../../i386/i386/trap.c:760
760 trap_fatal(frame, eva);
(kgdb)
#5 0xc02a95e9 in trap (frame=
{tf_fs = -755105768, tf_es = -1071710192, tf_ds = -1021116400, tf_edi =
-1027090432, tf_esi = 0, tf_ebp = -755066148, tf_isp = -755066192, tf_ebx =
-755065992, tf_edx = -102728, tf_ecx = 0, tf_eax = -755065992, tf_trapno = 12,
tf_err = 0, tf_eip = -1072192143, tf_cs = 8, tf_eflags = 66118, tf_esp = -755065992,
tf_ss = 104}) at ../../../i386/i386/trap.c:446
446 (void) trap_pfault(frame, FALSE, eva);
(kgdb)
#6 0xc029aba8 in calltrap () at {standard input}:98
in {standard input}
Current language: auto; currently asm
(kgdb)
#7 0xc02035de in vflush (mp=0xc2c7d800, rootrefs=1, flags=2) at vnode_if.h:309
309 rc =
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 actually *GUESS* at what you had intended to be the return value of a function? Is this a trick question? If I had to write my source code to read-only media, with no way to tell whose compiler was going to be used on it, and had no way to fix it afterwards, I think the answer would have to be yes. 8-) 8-). 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 likely intended, rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes - grammar error | FAILS | FAILS | | syntax error| FAILS | WORKS | - 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 -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 no return opcode in the AML. The AML interpreter has nothing to return and things fall apart. However, the error was written in (1) and should have been caught by the ASL compiler in (2). However, there are other ASL compilers out there that do not perform such error-checking. This is how these kinds of problems creep into the BIOS AML code. Bob -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 2:54 PM To: Moore, Robert Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Grover, Andrew Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 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 actually *GUESS* at what you had intended to be the return value of a function? Is this a trick question? If I had to write my source code to read-only media, with no way to tell whose compiler was going to be used on it, and had no way to fix it afterwards, I think the answer would have to be yes. 8-) 8-). 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 likely intended, rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes - grammar error | FAILS | FAILS | | syntax error| FAILS | WORKS | - 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 -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 the original ASL, so there is no return opcode in the AML. The AML interpreter has nothing to return and things fall apart. However, the error was written in (1) and should have been caught by the ASL compiler in (2). However, there are other ASL compilers out there that do not perform such error-checking. This is how these kinds of problems creep into the BIOS AML code. As a consumer of 1-3, I have zero opportunity to fix the problem before item #4. Since use of a trademark or other legal baseball bat (8-)) won't get the code in the BIOS fixed, the only way to make things work in the short term is to either intervene in step #4 or in step #5. In the long term, it'd probably be a good idea to release the source code for the ASL-to-AML compiler under a strict license, and displace all the ASL compilers that fail to do error checking, so problems like this can't arise in the first place. I guess I would like to know if the AML can be recognized as defective by the interpreter, and modify it at step #4 before interning it for interpretation; Windows has to have *some* way of dealing with this, short of supplying replacement AML for every PC ever manufacturered, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 before the method returns -- and therefore any implied return object is long gone by the time the method exits. Toshiba knows about this problem and has agreed to fix it in it's various BIOSs Bob -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 3:40 PM To: Moore, Robert Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Grover, Andrew Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 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 the original ASL, so there is no return opcode in the AML. The AML interpreter has nothing to return and things fall apart. However, the error was written in (1) and should have been caught by the ASL compiler in (2). However, there are other ASL compilers out there that do not perform such error-checking. This is how these kinds of problems creep into the BIOS AML code. As a consumer of 1-3, I have zero opportunity to fix the problem before item #4. Since use of a trademark or other legal baseball bat (8-)) won't get the code in the BIOS fixed, the only way to make things work in the short term is to either intervene in step #4 or in step #5. In the long term, it'd probably be a good idea to release the source code for the ASL-to-AML compiler under a strict license, and displace all the ASL compilers that fail to do error checking, so problems like this can't arise in the first place. I guess I would like to know if the AML can be recognized as defective by the interpreter, and modify it at step #4 before interning it for interpretation; Windows has to have *some* way of dealing with this, short of supplying replacement AML for every PC ever manufacturered, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
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: Tuesday, August 27, 2002 3:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
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
has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
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 that applied against our code to
workaround this problem. While we won't accept that patch into our release,
why can't you keep using it? Then, we get to keep the moral high ground and
you get fewer problems.
Regards -- Andy
Bob
-Original Message-
From: Yann Berthier [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
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
has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of
this erroneous
code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1744] RE: Call for testers: acpica-unix-20020815
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 functioning properly even
now (checked on my Toshiba PORTEGE 3110CT).
Real problem is;
rsirq-0234 [15] RsIrqResource : Invalid interrupt polarity/trigger in
resource list
can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA
I guess that
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
this buffer value causes AE_BAD_DATA error in RsIrqResource() ?
Or
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
wrong value came from from _SB_.MEM_.PAR3 or _SB_.MEM_.PRES ?
I'll track this down...
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
gcc 3.1 / streambuf.h broken with using namespace std;
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, from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/streambuf.h:87: syntax error before `*' token /usr/include/g++/streambuf.h:179: syntax error before `*' token /usr/include/g++/streambuf.h:126: warning: `class ios' only defines private constructors and has no friends /usr/include/g++/streambuf.h:180: syntax error before `*' token /usr/include/g++/streambuf.h:180: ISO C++ forbids declaration of `_tie' with no type /usr/include/g++/streambuf.h:180: `val' was not declared in this scope /usr/include/g++/streambuf.h:180: syntax error before `return' In file included from /usr/include/g++/iostream.h:31, from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/streambuf.h:25:1: unterminated #ifndef In file included from /usr/include/g++/strstream.h:32, from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/iostream.h:25:1: unterminated #ifndef In file included from /usr/include/g++/strstream:6, from test.cc:4: /usr/include/g++/strstream.h:27:1: unterminated #ifndef In file included from test.cc:4: alex@zerogravity ~ $ (5 day old -CURRENT) If you remove the using namespace std;, it works, but libh uses a lot of header files that want to use namespace std and are includes before header files that use strstream, and TBH I'm too lazy to add std:: on bazillion places manually. #if 0 Interestingly enough, I've found a VERY similar bug report at Mirosoft's Support base ;-) http://support.microsoft.com/default.aspx?scid=KB;EN-US;q192539; #endif Thanks for any info :) Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: mutex inp not owned at ../../../netinet/tcp_output.c:131
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 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c034e33a,0,c034d528,e13c49a8,e13c49c8) at Debugger+0x55 panic(c034d528,c0357483,c0358817,83,e13c49c8) at panic+0xfd _mtx_assert(c85660b0,1,c0358817,83,c3d1b600) at _mtx_assert+0xbc tcp_output(c8566100,c92ad8b8,c8566000,c9319970,1600) at tcp_output+0x5a tcp_mtudisc(c8566000,28,10,28,95330600) at tcp_mtudisc+0x103 in6_pcbnotify(c03a71f0,e13c4be0,950f,e13c4c00,1600) at in6_pcbnotify+0x1fb tcp6_ctlinput(5,e13c4be0,e13c4bb0,0,2) at tcp6_ctlinput+0x13e icmp6_notify_error(c3d20900,28,4d8,5,c3d20900) at icmp6_notify_error+0x587 icmp6_input(e13c4cb4,e13c4c8c,3a,c3cfecc0,28) at icmp6_input+0xe89 ip6_input(c3d20900,0,c035af11,ee,1c) at ip6_input+0xc78 ip6intr(c034d337,1a5,c3cf06c0,c3ced800,e13c4d0c) at ip6intr+0x91 swi_net(0,0,c034b774,217,c3cfc2b0) at swi_net+0x23 ithread_loop(c3ced800,e13c4d48,c034b471,369,0) at ithread_loop+0x182 fork_exit(c01d3a60,c3ced800,e13c4d48) at fork_exit+0xaf fork_trampoline() at fork_trampoline+0x1a db panic panic: from debugger cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 10h56m14s Dumping 2047 MB ata0: resetting devices .. panic: KSE not on run queue cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 10h56m15s Terminate ACPI -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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, ^^ There are no such files in gcc 3.1, AFAIK. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 /usr/include/g++/strstream.h:32, ^^ There are no such files in gcc 3.1, AFAIK. There are, but they are in: /usr/include/g++/backward/iostream.h /usr/include/g++/backward/strstream.h That is from my current system from August 18. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 3.1 sucks and 2.9x does not. 8-). Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 - -CURRENT upgrade path is broken then. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. 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. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 compiler version. The -STABLE - -CURRENT upgrade path is broken then. Yes. The same way it leaves the system version of perl installed, instead of deleting it out from under you and forcing you to install the package/port to get perl back. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. 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. If you have anything installed already which you don't rebuild (e.g. C++ libraries), then you will not be able to link the old and new code, since the C++ implementation details have changed sufficiently that object files generated by different versions of the compiler are no longer binary compatible. Going to 3.2 or the 3.3 beta version will at least make an effort toward you not having the problem again, in the future. If you treat -current as a stand-along thing, and not something that's supposed to work all the time, and for which upgrades from source will work without problems, then you won't run into things like this in the future. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
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 compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE - -CURRENT upgrade path is broken then. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. 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. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 likely intended, rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes - grammar error | FAILS | FAILS | | syntax error | FAILS | WORKS | - 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. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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. 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 way. | Everyone knows that dragons don't exist. But while this simplistic | formulation may satisfy the layman, it does not suffice for the | scientific mind. The School of Higher Neantical Nillity is in fact | wholly unconcerned with what does exist. Indeed, the banality of | existence has been so amply demonstrated, there is no need for us to | discuss it any further here. The brilliant Cerebron, attacking the | problem analytically, discovered three distinct kinds of dragon: the | mythical, the chimerical, and the purely hypothetical. They were all, | one might say, nonexistent, but each nonexisted in an entirely | different way ... | -- Stanislaw Lem, Cyberiad 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[] current ? ! TAPE !
Title: Untitled Document ·Îº¸Æ®ÇÒ¸®°¡ ¼®´Þ¸¸¿¡ MasterÇÑ ¼Ó¼º¿µ¾îÇнÀºñ¹ýÀ» ÇÒ¸®°¡ Á÷Á¢ °ø°³ÇÕ´Ï´Ù. ¼¼½º¿µ¾î´Â ±âÁ¸ÀÇ ÇнÀ¹æ¹ýÀ» Å»ÇÇÇÑ »õ·Î¿î ÇнÀ¹æ¹ýÀ¸·Î ´Ü±â°£¿¡ 1200°³ ¿µ¾î¹®ÀåÀ» ¾Ï±âÇÏ°í ¿µ¾îȸȸ¦ ¿Ï¼º ÇÒ ¼ö ÀÖµµ·Ï ÇØÁÝ´Ï´Ù. ¿µ¾î°¡ ³Ñ ½Å³´Ù ...1ÀÏ 30ºÐ¾¿ 100ÀÏÀ̸é 1200°³ Çʼö ¹®Àå ÀÚµ¿ ¾Ï±â´Â ¹°·Ð ¿øÇÏ´Â ÆÐÅÏÀÇ »ýÈ°¿µ¾î Ç¥Çö ±¸»ç±îÁö °¡´ÉÇØÁø´Ù. ¿µ¾î´ëȹ濡¼ ½ÇÀü¿¬½À ...ÀüÈ¿µ¾î ´ëȹ濡¼ ÇнÀ³»¿ëÀ» ¿µ¾î·Î ´ëÈÇÏ¸é¼ ½ÇÀü¿¬½ÀÇÑ´Ù. ¹Ì±¹Àΰ»ç ¹«·á¹èÁ¤) AFKN, CNN..³Ñ Àߵ鸰´Ù ...AFKN¹æ¼ÛÀ» µéÀ» ¶§, ³¸ÀÍÀº ´Ü¾î ¸î °³¸¸ µé¸®°í .³ª¸ÓÁö´Â µé¸®Áö ¾Ê´Âµ¥ ¸®µë°¨°¢,¿¬À½¿ø¸® ¶§¹®¿¡ Á¤Åë ¹Ì±¹¿µ¾î µè±â°¡ °¡´ÉÇØÁø´Ù. ¹«·á»ùÇà ½ÅûÇÏ±â ¡Ø À̸§,ÁÖ¼Ò ÀüȹøÈ£ Ç׸ñÀº ÇʼöÀÔ·ÂÀÔ´Ï´Ù. ¼º ÇÔ (*¹Ýµå½Ã ½Ç¸íÀ» ±âÀçÇØ Áֽñ⠹ٶø´Ï´Ù.) e-mail (¿¹: [EMAIL PROTECTED]) Á÷¾÷ Á÷ÀåÀÎ ÀÚ¿µ¾÷ ´ëÇлý ÃʵîÇлý Áß,°íµîÇлý ÁֺΠ±âŸ »ùÇà ¹ÞÀ¸½Ç ÁÖ¼Ò - ¿ìÆí¹øÈ£ (³ª¸ÓÁö ÁÖ¼Ò¸¦ Á¤È®È÷ Àû¾îÁÖ¼¼¿ä.) ÀüȹøÈ£ - - (¿¹: 02-515-1600) ÇÚµåÆù - - (¿¹: 011-123-4567) ±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù. Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© ±¤°í¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, ¼ö½Å°ÅºÎ ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù. ±ÍÇÏÀÇ ÀüÀÚ ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, ÀúÈñ´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆí ÁÖ¼Ò ¿Ü ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù. ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇØ Áֽʽÿä.
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
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 way. 'delete *' is a *whole lot* worse than `delete: File not found'. (You get the latter either way, actually. :-) There's always a danger in having too much magic. It's okay when the magic does something right part of the time and fizzles out the rest of the time. But when it does something terribly wrong, you have to question the tradeoff. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
