Re: cdrecord stopped working with 4.2 upgrade
On Fri, Dec 08, 2000 at 11:11:00AM -0500, Vivek Khera wrote: "MS" == Mike Smith [EMAIL PROTECTED] writes: Hmmm. Must be a new requirement. I never had that before. I'll give it a try. Thanks for the pointer. MS No excuses. cdrecord has always required the pass devices. Ok... can we have this requirement documented somewhere? Perhaps the pkg-descr file for the port? That would have been a timesaver! 'man ktrace' for a way to debug this sort of things. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cdrecord stopped working with 4.2 upgrade
"WB" == Wilko Bulte [EMAIL PROTECTED] writes: Ok... can we have this requirement documented somewhere? Perhaps the pkg-descr file for the port? That would have been a timesaver! WB 'man ktrace' for a way to debug this sort of things. The ktrace output was not so helpful yesterday. The error was reported when trying to open /dev/xpt0 like this: 60742 cdrecord CALL open(0x8067a2b,0x2,0xbfbfdf54) 60742 cdrecord NAMI "/dev/xpt0" 60742 cdrecord RET open 3 60742 cdrecord CALL break(0x8081000) 60742 cdrecord RET break 0 60742 cdrecord CALL ioctl(0x3,CAMIOCOMMAND,0xbfbfdf38) 60742 cdrecord RET ioctl 0 60742 cdrecord CALL close(0x3) 60742 cdrecord RET close 0 60742 cdrecord CALL write(0x2,0xbfbfe170,0x3e) 60742 cdrecord GIO fd 2 wrote 62 bytes "cdrecord: No such file or directory. Cannot open SCSI driver. Reading the man page for xpt we see: There is no kernel configuration required for the xpt driver. It is en- abled when SCSI support is enabled in the kernel. There is one instance I guess it requires "device pass" in the configuration to be useful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pcm0: problem
Andre DDAdmin: I'm running 4.1.1-release, and thinking of moving to 4.2-release or stable. the problem occurs whenever I play any sound file. mp3 or wav files. if the sound card is in use and I move my mouse, it gives me this error. pcm0: hwptr went backwards - pcm0: hwptr went backwards - pcm0: hwptr went backwards - Although this entirely harmless it is fixed with 4.2-RELEASE. You want to upgrade. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: crypt() default behavior
On Fri, Dec 08, 2000 at 11:46:43AM -0800, David O'Brien wrote: You don't need to do this anymore at all. I thought this and did it comment out in my postinstall script before I run it first on 4.2-STABLE. But surprisingly a 'passwd somone' resulted in creating a DES password key! Therefore, I activated my change of the links of the crypt libraries again in my script. That works for me, in that both DES and MD5 password keys are recognized by all programs in the system and only MD5 password keys are created. Thats what I want and what I had since 1994 (FreeBSD 1.1.5.1 :-) Liebe Grüße, Nora. -- [EMAIL PROTECTED]http://www.sappho-net.de/ Lesbian Computer Networks, Finland http://www.sappho.net/ Web for Women (von Frauen, für Frauen) http://www.w4w.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On 2000-12-08 10:02 -0600, Mike Silbersack [EMAIL PROTECTED] wrote: Seriously, though. There must be some way to abuse such direct access to the pci configuration registers. Just because nobody has figured it out how yet doesn't mean that enabling the feature is a good idea. Well, what makes you think, that nobody has figured out why read access to the pci config space registers might not be a good idea ? ;-) The reason is simple: There are a number of PCI devices that fail in a number of ways, if certain config space registers are accessed while the device is active. This is counterintuitive at first, but just try to read a config register beyond 0x80 from an NCR SCSI chip while it is executing SCRIPTS code ... The PCI spec made higher numbered config space registers implementation dependent. Some vendors mapped their devices' operational registers into config space, even though the spec never encouraged that (though I'm not sure that such an (ab)use of config registers was declared forbidden in later revisions of the spec.). Since there are a number of devices that could be severely impacted by read accesses to configuration space registers, we can't safely permit any user such read access. Root hopefully knows what he is doing and only accesses such registers that are meant to be accessed while the device is operating ... Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100 (i82557) Server Adapter not seen by fxp.
On Thu, 7 Dec 2000, Janet Sullivan wrote: Christopher Shumway wrote: The Intelligent Server Adapter has a PCI ID of 0x5201. The driver code, /usr/src/sys/pci/if_fxpreg.h defines the device ID for the i82557 as 0x1030, which is of course not what this partitular card is. One idea would be to edit if_fxpreg.h and replace this line: #define FXP_DEVICEID_i82559 0x1030 /* New 82559 device id.. */ With this line: #define FXP_DEVICEID_i82559 0x5201 /* New 82559 device id.. */ and then recompile a kernel. It *may* Just Work[tm]. Unfortunately, it didn't. As soon as I tried to use ifconfig to give the card an ip address, it locked the machine up solid. Upon reboot, here is what ifconfig -a reports (fxp0 is the Intelligent Server Adapter, fxp1 is an i82558). ifconfig snippit: fxp0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:00:00:00:00:00 media: manual supported media: manual Ick. It appears this card is just diffrent enough that the fxp driver doesn't understand it. fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.23.4 netmask 0xfff8 broadcast 192.168.23.7 ether 00:a0:c9:a0:ff:a4 media: 100baseTX full-duplex status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP dmesg snippit: fxp0: Intel InBusiness 10/100 Ethernet mem 0xe100-0xe11f irq 9 at devi ce 18.1 on pci0 fxp0: Ethernet address 00:00:00:00:00:00 fxp1: Intel Pro 10/100B/100+ Ethernet port 0xe800-0xe81f mem 0xe120-0xe12f ,0xe130-0xe1300fff irq 3 at device 19.0 on pci0 fxp1: Ethernet address 00:a0:c9:a0:ff:a4 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Modem
Are you running -Stable? Perhaps this question belongs on FreeBSD-questions, not stable. Anyway...What kind of modem is it? I hope it is a real modem and not a winmodem. Does it show up in your bootup/dmesg? (My PCI modem shows up as sio4, as an example.) -Marius M. Rex On Fri, 8 Dec 2000, Den wrote: Hello stable, I just installed FreeBSD, after 3 days of fighting with my HD (wanted both BSD Win98 on the same Drive), but i cant get my modem to work (yes i have a modem :(, im in the UK!), the modem is a port in itself (com3), but nothing i do, i cant connect to it, any help? Best regards, Den mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
PAM issues with login.
After my latest make world, I find I am now experiencing some PAM error when I log in: Dec 8 10:22:33 bsd login: auth_pam: Module is unknown Dec 8 16:14:17 bsd login: unable to dlopen(/lib/security/pam_deny.so) Dec 8 16:14:17 bsd login: [dlerror: Shared object "libc.so.6" not found] Dec 8 16:14:17 bsd login: adding faulty module: /lib/security/pam_deny.so Dec 8 16:14:17 bsd login: auth_pam: Module is unknown Dec 8 16:14:26 bsd su: gross to root on /dev/ttyp0 Dec 8 16:16:28 bsd login: unable to dlopen(/lib/security/pam_deny.so) Dec 8 16:16:28 bsd login: [dlerror: Shared object "libc.so.6" not found] Dec 8 16:16:28 bsd login: adding faulty module: /lib/security/pam_deny.so Dec 8 16:16:28 bsd login: auth_pam: Module is unknown 102 gross@bsd:/usr/home/gross% Is there a trick I need to know to get rid of these PAM errors? The login is able to proceed, but it is messy. Regards, Glen M. Gross Unix Technical Support Specialist Symark Software 5716 Corsa Avenue, Suite 200 Westlake Village, CA 91362 http://www.symark.com [EMAIL PROTECTED] Main: 800-234-9072 or 818-865-6100 Main fax: 818-889-1894 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Softupdates?
Warner Losh [EMAIL PROTECTED] writes: Briefly, they are a way of combining writes to disk so that fewer writes happen for meta data. There's also the "and ordering writes so that the disk is left in a consistent state after each write, preventing filesystem damage in a crash without the slowdown associated with a synchronous filesystem" part, which I think is really most important. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Thanks
Hello stable, Thanks for all your help, I have 4.0 Release (took me weeks to D/L, the ISO, bit by bit, with a 33.3 K/b modem), I think ill buy the next set of CD's!!, anyway I'll Unsubscribe Take Care Best regards, Den mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
No Subject
auth 56777a9b subscribe freebsd-stable [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote: I thought the space staked out by the *BSD gang was approximately this: NetBSD - the least amount of platform-specific code possible; run on most anything OpenBSD - pro-active security, bullet-proof from attacks FreeBSD - best performing on the Intel PC platform s/the Intel PC/server/ The Alpha has very good I/O bandwidth and 64-bit address space. Thus it fits our niche. You also mentioned Sparc, but really should have said sparc64(pci based). hopefully embeded soon too. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
