Re: Failing to understand getrusage()
On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
On Thu, Mar 02, 2006 at 11:50:29PM +, Nick Barnes wrote:
At 2006-03-02 22:24:17+, Nik Clayton writes:
I'm failing to understand how getrusage() works, which is a bit
perplexing,
because it doesn't seem like it would be terribly complicated.
ru_maxrss is the maximum resident set size, not the heap size.
malloc(big) doesn't grow the resident set. Touching the memory you
have allocated will grow the resident set. Try this:
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
p = malloc(SIZE);
assert(p)
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
for (i=0; iSIZE; ++i) {
p[i] = 0;
}
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
Well, there was a call to memset() in the original Nik's program
while your code just does the same by itself.
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like
for (x = 0; x 0x100; x++)
getpid();
and you would get statisically stable results:
deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548
See,
% sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
133 Hz is very slow on 3GHz machine, and curproc-p_stats-p_ru is
updated on statclock tick, see sys/kern/kern_clock.c.
pgpKxJflUdGZG.pgp
Description: PGP signature
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Mon, Mar 06, 2006 at 02:50:41PM -0800, Ade Lovett wrote: While we're at it, bin/94028 points out a fundamental problem with ifconfig(8) as it stands on 6.1-PRERELEASE, preventing MTUs from being set on vlan interfaces. I've taken the PR -- no reason to panic. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA drive 1 disappears
Dear list, I've seen GEOM mirror error messages at two nearly identical systems. Both are running on Asrock K7VT4xx (VIA chipset) boards and having two SATA drives connected (Hitachi HDS728080PLA380/PF2OA60A). On both systems we're using gmirror RAID-1 per slice. After same weeks of productional use, on both systems the first disc (ad4) within the RAID set came out with error messages like: +ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=127199808 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=10968959 +ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=10968959 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=118404223 +ad4: FAILURE - WRITE_DMA timed out LBA=10968959 +GEOM_MIRROR: Request failed (error=5). ad4s1[WRITE(offset=5616074752, length=16384)] +GEOM_MIRROR: Device gm0s1: provider ad4s1 disconnected. +ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=118404223 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=122117983 +ad4: FAILURE - WRITE_DMA timed out LBA=118404223 ... +subdisk4: detached +ad4: detached +GEOM_MIRROR: Device gm0s2: provider ad4s2 disconnected. +GEOM_MIRROR: Request failed (error=5). ad4s2[READ(offset=8987662336, length=2048)] After these messages the disc isn't seen by the system anymore: atacontrol list ATA channel 0: Master: acd0 NEC DVD RW ND-3540A/1.01 ATA/ATAPI revision 0 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: no device present ATA channel 3: Master: ad6 HDS728080PLA380/PF2OA60A Serial ATA v1.0 Slave: no device present The (S)ATA controller and devices is being detected at startup as: +atapci0: VIA 6420 SATA150 controller port +atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f +ad4: 78533MB HDS728080PLA380 PF2OA60A at ata2-master SATA150 +ad6: 78533MB HDS728080PLA380 PF2OA60A at ata3-master SATA150 +GEOM_MIRROR: Device gm0s1 created (id=613166686). +GEOM_MIRROR: Device gm0s1: provider ad4s1 detected. +GEOM_MIRROR: Device gm0s2 created (id=91558579). +GEOM_MIRROR: Device gm0s2: provider ad4s2 detected. +GEOM_MIRROR: Device gm0s1: provider ad6s1 detected. +GEOM_MIRROR: Device gm0s1: provider ad6s1 activated. +GEOM_MIRROR: Device gm0s1: provider ad4s1 activated. +GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 launched. +GEOM_MIRROR: Device gm0s2: provider ad6s2 detected. +GEOM_MIRROR: Device gm0s2: provider ad6s2 activated. +GEOM_MIRROR: Device gm0s2: provider ad4s2 activated. +GEOM_MIRROR: Device gm0s2: provider mirror/gm0s2 launched. The RAID set is now running degraded. Both systems are running on R 6.0. I know it's more like guesswork, but what might be the reason for these disc errors? Are the discs really dying? When rebooting the system(s) the first disc re-appears for a few days and will disappear again later. The hdu connectors have been checked. Is there something wrong with gmirror, geom or the controller driver? What makes me scratching my head is on both systems just the first disc is dying. I've found postings from one year ago and the conclusion was faulty hardware. Are there any signs for geom or driver problems? `uname -a': FreeBSD GwOsl 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 30 02:41:47 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GwOsl i386 Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
On Friday 03 March 2006 23:45, Mark Kirkwood wrote: I would certainly see the installer handling software RAID as a considerable benefit. From what I've seen on the net, to install and boot off RAIDed system disks is quite fiddly (maybe gmirror is the exception here, as I've mainly been looking at striping). Cheers Mark geom changed this complications definitely, using gmirror or gstripe commands is easy as copying a file. Probably one of the most important things that with vinum as example it was not possible to mirror a root partition but since gmirror places the metadata different we can have now a mirrored and bootable root partition. Striping with ccd and vinum or mirroring was certainly a pain even if it worked then stable and reliable. So in comparism the easy use of geom is great and the people which developed geom did a really fantastic job. João Joao, I do agree that gmirror is not that bad and not that difficult. But take a look at how to setup a fresh system using gmirror (slice by slice mirroring): - install a complete system to a fresh disc - create the (well sized) slices on a 2nd disc (not that easy) - create the gmirror set on disc 2 - bring gmirror up - copy all filesystems over to the gmirror set - reboot - create exactly sized slices on disc 1 - insert everything into the gmirror set Using that procedure you're going to copy each installed file three times (install, copy to mirror, sync mirror). That's a waste of time compared to a solution where the installer would be able to install directly into a mirror. When using disc based gmirror (instead of per slice gmirror) the procedure is a bit easier, but similar. If one could create a gmirror set before installing the base system and tell the installer to install into gmX instead of adX/daX, the whole procedure would be much easier and would take less time. I've had to setup a handful of fresh systems over the last months and it was a pain to manually setup gmirror on each fresh system. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
On Tuesday 07 March 2006 08:55, Volker wrote: I do agree that gmirror is not that bad and not that difficult. But take a look at how to setup a fresh system using gmirror (slice by slice mirroring): - install a complete system to a fresh disc - create the (well sized) slices on a 2nd disc (not that easy) - create the gmirror set on disc 2 - bring gmirror up - copy all filesystems over to the gmirror set - reboot - create exactly sized slices on disc 1 - insert everything into the gmirror set Using that procedure you're going to copy each installed file three times (install, copy to mirror, sync mirror). That's a waste of time compared to a solution where the installer would be able to install directly into a mirror. When using disc based gmirror (instead of per slice gmirror) the procedure is a bit easier, but similar. Hi there is no need to copy anything around ... - you do install the system as usual - before rebooting you create the to be mirrored disk with the gmirror label command (you do not loose data here) - then you change your fstab acordingly - you reboot - you insert the mirror disk(s) - gmirror should start syncing automatically if you did everything right ready, this is a 3 minute thing João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Hi! On Tue, Mar 07, 2006 at 09:39:29AM -0300, JoaoBR wrote: there is no need to copy anything around ... - you do install the system as usual - before rebooting you create the to be mirrored disk with the gmirror label command (you do not loose data here) - then you change your fstab acordingly - you reboot - you insert the mirror disk(s) - gmirror should start syncing automatically if you did everything right ready, this is a 3 minute thing Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Patrick, On 2006-03-07 13:45, Patrick M. Hausen wrote: . Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick Yes, Ralf S. Engelschall created a good guide: http://people.freebsd.org/~rse/mirror/ See 'GEOM mirror Approach 2: Single Slice, Preferred, More Flexible' Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Hello! On Tue, Mar 07, 2006 at 01:56:57PM +0100, Volker wrote: Patrick, On 2006-03-07 13:45, Patrick M. Hausen wrote: . Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick Yes, Ralf S. Engelschall created a good guide: http://people.freebsd.org/~rse/mirror/ See 'GEOM mirror Approach 2: Single Slice, Preferred, More Flexible' I _know_. This guide was first mentioned by me in this thread. But it assumes - install - boot - create mirror on second disk - copy data - reboot - sync mirror Now Joao said, creating a mirrored disk can be done from the emergency holographic shell at install time. OK, fine. Spares the copying. My question was: can I create a mirrored slice instead of a mirrored disk without copying the data at install time from the emergency shell? Otherwise I will still have to use Ralf's instructions, which are a bit more work to follow. Thanks, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Patrick, On 2006-03-07 14:22, Patrick M. Hausen wrote: Hello! On Tue, Mar 07, 2006 at 01:56:57PM +0100, Volker wrote: Patrick, On 2006-03-07 13:45, Patrick M. Hausen wrote: . Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick Yes, Ralf S. Engelschall created a good guide: http://people.freebsd.org/~rse/mirror/ See 'GEOM mirror Approach 2: Single Slice, Preferred, More Flexible' I _know_. This guide was first mentioned by me in this thread. But it assumes - install - boot - create mirror on second disk - copy data - reboot - sync mirror Now Joao said, creating a mirrored disk can be done from the emergency holographic shell at install time. OK, fine. Spares the copying. My question was: can I create a mirrored slice instead of a mirrored disk without copying the data at install time from the emergency shell? Otherwise I will still have to use Ralf's instructions, which are a bit more work to follow. Thanks, Patrick As far as I understand Joao's solution, he's mentioning disc mirroring (disc in a whole). When using slice mirroring I don't see a simple solution and RSE's paper is the only way to go. Anybody please correct me if I'm wrong. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 on TC1000 (was: wireless, ndis problems on Compaq TC1000 Tablet running 6-STABLE)
On Wednesday 30 November 2005 15:38, John Nielsen wrote: On Tuesday 29 November 2005 06:03 pm, Milan Obuch wrote: On Tuesday 29 November 2005 21:39, John Nielsen wrote: After successfully installing FreeBSD 6.0 on a Compaq TC1000 Tablet PC By the way, how did you install 6.0 there? I am working with TC1000 too, but it looks almost impossible to install FreeBSD without keyboard. Just would like to know possibilities - I tried 7.0 but ACPI does not work (does not boot even, only with ACPI disabled). My only obstacle was getting a keyboard attached to the console - by default it would boot up to sysinstall just fine but the keyboard wouldn't work. (It was detected, but not attached.. i.e. caps lock, etc would work but sysinstall wasn't getting any input.) Using a 6.0-BETA or RC disk (I don't remember which one), I wasn't able to get around this. However, using 6.0-RELEASE I was able to use the builtin keyboard by disabling atkbd0 AND atkbdc0 in the loader. I did verify this method with 6.1-BETA3. While I did not install it, only came to sysinstall, it works - even with ACPI loaded, which was my primary question. So after I build new 5.5-soon-to-be-RELEASE working partition, I can wipe currently used 5.4-STABLE, couple of months old one and put 6.1 there to test. Loading the kbdmux module may or may not be helpful--I didn't end up needing it. While I consider using loading kbdmux extremely useful, it did not work as an alternative for your installing method. Neither buttons nor keyboard worked, so no use... Once installed (and with sshd running as a backup), I updated to -STABLE and built a custom kernel that does not include atkbdc, atkbd, or psm. It works fine. (And it's especially nice with a VESA 1024x768 mode in syscons.) Could you share your setup? Kernel config and similar? Maybe X setup, if you are using it... I would like to put all information regarding TC1000 to my web log at www.dino.sk, so others could benefit from my observations as well. Regards, Milan N. B. No need to CC me, I read this list regularly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror(8) and graid3(8) changes.
On Mon, Mar 06, 2006 at 11:28:44PM +0100, Pawel Jakub Dawidek wrote: Hi. Here you can find patches with changes to gmirror(8) and graid3(8): http://people.freebsd.org/~pjd/patches/gmirror.7.patch http://people.freebsd.org/~pjd/patches/graid3.patch Hi Pawel, I've been experiencing lockups with gmirror, ATA/SATA on both i386 and amd64, under severe I/O (very heavily loaded Postgres DB). This has been on several different machines (remotely located, with no possibility of breaking into the debugger). Do you think these patches are worth testing in my case ? Phil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
Kris, If relevant, I may be able to test your patch, but the problem is occurring only rarely. Do you have any suggestions for isolating and reproducing this bug? Run your script in a loop? And I assume I can meaningfully test w/o the rsync call? I.e., just mounting and unmounting the drive over and over again should trigger the error, no? chad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 on TC1000 (was: wireless, ndis problems on Compaq TC1000 Tablet running 6-STABLE)
On Tuesday 07 March 2006 08:57, Milan Obuch wrote: On Wednesday 30 November 2005 15:38, John Nielsen wrote: On Tuesday 29 November 2005 06:03 pm, Milan Obuch wrote: On Tuesday 29 November 2005 21:39, John Nielsen wrote: After successfully installing FreeBSD 6.0 on a Compaq TC1000 Tablet PC By the way, how did you install 6.0 there? I am working with TC1000 too, but it looks almost impossible to install FreeBSD without keyboard. Just would like to know possibilities - I tried 7.0 but ACPI does not work (does not boot even, only with ACPI disabled). My only obstacle was getting a keyboard attached to the console - by default it would boot up to sysinstall just fine but the keyboard wouldn't work. (It was detected, but not attached.. i.e. caps lock, etc would work but sysinstall wasn't getting any input.) Using a 6.0-BETA or RC disk (I don't remember which one), I wasn't able to get around this. However, using 6.0-RELEASE I was able to use the builtin keyboard by disabling atkbd0 AND atkbdc0 in the loader. I did verify this method with 6.1-BETA3. While I did not install it, only came to sysinstall, it works - even with ACPI loaded, which was my primary question. So after I build new 5.5-soon-to-be-RELEASE working partition, I can wipe currently used 5.4-STABLE, couple of months old one and put 6.1 there to test. Glad to hear it. Loading the kbdmux module may or may not be helpful--I didn't end up needing it. While I consider using loading kbdmux extremely useful, it did not work as an alternative for your installing method. Neither buttons nor keyboard worked, so no use... Yeah, I'll have to play around with this some more. Once installed (and with sshd running as a backup), I updated to -STABLE and built a custom kernel that does not include atkbdc, atkbd, or psm. It works fine. (And it's especially nice with a VESA 1024x768 mode in syscons.) Could you share your setup? Kernel config and similar? Maybe X setup, if you are using it... I would like to put all information regarding TC1000 to my web log at www.dino.sk, so others could benefit from my observations as well. I don't have the tablet with me at the moment, but I do have the kernel config file (attached). The only options in there that I don't typically include on other machines are CPU_ENABLE_LONGRUN and SC_PIXEL_MODE, but I did have the sound and CD-ROM working on this kernel. For the VESA console you'll want to check the output of vidcontrol -i mode, but IIRC I used this in /etc/rc.conf: allscreens_flags=-f 8x8 cp437-8x8.fnt MODE_280 Obviously you could substitute different font sizes and character pages as appropriate. I did set up X.org, but don't have my config file. Xorg -configure was reasonably helpful. I may have only been able to use X's VESA driver, but I don't remember for certain. I do remember that the mouse was flakey. My inability to get the built-in wireless working (even with NDIS) coupled with the mouse not behaving well enough to use in X put a damper on my enthusiasm for running FreeBSD on the device. I didn't explore using the stylus at all. I'd be interested in getting e-mail updates if you make any headway on any of those fronts, and I'll try to keep an eye on your blog. JN # SPARRTAB - Compaq TC1000 tablet machine i386 cpu I586_CPU ident SPARRTAB options CPU_ENABLE_LONGRUN options IPFIREWALL options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options LIBMCHAIN options LIBICONV options NETSMB options NETSMBCRYPTO options SMBFS #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style
Re: VFS MFC testers wanted
Jeff, Kris Kennaway directed me to this thread from FreeBSD-questions. I am seeing a panic: unmount: dangling vnode with 6.0-RELEASE. Here are the relevant threads: 2 probs w/ backup.sh: Device busy and dangling vnode http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/114825.html Panic: unmount: dangling vnode http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/115060.html If relevant, I may be able to test your patch, but the problem is occurring only rarely. Do you have any suggestions for isolating and reproducing this bug? Also, we are seeing this problem on a production box. I notice that the patch fixes 6 issues, and apparently breaks the kernel ABI, which sounds nasty from out here in userland. Any chance of getting a patch that isolates this specific issue? I'll be more likely able to apply such a patch. Our alternative is to simply keep our backup drive always mounted until 6.1 comes out and test your patch then. :^) Thoughts? Thanks for your work on this. Chad Whitacre http://www.zetadev.com/ Jeff Roberson wrote: I plan to MFC all of this lovely stuff for 6.1: http://www.chesapeake.net/~jroberson/vfsmfc.diff I'm looking for people who are willing to patch their stable boxes and test this. This has the following changes in it: 1) Improved debugging with DEBUG_LOCKS via the new stack(9) api. 2) Fixed an INACTIVE leak. 3) Fixed several unmount races. 4) Fixed several nullfs unmount issues. 5) Some more Giant related VFS fixes and asserts. 6) Fixed the quota deadlock. These problems should be rare enough that most of you have not seen them. So just let me know if this introduces any new problems etc. I will be MFCing within a week. Thanks, Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Tue, Mar 07, 2006 at 12:11:56PM +0200, Kostik Belousov wrote:
On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like
for (x = 0; x 0x100; x++)
getpid();
and you would get statisically stable results:
deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548
See,
% sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
133 Hz is very slow on 3GHz machine, and curproc-p_stats-p_ru is
updated on statclock tick, see sys/kern/kern_clock.c.
This sounds very clear and reasonable. I shouldn't have forgotten
about the driving role of statclock in collecting all rusage stats,
including those related to memory consumption.
Thank you for resolving our doubts! :-)
--
Yar
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch for quota deadlock
Hello. On Tue, Feb 28, 2006 at 02:51:39AM -0500, Kris Kennaway wrote: On Tue, Feb 28, 2006 at 08:40:37AM +0100, Oliver Brandmueller wrote: Anyway, I'll discuss with my colleagues and we'll see if we want to take the risk. Thanks, it would be a big help if you're willing to try. We're in the middle of a migration, so I could only put the version to the standby server, which had no problems in the past. Anyway, as soon as all this is done, I can test, probaly from the middle of next week. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | pgpuK0LjFI03F.pgp Description: PGP signature
Re: gmirror(8) and graid3(8) changes.
On Tue, Mar 07, 2006 at 03:15:19PM +0100, Phil Regnauld wrote: + On Mon, Mar 06, 2006 at 11:28:44PM +0100, Pawel Jakub Dawidek wrote: + Hi. + + Here you can find patches with changes to gmirror(8) and graid3(8): + + http://people.freebsd.org/~pjd/patches/gmirror.7.patch + http://people.freebsd.org/~pjd/patches/graid3.patch + + Hi Pawel, + + I've been experiencing lockups with gmirror, ATA/SATA on both + i386 and amd64, under severe I/O (very heavily loaded Postgres DB). + This has been on several different machines (remotely located, with + no possibility of breaking into the debugger). + + Do you think these patches are worth testing in my case ? Are you sure it was gmirror's fault? It will be quite hard for gmirror to hang machine so badly that we are not able to enter ddb... Anyway, I'd prefer to test those patches not in production environment yet. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpO1iG9gK4y4.pgp Description: PGP signature
Re: gmirror(8) and graid3(8) changes.
On Tue, Mar 07, 2006 at 04:16:36PM +0100, Pawel Jakub Dawidek wrote: + +I've been experiencing lockups with gmirror, ATA/SATA on both +i386 and amd64, under severe I/O (very heavily loaded Postgres DB). +This has been on several different machines (remotely located, with +no possibility of breaking into the debugger). + +Do you think these patches are worth testing in my case ? Are you sure it was gmirror's fault? It doesn't happen if I use either underlying raw disk without gmirror. It will be quite hard for gmirror to hang machine so badly that we are not able to enter ddb... No, I meant, I couldn't access the box's DDB remotely as it was in a hosting center without access to a physical console, and I had to have someone restart it. Anyway, I'd prefer to test those patches not in production environment yet. It is a test machine, so I don't mind, was just curious if this could be related. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
On Tue, Mar 07, 2006 at 06:06:31PM +0300, Yar Tikhiy wrote:
On Tue, Mar 07, 2006 at 12:11:56PM +0200, Kostik Belousov wrote:
On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
Personally, I'd like to say a me too. /me too fails to see why
in a quiet, idle system ru_maxrss is very unpredictable over numerous
runs of the test program, both before and after the malloc+memset.
Filling the memory with a non-zero value doesn't matter. Is it the
Heizenberg daemon at work? :-)
I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like
for (x = 0; x 0x100; x++)
getpid();
and you would get statisically stable results:
deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548
See,
% sysctl kern.clockrate
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
133 Hz is very slow on 3GHz machine, and curproc-p_stats-p_ru is
updated on statclock tick, see sys/kern/kern_clock.c.
This sounds very clear and reasonable. I shouldn't have forgotten
about the driving role of statclock in collecting all rusage stats,
including those related to memory consumption.
It may be desirable to add ru_maxrss sampling at the calcru time too.
Something like this:
Index: sys/kern/kern_resource.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.156
diff -u -r1.156 kern_resource.c
--- sys/kern/kern_resource.c22 Feb 2006 16:58:48 - 1.156
+++ sys/kern/kern_resource.c7 Mar 2006 16:10:27 -
@@ -853,9 +853,16 @@
struct rusage *rup;
{
struct proc *p;
+ struct vmspace *vm;
+ long rss;
p = td-td_proc;
PROC_LOCK(p);
+ vm = p-p_vmspace;
+ rss = pgtok(vmspace_resident_count(vm));
+ if (rup-ru_maxrss rss)
+ rup-ru_maxrss = rss;
+
switch (who) {
case RUSAGE_SELF:
pgpMImMfLdJf7.pgp
Description: PGP signature
Re: VFS MFC testers wanted
On Tue, Mar 07, 2006 at 09:58:35AM -0500, Chad Whitacre wrote: Kris, If relevant, I may be able to test your patch, but the problem is occurring only rarely. Do you have any suggestions for isolating and reproducing this bug? Run your script in a loop? And I assume I can meaningfully test w/o the rsync call? I.e., just mounting and unmounting the drive over and over again should trigger the error, no? No, the rsync (i.e. activity on the filesystem) is important. Kris pgpbfK9ZsnPAD.pgp Description: PGP signature
Re: Fresh install on gmirror'ed disks?
On Tue, March 7, 2006 4:39 am, JoaoBR wrote: On Tuesday 07 March 2006 08:55, Volker wrote: I do agree that gmirror is not that bad and not that difficult. But take a look at how to setup a fresh system using gmirror (slice by slice mirroring): - install a complete system to a fresh disc - create the (well sized) slices on a 2nd disc (not that easy) - create the gmirror set on disc 2 - bring gmirror up - copy all filesystems over to the gmirror set - reboot - create exactly sized slices on disc 1 - insert everything into the gmirror set Using that procedure you're going to copy each installed file three times (install, copy to mirror, sync mirror). That's a waste of time compared to a solution where the installer would be able to install directly into a mirror. There's no need to copy files around. gmirror handles it all for you behind the scenes. Just create the gmirror labels using the existing disks/slices/partitions, then insert the second set of disks/slices/parittions. gmirror will handle synchonising the data across the mirror. When using disc based gmirror (instead of per slice gmirror) the procedure is a bit easier, but similar. there is no need to copy anything around ... - you do install the system as usual - before rebooting you create the to be mirrored disk with the gmirror label command (you do not loose data here) - then you change your fstab acordingly - you reboot - you insert the mirror disk(s) - gmirror should start syncing automatically if you did everything right realy, this is a 3 minute thing This is the process I just went through. It would be nice if there was a post-install step that did this automatically, but it wasn't all that hard to do manually. Just CTRL+F4 to open the terminal, run a few commands to create the mirror, edit /etc/fstab, and exit the installer. Dru Lavigne's OnLamp article about this makes it almost trivial to do. Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
Kris, No, the rsync (i.e. activity on the filesystem) is important. Yeah, just ran a test w/o it actually. We are planning to run a test w/ some disk activity later this afternoon. I suppose the more activity, the more likely to see the bug, eh? chad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
On Tue, Mar 07, 2006 at 12:26:47PM -0500, Chad Whitacre wrote: Kris, No, the rsync (i.e. activity on the filesystem) is important. Yeah, just ran a test w/o it actually. We are planning to run a test w/ some disk activity later this afternoon. I suppose the more activity, the more likely to see the bug, eh? Yes. FYI, I am fairly confident this is fixed, because I make extensive use of mount/umount+filesystem activity, and I am no longer seeing problems like this. Kris pgpdOdnItHgpw.pgp Description: PGP signature
Re: VFS MFC testers wanted
Kris, Yes. FYI, I am fairly confident this is fixed, because I make extensive use of mount/umount+filesystem activity, and I am no longer seeing problems like this. Great! Thanks for the info. We won't kill ourselves trying to test this then. chad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
The problem I'm having is not exactly what is described in pr bin/80389, although it is very much related. So, I'm unable to verify if the patch you gave corrects the problem, since the problem is not visible on my systems. I do have a lockd hang, however... Here is as much data as I can gather: 1- Only one client machine of all I have, the only one which is remote booted, hangs on startup with rpc.lockd/rpc.statd enabled. The hang occurs when daemons try to open their pid file using pidfile_open functions after statd and lockd have been started. 2- The problem does not appear when I do touch test; lockf test echo 1. 3- The only machine that shows this problem is the only machine where /var is an NFS mount. 4- Applying the patch to revert to the Oct/2004 version, either to the client or the server, didn't change a thing. 5- I'm led to believe that the hang on my machine is related to a problem on the pidfile_open functions, not on rpc.lockd. Can anybody else verify if the system hangs on pidfile_open when: - /var is nfs mounted - lockd and statd are running - a daemon is started (perhaps /etc/rc.d/cron start) Ter, 2006-03-07 às 08:10 +0900, Jun Kuriyama escreveu: At Mon, 06 Mar 2006 22:56:46 +, Miguel Ramos wrote: I'm getting rpc.lockd related hangs on a single machine which is remote booted. I'm goind to test you patch as soon as possible. Thanks! Thanks. -- Miguel Ramos [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
On Tue, Mar 07, 2006 at 12:33:28PM -0500, Chad Whitacre wrote: Kris, Yes. FYI, I am fairly confident this is fixed, because I make extensive use of mount/umount+filesystem activity, and I am no longer seeing problems like this. Great! Thanks for the info. We won't kill ourselves trying to test this then. Well, I'd still like you to test it just to be sure. I'm not able to detect all FreeBSD bugs, after all (though I try :-) Kris pgpPkk9pi3I9L.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 05:38:56PM +, Miguel Ramos wrote: The problem I'm having is not exactly what is described in pr bin/80389, although it is very much related. So, I'm unable to verify if the patch you gave corrects the problem, since the problem is not visible on my systems. I do have a lockd hang, however... Here is as much data as I can gather: 1- Only one client machine of all I have, the only one which is remote booted, hangs on startup with rpc.lockd/rpc.statd enabled. Just to verify: lockd is enabled on BOTH client AND server? Kris pgpetHf2mFo2P.pgp Description: PGP signature
Re: FreeBSD 6.0 on TC1000
On Tuesday 07 March 2006 15:58, John Nielsen wrote: [snip] I will try to document your method on my web. It's far easier than my first method - take disc drive out, install system elsewhere, do not forget anything and enjoy :) While I consider using loading kbdmux extremely useful, it did not work as an alternative for your installing method. Neither buttons nor keyboard worked, so no use... Yeah, I'll have to play around with this some more. Just to be exact - it did not work at install time. I did load kbdmux from loader prompt, but to no avail... Loading kbdmux after FreeBSD is installed (tested with 7.0-CURRENT) works great. [snip] I don't have the tablet with me at the moment, but I do have the kernel config file (attached). The only options in there that I don't typically include on other machines are CPU_ENABLE_LONGRUN and SC_PIXEL_MODE, but I did have the sound and CD-ROM working on this kernel. I do include CPU_ENABLE_LONGRUN in my kernel as well, SC_PIXEL_MODE is not yet known to me. I will test it. Reason I am asking about config is there are some special devices there not yet functioning - Compaq QMenu button and (designed to be) Outlook button are the first coming in sight. There are others... like softmodem, atmel wifi, pen. From these mentioned, pen is working - see http://www.freebsd.org/cgi/query-pr.cgi?pr=65355 for patch I am using for this. Three 'soft touch' buttons (change orientation, journal and editor) do not work, but I will try to play with them somewhat later. Actually they are just a pen extensions. Sound is working well, too. By the way, do you have docking station as well or are you using USB connected CD ROM? [snip] I did set up X.org, but don't have my config file. Xorg -configure was reasonably helpful. I may have only been able to use X's VESA driver, but I don't remember for certain. I do remember that the mouse was flakey. I am using X (oh, just remembered, I reported tablet working with FreeBSD at some database some at http://gerda.univie.ac.at or something like this some time, maybe two years, ago with 5.2.1) and no problem, mouse did not work, but works with 7.0-CURRENT, but I have no X there yet. My inability to get the built-in wireless working (even with NDIS) coupled with the mouse not behaving well enough to use in X put a damper on my enthusiasm for running FreeBSD on the device. I didn't explore using the stylus at all. Do not get disgust yourself, this tablet is great, eve if not everything works at all or well. I choose it because of its weight - half of those mean notebooks, got great price for the device and great device to play with as well :) I am using standard USB mouse or stylus. Both work well, so no trouble at all. And this is my almost daily used tablet, so I can only tell it's OK. Well, but could be better, and that's what I'am aiming at. I'd be interested in getting e-mail updates if you make any headway on any of those fronts, and I'll try to keep an eye on your blog. Great. And, as usual, any help appreciated to keep everything getting better. There is much info on getting linux to work with TC1000, but almost nothing about FreeBSD, so when I get any trace I am investigating. -- N. B.: No need to CC me, I read this list regularly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
1- Only one client machine of all I have, the only one which is remote booted, hangs on startup with rpc.lockd/rpc.statd enabled. Just to verify: lockd is enabled on BOTH client AND server? Kris Oh yes. If any of the daemons is not enabled on both machines there's no locking, there's no system hang and all that occurs is: can't open or create /var/run/cron.pid: Operation not supported. which is ok, of course, although it's a pitty that it can't work without locking. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 05:56:22PM +, Miguel Lopes Santos Ramos wrote: 1- Only one client machine of all I have, the only one which is remote booted, hangs on startup with rpc.lockd/rpc.statd enabled. Just to verify: lockd is enabled on BOTH client AND server? Kris Oh yes. If any of the daemons is not enabled on both machines there's no locking, there's no system hang and all that occurs is: can't open or create /var/run/cron.pid: Operation not supported. OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken operation. Kris pgp1XQEd2K5rT.pgp Description: PGP signature
Re: gmirror(8) and graid3(8) changes.
On Tue, Mar 07, 2006 at 04:46:04PM +0100, Phil Regnauld wrote: + Anyway, I'd prefer to test those patches not in production environment + yet. + + It is a test machine, so I don't mind, was just curious if this could + be related. Could be, please give it a shot. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpqRiNGH3nYD.pgp Description: PGP signature
Re: VFS MFC testers wanted
On 3/3/06, Jeff Roberson [EMAIL PROTECTED] wrote: I plan to MFC all of this lovely stuff for 6.1: http://www.chesapeake.net/~jroberson/vfsmfc.diff I'm looking for people who are willing to patch their stable boxes and test this. This has the following changes in it: 1) Improved debugging with DEBUG_LOCKS via the new stack(9) api. 2) Fixed an INACTIVE leak. 3) Fixed several unmount races. 4) Fixed several nullfs unmount issues. 5) Some more Giant related VFS fixes and asserts. 6) Fixed the quota deadlock. These problems should be rare enough that most of you have not seen them. So just let me know if this introduces any new problems etc. I will be MFCing within a week. Do you have a list of the PRs that this affects and/or resolves? I'm curious, specifically, about kern/84589. I believe it may be related to snapshots in some way, but I don't know. I'm not going to be able to test the patch on these servers, unfortunately, as they're fully in production now. The servers are stable now with background_fsck=NO, but YES is still the default (last I checked). FWIW: the deadlock in 84589 doesn't involve quotas, as there were no quotas enabled in the kernel. The URLs referenced in the PR are no longer valid (they were never clicked) but I can produce them if necessary. Also: http://www.freebsd.org/releases/6.1R/todo.html The todo page mentions deadlocks but doesn't link to any specific PRs/threads that discuss them. Are these fixed with this MFC? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken operation. Kris Will you help me? I've been trying to use tcpdump -vvv on this but I get either a lot of trash or nothing. Which ports should I dump? So far I tried running on the server # tcpdump -vvv 'host client and (udp port lockd or udp port sunrpc)' This gets me nothing. When I try nfs ports I get lots of trash, since all filesystems in this client are nfs mounted from this server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
On Tue, Mar 07, 2006 at 10:15:59AM -0800, David Kirchner wrote: Do you have a list of the PRs that this affects and/or resolves? I don't know of any relevant PRs, but I haven't looked very hard. The bugs Jeff has been fixing are mostly those I've been able to reproduce myself in testing. I'm curious, specifically, about kern/84589. I believe it may be related to snapshots in some way, but I don't know. I'm not going to be able to test the patch on these servers, unfortunately, as they're fully in production now. The servers are stable now with background_fsck=NO, but YES is still the default (last I checked). You need to enable debugging, specifically KDB, DDB, INVARIANTS, INVARIANT_SUPPORT, DEBUG_LOCKS and DEBUG_VFS_LOCKS (ideally with the patch applied, as it gives more useful debugging). Then reproduce the deadlock condition, break to DDB and do 'show lockedvnods' and 'wh pid' where pid are the processes listed as holding locks. Also: http://www.freebsd.org/releases/6.1R/todo.html The todo page mentions deadlocks but doesn't link to any specific PRs/threads that discuss them. Are these fixed with this MFC? Some deadlocks are resolved, yes. There are other snapshot-related deadlocks that are not fixed with this patch, but which Jeff and others are still working on. Kris pgpDkCqJCV3wS.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 06:17:00PM +, Miguel Lopes Santos Ramos wrote: OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken operation. Kris Will you help me? I've been trying to use tcpdump -vvv on this but I get either a lot of trash or nothing. Which ports should I dump? So far I tried running on the server # tcpdump -vvv 'host client and (udp port lockd or udp port sunrpc)' This gets me nothing. When I try nfs ports I get lots of trash, since all filesystems in this client are nfs mounted from this server. You do indeed need to dump the nfs traffic. Try to do it when the system is otherwise quiet if it is generating too much traffic. Kris pgpohg1FU7HY4.pgp Description: PGP signature
Fatal trap 12: page fault while in kernel mode tc_windup()
After a cvsup to RELENG_6 today I got the following trap while encoding some videos with Avidemux. I'm going to leave the machine at the ddb prompt since the following trace information doesn't seem very helpful. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffbb80551f10 fault code = supervisor read, page not present instruction pointer = 0x8:0x802371c4 stack pointer = 0x10:0x9634bb90 frame pointer = 0x10:0x9634bbf0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 19381 (avidemux2) [thread pid 19381 tid 100115 ] Stopped at tc_windup+0x24: movl0x50(%r13),%eax db db bt Tracing pid 19381 tid 100115 td 0xff001cb0b980 tc_windup() at tc_windup+0x24 hardclock() at hardclock+0x17 lapic_handle_timer() at lapic_handle_timer+0x11c Xtimerint() at Xtimerint+0x76 -- Anish Mistry pgpSSCEArdCAU.pgp Description: PGP signature
Re: cvs commit: www/en/releases/6.1R todo.sgml
On Mon, Mar 06, 2006 at 02:50:41PM -0800, Ade Lovett wrote: While we're at it, bin/94028 points out a fundamental problem with ifconfig(8) as it stands on 6.1-PRERELEASE, preventing MTUs from being set on vlan interfaces. A patch has been sent to the audit trail of the PR. All interested folks, please test and review it. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken operation. Kris I have it. I had just to disable cron startup, which was the only daemon that used pidfile_open and started after statd/lockd, and then start it by hand. Now, perhaps it is better to post it off-list, since it is 69kB for -vvv or 196kB for -X -vvv. Are you willing to look at the dump yourself? Anyone? BTW, cron was left in an unkillable state, it couldn't be killed with SIGKILL. In the meanwhile, I'll try to revert lib/libutil/pidfile.c to Jan 1st, which is my suspect. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 06:58:45PM +, Miguel Lopes Santos Ramos wrote: OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken operation. Kris I have it. I had just to disable cron startup, which was the only daemon that used pidfile_open and started after statd/lockd, and then start it by hand. Now, perhaps it is better to post it off-list, since it is 69kB for -vvv or 196kB for -X -vvv. Are you willing to look at the dump yourself? Anyone? Can you put it at a URL somewhere? If not, send it privately. Kris pgp2Hj4MFYSlx.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
Can you put it at a URL somewhere? If not, send it privately. Kris Ok. There are two versions: http://mega.ist.utl.pt/~mlsr/nfs.dump is the output of tcpdump -vvv host targa and udp port nfs http://mega.ist.utl.pt/~mlsr/nfsx.dump is the output of tcpdump -X -vvv host targa and udp port nfs - targa.anjos.strangled.net is the name of the client which has a single / filesystem (therefore including /var) nfs mounted from the server. - compaq.anjos.strangled.net is the name of the server. Dump begins when I do /etc/rc.d/cron start, after system is fully functional in multiuser mode, lockd and statd running. File locking seems to work in other situations, specifically for instance touch test ; lockf test echo ok. After checking the revision history for lib/libutil/pidfile.c, I'm convinced that it can't be the problem, and the same for usr.sbin/cron/cron.c, even though there was a change at 2006/01/15, and this setup seemed to work before January. Another thing, I didn't start this thread, and I hope I'm not moving attention away from the original post from Jun Kuriyama who was asking for help debugging a documented PR (bin/80389). Miguel Ramos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] MFC of the intr_event stuff
I have a somewhat large patch that MFC's some of the cleanups to the interrupt code that needs some testing before it is MFC'd. It mostly just better organizes some things inside the kernel itself. The only user-visible changes are that there will no longer be ithreads sitting around for IRQs that have no handlers, and it will now be possible (on all but powerpc) to share INTR_FAST and non-INTR_FAST handlers on the same IRQ. The patch is at http://www.FreeBSD.org/~jhb/patches/intr_mfc.patch A list of the commits to current that are contained in this patch is at http://www.FreeBSD.org/~jhb/patches/intr_mfc.txt. I have compiled i386 GENERIC and LINT, but it needs to be run tested and compile tested a lot as it touches every arch, etc. The code has been in current for several months now, so from that aspect it should be at least somewhat solid. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't boot into setup to install FreeBSD 6
Dear friends: Just downloaded the two FreeBSD CD's from the web and I would like to install them on my second hard drive. But I've discovered that I cannot boot up into my Setup (F2, as clearly indicated on my Dell 8200 Dimension during bootup). I have never had this kind of problem before. I have two 40GB hard drives and wanted to install Linux into my second hard drive, but to do this I have to be able to go into my Bios and change the boot sequence. I have done this several times before with the same computer and the same Win XP OS. But now there is something wrong. In fact, I even tried to insert my Windows XP CD and tried to click on F2. But, once again, all that happened is that I was taken immediately to Windows XP. How do I regain entry to my Setup? One last thing: I searched for the boot.ini file (making sure that the search included all hidden and system files). It's under C:\boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=Microsoft Windows XP Professional /fastdetect /NoExecute=OptIn I called Dell and asked for their help. Unfortunately, they are now charging $99 per incident, which is way beyond what I and my family (being Katrina refugees) can afford. But they did let me explain the problem, and the lady said that in her opinion this is a software issue. I tend to agree since I have never had a single hardware problem with my Dell computer in the six years I have had it. If so, may I ask if someone on the FreeBSD list would be kind enough to help me resolve this. We would very much appreciate it. Thank you so much. Benjamin Sher 865-690-3898 Thank you so very much. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't boot into setup to install FreeBSD 6 -- Rev
Dear friends: Two more important pieces of information: 1) While I am unable to get into Setup (F2) during bootup, I am able to stop the booting with F12 (boot menu), which offers me four choices: Normal, Diskette, Hard drive and CD. But when I select any of them, I get Try reboot with F2 or hit F1. When I try the CD, I am told boot medium missing (I think). 2) I have downloaded the FreeBSD 6 files (551 MB and 650 MB), but I have been unable sofar to burn the ISO image correctly using my Nero 5.5. But I'll deal with that later. Thank you. Benjamin Just downloaded the two FreeBSD CD's from the web and I would like to install them on my second hard drive. But I've discovered that I cannot boot up into my Setup (F2, as clearly indicated on my Dell 8200 Dimension during bootup). I have never had this kind of problem before. I have two 40GB hard drives and wanted to install Linux into my second hard drive, but to do this I have to be able to go into my Bios and change the boot sequence. I have done this several times before with the same computer and the same Win XP OS. But now there is something wrong. In fact, I even tried to insert my Windows XP CD and tried to click on F2. But, once again, all that happened is that I was taken immediately to Windows XP. How do I regain entry to my Setup? One last thing: I searched for the boot.ini file (making sure that the search included all hidden and system files). It's under C:\boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=Microsoft Windows XP Professional /fastdetect /NoExecute=OptIn I called Dell and asked for their help. Unfortunately, they are now charging $99 per incident, which is way beyond what I and my family (being Katrina refugees) can afford. But they did let me explain the problem, and the lady said that in her opinion this is a software issue. I tend to agree since I have never had a single hardware problem with my Dell computer in the six years I have had it. If so, may I ask if someone on the FreeBSD list would be kind enough to help me resolve this. We would very much appreciate it. Thank you so much. Benjamin Sher 865-690-3898 Thank you so very much. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror(8) and graid3(8) changes.
On Mon, Mar 06, 2006 at 04:45:06PM -0600, Larry Rosenman wrote: + Pawel Jakub Dawidek wrote: + Hi. + + Here you can find patches with changes to gmirror(8) and graid3(8): + + http://people.freebsd.org/~pjd/patches/gmirror.7.patch + http://people.freebsd.org/~pjd/patches/graid3.patch + + The patches does the following: + - Significant synchronization speed improvement. Now many parallel +synchronization I/O requests can be used instead of only one before. +Many people requested this. + - Close race between regular and synchronization requests (I wasn't +able to trigger it with one sync request, but with many parallel +requests it's real). + - Reimplement locking. I moved softc synchronization from the topology +lock to per-device sx lock. + + I'd like to ask gmirror/graid3 users to test those patches as much as + possible, because I want to commit them to the HEAD and RELENG_6 + branches. + + Because of locking changes it will be really good if you can turn on + INVARIANTS, INVARIANT_SUPPORT options and eventually DIAGNOSTIC in + your kernel. + + Thanks in advance! + + is there any chance at all of making a way to do a kernel dump onto a + gmirror'd device? + + or at least exposing the 'b' slices of the disks so to allow a dump to them? I'm CCing the list you removed, because I'm seeing this question not the first time. In theory it is possible, but in practise its hard. Here are the problems: - Kernel is dumped without GEOM knowledge, so when gmirror is configured on top of da0 and da1, let's say it will decide to dump on da0. After reboot savecore will try to read the dump from a mirror provider. If we have round-robin balance algorithm it will get trash, because there is a kernel dump on da0, but not on da1. So basically we should setup 'perfer' balance algorithm to always read from one disk only. - 'prefer' balance algorithm reads from the component with the higest priority if it is in an active state (is UP and it's not beeing synchronized). When it is synchronized which component should I choose on dumpon(8) call? If I choose the first active component, synchronization can be finished before kernel is dumped. If I choose component with the higest priority even if it is synchronized, kernel can be dumped before synchronization is finished, so on boot 'prefer' balance algorithm can read from the wrong (active) component. To handle this I'd need to remember if kerneldump was requested and update component to dump when synchronization will finish or when component will be disconnected, etc. Such automatic control will break possibility to change dump device with dumpon(8) command once it was configured to dump on gmirror's provider: 1. dumpon /dev/mirror/foo 2. dumpon /dev/da2s1b 3. da0 is disconnected from mirror/foo, so gmirror changes automatically to dump on da1. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp8FXPsrQiiA.pgp Description: PGP signature
Re: Can't boot into setup to install FreeBSD 6
Dear Miguel: Thank you so very much for trying to help. My answers below: Miguel Lopes Santos Ramos wrote: From: Benjamin Sher [EMAIL PROTECTED] Subject: Can't boot into setup to install FreeBSD 6 Dear friends: Just downloaded the two FreeBSD CD's from the web and I would like to install them on my second hard drive. But I've discovered that I cannot boot up into my Setup (F2, as clearly indicated on my Dell 8200 Dimension during bootup). I have never had this kind of problem before. I have two 40GB hard drives and wanted to install Linux into my second hard drive, but to do this I have to be able to go into my Bios and change the boot sequence. I have done this several times before with the same computer and the same Win XP OS. But now there is something wrong. In fact, I even tried to insert my Windows XP CD and tried to click on F2. But, once again, all that happened is that I was taken immediately to Windows XP. How do I regain entry to my Setup? One last thing: I searched for the boot.ini file (making sure that the search included all hidden and system files). It's under C:\boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=Microsoft Windows XP Professional /fastdetect /NoExecute=OptIn I called Dell and asked for their help. Unfortunately, they are now charging $99 per incident, which is way beyond what I and my family (being Katrina refugees) can afford. But they did let me explain the problem, and the lady said that in her opinion this is a software issue. I tend to agree since I have never had a single hardware problem with my Dell computer in the six years I have had it. If so, may I ask if someone on the FreeBSD list would be kind enough to help me resolve this. We would very much appreciate it. Thank you so much. Benjamin Sher 865-690-3898 I think this is a bit off-topic on this list, but of course I'd like to help. I don't think this can be a 'software issue', this must be the BIOS (firmware). 1- Did you change your keyboard, or is your keyboard not well connected? I once had a keyboard which had a long reset time and sometimes was not detected. Try different keyboards, check the plugs. First, my thanks for explaining that this is a BIOS issue. Does this mean that it is a HARDWARE issue? I did change my keyboard some months ago. I changed my keyboard from a Belkin ergonomic keyboard to a Microsoft ergonomic keyboard when I arrived in Knoxville. But I had this problem before in New Orleans with my old keyboard. The Setup got jammed sometimes last fall for some inexplicable reason and has never worked right since. 2- Are you pressing F2 at the right time? Try keeping F2 pressed as soon as you power on, keep it pressed. Believe me, I press F2 the moment boot starts and keep hitting it throughout the boot process. On the other hand, I can stop the boot process with F12. 3- Did you update your BIOS? I don't think removing the CMOS battery can help in this case. Your problem seems surreal. No, I have not updated my BIOS since I purchased the Dell. Thank you again. Benjamin Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 07:38:48PM +, Miguel Lopes Santos Ramos wrote: Can you put it at a URL somewhere? If not, send it privately. Kris Ok. There are two versions: http://mega.ist.utl.pt/~mlsr/nfs.dump is the output of tcpdump -vvv host targa and udp port nfs http://mega.ist.utl.pt/~mlsr/nfsx.dump is the output of tcpdump -X -vvv host targa and udp port nfs Hmm, looks like you need -s 0 in addition to -X -vvv. Kris pgpNru2xaOgMn.pgp Description: PGP signature
Re: Can't boot into setup to install FreeBSD 6
From: Benjamin Sher [EMAIL PROTECTED] Subject: Re: Can't boot into setup to install FreeBSD 6 Dear Miguel: Thank you so very much for trying to help. My answers below: I think this is a bit off-topic on this list, but of course I'd like to help. I don't think this can be a 'software issue', this must be the BIOS (firmware). 1- Did you change your keyboard, or is your keyboard not well connected? I once had a keyboard which had a long reset time and sometimes was not detected. Try different keyboards, check the plugs. First, my thanks for explaining that this is a BIOS issue. Does this mean that it is a HARDWARE issue? The BIOS is a program which is stored in a Read-Only Memory (ROM). It is the Basic Input/Output System that among other things boots your OS. It is often called firmware for being a bit in between software and hardware. Anyway, seems not to be a Windows-related problem. I did change my keyboard some months ago. I changed my keyboard from a Belkin ergonomic keyboard to a Microsoft ergonomic keyboard when I arrived in Knoxville. But I had this problem before in New Orleans with my old keyboard. The Setup got jammed sometimes last fall for some inexplicable reason and has never worked right since. Well, trying different keyboards is my best bet on this issue. 2- Are you pressing F2 at the right time? Try keeping F2 pressed as soon as you power on, keep it pressed. Believe me, I press F2 the moment boot starts and keep hitting it throughout the boot process. On the other hand, I can stop the boot process with F12. Never heard of a key to stop the boot process... Does't that really boot from the CD? Perhaps the CD player is not very good with CD-Rs... and the system boots from the hard disk... I don't think removing the CMOS battery can help in this case. Your problem seems surreal. There's a chance that removing the CMOS battery for a while and then placing it back again restores your BIOS Setup to its default settings, and then it may boot from the CD. But you should ask someone who is experienced with opening up computers to do that operation. Also, this may be a risky operation, and may be useless. Thank you again. Benjamin I'm really out of ideas. Do try different keyboards, borrow a few. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel INCLUDE_CONFIG_FILE workaround?
In the past options INCLUDE_CONFIG_FILE worked great. Unfortunately,
following recent changes in how kernel configuration files are parsed
(namely the changes that use the DEFAULTS to include the 'isa' and
'npx' devices), this feature appears to be broken. For example, here's
what appears in an almost-stock SMP kernel (on a 6.0-RELEASE-px box):
# echo options INCLUDE_CONFIG_FILE ! /sys/i386/conf/SMP
# cd /usr/src
# make KERNCONF=SMP buildkernel
.
[build magic happens]
.
# strings /usr/obj/usr/src/sys/SMP/kernel | egrep ^___
___#
___# SMP -- Generic kernel configuration file for FreeBSD/i386 SMP
___# Use this for multi-processor machines
___#
___# $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58
scottl Exp $
___include GENERIC
___identSMP-GENERIC
___# To make an SMP kernel, the next line is needed
___options SMP # Symmetric MultiProcessor Kernel
___options INCLUDE_CONFIG_FILE
Obviously that's not complete. There should be, at minimum, an 'npx'
and 'isa' device. ;-)
I'm not interested in rehashing earlier threads on the merits of dumbing
down or improving (depending on which side of the issue you were on)
kernel configuration through silent inclusion of devices via mechanisms
like DEFAULTS. I *am* interested seeing restored to functionality a
feature that used to work great, but is now broken.
Does anyone know if this is due to be fixed, or if there's a workaround?
(I've searched for PR's relating to INCLUDE_CONFIG_FILE but see
none.) One possible workaround (the one that seems to make the most
sense) is to delete DEFAULTS from /sys/`uname -m`/conf and use kernel
configs that don't use include {otherconfig}. However, besides the
fact that DEFAULTS would come back every time /usr/src is sync'ed, I'm
unsure what the long-term ramifications are.
--
Alan Amesbury
University of Minnesota
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS MFC testers wanted
Kris, For the record, we ran the following for about 30 minutes, with no ill effect: #!/bin/sh exec /var/log/panic exec 21 echo echo `date` -- trying to panic while [ 1 ] do /sbin/mount /backup/ /bin/rm -rf /backup/foo /bin/cp -R /usr/bin /backup/foo /sbin/umount /backup/ echo -n '.' done At this point our plan is to cross our fingers and wait for 6.1. Thanks for all your efforts! chad Kris Kennaway wrote: On Tue, Mar 07, 2006 at 12:33:28PM -0500, Chad Whitacre wrote: Kris, Yes. FYI, I am fairly confident this is fixed, because I make extensive use of mount/umount+filesystem activity, and I am no longer seeing problems like this. Great! Thanks for the info. We won't kill ourselves trying to test this then. Well, I'd still like you to test it just to be sure. I'm not able to detect all FreeBSD bugs, after all (though I try :-) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
From: Kris Kennaway [EMAIL PROTECTED] Subject: Re: rpc.lockd brokenness (2) Ok. There are two versions: http://mega.ist.utl.pt/~mlsr/nfs.dump is the output of tcpdump -vvv host targa and udp port nfs http://mega.ist.utl.pt/~mlsr/nfsx.dump is the output of tcpdump -X -vvv host targa and udp port nfs Hmm, looks like you need -s 0 in addition to -X -vvv. There. http://mega.ist.utl.pt/~mlsr/nfsxs.dump I did just cron, instead of /etc/rc.d/cron start. It has much less garbage now. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MegaRAID lockups under 5.5 PRELEASE
Folks, We have a pair of servers, each with an of Intel SCRU42X branded MegaRAID controller installed. The cards both have battery backed cache. The servers form a 2-node Slony cluster for PostgreSQL, with each node having a single RAID5 array consisting of 3 live disks with a hot standby disk. About a week ago we upgraded FreeBSD on both boxes from a point on RELENG_5 (1 July 2005) to 5.5-PRERELEASE and now one of the boxes has started behaving badly. In the space of two days we've had about half a dozen occurrences of random processes blocking and rendering the machine unusable. 'top' shows the stricken processes in state 'ffsfsn' and they cannot be killed. The affected machine is a Slony subscriber and so isn't directly used by customers, but is still an important component in our system. PostgreSQL seems to be most likely to block, but sshd has also blocked preventing logins. The interesting thing is that the main box, which has an almost identical configuration and a greater work load, has remained unaffected, so far. The only difference between the two machine configurations is that the misbehaving machine only has 128Mb of on-board battery backed cache, while the main machine has 256Mb. The firmware on both machines is Intel's version 413Y. This is not the first time that we've had problems like this with FreeBSD and this model of controller. For background see: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=172108+0+archive/2004/freebsd-stable/20041231.freebsd-stable http://docs.freebsd.org/cgi/getmsg.cgi?fetch=126427+0+archive/2004/freebsd-stable/20041121.freebsd-stable The current problem is very reminiscent of the latter issue, which had been causing headaches for us over a year ago, but which disappeared after some driver improvements by Scott Long (many thanks Scott :-). I see from a diff of the driver code from RELENG_5 on 1 July 2005 and the latest RELENG_5 version that some further changes have been made to the driver. I would have been moderately happy if I could have pinned the reemergence of the problem on these changes, because then I would have had a specific cause. However, as a test, I reverted to the *previous* kernel from 1 July 2005 and the box blocked in sshd within a few hours, preventing login. At this stage I'm looking at upgrading the firmware of the RAID card to the latest and greatest and if that doesn't resolve it, I plan to make a jump to FreeBSD 6, which appears to have substantial changes to the amr driver and which might solve the problem. Before I leap though, I'd be interested in hearing if anyone is familiar with the behavior that I've described and can point me in the right direction. Alternatively, if someone can say hey we use FreeBSD 6.x with the SCRU42X and it works great then I'd be obliged. Our woes may well be caused be some faulty hardware, especially since the other box has remained stable after the same upgrade, but I remain suspicious because the the problem arose so soon after an upgrade of FreeBSD and after many months of uptime. Many thanks, Regards, Tony. -- Tony Byrne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem writing FreeBSD 6 ISO files using Nero 5.5
Dear friends: Now that my BIOS problem has been resolved (I'm going out momentarily to buy a new keyboard), my last major hurdle before I can install FreeBSD is burning the two FreeBSD ISO images on my CD-RW CD using my CDWriter and Nero 5.5. When I insert my brand new CD-RW (700 MB) into my CD-RW drive and click on Burn Image in Nero, then go to my FreeBSD folder, then select the first FreeBSD ISO disk and then hit Write, the writing starts with Checking disks in the status bar. But soon it stops and the CD is expelled from the CD drive with the error message: Medium empty. Please put new CD (or whatever) into drive. This happens every time even though each time I put a brand new Memorex CD. Your help would be much appreciated. Thank you in advance. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't boot up into Setup -- SOLVED!
Dear Miguel and friends: A million thanks for your suggestion to try another keyboard. You were right on the money! I tried a cheap Micro Ergonomic keyboard ($15) and instantly my Dell 8200 responded when I hit F2 and opened up the Setup. And, imagine, I spent $56 on the Microsoft Ergonomic keyboard at Office Depot. Who would have guessed? So, that problem has been solved. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem writing FreeBSD 6 ISO files using Nero 5.5
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Benjamin Sher Envoyé : mercredi 8 mars 2006 00:23 À : freebsd-stable@freebsd.org Objet : Problem writing FreeBSD 6 ISO files using Nero 5.5 Dear friends: Now that my BIOS problem has been resolved (I'm going out momentarily to buy a new keyboard), my last major hurdle before I can install FreeBSD is burning the two FreeBSD ISO images on my CD-RW CD using my CDWriter and Nero 5.5. When I insert my brand new CD-RW (700 MB) into my CD-RW drive and click on Burn Image in Nero, then go to my FreeBSD folder, then select the first FreeBSD ISO disk and then hit Write, the writing starts with Checking disks in the status bar. But soon it stops and the CD is expelled from the CD drive with the error message: Medium empty. Please put new CD (or whatever) into drive. This happens every time even though each time I put a brand new Memorex CD. Your help would be much appreciated. Thank you in advance. Benjamin Wouldn't that be related to the type of the CD-RW? High-speed CD writers can't use newer Ultra-speed CD-RWs. Can you write anything else on the disks? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 10:04:46PM +, Miguel Lopes Santos Ramos wrote:
From: Kris Kennaway [EMAIL PROTECTED]
Subject: Re: rpc.lockd brokenness (2)
Ok. There are two versions:
http://mega.ist.utl.pt/~mlsr/nfs.dump
is the output of tcpdump -vvv host targa and udp port nfs
http://mega.ist.utl.pt/~mlsr/nfsx.dump
is the output of tcpdump -X -vvv host targa and udp port nfs
Hmm, looks like you need -s 0 in addition to -X -vvv.
There. http://mega.ist.utl.pt/~mlsr/nfsxs.dump
I did just cron, instead of /etc/rc.d/cron start. It has much less garbage
now.
Thanks.
Here is when pidfile_open() creates the file:
21:57:15.792751 IP (tos 0x0, ttl 64, id 10697, offset 0, flags [none], proto:
UDP (17), length: 172) targa.anjos.strangled.net.1365908870
ns1.anjos.strangled.net.nfs: 144 create fh 1082,176026/1149552 cron.pid
0x: 4500 00ac 29c9 4011 3a5d 0a00 011a E...)[EMAIL
PROTECTED]:]
0x0010: 0a00 0102 02ed 0801 0098 effb 516a 1d86 Qj..
0x0020: 0002 0001 86a3 0002
0x0030: 0009 0001 001c
0x0040: 0002
0x0050: 0005
0x0060: 9aaf a243 6dc5 8ae9 0c00 708a 1100 ...Cm...p...
0x0070: d586 7301 ..s.
0x0080: 0008 6372 6f6e 2e70 6964 8180 cron.pid
0x0090:
0x00a0:
21:57:15.793111 IP (tos 0x0, ttl 64, id 7899, offset 0, flags [none], proto:
UDP (17), length: 156) ns1.anjos.strangled.net.nfs
targa.anjos.strangled.net.1365908870: reply ok 128 create fh
1082,176026/1149685 REG 100600 ids 0/0 sz 0 nlink 1 rdev 0 fsid 82 nodeid
118af5 a/m/ctime 1141768635.00 1141768635.00 1141768635.00
0x: 4500 009c 1edb 4011 455b 0a00 0102 [EMAIL PROTECTED]
0x0010: 0a00 011a 0801 02ed 0088 5407 516a 1d86 ..T.Qj..
0x0020: 0001
0x0030: 9aaf a243 6dc5 8ae9 ...Cm...
0x0040: 0c00 f58a 1100 34eb 3f5c 4.?\
0x0050: 0001 8180
0x0060: 0001
0x0070: 8000 0082
0x0080: 0011 8af5 440e 01bb 440e 01bb D...D...
0x0090: 440e 01bb D...
It runs fstat() on it:
21:57:15.793314 IP (tos 0x0, ttl 64, id 10698, offset 0, flags [none], proto:
UDP (17), length: 128) targa.anjos.strangled.net.1365908871
ns1.anjos.strangled.net.nfs: 100 getattr fh 1082,176026/1149685
0x: 4500 0080 29ca 4011 3a88 0a00 011a E...)[EMAIL
PROTECTED]:.
0x0010: 0a00 0102 02ed 0801 006c 2bd9 516a 1d87 .l+.Qj..
0x0020: 0002 0001 86a3 0002
0x0030: 0001 0001 001c
0x0040: 0002
0x0050: 0005
0x0060: 9aaf a243 6dc5 8ae9 0c00 f58a 1100 ...Cm...
0x0070: 34eb 3f5c 4.?\
21:57:15.793456 IP (tos 0x0, ttl 64, id 7900, offset 0, flags [none], proto:
UDP (17), length: 124) ns1.anjos.strangled.net.nfs
targa.anjos.strangled.net.1365908871: reply ok 96 getattr REG 100600 ids 0/0 sz 0
0x: 4500 007c 1edc 4011 457a 0a00 0102 E..|[EMAIL PROTECTED]
0x0010: 0a00 011a 0801 02ed 0068 10bb 516a 1d87 .h..Qj..
0x0020: 0001
0x0030: 0001 8180
0x0040: 0001
0x0050: 8000 0082
0x0060: 0011 8af5 440e 01bb 440e 01bb D...D...
0x0070: 440e 01bb D...
and returns to cron. Cron is supposed to daemonize and then write to the
pidfile:
} else {
if (daemon(1, 0) == -1) {
pidfile_remove(pfh);
log_it(CRON,getpid(),DEATH,can't become daemon);
exit(0);
}
}
pidfile_write(pfh);
but there's no evidence in the trace that it ever tries to write. Can
you also obtain a ktrace -i dump from cron?
Kris
pgpYTELacwdGj.pgp
Description: PGP signature
Setup and Boot Sequence Issues Revisited
Dear friends: Sorry to report that the issue may be more complicated. 1) I played around with the $15 Micro keyboard that successfully allowed access to my Setup. I set the boot sequence for the CD Rom and inserted my Win XP Pro OS CD. I then saved the settings and let it boot. It brought up the line about booting from the CD. So, I clicked hoping that this would allow me to bring up the WinXP CD. Instead, I got the same Click on F1 to retry Setup or Click on F12 for boot menu. When I clicked on these options, I ended up in a loop. 2) I have a DVD player drive (for movies, etc) that is listed as one of the drives (listed as OFF, volume=Unknown). Options when clicking on it: OFF or n/a. Unfortunately, the boot sequence lists only three options: Floppy, Hard Disk, IDE CD ROM. But NOT the DVD drive. I was considering buying the latest Linux Format magazine with the FreeBSD DVD, but now it seems that, due to the restrictions of my BIOS, I will not be able to install anything from this DVD into my second hard drive. Is that true? Thank you all so much. Benjamin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't boot up into Setup -- SOLVED!
Benjamin Sher wrote: Dear Miguel and friends: A million thanks for your suggestion to try another keyboard. You were right on the money! I tried a cheap Micro Ergonomic keyboard ($15) and instantly my Dell 8200 responded when I hit F2 and opened up the Setup. And, imagine, I spent $56 on the Microsoft Ergonomic keyboard at Office Depot. Who would have guessed? So, that problem has been solved. Benjamin You should have checked out the FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/funnies.html#LETMEOUTOFHERE You're pretty lucky that your soul wasn't damned ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Tue, Mar 07, 2006 at 05:43:37PM -0500, Kris Kennaway wrote: but there's no evidence in the trace that it ever tries to write. Can you also obtain a ktrace -i dump from cron? Kris Also while you're there, could you obtain a binary format tcpdump (tcpdump -w) instead? This may be parsed with tools like ethereal which will help with the analysis. Kris pgpuYCQ5O9IoT.pgp Description: PGP signature
Re: [PATCH] MFC of the intr_event stuff
At 03:02 PM 07/03/2006, John Baldwin wrote: I have a somewhat large patch that MFC's some of the cleanups to the interrupt code that needs some testing before it is MFC'd. It seems to help my sio overflows that are described in http://www.freebsd.org/cgi/query-pr.cgi?pr=51982 I have it applied to a number of different chipsets and am testing with a couple of different PCI modems. post patch dmesgs can be found at http://www.tancsa.com/irq-mfc/ including an dual core X2, ICH6 and a via mini-itx with 4 com ports built in. Apart from doing sio stuff, any particular way to stress the devices ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
From: Kris Kennaway [EMAIL PROTECTED] Subject: Re: rpc.lockd brokenness (2) [...] but there's no evidence in the trace that it ever tries to write. Can you also obtain a ktrace -i dump from cron? The file remains empty. I really don't know enough about NFS, but isn't that getattr message repeated some seconds latter, and repeated... (even though it always gets an answer) The ktrace is in http://mega.ist.utl.pt/~mlsr/ktrace.txt I'm not sure it's good. I can't see cron.pid there. I had to reboot to end the process, otherwise I couldn't kill cron and the trace didn't grow either. Also while you're there, could you obtain a binary format tcpdump (tcpdump -w) instead? This may be parsed with tools like ethereal which will help with the analysis. The tcpdump -w is in http://mega.ist.utl.pt/~mlsr/nfs.bin Thank you Miguel Ramos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] MFC of the intr_event stuff
At 07:29 PM 07/03/2006, Mike Tancsa wrote: At 03:02 PM 07/03/2006, John Baldwin wrote: I have a somewhat large patch that MFC's some of the cleanups to the interrupt code that needs some testing before it is MFC'd. It seems to help my sio overflows that are described in http://www.freebsd.org/cgi/query-pr.cgi?pr=51982 Actually, it only helps on the ICH box. On the VIA, I still need to make the change that Bruce Evans suggests i.e. cp4ticks = speed / 10 / hz * 4; to something like: cp4ticks = speed / 10 / hz * 40; ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Wed, Mar 08, 2006 at 12:30:02AM +, Miguel Lopes Santos Ramos wrote: From: Kris Kennaway [EMAIL PROTECTED] Subject: Re: rpc.lockd brokenness (2) [...] but there's no evidence in the trace that it ever tries to write. Can you also obtain a ktrace -i dump from cron? The file remains empty. I really don't know enough about NFS, but isn't that getattr message repeated some seconds latter, and repeated... (even though it always gets an answer) They have different file handles (which weren't identified in the previous trace, i.e. they predate the start of the trace), so it could just be background noise from other reads on the system. The ktrace is in http://mega.ist.utl.pt/~mlsr/ktrace.txt I'm not sure it's good. I can't see cron.pid there. I had to reboot to end the process, otherwise I couldn't kill cron and the trace didn't grow either. I wonder if something else is going wrong and it's not rpc.lockd at all. Also while you're there, could you obtain a binary format tcpdump (tcpdump -w) instead? This may be parsed with tools like ethereal which will help with the analysis. The tcpdump -w is in http://mega.ist.utl.pt/~mlsr/nfs.bin It looks like this wasn't made using -s 0 - sorry if I wasn't explicit. Kris pgpqJAnNuUvYE.pgp Description: PGP signature
[SOLVED] cnet compile problem
Hello Brett,
I am currently studying a Data communications and networking
subject at Monash University. I am using cnet at home for the labs on my
FreeBSD notebook as we are using William Stallings' textbook. There
seems to be a problem with the cnet source code. I have emailed the
FreeBSD cnet maintainer and they suggested emailing you. Basically the
problem is as follows;
All of these errors are the same and stem from the fact that your
version of cnet, v2.0.9 I think, was built before the latest versions of
gcc (in FreeBSD and Fedora, among others) became more aggressive about
parameter type checking.
Two simple changes are necessary:
In the cnet header file, cnet.h, change to:
extern void CNET_exit(const char *filenm, const char *function, int lineno);
and in src/exit.c change to:
void CNET_exit(const char *filenm, const char *function, int lineno)
{
}
I've made these and a few other (overdue) changes in the distribution,
now v2.0.10, available from from:
http://www.csse.uwa.edu.au/cnet/index.html
Please feel free to distribute this email as widely as you need.
Comments and more bug reports welcome.
--
If you are new to UNIX, you may be used to clicking something and seeing either an
OK message, an error, nothing, or (all too often) a pretty blue screen with nifty
high-tech letters explaining exactly where the system crashed - Michael Lucas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] cnet compile problem
On Wed, 08 Mar 2006 13:12:15 +1100 B .Wiggins [EMAIL PROTECTED] wrote: Hello Brett, I am currently studying a Data communications and networking subject at Monash University. I am using cnet at home for the labs on my FreeBSD notebook as we are using William Stallings' textbook. There seems to be a problem with the cnet source code. I have emailed the FreeBSD cnet maintainer and they suggested emailing you. Basically the problem is as follows; All of these errors are the same and stem from the fact that your version of cnet, v2.0.9 I think, was built before the latest versions of gcc (in FreeBSD and Fedora, among others) became more aggressive about parameter type checking. Heh, so I was right. I will update the port. Thanks, -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #204: Just pick up the phone and give modem connect sounds. Well you said we should get more lines so we don't have voice lines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipw can not work in adhoc mode
See atttachment.
I have already submit this bug via report a bug in Nov last year, but
no reply, and the problem still exist in stable-6 now.
Any one who knows how to solve this problem ?
Thanks...
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
headtitleProblem Report kern/88917 : [ipw] ipw can not work in adhoc
mode/title
meta http-equiv='content-type' content='text/html; charset=iso-8859-1' /
meta name='robots' content='nofollow' /
link rel=stylesheet media=screen
href=../layout/css/fixed.css type=text/css
title=Normal Text /
link rel=alternate stylesheet media=screen
href=../layout/css/fixed_large.css type=text/css
title=Large Text /
script type=text/javascript src=../layout/js/styleswitcher.js
/script
/head
body
div id=containerwrap
div id=container
span class=txtoffscreena href=#content
title=Skip site navigation accesskey=1Skip site
navigation/a (1)/spanspan class=txtoffscreena
href=#content title=Skip section navigation
accesskey=2Skip section navigation/a (2)/span
div id=headercontainer
div id=header
h2 class=blockhideHeader And Logo/h2
div id=headerlogoleft
a href=.. title=FreeBSDimg
src=../layout/images/logo.png width=360
height=40 alt=FreeBSD //a
/div
div id=headerlogoright
h2 class=blockhidePeripheral Links/h2
div id=searchnav
ul id=searchnavlist
liText Size: a href=#
onkeypress=return false;
onclick=setActiveStyleSheet('Normal Text'); return false;
title=Normal Text SizeNormal/a / a
href=# onkeypress=return false;
onclick=setActiveStyleSheet('Large Text'); return false;
title=Large Text SizeLarge/a/li
lia href=../donations/
title=DonateDonate/a/li
li class=last-childa href=../mailto.html
title=ContactContact/a/li
/ul
/div
div id=search
form
action=http://www.FreeBSD.org/cgi/search.cgi;
method=get
div
h2 class=blockhidelabel
for=wordsSearch/label/h2
input type=hidden name=max
value=25 /input type=hidden name=source
value=www /input id=words name=words
type=text size=20 maxlength=255
onfocus=if( this.value==this.defaultValue ) this.value='';
value=Search /nbsp;input id=submit
name=submit type=submit value=Search /
/div
/form
/div
/div
/div
h2 class=blockhideSite Navigation/h2
div id=topnav
ul id=topnavlist
lia href=../ title=HomeHome/a/li
lia href=../about.html
title=AboutAbout/a/li
lia href=../where.html title=Get FreeBSDGet
FreeBSD/a/li
lia href=../docs.html
title=DocumentationDocumentation/a/li
lia href=../community.html
title=CommunityCommunity/a/li
lia href=../projects/index.html
title=DevelopersDevelopers/a/li
lia href=../support.html
title=SupportSupport/a/li
/ul
/div
/div
div id=content
h1Problem Report kern/88917 : [ipw] ipw can not work in adhoc mode/h1
pstrong[ipw] ipw can not work in adhoc mode/strong/p
dl
dtstrongConfidential/strong/dtdd
no/dd
dtstrongSeverity/strong/dtdd
serious/dd
dtstrongPriority/strong/dtdd
low/dd
dtstrongResponsible/strong/dtdd
a href='mailto:[EMAIL PROTECTED]'[EMAIL PROTECTED]/a/dd
dtstrongState/strong/dtdd
open/dd
dtstrongClass/strong/dtdd
sw-bug/dd
dtstrongSubmitter-Id/strong/dtdd
current-users/dd
dtstrongArrival-Date/strong/dtdd
Sun Nov 13 11:40:22 GMT 2005/dd
dtstrongLast-Modified/strong/dtdd
Fri Jan 13 06:20:38 GMT 2006/dd
dtstrongOriginator/strong/dtdd
Li RUi jiang lt;a href='mailto:[EMAIL PROTECTED]'[EMAIL
PROTECTED]/agt;/dd
dtstrongRelease/strong/dtdd
6.0/dd
dtstrongOrganization/strong/dtdd
/dd
ddpre
Fudan university,ShangHai,China
/pre/dd
dtstrongEnvironment/strong/dtdd
/dd
ddpre
FreeBSD lith.3322.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Nov 4 04:19:50
CST 2005 root@:/usr/obj/usr/src/sys/CUSTOM_6 i386
/pre/dd
dtstrongDescription/strong/dtdd
/dd
ddpre
The machine running windows is set to adhoc mode.
ssid is cat
On FreeBSD machine, I type:
--
ipwcontrol -f /usr/local/share/ipw-firmware/ipw-i.fw
ifconfig ipw0 mediaopt adhoc
ifconfig ipw0 ssid cat
ifconfig
Inode Usage
I am building a tool to identify the file that has a specific LBA. The approach I am using is to search through each inode from number 2 up. This approach works well with UFS1 file systems as then preinitialize all the inodes. However, UFS2 does lazy inode initialization so there are always some that are basically garbage. I have not found any relaiable way to determine from the inode contents if it is in use or not. I suspect that information is in the inode bit map. However, I haven't found any way to access that. Nothing in ffs.h seems to fit the need. Is there a way to tell if inode x is initialized or in use? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw can not work in adhoc mode
lithium7456 == lithium7456 [EMAIL PROTECTED] writes: lithium7456 problem still exist in stable-6 now. Any one who knows lithium7456 how to solve this problem ? Thanks... Could you try the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=84861 ? -- DSS5-RIPE DSS-RIPN 2:550/[EMAIL PROTECTED] 2:550/[EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://neva.vlink.ru/~dsh/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Inode Usage
At 07:11 PM 3/7/2006, Doug Hardie wrote: I am building a tool to identify the file that has a specific LBA. The approach I am using is to search through each inode from number 2 up. This approach works well with UFS1 file systems as then preinitialize all the inodes. However, UFS2 does lazy inode initialization so there are always some that are basically garbage. I have not found any relaiable way to determine from the inode contents if it is in use or not. I suspect that information is in the inode bit map. However, I haven't found any way to access that. Nothing in ffs.h seems to fit the need. Is there a way to tell if inode x is initialized or in use? I believe there are macros for that in sys/ufs/ffs/fs.h. Also, the source for dumpfs probably has good examples of how to use them. -Glenn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
