Re: cvs commit: src/sys/pccard pccard_nbk.c pcic.c
After the next commit 'make buildkernel' stops in
'sys/modules/oldcard' directory. After applaing the following patch
I can make buildkernel.
N.Dudorov
imp 2000/08/10 10:35:11 PDT
Modified files:
sys/pccard pccard_nbk.c pcic.c
Log:
Add some infrastructure support for dealing with large attribute
memory space needed by the raylink driver (in progress, nearing
completion).
This is a minorly cleaned up diff from Duncan to help him reduce the
diffs from stock FreeBSD.
Submitted by: Duncan Barclay [EMAIL PROTECTED]
Revision ChangesPath
1.20 +10 -1 src/sys/pccard/pccard_nbk.c
1.95 +53 -6 src/sys/pccard/pcic.c
Index: sys/dev/pccard/card_if.m
===
RCS file: /store/CVS/src/sys/dev/pccard/card_if.m,v
retrieving revision 1.6
diff -b -u -r1.6 card_if.m
--- sys/dev/pccard/card_if.m2000/06/18 05:02:09 1.6
+++ sys/dev/pccard/card_if.m2000/08/11 06:00:24
@@ -66,6 +66,13 @@
u_int32_t offset;
}
+METHOD int get_memory_offset {
+ device_t dev;
+ device_t child;
+int rid;
+u_int32_t *offset;
+}
+
#
# pccard bridges call this method to initate the attachment of a card
#
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Hi, here is the latest (and maybe final?) report on our ACPI project's : progress. : : We are ready now to merge our work on ACPI into main source tree! Bravo! Wonderful work! Thanks. I think we need to implement power management features by ACPI replacing APM at least before BIOS w/o APM become majority... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount hangs system
Benedikt Schmidt wrote: Everytime I try to unmount one of the ufs partitions on my harddisk the system hangs and I can do nothing but a hard reset. This happens whenever I shutdown the system too. It tries to unmount one of the partitions and hangs before the "dirty flag" is removed from any of the partitions. Thats why all the partitions are checked/repaired by fsck _everytime_ I boot. I have no problem whith unmounting nfs/msdos/ext2 partitions. This problem appeared some weeks ago and I never had it before with -current. Any ideas how the problem can be solved ? Did you take the "device apm" out of your kernel? I saw this same behavior on my laptop when I took apm out of my kernel. When I put it back in everything was back to normal. ___ Benedikt Schmidt -- ___ Evan Oldford * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pccard pccard_nbk.c pcic.c
In message [EMAIL PROTECTED] Nickolay Dudorov writes: : After the next commit 'make buildkernel' stops in : 'sys/modules/oldcard' directory. After applaing the following patch : I can make buildkernel. I broke this, I'm sorry. I just committed a fix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
Well, I've failed in my main objective (to deuglify the shutdown messages), but an interesting debate has resulted instead, so I can't feel too bad. I did a little research to support my position on sleep/wakeup, and here's the best I have. This is pretty long, and unlikely to shake your world view, so those of you with drooping eyelids can just head over to slashdot, or something. :-) Some pseudo code from "The Design of the Unix Operating System", by Maurice Bach, page 33 shows how sleep() is used: while (condition is true) sleep (event: the condition becomes false); set condition true; and the next page shows how wakeup() is used: set condition false; wakeup (event: the condition is false); In the description, it says `Thus, the "while-sleep" loop insures that at most one process can gain access to a resource.' Not the most convincing evidence, but on the other hand, he does not mention the idea of *not* protecting against sudden wakeup. From "Writing a Unix Device Driver", by Egan and Teixeira, on page 92 we find It is not uncommon for several processes to sleep on the same channel. They may be competing for the same resource, or they may be waiting for different reasons that have been associated with the same channel value. In this situation a single wakeup call on the common channel will cause all the sleeping processes to become executable; ... A driver routine must not assume that it can proceed after a return from a sleep call. It should check to see whether the event it was waiting for has actually occurred; if it has not it should sleep again, and repeat this cycle until the awaited event has actually occurred. The book is oriented rather towards I/O, so perhaps not all possible uses of routines are covered. But again, no mention of *not* using a while loop. Quite the opposite. Also "Magic Garden Explained" points out that you really want to sleep on an "event", but all you have is the address of some data. So, you often have multiple semantically different events represented by the same integer wakeup channel. A good reason to program defensively, I think. But the best evidence is from kern_synch.c from 4.2 BSD, line 98, in the header comment of the sleep() routine: * Callers of this routine must be prepared for * premature return, and check that the reason for * sleeping has gone away. That comment on sleep() is present from 4.0 BSD up to and including 4.3 tahoe, but disappears in 4.3 reno, when the 4.4 style tsleep() was introduced. After a bit of searching through the PUPS archive, I see it is even present in Edition 6, character for character, in a file called slp.c. Well, I knew I wasn't a senile old fart yet, and Kirk's BSD CD compendium and the PUPS archive show that I remember some things correctly still. For a considerable portion of Unix history, sleep() could return for no good reason at all, and was documented to do so (if only in the source code). Now, how does this relate to the current day? Nobody in the BSD world uses plain sleep() any more. Once tsleep() appeared, the rules seem to have changed. Perhaps some people had gotten away with ignoring the dire warnings in the sleep() code, and decided that unexpected wakeups weren't such a useful part of the API. I hope Kirk or other BSD veterans can be coaxed into offering an opinion. I'd offer at least one beer for this purpose. :-) Regardless of the history of it all, FreeBSD is full of places where unexpected wakeups can stuff you right up. Should we regard tsleep() like the older sleep() call, as suspect, and program defensively? Should we be pragmatic, admit "We've gotten away with it so far", and document the "no sudden wakeups" behaviour? I quite like the general principle outlined in one of the earlier replies, that a while loop can be shown to be correct through a local code reading, but a simple conditional must be verified by reading all the rest of the code. That's close to the same argument I use against global variables. Their use is too hard to verify as correct. In short, I'd like to see all cases where tsleep() is not carefully used in a loop repaired. Practically speaking, though, I can't see that happening, especially if we have any major players against the idea (DG for example). Given that, I'd like as a minimum a bit more of the history of sleep() in the tsleep() manual page, and a discussion of when a while-loop protected tsleep() is mandatory, and when it is optional. Some sort of pronouncement against issuing wakeup() calls against arbitrary addresses would help too. I would do that right now, except I'm escaping computing for a few months. Almost heresy nowadays, I suppose. And I won't be the first in line for a brain implanted net connection either. ;-) Stephen. PS By the time you read this, I've probably
Re: hotmail now running win2000
Thus spake The Hermit Hacker ([EMAIL PROTECTED]): switch is web administered, so it would be too easy to build a quick perl script to trigger a power outlet correspondign to the partiular server a quick DirectActiveVBScript, you mean. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In message [EMAIL PROTECTED], Stephen McKay writes: Regardless of the history of it all, FreeBSD is full of places where unexpected wakeups can stuff you right up. Should we regard tsleep() like the older sleep() call, as suspect, and program defensively? Should we be pragmatic, admit "We've gotten away with it so far", and document the "no sudden wakeups" behaviour? I quite like the general principle outlined in one of the earlier replies, that a while loop can be shown to be correct through a local code reading, but a simple conditional must be verified by reading all the rest of the code. That's close to the same argument I use against global variables. Their use is too hard to verify as correct. I support this notion with a footnote to the effect that if the test is expensive the while() can be left out if a comment points out exactly why the while() isn't needed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount hangs system
On Thu, 10 Aug 2000, Evan Oldford wrote: This happens whenever I shutdown the system too. It tries to unmount one of the partitions and hangs before the "dirty flag" is removed from any of the partitions. Thats why all the partitions are checked/repaired by fsck _everytime_ I boot. Did you take the "device apm" out of your kernel? I saw this same behavior on my laptop when I took apm out of my kernel. When I put it back in everything was back to normal. I saw this same behavior 1-2 weeks ago on my -current desktop without apm. Now... FreeBSD storm.adept.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Aug 8 20:34:08 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/STORM i386 ...I do not see the behavior when I reboot. -mrh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup overzealous
With world and kernel of 10th August, 01:00 GMT cvsup is reporting 'SetAttrs' adjustments for every file it encounters on repeated runs against a server that has not been updated. Running under an old kernel, cvsup is not performing any updates. -- Mark Knight PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel causes CVSup SetAttrs flood (was: cvsup overzealous)
[I changed the subject to something more represenative.] In article [EMAIL PROTECTED], Mark Knight [EMAIL PROTECTED] wrote: With world and kernel of 10th August, 01:00 GMT cvsup is reporting 'SetAttrs' adjustments for every file it encounters on repeated runs against a server that has not been updated. Running under an old kernel, cvsup is not performing any updates. Stranger things have happened, but still I am skeptical of this. Please make sure that the kernel is really the only difference. Especially check that on each run you: - have the same umask - are logged in as the same user - are using the same cvsup command line and supfile Thanks, John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp troubles
I've been seeing these errors for about a month now. When PPP is first started, it outputs: calwell:/usr/src/bzflagppp -ddial -nat papchap Working in ddial mode Using interface: tun0 Warning: Add route failed: 0.0.0.0: errno: Network is unreachable It still dials and connects, then gets an IP, but I never get the default route. I have to manually ifconfig to find the ip and route add default it. Before: calwell:/usr/src/bzflag netstat -rn | head Routing tables Internet: DestinationGatewayFlags Netif Expire 127.0.0.1 127.0.0.1 UH 469726 lo0 192.168/16 link#1 UC 00 rl0 = 192.168.0.10:c0:ca:12:7d:30 UHLW08 lo0 192.168.0.11 0:5:2:b6:ad:21 UHLW1 106946 rl0251 192.168.0.12 0:80:ad:b0:3b:ef UHLW2 342 rl0 1162 192.168.255.255ff:ff:ff:ff:ff:ff UHLWb 3 155 rl0 After: calwell:/usr/src/bzflag netstat -rn | head Routing tables Internet: DestinationGatewayFlags Netif Expire default216.26.1.5 UGSc3 24 tun0 127.0.0.1 127.0.0.1 UH 469750 lo0 192.168/16 link#1 UC 00 rl0 = 192.168.0.10:c0:ca:12:7d:30 UHLW08 lo0 192.168.0.11 0:5:2:b6:ad:21 UHLW1 106973 rl0208 192.168.0.12 0:80:ad:b0:3b:ef UHLW2 342 rl0 1119 calwell:/usr/src/bzflag ifconfig tun0 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1524 inet6 fe80::2c0:caff:fe12:7d30%tun0 -- :: prefixlen 64 scopeid 0xa inet 216.26.2.219 -- 216.26.1.5 netmask 0xff00 Opened by PID 21106 Excerpts from ppp.conf default: set device /dev/cuaa0 set log Phase Chat LCP IPCP tun command connect #CCP set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set timeout 120 # 3 mintue idle timer (the default) set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 add default HISADDR # Add a (sticky) default route (then the regular papchap stuff) Can anyone help me? This is really annying, especially since I have a very nasty connection that keeps dropping and making me route delete, ifconfig -a ( repeat), route add again. If there is any other info needed, I would be glad to post. -- -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
Folks, there are a lot of exciting and cool things, like Processor and Device Power State Control, Thermal Management, Replacement PnP system, OS initiated hibernation and many :-) I think now is the time to start open and development, not only in Japan, for FreeBSD ACPI support! This all sounds very useful! Glad to see it's merging into the current branch! Thanks! I know that we need to have a lot of developers to implement these things :-) # We are a very small team in Japan and capabilities is also limited... Now we got very fundamental facility of ACPI here, I hope that many people will have fun hacking them and be involved in the projects. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : # I haven't checked ACPI spec 2.0 yet though :-) Wouldn't you know it. I printed the 1.0, and then the errata for it. Now I have to kill another couple of trees to print the 2.0 spec. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
It is related with quite wide areas, not only for power management. # I'm interested in power management part personally for the first step # though. Do I understand correctly that things like monitoring cooling fans etc is also possible? I guess the people running (lots of) servers will be interested in those features too. Yes, of course :-) ACPI covers the thermal management also. I could imagine that there are quite big needs in this area for server computing. I think this is what you are interested in, from ACPI 1.0b spec. contents; 12. THERMAL MANAGEMENT 12.1 Thermal Control 12.1.1 Active, Passive, and Critical Policies 12.1.2 Dynamically Changing Cooling Temperatures 12.1.3 Hardware Thermal Events 12.1.4 Active Cooling Strength 12.1.5 Passive Cooling Equation 12.1.6 Critical Shutdown You can get ACPI spec. documents from http://www.teleport.com/~acpi/spec.htm # I haven't checked ACPI spec 2.0 yet though :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
I'm not quite sure what it does, but it seems to work fine here on my ASUS CUSL2, at least the shutdown part. Thank you for your report. It would be helpful to check http://www.teleport.com/~acpi/whatis1.htm and it's links. It is related with quite wide areas, not only for power management. # I'm interested in power management part personally for the first step # though. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
On Sat, Aug 12, 2000 at 12:35:27AM +0900, Mitsuru IWASAKI wrote: I'm not quite sure what it does, but it seems to work fine here on my ASUS CUSL2, at least the shutdown part. Thank you for your report. It would be helpful to check http://www.teleport.com/~acpi/whatis1.htm and it's links. Interesting information, thanks for the pointer. It is related with quite wide areas, not only for power management. # I'm interested in power management part personally for the first step # though. Do I understand correctly that things like monitoring cooling fans etc is also possible? I guess the people running (lots of) servers will be interested in those features too. -- Wilko Bulte [EMAIL PROTECTED] Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
