Re: [acpi-jp 1753] 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.
Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
# iasl Tecra8200.asl
# cp acpi_dsdt.aml /boot/
# echo 'acpi_dsdt_load=YES' /boot/loader.conf
Thanks
--- Tecra8200.asl- Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x1)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x2)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x3)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x4)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x5)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x8)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
Name(_HID, 0x010cd041)
Name(_STA, 0xf)
Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
}
OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
Name(_HID, 0x000ed041)
Name(_UID, 0x2)
Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
}
Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
}
Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
}
Method(_SRS, 1) {
SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
PS3_(0x25)
}
Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
}
Name(_PRW, Package(0x2) {
0xb,
@@ -982,7 +982,7 @@
Device(VDSC) {
Name(_HID, 0x1001a865)
Method(_STA) {
-STA_(0x26)
+Return(STA_(0x26))
}
}
PowerResource(PDOC, 1, 0) {
@@ -1006,7 +1006,7 @@
Event(DKSQ)
Device(DLAN) {
Name(_ADR, 0x000a)
-Name(_EJD, \_SB_.PCI0.PCIB.DOCK)
+Name(_EJD, _SB_.PCI0.PCIB.DOCK)
Re: USB slowdown on recent -current
On Tue, Aug 27, 2002 at 01:46:25PM -0700, Maksim Yevmenkin wrote: 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? That's interesting and was going to be my suggestion. Unfortunately there's a nasty bug in there without that defined, which I've not managed to track down yet. If you come across it please let me know privately and we'll try and nail it. It manifests itself as the bus hanging after a device has been unplugged. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1745] Re: Call for testers: acpica-unix-20020815
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) This is very important fact for me! OK, I'll import 20020815 version today. BTW, Could you check your BIOS setting and see if printer port is disabled? And if so, how about enabling printer port? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CURRENT's termcap broken
Hi Jens, I just updated to the latest -current and my TERM=xterm-color applications (mutt and centericq) are broken. Mutt shows this when I start vi as my editor or run fetchmail: TERMCAP, line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars My centericq window ends up using pipe signs (|), minus signs (-) and plus signs (+) to draw boxes. This breakage is visible with the following revisions of the termcap src files: rev 1.129 of src/share/misc/termcap.src rev 1.5 of src/share/misc/reorder Reverting to these revisions of the termcap src files makes things behave as they did before your changes: rev 1.124 of src/share/misc/termcap.src rev 1.4 of src/share/misc/reorder Any ideas? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 release schedule?
Hi, According to the timetable at http://www.freebsd.org/releases/5.0R/schedule.html, DP2 for FreeBSD 5.0 should have been released over a month ago, but I can't find it on the FTP site. Is it lurking in some strange location, or has it not been released? If the latter, does anybody have any idea of when it will be released? Would I be correct in assuming that 5.0 final will be delayed, as well? Thanks. -- Rod Smith [EMAIL PROTECTED] http://www.rodsbooks.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 release schedule?
It's been under discussion for a while now. Basically, we'll release DP2 when we feel -current is in suitable shape. :-) On Wed, Aug 28, 2002 at 09:08:32AM -0400, Rod Smith wrote: Hi, According to the timetable at http://www.freebsd.org/releases/5.0R/schedule.html, DP2 for FreeBSD 5.0 should have been released over a month ago, but I can't find it on the FTP site. Is it lurking in some strange location, or has it not been released? If the latter, does anybody have any idea of when it will be released? Would I be correct in assuming that 5.0 final will be delayed, as well? Thanks. -- Rod Smith [EMAIL PROTECTED] http://www.rodsbooks.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 release schedule?
I think we're on our way to stabilizing -CURRENT enough for a DP2 soon. I would sit and wait it out just a tad longer. :-) On Wed, Aug 28, 2002 at 09:25:29AM -0400, Michael Lucas wrote: It's been under discussion for a while now. Basically, we'll release DP2 when we feel -current is in suitable shape. :-) On Wed, Aug 28, 2002 at 09:08:32AM -0400, Rod Smith wrote: Hi, According to the timetable at http://www.freebsd.org/releases/5.0R/schedule.html, DP2 for FreeBSD 5.0 should have been released over a month ago, but I can't find it on the FTP site. Is it lurking in some strange location, or has it not been released? If the latter, does anybody have any idea of when it will be released? Would I be correct in assuming that 5.0 final will be delayed, as well? Thanks. -- Rod Smith [EMAIL PROTECTED] http://www.rodsbooks.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI video driver (for Dell Latitude C640)
On Tue, Aug 27, 2002 at 05:58:55PM +0900, Mitsuru IWASAKI wrote: For starting, I think just extending vga_pci would be OK. I hacked up a very rough version of a acpivideo driver for my specific DSDT. My screen now goes off if I suspend. I also think that I figured out what I need to turn it back on on resume , however I have a problem. It seems that the 'device_resume' functions are called rather unreliably. Most of the time it is not called at all, I couldn't find a pattern yet. Is this a known problem? /* * Re-wake the system. * * XXX note that a better two-pass approach with a 'veto' pass * followed by a real thing pass would be better, but the * current bus interface does not provide for this. */ I found this comment, which might be related? So like I said, if I can get the resume function to work, it might be solved. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
Your patches seem to fix three things:
1) Implicit returns
2) Invalid escape sequences (missing double backslashes)
3) Uninitialized Locals
Which one was causing the original problem as reported?
Thanks,
Bob
-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 28, 2002 3:36 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [acpi-jp 1759] 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.
Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
# iasl Tecra8200.asl
# cp acpi_dsdt.aml /boot/
# echo 'acpi_dsdt_load=YES' /boot/loader.conf
Thanks
--- Tecra8200.asl- Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x1)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x2)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x3)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x4)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x5)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x8)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
Name(_HID, 0x010cd041)
Name(_STA, 0xf)
Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
}
OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
Name(_HID, 0x000ed041)
Name(_UID, 0x2)
Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
}
Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
}
Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
}
Method(_SRS, 1) {
SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
PS3_(0x25)
}
Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
}
Name(_PRW, Package(0x2) {
0xb,
@@ -982,7 +982,7 @@
Device(VDSC) {
Re: CURRENT's termcap broken
Dear all, On Wed, Aug 28, 2002 at 02:48:21PM +0200, Sheldon Hearn wrote: # Hi Jens, # # I just updated to the latest -current and my TERM=xterm-color applications # (mutt and centericq) are broken. # # Mutt shows this when I start vi as my editor or run fetchmail: # # TERMCAP, line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars # # My centericq window ends up using pipe signs (|), minus signs (-) and # plus signs (+) to draw boxes. # # This breakage is visible with the following revisions of the termcap src # files: # # rev 1.129 of src/share/misc/termcap.src # rev 1.5 of src/share/misc/reorder # # Reverting to these revisions of the termcap src files makes things # behave as they did before your changes: # # rev 1.124 of src/share/misc/termcap.src # rev 1.4 of src/share/misc/reorder # # Any ideas? Please use plain TERM=xterm which now has color support. If any problems remain, please let me know. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
Sheldon, On Wed, Aug 28, 2002 at 07:35:32PM +0200, Sheldon Hearn wrote: # On (2002/08/28 19:04), Jens Schweikhardt wrote: # # Yes, use plain TERM=xterm. It's got color now as it should. I'm thinking # of removing xterm-color if I can't resolve the enter_alt_charset_mode # stuff. Let me know if TERM=xterm does not work as expected in mutt et al. # I'll post a minor HEADS UP to current@. # # Doesn't work for centericq or mutt. Are you sure? I use mutt too (in an rxvt), and TERM=xterm works wonderfully with colors. Hang on, will test mutt in plain xterm... yes, works there too. I do have customized my .muttrc and app-defaults/XTerm, however to use different colors from the standard ones. Maybe you have a stale termcap.db? cd /usr/src/share/termcap touch termcap.src make make install should run cap_mkdb termcap and install the termcap.db. # I suspect that a lot of # applications will do explicit testing for [axvt]term-color. This is # naughty, but a fact of life. I wonder why/how these work on systems where the termcaps are also taken from the XFree86 xterm. Could it be something else that's different on your system? I find it hard to believe that any app would scan /etc/termcap and ignoring what it finds in the environment variable TERM. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
In the last episode (Aug 28), Jens Schweikhardt said: On Wed, Aug 28, 2002 at 07:35:32PM +0200, Sheldon Hearn wrote: # On (2002/08/28 19:04), Jens Schweikhardt wrote: # Yes, use plain TERM=xterm. It's got color now as it should. I'm # thinking of removing xterm-color if I can't resolve the # enter_alt_charset_mode stuff. Let me know if TERM=xterm does not # work as expected in mutt et al. I'll post a minor HEADS UP to # current@. # # Doesn't work for centericq or mutt. Are you sure? I use mutt too (in an rxvt), and TERM=xterm works wonderfully with colors. Hang on, will test mutt in plain xterm... yes, works there too. Older versions of the mutt port used the slang terminal library, which had (has?) a bug that assumed that all xterms supported color. It didn't matter what your termcap says. If tput Co prints '8', your termcap entry supports colors. If ldd usr/local/bin/mutt shows libslang instead of libncurses, it'll display colors no matter what. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On (2002/08/28 20:32), Jens Schweikhardt wrote: # Yes, use plain TERM=xterm. It's got color now as it should. I'm # thinking of removing xterm-color if I can't resolve the # enter_alt_charset_mode stuff. Let me know if TERM=xterm does not # work as expected in mutt et al. I'll post a minor HEADS UP to # current@. # # Doesn't work for centericq or mutt. Are you sure? I use mutt too (in an rxvt), and TERM=xterm works wonderfully with colors. Hang on, will test mutt in plain xterm... yes, works there too. I do have customized my .muttrc and app-defaults/XTerm, however to use different colors from the standard ones. Maybe you have a stale termcap.db? Argh, how stupid of me. I tried removing TERM=xterm-color without rolling forward to your latest version where xterm has colour support! Your fix works great, thanks. Do you have time to commit mention of it to UPDATING? If so, please draw Bruce Mah's attention to the delta so that he can steal your text for use in the release notes. If not, I'll get around to it eventually. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
On Wed, 28 Aug 2002, Mitsuru IWASAKI wrote: 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. Attached patches will fix the ASL. It seems that no ... :( In fact, enabling the printer port in the bios, as you requested in another post, have the nice side effect to silence the can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA warning. I have now anyway: full suspend / resume with acpi, and routed interrupts so I can now use my embedded wi card, those are two big steps forward. Thanks to all for this ! - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
Sheldon, # Maybe you have a stale termcap.db? # # Argh, how stupid of me. GUMPStupid is who does stupid things/GUMP :-) # I tried removing TERM=xterm-color without rolling forward to your latest # version where xterm has colour support! # # Your fix works great, thanks. # # Do you have time to commit mention of it to UPDATING? If so, please # draw Bruce Mah's attention to the delta so that he can steal your text # for use in the release notes. If not, I'll get around to it eventually. # :-) I just added a note to src/UPDATING. Bruce, are you listening for the release notes? 20020827: Our /etc/termcap now has all the entries from the XFree86 xterm almost unchanged. This means xterm now supports color by default. If you used TERM=xterm-color in the past you now should use TERM=xterm. (xterm-color will lead to benign warnings). Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
If memory serves me right, Jens Schweikhardt wrote: # Do you have time to commit mention of it to UPDATING? If so, please # draw Bruce Mah's attention to the delta so that he can steal your text # for use in the release notes. If not, I'll get around to it eventually. # :-) I just added a note to src/UPDATING. Bruce, are you listening for the release notes? 20020827: Our /etc/termcap now has all the entries from the XFree86 xterm almost unchanged. This means xterm now supports color by default. If you used TERM=xterm-color in the past you now should use TERM=xterm. (xterm-color will lead to benign warnings). I'm on it, thanks for the heads-up. Are you thinking of merging this for 4.7? Bruce. msg42272/pgp0.pgp Description: PGP signature
acpi issues on IBM A30p and -current
Hi,
acpi on my IBM A30p doesn't seem to work as expected.
Closing the display gives me a syslog entry:
...
system power profile changed to 'economy'
acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
sysctl -a | grep acpi gives:
...
debug.acpi_debug_layer: 4095
debug.acpi_debug_level: 45
debug.acpi_ca_version: 537003813
debug.acpi_semaphore_debug: 0
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: S1
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 1
hw.acpi.verbose: 0
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 30
hw.acpi.thermal.tz0.temperature: 3402
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 3647
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 3702
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.battery.life: 100
hw.acpi.battery.time: -1
hw.acpi.battery.state: 0
hw.acpi.battery.units: 2
hw.acpi.battery.info_expire: 5
hw.acpi.acline: 0
machdep.acpi_timer_freq: 3579545
where the *battery* entries do not seem to be right.
BTW:
When re-compiling the A30p.asl file I got with:
acpidump -o A30p.dsdt A30p.asl
I get:
(nihil)(root) # iasl A30p.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20020815 [Aug 28 2002]
Copyright (C) 2000 - 2002 Intel Corporation
Supports ACPI Specification Revision 2.0a
A30p.asl 102: If(\_OSI) {
Error1028 - Too few arguments ^ (\_OSI requires 1)
A30p.asl 103: Windows 2001
Error1037 - syntax error ^
A30p.asl 6492: ShiftLeft(Arg0, 0x8, Local0)
Error1014 - ^ Method argument is not initialized
(Arg0)
A30p.asl 6492: ShiftLeft(Arg0, 0x8, Local0)
Remark 3041 - ^ Not a parameter, used as local only
(Arg0)
ASL Input: A30p.asl - 6947 lines, 253823 bytes, 4688 keywords
Compilation complete. 3 Errors, 0 Warnings, 1 Remarks, 1969 Optimizations
Is the info stored in the BIOS buggy?
Bye!
Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS
A30p.dsdt.gz
Description: application/gunzip
A30p.asl.gz
Description: application/gunzip
dmesg.txt.gz
Description: application/gunzip
Re: USB slowdown on recent -current
Maksim Yevmenkin wrote: 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? Hmm. USB_USE_SOFTINTR is no longer necessary and would cause extra context switches. It should be removed now because the reasons for it existing are long gone in -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. 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 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1766] acpi issues on IBM A30p and -current
Hi,
acpi on my IBM A30p doesn't seem to work as expected.
Closing the display gives me a syslog entry:
...
system power profile changed to 'economy'
acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
It's expected :-)
Because there is no _S1_ object in your ACPI BIOS,
and the system is going to enter S1 sleep by lid switch.
hw.acpi.lid_switch_state: S1
hw.acpi.battery.life: 100
hw.acpi.battery.time: -1
hw.acpi.battery.state: 0
hw.acpi.battery.units: 2
hw.acpi.battery.info_expire: 5
hw.acpi.acline: 0
machdep.acpi_timer_freq: 3579545
where the *battery* entries do not seem to be right.
seem to be right for me. If you concern about time = -1,
never mind, it's normal. Many machines doesn't report
correct info. when AC-line is plugged.
BTW:
When re-compiling the A30p.asl file I got with:
acpidump -o A30p.dsdt A30p.asl
I get:
(nihil)(root) # iasl A30p.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20020815 [Aug 28 2002]
Copyright (C) 2000 - 2002 Intel Corporation
Supports ACPI Specification Revision 2.0a
A30p.asl 102: If(\_OSI) {
Error1028 - Too few arguments ^ (\_OSI requires 1)
Hmmm, our acpidump don't understand _OSI method...
Any volunteers to implement parser for pre-defined methods?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Signal handling changes
It looks like there are still problems with SIGSTOP/SIGCONT signal handling.
With a kernel/world from August 24 and using csh or sh (choice of shell
is probably not relevant), running sleep 30 then suspending it with ^Z
then continuing it with fg causes the sleep process to exit as soon
as it's continued, instead of sleeping for the remainder of the interval
as it does on 4.6.2.
Here's a test program that demonstrates what I mean.. the sleep(1) call in
the parent process is just to avoid a race and isn't part of the bug.
4.6.2-RELEASE i386
5.0-CURRENT i386 built July 1
5.0-CURRENT alpha built July 19
OpenBSD 2.9 i386
SunOS 5.7 sparc
$ ./a.out
30.00 seconds elapsed
5.0-CURRENT i386 built August 24:
$ ./a.out
1.00 seconds elapsed
(wish I had more datapoints for the `broken' case)
#include err.h
#include signal.h
#include time.h
#include unistd.h
int
main(int argc, char *argv[])
{
pid_t pid;
int status;
time_t before, after;
time(before);
if ((pid = fork()) == -1)
err(1, fork);
else if (pid == 0) {
sleep(30);
_exit(0);
}
sleep(1);
kill(pid, SIGSTOP);
kill(pid, SIGCONT);
while (wait(status) != pid)
;
time(after);
printf(%f seconds elapsed\n, difftime(after, before));
exit(0);
}
My first idea was that it had something to do with siginterrupt(), but
errno == 0 after the sleep(3) returns prematurely.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
lukemftpd not logging wtmp?
-w (log sessions to wtmp) is theoretically the default (according to the man page), however FTP sessions never get logged to the wtmp file (or utmp file if '-u' is specified). I searched the mailing list archives but didn't see anything. Before I peak at the code I wanted to see if this was known behavior? This occurs with or without '-r' being specified (I had thought maybe it was because of the privelage reduction but that is not the case apparently). -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lukemftpd not logging wtmp?
Bah. I spoke to quickly. It looks like PR bin/41556 partially addresses this. So it is a known problem. I'll apply the patch listed in the PR. Sorry to bother. -Steve On Wed, Aug 28, 2002 at 10:57:53PM -0500, Steve Ames wrote: -w (log sessions to wtmp) is theoretically the default (according to the man page), however FTP sessions never get logged to the wtmp file (or utmp file if '-u' is specified). I searched the mailing list archives but didn't see anything. Before I peak at the code I wanted to see if this was known behavior? This occurs with or without '-r' being specified (I had thought maybe it was because of the privelage reduction but that is not the case apparently). -Steve 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
