Re: procfs problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > > JM>map02# strace -p 730
> > > JM>strace: open("/proc/...", ...): No such file or directory
> > > JM>trouble 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: procfs problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> JM>map02# strace -p 730
> JM>strace: open("/proc/...", ...): No such file or directory
> JM>trouble 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: 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: 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: 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: 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: 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: 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 [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 [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=0x183fbff 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: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef40-0xef5f irq 9 at device 7.2 on pci0 usb0: 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: at device 7.3 (no driver attached) +piix0 port 0x440-0x44f at device 7.3 on pci0 +Timecounter "PIIX" frequency 3579545 Hz atapci1: 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: 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: port 0xef80-0xef9f irq 11 at device 16.0 on pci0 pcm0: 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: on dc0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) orm0: at iomem 0xd0800-0xd1fff,0xcc000-0xd07ff,0xc-0xca7ff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: 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: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unkn
