Re: Something is wrong with the fxp network driver
On Sat, Sep 27, 2003 at 12:12:40AM -0400, Mike Tancsa wrote: At 11:32 PM 26/09/2003, Glenn Johnson wrote: On Fri, Sep 26, 2003 at 08:07:38PM -0400, Mike Tancsa wrote: Are they Tyan motherboards by chance ? There was a thread in stable about this a few weeks ago. The problems seem specific to those motherboards. Someone posted a potential workaround as well. No, five of them are MSI dual Athlon-MP boards (can not remember the what does pciconf -v -l show for the cards ? I will not be able to answer that until Monday. Are all on the same switch ? Yes, they are all on the same switch. Other machines with an xl interface are fine though. Is it a flow control issue perhaps ? I am not sure what you mean? -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Something is wrong with the fxp network driver
I am having a problem with recent builds of -current with the fxp driver. A couple of days ago, the 6 machines in my cluster with fxp interfaces all died at about the same time with fxp timeout errors. The machines with 3Com xl interfaces kept on going. Today, I am observing that the throughput is about half of what I am seeing on my machines with a 3Com xl interface. Is anybody else observing this? What other information do I need to provide? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Something is wrong with the fxp network driver
On Fri, Sep 26, 2003 at 08:07:38PM -0400, Mike Tancsa wrote: Are they Tyan motherboards by chance ? There was a thread in stable about this a few weeks ago. The problems seem specific to those motherboards. Someone posted a potential workaround as well. No, five of them are MSI dual Athlon-MP boards (can not remember the exact model and am not near the machines now), and one is an Epox Athlon-XP board. The five MSI boards are using a built-in LAN interface and the Epox is using a PCI card. I do have some machines with Tyan motherboards but they have 3Com xl interfaces in them. On Fri, 26 Sep 2003 11:40:08 -0500, in sentex.lists.freebsd.current you wrote: I am having a problem with recent builds of -current with the fxp driver. A couple of days ago, the 6 machines in my cluster with fxp interfaces all died at about the same time with fxp timeout errors. The machines with 3Com xl interfaces kept on going. Today, I am observing that the throughput is about half of what I am seeing on my machines with a 3Com xl interface. Is anybody else observing this? What other information do I need to provide? Thanks. -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
mtools access to floppy stopped working with recent -current
With a recent version of -current (09-14-2003) I can no longer write to a floppy drive with mtools commands. I get the following when trying to delete a file: plain_io: Bad address buffer_flush: write: Bad address plain_io: Bad address buffer_flush: write: Bad address plain_io: Bad address buffer_flush: write: Bad address This worked fine with a -current from about a week ago. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi_cd or atapicam crash in current.
On Fri, Sep 12, 2003 at 08:57:22AM -0700, Kevin Oberman wrote: I am seeing a peculiar, possibly timing sensitive, crash that looks like if is probably in either atapicam or scsi_cd. The system is CURRENT as of yesterday morning. The crash happens frequently when nautilus starts up. It does not always crash, but does so fairly frequently and leaves my laptop locked in X with no access to the console. If nautilus starts, the system continues without problems until X is terminated and restarted. Check your cdrom entry in /etc/fstab. If you have an entry for /dev/cd0, try changing that to /dev/acd0, or whatever the appropriate ATAPI device is for your system. I was having the same problem you describe and that fixed it. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with password expire
On Sun, Sep 07, 2003 at 04:31:33PM -0700, Chris Petrik wrote: I am trying to use freebsd's way of password expiration to make it so i need to change my password every 30 days ive got: :warnpassword=4d:\ :passwordtime=30d: in my /etc/login.conf did a cap_mkdb /etc/login.conf i tryed to change the password of one of my users using passwd and it doesnt seem to add a change time to it according to chpass the: Change [month day year]: stays unchanged but if i manually add the change time using pw it adds the change time but if i change the password it doesnt add a new change time do i need to edit the /etc/pam.d/passwd and uncomment the top line thats commented out ? cause it seems to be broken atm as it doesnt do what i ask it to do. if you need anythign else please let me know A password expiry system is not natively implemented in FreeBSD although the password expiry field in the password database allows one to set up a system. The users on the system where I work log in mostly via gdm so I set up some checks in the PreSession file to check the password expiry field and call passwd if the password has expired. After a successful password change, the pw command is called to reset the expiry field. To catch the case where a user changes the password at a time other than when prompted via the PreSession script I set up a script that runs via periodic/daily. This script checks the expiry field and if 0 it calls pw to set the expiry field to the appropriate value. Since this runs daily, the assumption is that the password was changed within the last 24 hours. The password warning feature works really well with gdm as it pops up a dialog box. There is no warning at console logins but I am the only one allowed to login at the console so that is not a big deal for me but may be for you. There is a warning displayed during an ssh login but it is very easy to miss it as it scrolls off the screen. One warning about ssh: Once the user's password has expired, ssh will not allow the login thereby locking out that user from that mode of access. This is not FreeBSD specific. There are probably several ways to write scripts for this and they would have to be tailored to your situation but hopefully I have given you some ideas about how to proceed. One thing that will definitely influence how you ultimately set this up is whether you use NIS or not. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 11:02:13PM -0500, wrote: On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 11:56:57PM -0500, Glenn Johnson wrote: On Fri, Aug 29, 2003 at 11:02:13PM -0500, wrote: On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. Another data point: If I start a non-gnome session, and then launch nautilus, it does not crash the system. However, when I start a gnome session, the machine crashes when nautilus loads. If I take atapicam out of my kernel config, rebuild/reinstall the kernel, I do not get any crashes at all. Why it worked a couple of times earlier this evening I do not know. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Thu, Aug 28, 2003 at 12:39:59AM +0200, Thomas Quinot wrote: OK, trivial one. Thanks to all who contributed feedback on this issue. Thomas. Index: atapi-cam.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.20 ...snip... When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? I do not really know. Since the keyboard locks up I can not switch to a console. There was nothing written to the log file that I remember but I should check that again tonight when I get home. I will also try to ssh in from another machine and see if the network is still up. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 04:17:33PM -0400, Joe Marcus Clarke wrote: On Fri, 2003-08-29 at 15:53, Glenn Johnson wrote: On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? I do not really know. Since the keyboard locks up I can not switch to a console. There was nothing written to the log file that I remember but I should check that again tonight when I get home. I will also try to ssh in from another machine and see if the network is still up. If you're testing GNOME 2.3, this might be related to nautilus-cd-burner. If so, please try rebuilding it so that it can compile with the new code. No, I am not testing Gnome 2.3, I am using Gnome 2.2.2 on that machine. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: I had similar problem with a 7200 and OGL. I solved the problem by turning off some of the options in the X config. On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch [EMAIL PROTECTED] wrote: Is anyone else seeing this issue? I'm running into it on desktop boxes and a laptop running 4.8-RELEASE with up to date ports collections and various versions of DRI installed over a ports version of X. I'm also seeing this under 5.1-RELEASE on the laptop. Everything works perfectly unless/until I restart the X server. This appears to be initiated automatically when running GDM -- ie, GDM starts, you log in using that X session, you log out and the session stops, GDM starts X again and displays the login screen. This seems to happen a bit more than 1/3 of the times I try it (intentionally or not). It isn't much of a problem on the laptop as I'm the only user and tend to turn the machine off when I log out but it is causing all sorts of issues on the desktops because they are intended to be used as multi-user (serially and also simultaneously) systems. Any ideas? The instability goes away completely with DRI disabled, but part of the use of these desktops is in the accelerated OpenGL rendering... Sean (CC'ed to -current since it's not -stable specific) This is an example of why people need to send PRs and not just emails. I realize now I've seen emails on this before, but I had forgotten about them because they seemed isolated and I didn't have them piling up in my assigned prs list (things pile up in my mailboxes easily, and I don't go back and check very often). Speaking for myself, I was not sure whether the problem was a BIOS setting problem, a graphics card problem, a FreeBSD problem, an XFree86 problem, or a configuration problem on my part. Until today, I thought I was the only one with seeing this. I discovered the ForcePCIMode option as a potential workaround only two days ago and I wanted to confirm that it did indeed make the problem go away before filing a PR and sending an e-mail directly to you about the issue. In fact, I was planning on doing that this evening after a few more tests. I've tried to reproduce this with a radeon, by doing startx, C-A-B to kill the server, then startx again. The second time, the screen displays for a brief moment then goes black. The system isn't hung, and I can exit using C-A-B again. Is this what everyone else sees? Sometimes. At times the Xserver will not start and I can switch to a console and login. Any further attempts to restart X will lock the machine up. Other times, the screen just goes black and the machine is locked up. I can not switch to a console nor ssh in via another machine. In that case, I have to hit the reset switch. Still other times, the gdm login screen will appear and look normal, except the cursor is not blinking and the keyboard and mouse do not respond. I did not try to ssh into the machine in that state but I would guess that it would fail. Everyone that's experiencing this and is using the DRI, what version of the radeon DRM is loaded? (dmesg | grep drm) I will have to get the dmesg output for you when I get home but it is the latest version in -current, with -current being up to date as of Aug 25, 2003, about 9:00 PM CDT. Is anyone experiencing this without the DRI loaded? Not me; when I disable DRI the lock ups do not occur. The ForcePCIMode workaround is interesting, I'll take a look at what could be going on there. I have had that option in my config file for about two days and have tested by logging in and out repeatedly. So far, I have not had a lock up with that option enabled. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 03:31:29PM -0500, Sean Welch wrote: I have precisely the same symptoms as what Glenn listed. I have now tried the forcepcimode option on the laptop and unfortunately experienced what appears to be the opposite effect to what Glenn noted. I get a black screen with lots of disk activity. I can log in remotely (at least that seemed to work every time) and a top listing shows X taking up more and more CPU cycles. It seems to be scribbling to the disk making temporary files as well because eventually I couldn't edit the XF86Config file any longer -- I was getting a no space left on device error. I ended up taking out all options short of disabling DRI altogether and eventually discovered the only way I could run with DRI switches on and forcepcimode set to true was to unload the agp module from kernel space. This got it started just fine but there was no DRI. It seems that X is getting confused and somehow PCI and AGP modes are duking it out... Does it work on your desktops? I do not have agp in the kernel config. When X starts it loads both the radeon and agp modules, or maybe the radeon module is loading the agp module. Either way, both radeon.ko and agp.ko get loaded up. Here is some info about my hardware: - The motherboard is an Abit IS7 (P4c w/865PE chipset) - The graphics card is an ATI Radeon 9100 Here is the device section of my XF86Config (sans comments): Section Device Identifier Card0 Driver ati VendorName ATI Technologies Inc BoardName Radeon R200 QM [Radeon 9100] BusID PCI:1:0:0 Option DDCMode true Option ForcePCIMode true EndSection Finally, here are the first few lines of glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: ...snip... Everyone that's experiencing this and is using the DRI, what version of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing this without the DRI loaded? The ForcePCIMode workaround is interesting, I'll take a look at what could be going on there. drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf900-0xf900,0xe000-0xefff irq 2 at device 0.0 on pci1 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 info: [drm] Loading R200 Microcode -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon 7500 w/ DRI locking on restart of X
On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: I had similar problem with a 7200 and OGL. I solved the problem by turning off some of the options in the X config. On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch [EMAIL PROTECTED] wrote: Is anyone else seeing this issue? I'm running into it on desktop boxes and a laptop running 4.8-RELEASE with up to date ports collections and various versions of DRI installed over a ports version of X. I'm also seeing this under 5.1-RELEASE on the laptop. Everything works perfectly unless/until I restart the X server. This appears to be initiated automatically when running GDM -- ie, GDM starts, you log in using that X session, you log out and the session stops, GDM starts X again and displays the login screen. Everyone that's experiencing this and is using the DRI, what version of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing this without the DRI loaded? The ForcePCIMode workaround is interesting, I'll take a look at what could be going on there. I did some googling tonight and found out this problem is supposedly fixed in XFree86-4.3.99 although I do not see any specific mention of this problem in the Changelog. See: http://www.knoppix.net/forum/viewtopic.php?t=2504highlight= -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3C940 / Asus P4P800 gigabit LAN driver
On Mon, Aug 25, 2003 at 11:20:23AM -0500, Glenn Johnson wrote: On Mon, Aug 25, 2003 at 11:14:25AM +0100, Stuart Walsh wrote: On Sun Aug 24, 10:42P -0500, Glenn Johnson wrote: On Sun, Aug 24, 2003 at 01:22:39PM +0200, Wilko Bulte wrote: On Sat, Aug 23, 2003 at 04:45:30PM +0100, Stuart Walsh wrote: Hi, I ported the openbsd additions to the sk driver to support the 3c940 gigabit network card which is commonly found in the above asus motherboard. Testers/comments/commits welcome, but please don't blame me if it burns your house down or something :) Hi Stuart, I tried this patch instead of the earlier ones you pointed me to on IRC. Unfortunately my Asus P4P800 still locks up solid (reset button required) after printing the 3c940's ethernet address. I'm interested to know if other P4P800 owners have the same issue. I have an Abit IS7 with a 3c940. I also get a lockup at boot time. I tried loading the module after bootup as well. I tried that two times; it loaded one time and locked the machine up the other time. Does it lock up after printing the ethernet address as in Wilko's case? Yes. Does the card work properly if the module does manage to load? I do not know. I did not have a cable plugged in to the 3c940 port at the time. I do remember some message about not being able to set up a jumbo frame. I was going to plug a cable into the port to see if it worked but I was not able to get the module to load again without locking up the machine. Also could you mail your dmesg. Yes, but not until I get home later this evening as the 3c940 is on my home system. Here is my dmesg output: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #94: Mon Aug 25 22:43:06 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GFORCE Preloaded elf kernel /boot/kernel/kernel at 0xc0433000. Preloaded elf module /boot/kernel/if_xl.ko at 0xc04331f4. Preloaded elf module /boot/kernel/miibus.ko at 0xc04332a0. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc043334c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04333f8. Preloaded elf module /boot/kernel/random.ko at 0xc04334a4. Preloaded elf module /boot/kernel/acpi.ko at 0xc0433550. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2405.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 536805376 (511 MB) avail memory = 516743168 (492 MB) Changing APIC ID for IO APIC #0 from 0 to 2 on chip Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: IntelR AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdd30 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 19 - irq 5 IOAPIC #0 intpin 18 - irq 9 IOAPIC #0 intpin 23 - irq 10 IOAPIC #0 intpin 17 - irq 11 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.3 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pci2: network, ethernet at device 2.0 (no driver attached) xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa400-0xa47f mem 0xfb004000-0xfb00407f irq 11 at device 9.0 on pci2 xl0: Ethernet address: 00:01:02:84:81:50 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 SATA150 controller port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 9 at device 31.2 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1
Re: 3C940 / Asus P4P800 gigabit LAN driver
On Sun, Aug 24, 2003 at 01:22:39PM +0200, Wilko Bulte wrote: On Sat, Aug 23, 2003 at 04:45:30PM +0100, Stuart Walsh wrote: Hi, I ported the openbsd additions to the sk driver to support the 3c940 gigabit network card which is commonly found in the above asus motherboard. Testers/comments/commits welcome, but please don't blame me if it burns your house down or something :) Hi Stuart, I tried this patch instead of the earlier ones you pointed me to on IRC. Unfortunately my Asus P4P800 still locks up solid (reset button required) after printing the 3c940's ethernet address. I'm interested to know if other P4P800 owners have the same issue. I have an Abit IS7 with a 3c940. I also get a lockup at boot time. I tried loading the module after bootup as well. I tried that two times; it loaded one time and locked the machine up the other time. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3C940 / Asus P4P800 gigabit LAN driver
On Mon, Aug 25, 2003 at 11:14:25AM +0100, Stuart Walsh wrote: On Sun Aug 24, 10:42P -0500, Glenn Johnson wrote: On Sun, Aug 24, 2003 at 01:22:39PM +0200, Wilko Bulte wrote: On Sat, Aug 23, 2003 at 04:45:30PM +0100, Stuart Walsh wrote: Hi, I ported the openbsd additions to the sk driver to support the 3c940 gigabit network card which is commonly found in the above asus motherboard. Testers/comments/commits welcome, but please don't blame me if it burns your house down or something :) Hi Stuart, I tried this patch instead of the earlier ones you pointed me to on IRC. Unfortunately my Asus P4P800 still locks up solid (reset button required) after printing the 3c940's ethernet address. I'm interested to know if other P4P800 owners have the same issue. I have an Abit IS7 with a 3c940. I also get a lockup at boot time. I tried loading the module after bootup as well. I tried that two times; it loaded one time and locked the machine up the other time. Does it lock up after printing the ethernet address as in Wilko's case? Yes. Does the card work properly if the module does manage to load? I do not know. I did not have a cable plugged in to the 3c940 port at the time. I do remember some message about not being able to set up a jumbo frame. I was going to plug a cable into the port to see if it worked but I was not able to get the module to load again without locking up the machine. Also could you mail your dmesg. Yes, but not until I get home later this evening as the 3c940 is on my home system. -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System freezes with radeon 9100 graphics card
On Sat, Aug 23, 2003 at 02:11:15PM -0500, Glenn Johnson wrote: I have had an ongoing problem with -current freezing during a restart of the X serer. The graphics card is an ATI Radeon 9100. I am pretty sure this is related to DRI as I have not had it happen with DRI disabled. I am not sure if the problem is with the radeon kernel module, with XFree86-Server, or something else. The freezes totally lock up the machine, no ssh access is possible, no crash dumps are produced, I have to hit the reset button and run fsck in single user mode. Is anyone else seeing this with a radeon card? Any options I can set to alleviate the problem? I going to turn on DRM_DEBUG and see what that yields. Thanks. Some more info: I get the following error messages when the X server starts: drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf900-0xf900,0xe000-0xefff irq 2 at device 0.0 on pci1 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 579 using kernel context 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 738 using kernel context 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 865 using kernel context 0 -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System freezes with radeon 9100 graphics card
On Sat, Aug 23, 2003 at 09:40:55PM -0700, Scott M. Likens wrote: On Sat, 2003-08-23 at 20:38, Glenn Johnson wrote: On Sat, Aug 23, 2003 at 02:11:15PM -0500, Glenn Johnson wrote: I have had an ongoing problem with -current freezing during a restart of the X serer. The graphics card is an ATI Radeon 9100. I am pretty sure this is related to DRI as I have not had it happen with DRI disabled. I am not sure if the problem is with the radeon kernel module, with XFree86-Server, or something else. The freezes totally lock up the machine, no ssh access is possible, no crash dumps are produced, I have to hit the reset button and run fsck in single user mode. Is anyone else seeing this with a radeon card? Any options I can set to alleviate the problem? I going to turn on DRM_DEBUG and see what that yields. Thanks. Some more info: I get the following error messages when the X server starts: drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf900-0xf900,0xe000-0xefff irq 2 at device 0.0 on pci1 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 579 using kernel context 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 738 using kernel context 0 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held error: [drm:radeon_unlock] *ERROR* Process 865 using kernel context 0 I might suggest to you that you try the DRI lists... see http://dri.sf.net or email [EMAIL PROTECTED] I have, to the first. Also please teach your email client to word wrap. That's nasty. My e-mail client knows how to word wrap. The unwrapped part above was from command output, which should *not* be wrapped, to maintain integrity of the output. If you saw more than one line that was not wrapped then I submit that there is something wrong with your e-mail client. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
System freezes with radeon 9100 graphics card
I have had an ongoing problem with -current freezing during a restart of the X serer. The graphics card is an ATI Radeon 9100. I am pretty sure this is related to DRI as I have not had it happen with DRI disabled. I am not sure if the problem is with the radeon kernel module, with XFree86-Server, or something else. The freezes totally lock up the machine, no ssh access is possible, no crash dumps are produced, I have to hit the reset button and run fsck in single user mode. Is anyone else seeing this with a radeon card? Any options I can set to alleviate the problem? I going to turn on DRM_DEBUG and see what that yields. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent changes to AC97 files breaks sound
On Fri, Aug 22, 2003 at 01:38:22PM -0700, Orion Hodson wrote: /-- Lars Eggert wrote: | This is a cryptographically signed message in MIME format. | | --ms080500030203050209080702 Content-Type: text/plain; | charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit | | Hi, | | Rudolf Cejka wrote: | | Glenn Johnson wrote (2003/08/21): | | sound no longer works. I reverted to the previous versions of | these files to get sound back. | | I might have the same issue. Does no longer work means | silence? Then I do. (Just got this box, so I don't know whether this | was recently broken or not.) Here's my hardware: | | pcm0: SiS 7012 port 0x9000-0x907f,0x9400-0x94ff irq 15 at device | 2.7 on pci0 pcm0: Avance Logic ALC650 AC97 Codec | | Could you do ALC650 register dump? If you look into | ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/ich/ , you can see small | how-to in DEBUG sections. | | Would the dump work/help for the SiS chip as well? Lars First off, apologies for the breakage. Before investing any time doing a register dump, can you just check whether your mixer now has an ogain control and that it is non-zero. No ogain control in my case. Everything in the mixer output looks the same as before, including same level settings, just no sound is output. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent changes to AC97 files breaks sound
After the changes to: ac97.c ac97.h ac97_patch.c ac97_patch.h sound no longer works. I reverted to the previous versions of these files to get sound back. pcm0: Intel ICH5 (82801EB) port 0xdc00-0xdc3f,0xd800-0xd8ff mem 0xfc002000-0xfc0020ff,0xfc001000-0xfc0011ff irq 10 at device 31.5 on pci0 pcm0: Avance Logic ALC650 AC97 Codec -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with nvidia graphics card and -current
On Tue, Aug 05, 2003 at 02:38:05PM +1000, Alastair G. Hogge wrote: On Tuesday, 05 August 2003 14:34, Matthew N. Dodd wrote: On Mon, 4 Aug 2003, Glenn Johnson wrote: Question for the developers: Is there someway to avoid having the combination of vesa and nvidia cause a total lockup of the machine? I have a feeling I may not be the last person to try the nvidia driver with vesa enabled, either as a module, or compiled in the kernel. I'm running a system with the VESA stuff compiled in; the nvidia drivers work just fine. IIRC you're running with ACPI; try not doing that. I'm also running a system with the vesa module loaded. I'm also running ACPI. Hmm, the only other thing I can offer here is that I had the console screen set to -g 100x37 VESA_800x600. How does that fit into the picture? Perhaps I could have left vesa in but just set the resolution to something else. Perhaps the machine just has quirky hardware. It is a VIA KT-133 chipset, Athlon-tbird processor. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with nvidia graphics card and -current
On Tue, Aug 05, 2003 at 01:28:58PM +1000, Alastair G. Hogge wrote: On Tuesday, 05 August 2003 13:07, Glenn Johnson wrote: On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: I was setting up a system today with an nvidia Geforce4-MX 440 graphics card. I am not at the system at the moment but the -current sources were from about 2:00 PM CDT. I installed the nvidia-driver port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The first time an X server is started, everything works fine, including glx loading. After exiting the X session and shutting down the server and then at some point later starting the X server again, the system will freeze. No messages, no panic, nothing. The only thing to do is hit the reset button. I played with this a bit more tonight. I rebuilt the kernel (fresh cvsup) and the nvidia-driver bits. I even tried loading without glx. I still have the same problem. At this point I do not know if this is a problem with the nvidia-driver port, a problem with -current, or something I am doing wrong. Does anybody have a functioning nvidia card with FreeBSD -current at this time? Yes I do. I posted to the list a few days with a glx problem. However the problem was solved when I did an update one day ago. I didn't have to changed anything either. I didn't know what was wrong for some reason X would about with sig 10 or 11 when the glx module was loaded. Well, after much hair pulling and trying various troubleshooting steps I had one last idea. I had the vesa kernel module loaded and thought maybe that is causing the hangup. I disabled the loading of the vesa kernel module in /boot/loader.conf and rebooted. Sure enough, everything worked. I now have the nvidia card working and can proceed with the rest of the setup for this machine. Thanks for your reply stating that it works for you. It gave me the incentive to try one more time. Question for the developers: Is there someway to avoid having the combination of vesa and nvidia cause a total lockup of the machine? I have a feeling I may not be the last person to try the nvidia driver with vesa enabled, either as a module, or compiled in the kernel. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with nvidia graphics card and -current
On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: I was setting up a system today with an nvidia Geforce4-MX 440 graphics card. I am not at the system at the moment but the -current sources were from about 2:00 PM CDT. I installed the nvidia-driver port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The first time an X server is started, everything works fine, including glx loading. After exiting the X session and shutting down the server and then at some point later starting the X server again, the system will freeze. No messages, no panic, nothing. The only thing to do is hit the reset button. I played with this a bit more tonight. I rebuilt the kernel (fresh cvsup) and the nvidia-driver bits. I even tried loading without glx. I still have the same problem. At this point I do not know if this is a problem with the nvidia-driver port, a problem with -current, or something I am doing wrong. Does anybody have a functioning nvidia card with FreeBSD -current at this time? -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
password strength checking not consistently implemented
I have set up the password strength checking system using pam_passwdqc.so, set in /etc/pam.d/passwd. I have also set up password expiration. When a user issues the 'passwd' command, the password strength checking module works as expected. When a user logs in via the console after the password expiry time has passed, the login program prompts for a new password before the session begins. However, this password change has no strength check at all. Is there some other change I need to make to may pam configuration? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with nvidia graphics card and -current
On Mon, Aug 04, 2003 at 11:53:05PM -0500, Glenn Johnson wrote: On Tue, Aug 05, 2003 at 02:38:05PM +1000, Alastair G. Hogge wrote: On Tuesday, 05 August 2003 14:34, Matthew N. Dodd wrote: On Mon, 4 Aug 2003, Glenn Johnson wrote: Question for the developers: Is there someway to avoid having the combination of vesa and nvidia cause a total lockup of the machine? I have a feeling I may not be the last person to try the nvidia driver with vesa enabled, either as a module, or compiled in the kernel. I'm running a system with the VESA stuff compiled in; the nvidia drivers work just fine. IIRC you're running with ACPI; try not doing that. I'm also running a system with the vesa module loaded. I'm also running ACPI. Hmm, the only other thing I can offer here is that I had the console screen set to -g 100x37 VESA_800x600. How does that fit into the picture? Perhaps I could have left vesa in but just set the resolution to something else. Well, I can have the vesa kernel module loaded and use standard modes for the console and all is well. However, If I use any of the VESA video modes, the nvidia driver will not work. I can start the X server once, any subsequent attempt to restart the X server will cause the machine to freeze up if any of the VESA modes for the console are loaded. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with nvidia graphics card and -current
I was setting up a system today with an nvidia Geforce4-MX 440 graphics card. I am not at the system at the moment but the -current sources were from about 2:00 PM CDT. I installed the nvidia-driver port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The first time an X server is started, everything works fine, including glx loading. After exiting the X session and shutting down the server and then at some point later starting the X server again, the system will freeze. No messages, no panic, nothing. The only thing to do is hit the reset button. Any ideas? I saw some discussion about kernel changes made for wine and nvidia but I am not sure if that is relevant in my case. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
syntax problem with /etc/rc.d/nfslocking
Occasionally, one of my systems gets rpc.lockd stuck using all of the CPU cycles. I fix it by running '/etc/rc.d/nfslocking restart'. That works but it shows there is a syntax error somewhere. Here is the output that I get: [: checkyesno: unexpected operator Stopping statd. [: checkyesno: unexpected operator Stopping lockd. Starting statd. Starting lockd. I have the following in /etc/rc.conf: nfs_client_enable=YES nfs_server_enable=YES rpc_lockd_enable=YES rpc_statd_enable=YES rpcbind_enable=YES -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
setting CPUTYPE=p4 with gcc-3.3
Is it safe to set CPUTYPE to p4 for those with p4 processors now that gcc has been upgraded to 3.3 in -CURRENT? If so, should this be set up accordingly in bsd.cpu.mk? -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: features of ICH5/ICH5-R supported in -current or 5.1-RELEASE?
irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xccfff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-slave: ATAPI identify retries exceeded ad2: 78167MB Maxtor 6Y080M0 [158816/16/63] at ata1-master UDMA133 acd0: CD-RW MATSHITA CD-RW CW-7586 at ata0-master WDMA2 SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: MATSHITA CD-RW CW-7586 1.08 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: cd present [296447 x 2048 byte records] Mounting root from ufs:/dev/ad2s1a uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xbc00-0xbc1f irq 2 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xb000-0xb01f irq 9 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xb400-0xb41f irq 10 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xb800-0xb81f irq 2 at device 29.3 on pci0 usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfc00-0xfc0003ff irq 11 at device 29.7 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: EHCI (generic) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf900-0xf900,0xe000-0xefff irq 2 at device 0.0 on pci1 info: [drm] AGP at 0xf000 128MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 info: [drm] Loading R200 Microcode ---end dmesg output--- -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Hyperthreading
I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Fri, Jun 27, 2003 at 03:46:47PM -0700, Doug White wrote: On Fri, 27 Jun 2003, Glenn Johnson wrote: I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. man 4 smp See the machdep.hlt_logical_cpus sysctl. Thanks. I had read the smp manual page. I know _how_ to enable HTT; I was wondering whether I _should_ enable it. It seems the answer is that it is not beneficial in its current state because the scheduler does not yet differentiate between physical and logical processors. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: anyone used pam_passwdqc?
On Thu, Jun 19, 2003 at 06:41:59PM -0700, Julian Elischer wrote: Has anyone used this successfully? Yes. I uncommented the respective line in /etc/pam.d/passwd and then successfully changed a password. It was difficult to come with a password that met all of the rules. The help blurb that gets printed out neglects to mention that an uppercase letter that begins the password and a number that ends the password do not count when calculating the number of character classes used. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 03:54:22PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? I do not have the debugger enabled on the SMP box. I can set that up but probably not until next week. Will the debugger work if the machine locks up? -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 05:31:32PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 03:54:22PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? I do not have the debugger enabled on the SMP box. I can set that up but probably not until next week. Will the debugger work if the machine locks up? that depends.. when it locked up, did it still respond to pings? No, the networking was dead as well. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Mon, May 26, 2003 at 06:51:10PM -0400, Mike Makonnen wrote: Hello folks, Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. [1] - I haven't had a chance to test it on an SMP machine. The machine I was going to use crashed for unrelated reasons, but it should be back up soon. Never the less I would be interested to hear from people who have real world threaded applications on SMP systems. It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kp_proc and kp_eproc
On Fri, Apr 04, 2003 at 06:36:15PM -0800, Kris Kennaway wrote: On Fri, Apr 04, 2003 at 06:07:12PM -0600, Glenn Johnson wrote: On Fri, Apr 04, 2003 at 03:54:05PM -0800, Julian Elischer wrote: yes.. The entire process structure and it's surrounding enviroment has been through a blender. What do you wnat to do? I would like to learn what I need to do to get the software to compile on FreeBSD-5. I guess the question is, what information do I need to provide? The software in question is OpenPBS (http://www.openpbs.org), so it nothing proprietary. There were a whole bunch of dependency problems that I worked through manually and finally got to the point of the kp_proc failure. Here is a snippet of code that produces the failure: Here are untested patches I made for this a while ago. There's also a port PR somewhere. Thanks, I will give it a try, but probably not until Monday when I get back to work. Since you said you made this a while ago and it is untested, does that mean that you once used PBS and are using something else in its stead. I ask because I would really like to replace it with something else. I have been looking at SGE but it seems the FreeBSD port of that may not be quite ready. -- Glenn Johnson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kp_proc and kp_eproc
I have some software that compiled fine on FreeBSD-4 but is not compiling on FreeBSD-5. It is looking for kp_proc and kp_eproc. The error I get is: structure has no member named `kp_proc' structure has no member named `kp_eproc' Have those changed from FreeBSD-4? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kp_proc and kp_eproc
On Fri, Apr 04, 2003 at 03:54:05PM -0800, Julian Elischer wrote:
yes..
The entire process structure and it's surrounding enviroment has been
through a blender.
What do you wnat to do?
I would like to learn what I need to do to get the software to compile
on FreeBSD-5. I guess the question is, what information do I need to
provide? The software in question is OpenPBS (http://www.openpbs.org),
so it nothing proprietary. There were a whole bunch of dependency
problems that I worked through manually and finally got to the point
of the kp_proc failure. Here is a snippet of code that produces the
failure:
~~
static unsigned long cput_sum(pjob)
job *pjob;
{
static charid[] = cput_sum;
int i;
u_long cputime;
int nps = 0;
cputime = 0;
for (i=0; inproc; i++) {
struct kinfo_proc *pp = proc_tbl[i];
if (!injob(pjob, sess_tbl[i]))
continue;
nps++;
cputime += tvk(pp-kp_proc.p_rtime);
if (pp-kp_proc.p_ru == NULL) {
struct pstats ps;
DBPRT((%s: p_stats 0x%lx\n, id,
(u_long)pp-kp_proc.p_stats))
if (pp-kp_proc.p_stats == NULL)
continue;
if (kvm_read(kd, (u_long)pp-kp_proc.p_stats, ps,
sizeof(ps)) != sizeof(ps)) {
log_err(errno, id, kvm_read(pstats));
continue;
}
cputime += tv(ps.p_ru.ru_utime) +
tv(ps.p_ru.ru_stime) +
tv(ps.p_cru.ru_utime) +
tv(ps.p_cru.ru_stime);
}
else {
struct rusage ru;
DBPRT((%s: p_ru 0x%lx\n, id,
(u_long)pp-kp_proc.p_ru))
if (kvm_read(kd, (u_long)pp-kp_proc.p_ru, ru,
sizeof(ru)) != sizeof(ru)) {
log_err(errno, id, kvm_read(session));
continue;
}
cputime += tv(ru.ru_utime) + tv(ru.ru_stime);
}
DBPRT((%s: ses %d pid %d cputime %d\n, id,
sess_tbl[i], pp-kp_proc.p_pid, cputime))
}
if (nps == 0)
pjob-ji_flags |= MOM_NO_PROC;
return ((unsigned long)((double)cputime * cputfactor));
}
~~
On Fri, 4 Apr 2003, Glenn Johnson wrote:
I have some software that compiled fine on FreeBSD-4 but is not
compiling on FreeBSD-5. It is looking for kp_proc and kp_eproc.
The error I get is:
structure has no member named `kp_proc'
structure has no member named `kp_eproc'
Have those changed from FreeBSD-4?
Thanks.
--
Glenn Johnson
USDA, ARS, SRRC Phone: (504) 286-4252
New Orleans, LA 70124 e-mail: [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ypserv and sshd not getting along in -current
On Mon, Mar 31, 2003 at 10:46:07AM +1000, Rob B wrote: At 02:55 PM 29/03/03, Terry Lambert sent this up the stick: Glenn Johnson wrote: I can not login to a box with FreeBSD 5 -current via ssh because I get the following error from ypserv: Mar 28 12:48:15 node1 ypserv[317]: access to master.passwd.byuid denied -- client 192.168.1.1:49344 not privileged man ypbind (-s is the magic incantation). I have the same issue, I tried Terry's suggestion but I don't think its working like it should: On the client: aylee # ps fax|grep yp 252 ?? Is 0:0.62 /usr/sbin/ypbind -s aylee # rpcinfo -p localhost|grep yp 17 2 udp 1022ypbind 17 2 tcp 1023ypbind Tailing the server's log: Mar 31 10:10:39 erwin ypserv[92]: access to master.passwd.byuid denied -- client 192.168.100.30:49255 not privileged Why would the request be coming from a high port when I have specifically told it to bind to a low port? The answer (work around) is to turn off PrivelegeSeparation in your sshd_config file. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ypserv and sshd not getting along in -current
I can not login to a box with FreeBSD 5 -current via ssh because I get the following error from ypserv: Mar 28 12:48:15 node1 ypserv[317]: access to master.passwd.byuid denied -- client 192.168.1.1:49344 not privileged Other than this, the NIS system seems to be working. I tried using the openssh port as well but get the same result so it is definitely a problem with ypserv. This box is an upgrade from FreeBSD 4 -stable and I cloned the setup. In fact I still have the original FreeBSD-4 setup on another box and it all works fine there. Any ideas? I wanted to move to 5.0 on my cluster to take advantage of the improved SMP support but I absolutely need to be able to ssh into this box. Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
where is rdist
I just noticed that rdist is not present on FreeBSD 5-current. Why was it removed? The /etc/periodic/daily/320.rdist file is still present. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
including a kernel config in another
I would like to include a kernel config file in another, as is done with the SMP config file and how it includes the GENERIC config file. When I try this with including any config file other than GENERIC, I get a syntax error. IS GENERIC the only config that can be included or am I doing something wrong? Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Downgrade ????
On Sun, Aug 22, 1999 at 02:49:49PM -0700, william woods wrote: OK, this is kinda a crazy questions, but..what the hell ...snip... How possible is it to cvsup stable ( I would blow away /uusr/src first) and then do a make world and have a 3.2-stable system or should I just re-install 3.2-stable? I think it would be better if you did a binary upgrade. That way you don't have to worry about build tools from CURRENT doing something funny to your 'make world'. In either case you will want to remove libraries from CURRENT not present in STABLE and any that may have had a version bump for CURRENT, ie. libfoo.so.1 in STABLE was libfoo.so.2 in CURRENT. Any ports that you compiled with c++ in CURRENT will have to be recompiled after you downgrade. Those are the types of issues I think you will run into. Doing the binary upgrade should preserve your /etc so your password database should be OK. It would of course be prudent to back up /etc anyway. Good luck. -- Glenn Johnson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE DMA timeouts (was: Kernel won't boot from IDE disk)
On Fri, Apr 30, 1999 at 02:05:00PM +0930, Greg Lehey wrote: On Thursday, 29 April 1999 at 10:10:43 -0500, Glenn Johnson wrote: I am doing a fresh installation. I installed the April 23, 1999 snapshot of STABLE and then cvsupped the CURRENT source (4.0 CURRENT). I did a 'make world' and that went fine. I copied the GENERIC kernel config to a new file and edited the copied file. I deleted whatever drivers I did not need. I also deleted, perhaps mistakenly, but out of habit, the line: optionsFAILSAFE I don't think this is your problem. I set the flags to wdc0 and wdc1 to 'a0ffa0ff' This might be. I then added the following: options SOFTUPDATES options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options CPU_WT_ALLOC controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 Upon reboot, the system would hang after doing all of the probes. Below is some of the output that I got from a boot -v. I wrote this down on paper, so the formatting may be a little off. isa_compat: didn't get drq for wdc1 ... changing root device to wd0s1a At this point it hangs. But if I press a key on the keyboard I then get: wd0s1: type 0xa5, start 0, end = 3173183, size 3173184 wd0s1: C/H/S end 197/132/63 (1659041) != end 3173183: invalid start_init: trying /sbin/init wd0: interrupt timeout (status 50rdy, seekdone error 0) wd0: wdtimeout() DMA status 4 This last two lines above are repeated 5x, then I get: wd0: Last time I say: interrupt timeout. Probably a portable PC. It is a desktop PC. I am not at the system now, so the following is from memory. It is an AMI BIOS, a Western Digital 1.6 GB IDE drive on the primary IDE and a Mitsumi 4x CD-ROM drive on the secondary IDE. What's your chipset? If it's an SiS 5591, I'd be interested in seeing your complete dmesg output (preferably with a -v output). You'll also be able to get it to work by changing the wdc0 flags to eliminate DMA. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key The IDE controller chip is an Intel PIIX3 Bus Master IDE controller. I did turn off all flags, via boot -c, then deleting the flags. That did not help. I have reinstalled 3.1 so the dmesg output below is from that. Not all of the messages from boot -v are there but I hope the relevant information is. Isn't there a way to expand the message buffer size via a kernel config option? Thanks. dmesg output from 3.1 which works: disabled, B: IRQ12, C: IRQ9, D: disabled MB0: IRQ15, MB1: found- vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base ffa0, size 4 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: ffa2 intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3 intel_piix_status: secondary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: ffaa found- vendor=0x1013, dev=0x00d0, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 1, range 32, base ffafc000, size 14 map[1]: type 1, range 32, base fc00, size 25 vga0: Cirrus Logic GD5462 SVGA controller rev 0x01 on pci0.8.0 found- vendor=0x1011, dev=0x0014, revid=0x21 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=12 map[0]: type 4, range 32, base 7880, size 7 map[1]: type 1, range 32, base ffafbe80, size 7 de0: Digital 21041 Ethernet rev 0x21 int a irq 12 on pci0.9.0 de0: 21041 [10Mb/s] pass 2.1 de0: address 00:c0:f0:37:d0:2d found- vendor=0x10cd, dev=0x1300, revid=0x03 class=01-00-00, hdrtype
Kernel won't boot from IDE disk
I am doing a fresh installation. I installed the April 23, 1999 snapshot of STABLE and then cvsupped the CURRENT source (4.0 CURRENT). I did a 'make world' and that went fine. I copied the GENERIC kernel config to a new file and edited the copied file. I deleted whatever drivers I did not need. I also deleted, perhaps mistakenly, but out of habit, the line: optionsFAILSAFE I set the flags to wdc0 and wdc1 to 'a0ffa0ff' I then added the following: options SOFTUPDATES options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options CPU_WT_ALLOC controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 Upon reboot, the system would hang after doing all of the probes. Below is some of the output that I got from a boot -v. I wrote this down on paper, so the formatting may be a little off. isa_compat: didn't get drq for wdc1 ... changing root device to wd0s1a At this point it hangs. But if I press a key on the keyboard I then get: wd0s1: type 0xa5, start 0, end = 3173183, size 3173184 wd0s1: C/H/S end 197/132/63 (1659041) != end 3173183: invalid start_init: trying /sbin/init wd0: interrupt timeout (status 50rdy, seekdone error 0) wd0: wdtimeout() DMA status 4 This last two lines above are repeated 5x, then I get: wd0: Last time I say: interrupt timeout. Probably a portable PC. It is a desktop PC. I am not at the system now, so the following is from memory. It is an AMI BIOS, a Western Digital 1.6 GB IDE drive on the primary IDE and a Mitsumi 4x CD-ROM drive on the secondary IDE. I can't boot an old kernel because the only old kernel I have is a 3.1 kernel and it lacks 'curproc()'. I don't remember the exact message for that. If there is any more info that is needed I will see if I can get it but I guess I will have to reinstall 3.1 for now. I hope this information is of value. Thanks. -- Glenn Johnson gljo...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: _my_ world is broken
On Thu, 22 Apr 1999, Alexander Leidinger wrote:
unsetenv CXXFLAGS
I don't know if you're supposed to be able to make world with this
variable set, but it screws up several things at present. I tripped
over this myself a few weeks back.
Kris
Look in /usr/share/mk/sys.mk and you will find:
CXXFLAGS?= ${CXXINCLUDES} ${CFLAGS}
So if you want your CFLAGS used for CXX you do nothing. If you need
to set some specific CXXFLAGS that you don't want set in CFLAGS then
you need to make sure that you also have ${CXXINCLUDES} listed on your
CXXFLAGS line.
--
Glenn Johnson
Technician
USDA, ARS, SRRC
New Orleans, LA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, Apr 09, 1999 at 03:52:58PM +0200, Jeremy Lea wrote:
Hi,
On Fri, Apr 09, 1999 at 10:37:55AM -0300, The Hermit Hacker wrote:
Geez, and I used to think it was only the commercial OSs that had a
problem with bloat and creeping featurisms ... :( Chuck's idea makes more
sense...how many programs does the average system run that needs a fortran
compiler? *raised eyebrow*
I always thought the criteria for inclusion of things into the base
system was:
1. Needed for 'make world';
2. Needed to get a basic functioning server up and running;
3. Something usefull only within FreeBSD (like the kernel ;), or
4. Can't be effectively built outside of /usr/src.
If {g77|f77} can be built as a port, using the system EGCS, then to
port's it goes. Otherwise why don't we include the Top 20 ports, or
maybe the Top 25, or...
Regards,
-Jeremy
First off, g77 is not your typical port. The build of g77 depends on
having the source to gcc on your system. The last time I checked,
installing the source was optional. The reason the current port of g77
is marked broken is because of this.
History: Newer versions of g77 cannot be built against gcc 2.7.2 and
older versions that can be built against gcc 2.7.2 don't work with
FreeBSD. This is because the FreeBSD gcc 2.7.2 was hacked too far away
from what g77 was developed for.
I would expect to see the same type of scenario arise with egcs as the
FreeBSD version becomes significantly changed from stock egcs. David has
already said that ports/egcs != src/contrib/egcs.
Future: Now it may be true that newer versions of g77 may not build
against whatever version of egcs we have but at least we would be
guaranteed of having a functional Fortran compiler.
Many people don't seem to understand that FreeBSD can be used for
workstations as well as servers and Fortran is *essential* on a
scientific/engineering workstation. I don't doubt that there are more
people using FreeBSD as a server but that doesn't mean that workstation
users should be denied an essential tool because it takes up a few
hundred kilobytes. I would predict that with SGI's entry into the NT
market you will see more people looking at Unix on Intel to replace
their aging SGI Irix boxes. It would be a shame for them to choose
Linux over FreeBSD because Linux can compile their Fortran programs and
FreeBSD cannot.
--
Glenn Johnson
Technician
USDA, ARS, SRRC
New Orleans, LA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Thu, Apr 08, 1999 at 04:50:56PM -0700, David O'Brien wrote: I've only heard back from 4 folks about adding EGCS's g77 to the base system -- all 4 said yes. Unless I get more feedback, I will add g77 to the base system this weekend. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) David, First off, great job on the egcs import. Maybe you have already counted me among the four, but if not, add me to the list. I would love to see g77 in the base system. Thanks. -- Glenn Johnson gljo...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
On Wed, Jan 27, 1999 at 05:14:33AM -0800, Satoshi Asami wrote: * The biggest problem has been that the port of g77 has not worked * properly for quite some time and in fact is currently marked as * broken. I would anticipate that this situation would not change much in That (and bug fix issues, as DavidO contends) all depends on the commitment of the maintainer (which there is none for the g77 port). Unless someone who uses g77 regularly steps up to maintain it, it will remain broken. This is the same for all ports, and I don't see why a Fortran compiler should be an exception. Granted, if won't be blatantly broken if it's in the base distribution, but that's only because people will yell and scream if their make world doesn't work. If the amount of noise that generates is significantly different from what happens if it's a broken port, that's actually a pretty good argument *against* putting it in the base distribution, as it means we can keep g77 running only by annoying people who don't use it when it's broken. (1/2 :) This port has been marked broken since July last year. Sorry, but I just don't have a whole lot of sympathy for something that can stay broken that long without anyone fixing it. ;) Your points are well taken. I had a local port of g77 that built against our current gcc. I never submitted it however for a couple of reasons: 1. The port I had was for 0.5.19. This will build against our current gcc, but g77 has advanced significantly since then. Unfortunately, the newer versions need gcc 2.8. It was simply easier for me to use the newer versions of g77 with gcc 2.8 or egcs release versions. Note that I said easier for me; some colleagues of mine could/would not want to have to maintain a compiler on their own. Yes, I was told this on a couple of occasions. I can not see a point in me becoming the g77 0.5.19 port maintainer when I am using newer versions of g77. 2. In light of the above, it seemed that f77 (f2c/gcc) was good enough for most cases. The g77 port was not essential because there was fairly good Fortran support in the base system. Apparently this will no longer be the case and therefore the g77 (or f2c) port will become essential. That is to say, essential for those needing Fortran. If it is decided that Fortran support will disappear from the base system and nobody else wants to maintain g77, I will gladly do it. However, I will only maintain a version that I am using so that means I will maintain a port once gcc 2.8 is officially brought in as the stock compiler. -- Glenn Johnson Technician USDA, ARS, SRRC New Orleans, LA To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
On Wed, Jan 27, 1999 at 09:29:38AM -0800, Satoshi Asami wrote: * The g77-0.5.19(.1) is *extremely* out-of-date. It should be dropped from * the ports collection, and if someone wants to use g77, then they should * install egcs. * * The newer versions of g77 do not work with gcc-2.7.2.x. The author of * g77 states that you shouldn't even try to back port g77 to any version * of gcc earlier than gcc-2.8 Well, Glenn said he got it to work with our compiler. :) No, I said I had a port of g77 0.5.19 that built against gcc 2.7.2.1. This was a while back. I am currently using g77 0.5.24, which needs gcc 2.8. Getting g77 from egcs is the best option right now. However, it seems to me that this adds a lot of bloat (duplication of C, C++, etc.) to the system for someone wanting to use FreeBSD as a scientific workstation platform. In contrast, how much bloat is added to the base system by having a g77 binary and a couple of libraries? But anyway, I don't have any problem to delete the g77 port for now. Is that ok with everyone else? This is OK by me. -- Glenn Johnson Technician USDA, ARS, SRRC New Orleans, LA To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: removing f2c from base distribution
On Tue, Jan 26, 1999 at 10:06:44PM -0800, David O'Brien wrote: The question is whether Peter wants to include g77, and whether people would see this as bloat. I know g77 outperforms f2c+gcc on my real-world benchmarks by a significant margin. A good question, is how easy it is to download egcs-g77-1.1.1.tar.gz and build it into something workable assuming the EGCS C and C++ compilers are part of the system. I've got a Bmaked contribified version of EGCS, but didn't do g77. So maybe a consensus should be made what to do about FORTRAN in the base system. I for one feel that Fortran should remain as part of the base system, either as f2c or g77. I would prefer g77 because of the performance advantage and compatability with Fortran code being ported from other systems. This is something I do quite a bit of. I have contributed a couple of ports that are written in Fortran and I plan on contributing more. I have been waiting to see what decisions were made in this area however before proceeding. The biggest problem has been that the port of g77 has not worked properly for quite some time and in fact is currently marked as broken. I would anticipate that this situation would not change much in the future if the base gcc (egcs?) is modified far enough away from a standard gcc distribution, as is currently the case with our gcc. As far as getting g77 from the egcs port, well, the release versions have been fine for g77 but the snapshots have been hit and miss. The ports system has not provided a reliable means of Fortran support, IMHO. However, if g77 were part of the base FreeBSD system, assuming f2c is ripped out, then Fortran support would be gaurenteed to be there when needed. I understand that most people using FreeBSD are using it for server tasks and C development. However, FreeBSD is also an excellent OS for a scientific workstation, and that means Fortran is essential. I run a farm of 6 dual CPU PPro/PII systems running quantum chemical calculations 24/7. I do my part to get my colleagues to try FreeBSD instead of NT and Linux. Removing Fortran support from the base system will make that a tougher job. Thanks. -- Glenn Johnson gljo...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
