Re: smmsp user check in Makefile.inc1
Stephen Hocking wrote: For those of us using NIS, it'd be nice if the check would be made against the passwd and group maps if the local passwd and group don't have these users. Actually, the correct fix is to use the id command. It will automagically find it no matter what the passwd source is: peter@overcee[11:38pm]~src/tools/tools/vop_table-148 id -u smmsp 25 peter@overcee[11:38pm]~src/tools/tools/vop_table-149 echo $status 0 peter@overcee[11:38pm]~src/tools/tools/vop_table-150 id -u fake id: fake: no such user peter@overcee[11:38pm]~src/tools/tools/vop_table-151 echo $status 1 Care to whip up a patch? I'll commit it for you. (I'd do it but I'm working on something) 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
Can't su
Current -CURRENT won't let me run su; it dies with SIGSEGV. The backtrace says: #0 0x28078c57 in openpam_add_module (policy=0xbfbff700, chain=0, flag=1, modpath=0xbfbff28f pam_nologin.so, optc=-1, optv=0xbfbfee78) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_load.c:182 #1 0x2807796d in openpam_read_policy_file (policy=0xbfbff700, service=0x2807967f other, filename=0x804c1e0 /etc/pam.d/other, style=1) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:189 #2 0x28077b83 in openpam_load_policy (policy=0xbfbff700, service=0x2807967f other) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:236 #3 0x28077c81 in openpam_configure (pamh=0x804f000, service=0x804a250 su) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:275 #4 0x280751b8 in pam_start (service=0x804a250 su, user=0x804a223 root, pam_conv=0xbfbffbd4, pamh=0x804b4ac) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/pam_start.c:68 #5 0x804948f in main (argc=1, argv=0xbfbffc38) at /usr/src/usr.bin/su/su.c:211 #6 0x8049061 in _start () Everything in /etc/pam.d is up to date. I can't run xdm either, (the X server starts, it sits for awhile without a greeter, the server exits and everything starts over) but I don't know if that's related or not. -Peter- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't su
On Fri, May 03, 2002 at 12:30:15AM -0700, Peter S. Housel wrote: Current -CURRENT won't let me run su; it dies with SIGSEGV. The backtrace says: #0 0x28078c57 in openpam_add_module (policy=0xbfbff700, chain=0, flag=1, modpath=0xbfbff28f pam_nologin.so, optc=-1, optv=0xbfbfee78) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_load.c:182 #1 0x2807796d in openpam_read_policy_file (policy=0xbfbff700, service=0x2807967f other, filename=0x804c1e0 /etc/pam.d/other, style=1) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:189 #2 0x28077b83 in openpam_load_policy (policy=0xbfbff700, service=0x2807967f other) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:236 #3 0x28077c81 in openpam_configure (pamh=0x804f000, service=0x804a250 su) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:275 #4 0x280751b8 in pam_start (service=0x804a250 su, user=0x804a223 root, pam_conv=0xbfbffbd4, pamh=0x804b4ac) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/pam_start.c:68 #5 0x804948f in main (argc=1, argv=0xbfbffc38) at /usr/src/usr.bin/su/su.c:211 #6 0x8049061 in _start () Everything in /etc/pam.d is up to date. I can't run xdm either, (the X server starts, it sits for awhile without a greeter, the server exits and everything starts over) but I don't know if that's related or not. You're not the only one, I noticed it because I have dnetc run in the background on startup by use of su and I suddenly say su dying. (Not used xdm so no idea about that one) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Can't install ports/emulators/linux_base on -CURRENT
Thanks, I hope this is not a long-term workaround! -Original Message- From: Brooks Davis [mailto:[EMAIL PROTECTED]] Sent: Friday, 3 May 2002 2:30 PM To: Thyer, Matthew Cc: '[EMAIL PROTECTED]' Subject: Re: Can't install ports/emulators/linux_base on -CURRENT On Fri, May 03, 2002 at 02:19:40PM +0930, Thyer, Matthew wrote: === Registering installation for rpm-3.0.6_6 === Returning to build of linux_base-6.1_1 === Patching for linux_base-6.1_1 === Configuring for linux_base-6.1_1 === Installing for linux_base-6.1_1 setup-2.0.5-1.noarch.rpm filesystem-1.3.5-1.noarch.rpm unpacking of archive failed on file /proc: cpio: chown failed - Operation not supported *** Error code 1 Stop in /usr/ports/emulators/linux_base. Unmount your linprocfs file system first. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't su
Also have the same problem with su on -CURRENT from yesterday. Yuri On Fri, 3 May 2002, Peter S. Housel wrote: Current -CURRENT won't let me run su; it dies with SIGSEGV. The backtrace says: #0 0x28078c57 in openpam_add_module (policy=0xbfbff700, chain=0, flag=1, modpath=0xbfbff28f pam_nologin.so, optc=-1, optv=0xbfbfee78) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_load.c:182 #1 0x2807796d in openpam_read_policy_file (policy=0xbfbff700, service=0x2807967f other, filename=0x804c1e0 /etc/pam.d/other, style=1) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:189 #2 0x28077b83 in openpam_load_policy (policy=0xbfbff700, service=0x2807967f other) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:236 #3 0x28077c81 in openpam_configure (pamh=0x804f000, service=0x804a250 su) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/openpam_configure.c:275 #4 0x280751b8 in pam_start (service=0x804a250 su, user=0x804a223 root, pam_conv=0xbfbffbd4, pamh=0x804b4ac) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/pam_start.c:68 #5 0x804948f in main (argc=1, argv=0xbfbffc38) at /usr/src/usr.bin/su/su.c:211 #6 0x8049061 in _start () Everything in /etc/pam.d is up to date. I can't run xdm either, (the X server starts, it sits for awhile without a greeter, the server exits and everything starts over) but I don't know if that's related or not. -Peter- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't su
[EMAIL PROTECTED] (Peter S. Housel) writes: Current -CURRENT won't let me run su; it dies with SIGSEGV. The backtrace says: Yep, I see what the error is. All I can say is arrrgh! since I've been running this code for a while now and it never segfaults on my box :( DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Status of USB subsystem.
Dear all, I wanted to write to talk about the status of our USB stack in -current because there has been some concern expressed over the last week about where were are at with it, and more importantly when the bugs are going to be ironed out. In particular there has been a call to backout it all out back to a time when it worked. The background is that I've been porting the developments that NetBSD has had into FreeBSD. In some cases we were two years behind the state of the art. Today we're in a much better shape; most of the controller code and device API is pretty much the same as NetBSD's now, and that means that it should be relatively easy to port the ehci USB2 controller code. A lot of the devices are now synced too, although in general these have diverged over the period a lot more than the controller code has. With a prevailing wind behind us we should now have been in a much better position than we were when I started this work at the beginning of the year. I think that we almost are, but there are a few bugs that at the moment are eluding me, they could be because the bug exists in NetBSD, or because of some FreeBSDism that I've not realised, or just because of some code that's not been ported yet. I don't know, but I am working on it. Here are the issues that I know about: * There's a disconnect bug, which I've tied down to interupt pipes not cancelling properly when a device is unplugged. What this leads to is an xfer that repeats, and locks the usb subsystem. I've experienced it with uhub and ums, but it's possible, and probably, that other devices are effected to. I made some headway on this last night, and am in communication with the NetBSD author who's helping me track the problem down. * There's an attach problem with the aue network device, and possibly cue and kue too. This bug appears to have been around for a while but has just been revealed by the recent memory manager changes. It caused an attach time panic due to a bad memory allocation. NetBSD's aue driver is different from ours and possibly doesn't have the same problem. * Problems with ulpt. These appear to be in NetBSD also. I've got a usb printer (HP office jet) and so potentially have the resources to track the problem down, but as it's not entirely broken for all users, this problem is less important than the two about IMO. If anyone has any others that they've not revealed I'd like to know please. Also, if anyone particularly fancies helping out I'd be very grateful. This is my first bout into the kernel, and although I've got all the tools (remote debugger etc) I'm still a little slow with using them. Mail me privately if you've got the time and energy to help out. I'm prepared to back everything out if required, but my feeling is that we're a stone's throw away from solving these problems; it's just I'm throwing stones slower than a seasoned kernel hacker would. It would be a shame to take such a large step backwards if it's just a small step forwards that's required. The last known good date was just before the uma commit, i.e. -D20020319\ 0900. Of course there have been some kernel infrastructure changes since then so it's not just a matter of backing out the sys/dev/usb directory to that date. There are some changes that need to be retained, but they should be obvious for anyone who wants to do this locally. I ask for your patience in getting to the bottom of these problems, and wanted people to know that I am taking these issues serious, something that might not be clear because I've not communicated much about it on the lists. The good news is that once these issues have been resolved we are in a good position to port the drivers that NetBSD have but we've not seen yet. There are lots, like uaudio and uvisor, that we should take avantage of. I hope that these will follow in the not too distant future. Regards, Joe p.s. I'm away for the weekend and so if you don't get a reply to any email until the early part of next week it's not because I'm ignoring you. msg37984/pgp0.pgp Description: PGP signature
Re: Status of USB subsystem.
In message [EMAIL PROTECTED], Josef Karthauser writes: I'm prepared to back everything out if required, but my feeling is that we're a stone's throw away from solving these problems; it's just I'm throwing stones slower than a seasoned kernel hacker would. Don't even think about it! I am very impressed that you have managed to make your way through the diff between FreeBSD and NetBSD, and I would expect that everybody with USB devices recognize the advantage of having a new USB-stuckee in FreeBSD totally balances out any inconvenience the current problems might cause. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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: Status of USB subsystem.
On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: If anyone has any others that they've not revealed I'd like to know please. I don't really know if is related, but gphoto2 doesn't work with my camera because of different linux-freebsd usb channel usage (i think). Also, if anyone particularly fancies helping out I'd be very grateful. [...] I'm prepared to back everything out if required ... If this can lead me to have a working usb driver for my digital camera (a cheaper agfa cl18) with gphoto2 (or something _much_ light, like a command line tool or a kernel driver to mount as a filesystem) I can help you with all my free time for testing any (non destructive) change. I ask for your patience... You are welcome :-) Riccardo. PS: Please don't break uscanner, I use it with an Epson Perfection 1200U. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of USB subsystem.
Joe, Thank you for taking the time to document your work-in-progress. I, for one, vastly appreciate what you're doing with the USB subsystem. I think a lot of our community issues could be greatly improved by more people doing exactly what you've done here. OK, back to the peanut gallery. ==ml On Fri, May 03, 2002 at 02:22:48PM +0100, Josef Karthauser wrote: Dear all, I wanted to write to talk about the status of our USB stack in -current because there has been some concern expressed over the last week about where were are at with it, and more importantly when the bugs are going to be ironed out. In particular there has been a call to backout it all out back to a time when it worked. The background is that I've been porting the developments that NetBSD has had into FreeBSD. In some cases we were two years behind the state of the art. Today we're in a much better shape; most of the controller code and device API is pretty much the same as NetBSD's now, and that means that it should be relatively easy to port the ehci USB2 controller code. A lot of the devices are now synced too, although in general these have diverged over the period a lot more than the controller code has. With a prevailing wind behind us we should now have been in a much better position than we were when I started this work at the beginning of the year. I think that we almost are, but there are a few bugs that at the moment are eluding me, they could be because the bug exists in NetBSD, or because of some FreeBSDism that I've not realised, or just because of some code that's not been ported yet. I don't know, but I am working on it. Here are the issues that I know about: * There's a disconnect bug, which I've tied down to interupt pipes not cancelling properly when a device is unplugged. What this leads to is an xfer that repeats, and locks the usb subsystem. I've experienced it with uhub and ums, but it's possible, and probably, that other devices are effected to. I made some headway on this last night, and am in communication with the NetBSD author who's helping me track the problem down. * There's an attach problem with the aue network device, and possibly cue and kue too. This bug appears to have been around for a while but has just been revealed by the recent memory manager changes. It caused an attach time panic due to a bad memory allocation. NetBSD's aue driver is different from ours and possibly doesn't have the same problem. * Problems with ulpt. These appear to be in NetBSD also. I've got a usb printer (HP office jet) and so potentially have the resources to track the problem down, but as it's not entirely broken for all users, this problem is less important than the two about IMO. If anyone has any others that they've not revealed I'd like to know please. Also, if anyone particularly fancies helping out I'd be very grateful. This is my first bout into the kernel, and although I've got all the tools (remote debugger etc) I'm still a little slow with using them. Mail me privately if you've got the time and energy to help out. I'm prepared to back everything out if required, but my feeling is that we're a stone's throw away from solving these problems; it's just I'm throwing stones slower than a seasoned kernel hacker would. It would be a shame to take such a large step backwards if it's just a small step forwards that's required. The last known good date was just before the uma commit, i.e. -D20020319\ 0900. Of course there have been some kernel infrastructure changes since then so it's not just a matter of backing out the sys/dev/usb directory to that date. There are some changes that need to be retained, but they should be obvious for anyone who wants to do this locally. I ask for your patience in getting to the bottom of these problems, and wanted people to know that I am taking these issues serious, something that might not be clear because I've not communicated much about it on the lists. The good news is that once these issues have been resolved we are in a good position to port the drivers that NetBSD have but we've not seen yet. There are lots, like uaudio and uvisor, that we should take avantage of. I hope that these will follow in the not too distant future. Regards, Joe p.s. I'm away for the weekend and so if you don't get a reply to any email until the early part of next week it's not because I'm ignoring you. -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.nostarch.com/abs_bsd.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't su
On 3 May 2002, Dag-Erling Smorgrav wrote: [EMAIL PROTECTED] (Peter S. Housel) writes: Current -CURRENT won't let me run su; it dies with SIGSEGV. The backtrace says: Yep, I see what the error is. All I can say is arrrgh! since I've been running this code for a while now and it never segfaults on my box :( DES DES: also seeing problems with ftpd: it dumps core on signal 10 a gdb/backtrace of it: #0 0x280cd9c7 in openpam_add_module () from /usr/lib/libpam.so.2 (gdb) bt #0 0x280cd9c7 in openpam_add_module () from /usr/lib/libpam.so.2 #1 0x280ccc58 in openpam_dispatch () from /usr/lib/libpam.so.2 #2 0x280cce1a in openpam_dispatch () from /usr/lib/libpam.so.2 #3 0x280ccedf in openpam_configure () from /usr/lib/libpam.so.2 #4 0x280caf13 in pam_start () from /usr/lib/libpam.so.2 #5 0x804c50a in getsockname () #6 0x804c749 in getsockname () #7 0x8050c98 in getsockname () #8 0x804b71d in getsockname () #9 0x804ac05 in getsockname () ouch. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't su
Trish Lynch [EMAIL PROTECTED] writes: DES: also seeing problems with ftpd: Same bug, same fix. Cvsup and rebuild libpam. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
unsuscribe freebsd-current
[no subject]
unsuscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: your mail
On 18:24+0300, May 3, 2002, Radoslav Vasilev wrote: unsuscribe freebsd-current use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of USB subsystem.
Riccardo Torrini wrote: On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: If anyone has any others that they've not revealed I'd like to know please. I don't really know if is related, but gphoto2 doesn't work with my camera because of different linux-freebsd usb channel usage (i think). I think this is the pipes problem; I think this was the first thing in Joseph's not working list. It's well enough known that there are people passing around patches for a workaround (not a real fix) on -hackers for the VOIP hardware. According to the author of the patch and the VOIP drivers, it's a problem in NetBSD that FreeBSD has inherited from having the NetBSD framework. Also according to the same person, FreeBSD wouldn't have support for the VOIP hardware at all, if it weren't for Joseph's work. Keep up the good work, Joseph! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
* Orion Hodson [EMAIL PROTECTED] [020501 18:10] wrote: /-- Alfred Perlstein wrote: | -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz You can set a sysctl to set the ac97 link rate. I don't recall offhand what it is (hw.snd.pcm0.ac97rate?) - sysctl -a | grep ac97 will find it. There is a calibration test in the ich code since various mfrs do funny things with the clock. I'd be interested to know what boot -v output is and what ac97 link rate works. This is the second box reported failing on this recently. This makes it sound almost perfect: sysctl hw.snd.pcm0.ac97rate=55000 the default 44061 is bad. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of USB subsystem.
Oops. Josef. Sorry; my spelling is atrocious. -- Terry Terry Lambert wrote: Riccardo Torrini wrote: On 03-May-2002 (13:22:48/GMT) Josef Karthauser wrote: If anyone has any others that they've not revealed I'd like to know please. I don't really know if is related, but gphoto2 doesn't work with my camera because of different linux-freebsd usb channel usage (i think). I think this is the pipes problem; I think this was the first thing in Joseph's not working list. It's well enough known that there are people passing around patches for a workaround (not a real fix) on -hackers for the VOIP hardware. According to the author of the patch and the VOIP drivers, it's a problem in NetBSD that FreeBSD has inherited from having the NetBSD framework. Also according to the same person, FreeBSD wouldn't have support for the VOIP hardware at all, if it weren't for Joseph's work. Keep up the good work, Joseph! -- Terry 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: fast playback with Intel 82801BA (ICH2)
Alfred Perlstein wrote: This makes it sound almost perfect: sysctl hw.snd.pcm0.ac97rate=55000 the default 44061 is bad. I thought this was because it's the CD sample rate... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
| -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz This makes it sound almost perfect: sysctl hw.snd.pcm0.ac97rate=55000 the default 44061 is bad. What about 56000? Our Dells seem to use it. I'm not sure what is so magic about it. Maybe they wanted to cater for modems on the ac97 channel. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
* John Hay [EMAIL PROTECTED] [020503 12:09] wrote: | -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz This makes it sound almost perfect: sysctl hw.snd.pcm0.ac97rate=55000 the default 44061 is bad. What about 56000? Our Dells seem to use it. I'm not sure what is so magic about it. Maybe they wanted to cater for modems on the ac97 channel. That sounds fine also, basically if i go lower then it sounds sped up, higher and it sounds slow. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
In message [EMAIL PROTECTED], Will Andrews writes : On Thu, May 02, 2002 at 03:30:40PM -0700, Brooks Davis wrote: I haven't tryed backing the commits out yet, but I'm seeing similar behavior on my HP Omnibook 500. In my case, it's actually not quite hung. What appears to be happening is that nothing is causing the console buffer to actually flush. The system is up (sort of), but the only way to see the console output is to cause a kernel printf, say be breaking in to the debugger. The system is basicaly useless at that point and you can't shutdown cleanly. Similar behavior manifests itself on my -current laptop dated before April 27. I.O.W. it appears to freeze but will flush the console if you break to the debugger then hit 'c'. I believe this was caused by an earlier change to the timecounter code. Unfortunately I didn't have time to investigate further. Do you see this with up to date -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
On Fri, May 03, 2002 at 11:10:06PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Will Andrews writes : On Thu, May 02, 2002 at 03:30:40PM -0700, Brooks Davis wrote: I haven't tryed backing the commits out yet, but I'm seeing similar behavior on my HP Omnibook 500. In my case, it's actually not quite hung. What appears to be happening is that nothing is causing the console buffer to actually flush. The system is up (sort of), but the only way to see the console output is to cause a kernel printf, say be breaking in to the debugger. The system is basicaly useless at that point and you can't shutdown cleanly. Similar behavior manifests itself on my -current laptop dated before April 27. I.O.W. it appears to freeze but will flush the console if you break to the debugger then hit 'c'. I believe this was caused by an earlier change to the timecounter code. Unfortunately I didn't have time to investigate further. Do you see this with up to date -current ? I still see this with a current as of this morning, including the most recent kern_tc.c commit. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg38000/pgp0.pgp Description: PGP signature
Re: cvs commit: src/share/mk bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.init.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk
On Wed, Apr 17, 2002 at 06:49:29 -0700, Ruslan Ermilov wrote: ru 2002/04/17 06:49:29 PDT Modified files: share/mk bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk Added files: share/mk bsd.init.mk Log: Don't include bsd.own.mk from sys.mk, this makes it impossible to use ``.if defined()'' inside bsd.own.mk to test for defines in individual makefiles. For example, setting DEBUG_FLAGS in Makefile didn't take the desired effect on the STRIP assignment. Added bsd.init.mk (like in NetBSD) that handles the inclusion of ../Makefile.inc and bsd.own.mk from all bsd.*.mk files that build something. Back out bsd.own.mk,v 1.15: moved OBJFORMAT initialization back to sys.mk (several source tree makefiles want to check it early) and removed MACHINE_ARCH initialization (it's hard to see from looking at the commitlogs what the problem was at the time, but now it serves no purpose). Prohibit the direct inclusion of bsd.man.mk and bsd.libnames.mk. Protect bsd.obj.mk from repetitive inclusion. Prohibiting the direct inclusion of bsd.obj.mk might be a good idea too. This commit breaks building -current kernels on -stable. == === 3dfx /usr/home/ken/perforce/FreeBSD-zero/src/sys/modules/3dfx/../../conf/kmod.mk, line 89: Could not find bsd.init.mk make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/ken/perforce/FreeBSD-zero/src/sys/modules. *** Error code 1 Stop in /usr/home/ken/perforce/FreeBSD-zero/src/sys/i386/compile/gondolin. == The attached patch fixes it for me. I'm sure someone can come up with a cleaner way of fixing the problem. Ken -- Kenneth Merry [EMAIL PROTECTED] //depot/FreeBSD-zero/src/sys/conf/kmod.mk#9 - /usr/home/ken/perforce/FreeBSD-zero/src/sys/conf/kmod.mk *** /tmp/tmp.18430.0Fri May 3 21:51:56 2002 --- /usr/home/ken/perforce/FreeBSD-zero/src/sys/conf/kmod.mkFri May 3 21:51:43 2002 *** *** 86,92 --- 86,98 .error Do not use KMODDEPS on 5.0+, use MODULE_VERSION/MODULE_DEPEND .endif + .if exists(__bsd.init.mk__) .include bsd.init.mk + .elif exists(../../../share/mk/bsd.init.mk) + .include ../../../share/mk/bsd.init.mk + .elif exists(../../../../share/mk/bsd.init.mk) + .include ../../../../share/mk/bsd.init.mk + .endif .SUFFIXES: .out .o .c .cc .cxx .C .y .l .s .S
Re: cvs commit: src/share/mk bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.init.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk
On Fri, May 03, 2002 at 22:00:05 -0600, Kenneth D. Merry wrote: On Wed, Apr 17, 2002 at 06:49:29 -0700, Ruslan Ermilov wrote: ru 2002/04/17 06:49:29 PDT Modified files: share/mk bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk Added files: share/mk bsd.init.mk Log: Don't include bsd.own.mk from sys.mk, this makes it impossible to use ``.if defined()'' inside bsd.own.mk to test for defines in individual makefiles. For example, setting DEBUG_FLAGS in Makefile didn't take the desired effect on the STRIP assignment. Added bsd.init.mk (like in NetBSD) that handles the inclusion of ../Makefile.inc and bsd.own.mk from all bsd.*.mk files that build something. Back out bsd.own.mk,v 1.15: moved OBJFORMAT initialization back to sys.mk (several source tree makefiles want to check it early) and removed MACHINE_ARCH initialization (it's hard to see from looking at the commitlogs what the problem was at the time, but now it serves no purpose). Prohibit the direct inclusion of bsd.man.mk and bsd.libnames.mk. Protect bsd.obj.mk from repetitive inclusion. Prohibiting the direct inclusion of bsd.obj.mk might be a good idea too. This commit breaks building -current kernels on -stable. == === 3dfx /usr/home/ken/perforce/FreeBSD-zero/src/sys/modules/3dfx/../../conf/kmod.mk, line 89: Could not find bsd.init.mk make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/ken/perforce/FreeBSD-zero/src/sys/modules. *** Error code 1 Stop in /usr/home/ken/perforce/FreeBSD-zero/src/sys/i386/compile/gondolin. == The attached patch fixes it for me. I'm sure someone can come up with a cleaner way of fixing the problem. Ken -- Kenneth Merry [EMAIL PROTECTED] Sorry, it was this commit that broke building -current kernels on -stable: ru 2002/04/22 08:47:11 PDT Modified files: sys/conf kmod.mk Log: Use standard bsd.init.mk prologue. Revision ChangesPath 1.116 +1 -7 src/sys/conf/kmod.mk //depot/FreeBSD-zero/src/sys/conf/kmod.mk#9 - /usr/home/ken/perforce/FreeBSD-zero/src/sys/conf/kmod.mk *** /tmp/tmp.18430.0 Fri May 3 21:51:56 2002 --- /usr/home/ken/perforce/FreeBSD-zero/src/sys/conf/kmod.mk Fri May 3 21:51:43 2002 *** *** 86,92 --- 86,98 .error Do not use KMODDEPS on 5.0+, use MODULE_VERSION/MODULE_DEPEND .endif + .if exists(__bsd.init.mk__) .include bsd.init.mk + .elif exists(../../../share/mk/bsd.init.mk) + .include ../../../share/mk/bsd.init.mk + .elif exists(../../../../share/mk/bsd.init.mk) + .include ../../../../share/mk/bsd.init.mk + .endif .SUFFIXES: .out .o .c .cc .cxx .C .y .l .s .S Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: build a -current kernel on a -stable box
ken Sorry, it was this commit that broke building -current kernels on -stable: How do you build -current kernel on your -stable box? cd /usr cvs -d /your/CVSROOT checkout src cd src make buildworld make buildkernel should work as it should be (and it's the only guaranteed procedure IIRC). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: build a -current kernel on a -stable box
On Sat, May 04, 2002 at 13:41:51 +0900, Makoto Matsushita wrote: ken Sorry, it was this commit that broke building -current kernels on -stable: How do you build -current kernel on your -stable box? cd /usr cvs -d /your/CVSROOT checkout src cd src make buildworld make buildkernel should work as it should be (and it's the only guaranteed procedure IIRC). Normally I skip the buildworld step and just build the kernel. It worked fine, up until the commit to kmod.mk. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Odd problem with MTRR and ACPI
Heh, finally someone that's actually trying to fix this. 8) The right thing is going to be to fix the MTRR code to preserve the extra MTRR bits; I've tried a few times to get some documentation on what these other bits mean without any luck. You'll need to hide these bits from the layers above and just hang on to them. Beyond that, I really don't have any great ideas unless/until you can find out what the bits do. = Mike I have an ASUS A7A266 motherboard with an Athlon XP processor which seems prone to weirdness. The BIOS seems to set the MTRRs to some undocumented values, which used to prevent X starting. I've now fixed the MTRR code and X works fine. Unfortunately, when X changes the MTRRs then ACPI stops working. I tracked this down and found that the ACPI data just vanishes out of memory when you change the MTRRs! (Illustration included below, including hexdump of the bits of memory in question.) Has anyone seen anything like this? Does anyone have any idea what the old MTRR values mean? They are changed from 0x10(=???) to 0x01(=write-combine). David. MSR 26e, old=0x1010101010101010 new=0x0101010101010101 MSR 26f, old=0x1010101010101010 new=0x0101010101010101 gonzo 3 # acpidump | head -3 Found sig at f78c0 Checksum OK at f78c0 /* RSD PTR: Checksum=144, OEMID=ASUS, RsdtAddress=0x17fec000 */ gonzo 4# dd if=/dev/mem bs=1024 count=1024 | hd -s 0xf78c0 000f78c0 52 53 44 20 50 54 52 20 90 41 53 55 53 20 20 00 |RSD PTR .ASUS . | 000f78d0 00 c0 fe 17 00 c0 fe 17 40 c0 fe 17 80 c0 fe 17 |@... | 000f78e0 00 c1 fe 17 00 f0 ff 17 00 00 00 00 00 00 00 00 | | 000f78f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | | * 000f8000 90 90 90 90 90 90 90 90 e9 41 61 2e 8b c0 8b c0 |.Aa. | snipped binary data, which looks like it might be bios continues up to 1M 0010 gonzo 5# memcontrol set -b 983040 -l 65536 -o XFree86 write-combine gonzo 6# acpidump | head -3 acpidump: Can't find ACPI information gonzo 7# dd if=/dev/mem bs=1024 count=1024 | hd -s 0xf78c0 000f78c0 0c 00 04 00 00 40 f0 17 01 00 00 00 0b 80 00 00 |.@.. | * 000fc240 0c 00 04 00 00 40 f0 17 01 00 00 00 00 00 00 00 |.@.. | 000fc250 0c 00 00 00 00 08 3e ca 01 00 00 00 00 00 00 00 |... | * 0010 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
