Re: procfs problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JMmap02# strace -p 730 JMstrace: open(/proc/..., ...): No such file or directory JMtrouble opening proc file You must mount procfs. # fstab; proc /proc procfs rw 0 0 The bi-weekly status messages have been claiming that all the common debugging tools except for truss have been converted to work without procfs, since procfs is now deprecated. Does that not include strace, or is there something else wrong here? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/eBpHswXMWWtptckRAgSoAJ9IcIadlSRauyYJQHDc9GinZ20YCACfVGf1 ysBa4h7i4d99kPhr4xBdfZ8= =7431 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: procfs problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JMmap02# strace -p 730 JMstrace: open(/proc/..., ...): No such file or directory JMtrouble opening proc file You must mount procfs. # fstab; proc /proc procfs rw 0 0 The bi-weekly status messages have been claiming that all the common debugging tools except for truss have been converted to work without procfs, since procfs is now deprecated. Does that not include strace, or is there something else wrong here? strace is not part of FreeBSD. Oh - I didn't think that truss was either, which lead me to believe that someone had gone through ports and fixed a bunch of them. Is someone working on fixing the strace and truss ports yet? Are there other popular ports that depend on procfs? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/eLTxswXMWWtptckRAtTdAKCiiZ1ffDqyLx0ZdT8pKEGmv1LX/wCgrTbx M3/ZMG8QAIivfTdyfm3zNWM= =s77n -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re-fdisk'ing a partition - permission denied?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You have hit one of the main issues still to be resolved in GEOM. (I don't know that phk thinks it's a problem to be resolved or a feature to be documented.) In any case, since GEOM was added you can no longer slice or label an active device. Ah - is that to say that, in general, you can't mess with the disk's MBR? I was also running into this. The situation that I have is that I have a bunch of colocated machines that are set in the bios to try booting a hard disk, and then, failing that, pxe netboot. I keep a pxeboot server there in the colo with an up-to-date binary release, and when I want to upgrade a machine, I just overwrite the mbr with zeros and reboot. The bios will then netboot, and the release is scripted to be noninteractive, to wipe the disks and re-install and then reboot the system when it's done. If I can't touch the mbr on the running system, then I won't be able to work this way anymore. Is there some other alternative? If I were running linux, I could write to /dev/nvram to update the bios cmos settings from the running system - does freebsd have a similar way to access the bios cmos settings? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/XPqeswXMWWtptckRAiZPAJwLRGlbcIPCEJGgnJzeCG2sZtXvxACfWMhz tBO8PAjJu6OOZrNP4S3zIps= =9wdb -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re-fdisk'ing a partition - permission denied?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There was, at one point, talk of adding some sort of geom.dont_blame_phk_when_you_shoot_your_ankle_off sysctl to permit this type of access when the user was absolutely sure they knew exactly what kind of dangerous and potentially corrupting thing they were doing and wanted to do it anyway, but I'm not sure it got anywhere. I would be very much in favor of such a sysctl. For my particular issue, though, accessing the bios settings might be a viable alternative - is there any way to do so under freebsd? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/XQDDswXMWWtptckRAkXUAKCrCMfzxsovAnx+JwSvN/jAYKB2QgCdHC/H 070NTy87RnhJ2sL22NwcpiM= =V++P -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In this configuration I see a lot of nfs server ...: is not responding and nfs server ...: is alive again when I copy large files (e.g. a CD image). All of them happen in the same second. I haven't looked at the state or priority of the cp process when this happens. I'm also seeing a similar problem - I have a cluster of high-volume mailservers delivering mail over nfs to maildirs on a netapp. The cluster was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how they would do. The 5.1 boxes accepted and queued mail as well as the 4-stable boxes, but delivering the mail into the maildirs over nfs, I kept seeing those short-lived hangs, and so the queues started to back up as the boxes were accepting mail faster than they could deliver it. My mounts are all nfsv3 over udp. -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/TYRhswXMWWtptckRAl7XAKDqAe2Z3HnT7bb+J6gPchMfxGo2fQCaA8u0 8wKNDwTh8NIFkLUNdi2HV2Q= =g19M -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs tranfers hang in state getblck or nfsread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm also seeing a similar problem - I have a cluster of high-volume mailservers delivering mail over nfs to maildirs on a netapp. The cluster was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how they would do. [...] My mounts are all nfsv3 over udp. UDP has problems, if you lose any packets at all. The problem is that the packet reassembly buffer stays full until you retry, and the retry is out of band, for packets larger than the MTU size. What happens when you drop the read and write size low enough that the data and headers fit in a single UDP packet (e.g. according to tcpdump)? Does it suddenly become more reliable? I'll try to play around with it and see. We actually had this discussion already over on -performance (and I get what you're saying), but the interesting question here is, why is 5.1 behaving so differently from 4-stable on identical hardware under identical load. -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/TfwcswXMWWtptckRAoZIAKCA6doHe3VXrwFj/xX/HkfV18emYACfW1GK Yw5ZniWoHqHQg/ez8sj4Svc= =hFfm -END PGP SIGNATURE- ___ [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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. Just want to report initial success with this - my smp machine previously would not recognize my offboard pci-based ide devices with an smp kernel, but now it's working fine. I'm getting some unpleasant-looking messages when the drives get probed at boot-time, though: FreeBSD 5.1-CURRENT #0: Sun Aug 24 06:20:33 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JKERN [...] atapci1: Promise PDC20262 UDMA66 controller port 0xef00-0xef3f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 mem 0xfebc-0xfebd irq 11 at device 13.0 on pci0 ata2: at 0xefe0 on atapci1 ata3: at 0xefa0 on atapci1 [...] ata2-master: WARNING - ATA_IDENTIFY recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: 57241MB ST360021A [116301/16/63] at ata2-master UDMA66 ata3-master: WARNING - ATA_IDENTIFY recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad1: 25965MB Maxtor 92720U8 [52755/16/63] at ata3-master UDMA66 ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - WRITE_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt etc. Haven't seen any more of these messages since boot-time, and the everything seems to be working fine, but I still wonder what that's all about? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/S1BXswXMWWtptckRAlEJAKCZ8VGpH70D6zdzPQiI4Dgc0yfjGQCgg9dm /DsP4A5uLYEFBy7ZqiZID8k= =STWA -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files to your src tree, remove the contents of sys/dev/ata and extract the ATAng-*tgz file there, then do the usual drill to get a new kernel... Tried to grab this last night, but got 550 conf-patch: Permission denied. when trying to retrieve conf-patch. current driver from cvs doesn't find any disk -- when try to mount root :( I'm also having a problem with the -current ata driver. I have an smp system with an offboard promise ide card, and when I build an smp kernel, the ide drives do not get detected. If I take smp out of the kernel though, the drives get detected fine. Anyone know why this might be? dmesg's are below as a unified diff between the non-smp kernel and the smp kernel. -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu - --- dmesg.up Sat Aug 9 01:38:11 2003 +++ dmesg.smp Fri Aug 8 05:11:04 2003 @@ -1,99 +1,107 @@ 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 #0: Fri Aug 8 03:06:30 PDT 2003 +FreeBSD 5.1-CURRENT #1: Fri Aug 8 04:15:59 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JKERN - -Preloaded elf kernel /boot/kernel/kernel at 0xc052c000. +Preloaded elf kernel /boot/kernel/kernel at 0xc0546000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (350.80-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268435456 (256 MB) - -avail memory = 255090688 (243 MB) +avail memory = 254971904 (243 MB) +Programming 24 pins in IOAPIC #0 +IOAPIC #0 intpin 2 - irq 0 +IOAPIC #0 intpin 16 - irq 10 +IOAPIC #0 intpin 17 - irq 11 +IOAPIC #0 intpin 19 - irq 9 +FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs + cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 + cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 + io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 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) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xef40-0xef5f irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller 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 uscanner0: Hewlett-Packard HP ScanJet 5200C, rev 1.00/1.00, addr 2 - -pci0: bridge, PCI-unknown at device 7.3 (no driver attached) +piix0 port 0x440-0x44f at device 7.3 on pci0 +Timecounter PIIX frequency 3579545 Hz atapci1: Promise PDC20262 UDMA66 controller port 0xef00-0xef3f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 mem 0xfebc-0xfebd irq 11 at device 13.0 on pci0 ata2: at 0xefe0 on atapci1 ata3: at 0xefa0 on atapci1 ahc0: Adaptec 2940 Ultra SCSI adapter port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 10 at device 15.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs pcm0: Creative EMU10K1 port 0xef80-0xef9f irq 11 at device 16.0 on pci0 pcm0: TriTech TR28602 AC97 Codec dc0: 82c169 PNIC 10/100BaseTX port 0xe400-0xe4ff mem 0xfebfef00-0xfebfefff irq 11 at device 18.0 on pci0 dc0: Ethernet address: 00:a0:cc:40:8e:3e miibus0: MII bus on dc0 bmtphy0: BCM5201 10/100baseTX PHY on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, video at device 20.0 (no driver attached) pci0: multimedia at device 20.1 (no driver attached) orm0: Option ROMs at iomem 0xd0800-0xd1fff,0xcc000-0xd07ff,0xc-0xca7ff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO
