From mexas at bristol.ac.uk Wed Jul 1 09:31:55 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 1 09:32:02 2009 Subject: slices, partitions, fdisk and bsdlabel on ia64 Message-ID: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> I'm just starting using FBSD ia64, and it seems things are slightly different from alpha. This is a fresh install FreeBSD 8.0-CURRENT-200906 ia64. > df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35910 431110 8% / devfs 1 1 0 100% /dev /dev/da0p1 409504 163264 246240 40% /efi /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252628 11019554 2% /usr /dev/da0p4 1012974 418 931520 0% /var > Am I correct in thinking this is a "dangerously dedicated" (no slices) disk, and partitions are numbered p? Does this mean the handbook section 3.5, Disk Organisation, is incorrect for ia64? There's no fdisk on ia64, is there? I can't find bsdlabel either, on alpha it's under /sbin, but on ia64 it's nowhere to be found. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 1 10:57:43 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 1 10:58:02 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> Message-ID: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> On Thu, Jun 25, 2009 at 09:41:13AM -0700, Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: > > dev_taste(DEV,mirror/gm0) > > g_part_taste(PART,mirror/gm0) > > > > GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. > > GEOM: mirror/gm0: using the primary only -- recovery suggested. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. > > It's better to use gmirror per partition. Like this? # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # I've read some boot disk gmirror examples, e.g. http://people.freebsd.org/~rse/mirror however, all examples I've seen are for i386, talking about MBR, fdisk and bsdlabel, so these are not directly applicable to ia64. Application of gvinum for boot disk on ia64 is not clear either. It seems gvinum section of the handbook, 21.9, is also based on i386. Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 1 12:20:22 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 1 12:20:34 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <4A4B4FFE.7010400@jrv.org> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <4A4B4FFE.7010400@jrv.org> Message-ID: <20090701122015.GA62937@mech-cluster238.men.bris.ac.uk> On Wed, Jul 01, 2009 at 07:01:02AM -0500, James R. Van Artsdalen wrote: > Anton Shterenlikht wrote: > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > Is there a filesystem already mounted from da0p2? yes, da0 is the disk on which I installed the system. > Use gmirror label immediately after using gpart to create da0p2 then > always use /dev/mirror/root as the device after that, never da0p2, ie > > # gpart add -b 162 -s 1048576 -t freebsd-ufs ad0 wow! gpart is never mentioned in the handbook, neither in GEOM, nor in gvinum chapter. Is the handbook a bit out of date? > # gmirror label -vb round-robin root /dev/da0p2 > > # newfs /dev/mirror/root > > The examples from the gpart and gmirror man pages worked for me. are you using ia64? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From toyorunner at gmail.com Wed Jul 1 15:49:47 2009 From: toyorunner at gmail.com (ToyoRunner) Date: Wed Jul 1 15:49:53 2009 Subject: slices, partitions, fdisk and bsdlabel on ia64 In-Reply-To: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> References: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> Message-ID: FreeBSD-ia64 uses the GEOM framework for managing disks. On Wed, Jul 1, 2009 at 3:31 AM, Anton Shterenlikht wrote: > I'm just starting using FBSD ia64, and it seems things are slightly > different from alpha. > > This is a fresh install FreeBSD 8.0-CURRENT-200906 ia64. > >> df > Filesystem 1K-blocks ? Used ? ?Avail Capacity ?Mounted on > /dev/da0p2 ? ?507630 ?35910 ? 431110 ? ? 8% ? ?/ > devfs ? ? ? ? ? ? ?1 ? ? ?1 ? ? ? ?0 ? 100% ? ?/dev > /dev/da0p1 ? ?409504 163264 ? 246240 ? ?40% ? ?/efi > /dev/da0p5 ? 1012974 ? ? 12 ? 931926 ? ? 0% ? ?/tmp > /dev/da0p6 ?12252370 252628 11019554 ? ? 2% ? ?/usr > /dev/da0p4 ? 1012974 ? ?418 ? 931520 ? ? 0% ? ?/var >> > > Am I correct in thinking this is a "dangerously dedicated" (no slices) disk, > and partitions are numbered p? > Does this mean the handbook section 3.5, Disk Organisation, > is incorrect for ia64? > > There's no fdisk on ia64, is there? > > I can't find bsdlabel either, on alpha it's under /sbin, but > on ia64 it's nowhere to be found. > > many thanks > anton > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-ia64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ia64 > To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@freebsd.org" > From wojtek at wojtek.tensor.gdynia.pl Wed Jul 1 20:12:57 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Wed Jul 1 20:13:15 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> Message-ID: >> It's better to use gmirror per partition. > > Like this? > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. isn't that partition accessed by other process or mounted? From xcllnt at mac.com Thu Jul 2 04:43:16 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 2 04:43:23 2009 Subject: slices, partitions, fdisk and bsdlabel on ia64 In-Reply-To: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> References: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> Message-ID: On Jul 1, 2009, at 2:31 AM, Anton Shterenlikht wrote: > Am I correct in thinking this is a "dangerously dedicated" (no > slices) disk, > and partitions are numbered p? You're not correct. Itanium uses GPT and not MBR for partitions. > Does this mean the handbook section 3.5, Disk Organisation, > is incorrect for ia64? Yes, it's incorrect. There's a high bias towards PC in the handbook. Not surprising, but it means that you should not take it literally. > There's no fdisk on ia64, is there? gpart is used for all partition, including MBR. > > I can't find bsdlabel either, on alpha it's under /sbin, but > on ia64 it's nowhere to be found. gpart is used for BSD disklabels as well. FYI, -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Thu Jul 2 08:37:19 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 2 08:37:26 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> Message-ID: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> On Wed, Jul 01, 2009 at 10:00:54PM +0200, Wojciech Puchar wrote: > >> It's better to use gmirror per partition. > > > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > isn't that partition accessed by other process or mounted? should it not be mounted? Sorry, I was just following the handbook, but I now understand it is incorrect when it comes to ia64. many thanks anton > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Thu Jul 2 08:46:24 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 2 08:46:31 2009 Subject: slices, partitions, fdisk and bsdlabel on ia64 In-Reply-To: References: <20090701093150.GA62036@mech-cluster238.men.bris.ac.uk> Message-ID: <20090702084616.GB66827@mech-cluster238.men.bris.ac.uk> On Wed, Jul 01, 2009 at 09:43:15PM -0700, Marcel Moolenaar wrote: > > On Jul 1, 2009, at 2:31 AM, Anton Shterenlikht wrote: > > > Am I correct in thinking this is a "dangerously dedicated" (no > > slices) disk, > > and partitions are numbered p? > > You're not correct. Itanium uses GPT and not MBR for partitions. > > > Does this mean the handbook section 3.5, Disk Organisation, > > is incorrect for ia64? > > Yes, it's incorrect. There's a high bias towards PC in > the handbook. Not surprising, but it means that you > should not take it literally. > > > There's no fdisk on ia64, is there? > > gpart is used for all partition, including MBR. > > > > > I can't find bsdlabel either, on alpha it's under /sbin, but > > on ia64 it's nowhere to be found. > > gpart is used for BSD disklabels as well. Marcel, thank you, much clearer. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From wojtek at wojtek.tensor.gdynia.pl Thu Jul 2 14:02:32 2009 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Thu Jul 2 14:02:51 2009 Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt In-Reply-To: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> Message-ID: >>> >>> # gmirror label -vb round-robin root /dev/da0p2 >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. >> isn't that partition accessed by other process or mounted? > > should it not be mounted? yes it should not, no matter what architecture. From mexas at bristol.ac.uk Fri Jul 3 10:12:55 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 3 10:13:15 2009 Subject: gmirror per partition In-Reply-To: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> Message-ID: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> On Thu, Jul 02, 2009 at 03:48:41PM +0200, Wojciech Puchar wrote: > >>> > >>> # gmirror label -vb round-robin root /dev/da0p2 > >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > >> isn't that partition accessed by other process or mounted? > > > > should it not be mounted? > yes it should not, no matter what architecture. ok, thank you So how can I gmirror root partition? I can't unmount it, I think. Perhaps I need to use a single-user mode? Following is a gpart/gmirror report - some success and problems. I did a fresh FBSD current install on ia64 on directly attached scsi, da0. # gpart show => 34 35566411 da0 GPT (17G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 25310027 6 freebsd-ufs (12G) # What I want is to mirror the whole of the boot disk to da1, which is identical to da0, but following Marcel's advice, will apply gmirror per partition. So starting with efi partition: First I create GPT scheme on da1 # gpart create -s gpt da1 da1 created # gpart show da1 => 34 35566411 da1 GPT (17G) 34 35566411 - free - (17G) # then I create EFI partition of the same size as on the boot disk, da0. # gpart add -b 34 -s 819200 -t efi da1 da1p1 added # gpart show da1 => 34 35566411 da1 GPT (17G) 34 819200 1 efi (400M) 819234 34747211 - free - (17G) # then I umount /efi so that I can create gmirror label on da0p1. # umount /efi # gmirror label -vb round-robin efi /dev/da0p1 Metadata value stored on /dev/da0p1. Done. # Checking gmirror # gmirror status Name Status Components mirror/efi COMPLETE da0p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 # now insert a spare partition, da1p1, into the mirror # gmirror insert efi /dev/da1p1 status looks fine # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (44%) # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (87%) # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 2. Name: da1p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1724596009 # So far, so good. Now, I don't need to create the filesystem on the mirror, because EFI was copied from da0p1 to da1p1. So, I try to mount /dev/mirror/efi # mount -t msdosfs /dev/mirror/efi /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /mnt # again seems ok so I proceed to modify /etc/fstab and change da0p1 into mirror/efi # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0p3 none swap sw 0 0 /dev/da0p2 / ufs rw 1 1 /dev/mirror/efi /efi msdosfs rw 0 0 ^^^^^^^^^^^^^^^ /dev/da0p5 /tmp ufs rw 2 2 /dev/da0p6 /usr ufs rw 2 2 /dev/da0p4 /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # now I can try to just mount /efi # umount /mnt # mount /efi # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /efi # good, working! now to mirror root partition. My problem is that root is mounted and cannot (?) be unmounted, unlike /efi, on the live system. # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 da1p2 added # # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # If I create gmirror on da1, the spare disk: # gmirror label -vb round-robin root /dev/da1p2 Metadata value stored on /dev/da0p1. Done. # so that # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da1p2 # then I still cannot insert da0p2 # gmirror insert root da0p2 gmirror: Cannot access provider da0p2. # So how can I gmirror root partion on a live system? Also, if gmirror overwrites the last sector in the partition, then gmirror per partition cannot be used for /usr, because secondary GPT is stored in the last sector of /usr. Isn't it? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From dalroi at solfertje.student.utwente.nl Fri Jul 3 11:37:12 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Fri Jul 3 11:37:23 2009 Subject: gmirror per partition In-Reply-To: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> Message-ID: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > now to mirror root partition. > > My problem is that root is mounted and cannot (?) be unmounted, > unlike /efi, > on the live system. > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > da1p2 added > # > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > # > > If I create gmirror on da1, the spare disk: > > # gmirror label -vb round-robin root /dev/da1p2 > Metadata value stored on /dev/da0p1. > Done. > # > > so that > > # gmirror status > Name Status Components > mirror/efi COMPLETE da0p1 > da1p1 > mirror/root COMPLETE da1p2 > > # > > > then I still cannot insert da0p2 > > > # gmirror insert root da0p2 > gmirror: Cannot access provider da0p2. > # > > So how can I gmirror root partion on a live system? You're almost there... I did this a while ago, can't remember when, but I just upgraded the system that had this from FreeBSD 6.3 of sometime in 2006 to 7.2. What I believe I did from this point on was: Copy everything from the root partition to mirror/root. Modify /etc/fstab to mount root on mirror/root. Reboot. Now the original root partition isn't mounted anymore, so we can do operate on it's geom stuff. gmirror insert root da0p2 That should be it. If that doesn't work you can always boot off a live file-system CD/DVD and perform these actions from there. You won't have man pages in that case though, or at least I couldn't find a way to read them off the DVD last I tried. One thing I'd like to warn about at this point: If you ever upgrade to a kernel with a newer geom metadata version and that new kernel crashes, you're left with a system where the new kernel can't boot at all while the old kernel can't mount the root mirror as it's now of a version it can't handle. You can however mount a single geom provider of that root file system (/dev/da1p2 for example) to try to fix things. That file-system WILL be dirty, but DON'T run fsck on it or you will destroy it's contents. That's what happened to my upgrade above... Thankfully it was only my root partition with hardly any data on it and I did make level 0 dumps before the upgrade, but I needed to restore that FS from a fixit shell without man pages. Augh! > many thanks > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > > > > Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:910,4a4de90c759151073616872! From mexas at bristol.ac.uk Fri Jul 3 22:26:06 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 3 22:26:13 2009 Subject: SUCCESS: Re: gmirror per partition In-Reply-To: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> Message-ID: <20090703222558.GA32365@mech-cluster238.men.bris.ac.uk> On Fri, Jul 03, 2009 at 01:18:28PM +0200, Alban Hertroys wrote: > On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > > > now to mirror root partition. > > > > My problem is that root is mounted and cannot (?) be unmounted, > > unlike /efi, > > on the live system. > > > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > > da1p2 added > > # > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > If I create gmirror on da1, the spare disk: > > > > # gmirror label -vb round-robin root /dev/da1p2 > > Metadata value stored on /dev/da0p1. > > Done. > > # > > > > so that > > > > # gmirror status > > Name Status Components > > mirror/efi COMPLETE da0p1 > > da1p1 > > mirror/root COMPLETE da1p2 > > > > # > > > > > > then I still cannot insert da0p2 > > > > > > # gmirror insert root da0p2 > > gmirror: Cannot access provider da0p2. > > # > > > > So how can I gmirror root partion on a live system? > > You're almost there... I did this a while ago, can't remember when, > but I just upgraded the system that had this from FreeBSD 6.3 of > sometime in 2006 to 7.2. > > What I believe I did from this point on was: > > Copy everything from the root partition to mirror/root. > Modify /etc/fstab to mount root on mirror/root. > Reboot. > > Now the original root partition isn't mounted anymore, so we can do > operate on it's geom stuff. > > gmirror insert root da0p2 > > That should be it. > If that doesn't work you can always boot off a live file-system CD/DVD > and perform these actions from there. You won't have man pages in that > case though, or at least I couldn't find a way to read them off the > DVD last I tried. > > One thing I'd like to warn about at this point: > If you ever upgrade to a kernel with a newer geom metadata version and > that new kernel crashes, you're left with a system where the new > kernel can't boot at all while the old kernel can't mount the root > mirror as it's now of a version it can't handle. > You can however mount a single geom provider of that root file system > (/dev/da1p2 for example) to try to fix things. > That file-system WILL be dirty, but DON'T run fsck on it or you will > destroy it's contents. That's what happened to my upgrade above... > > Thankfully it was only my root partition with hardly any data on it > and I did make level 0 dumps before the upgrade, but I needed to > restore that FS from a fixit shell without man pages. Augh! thank you, that was helpful. I think I've got it, but it's a bit more complex on ia64 because /boot is a symlink to /efi/boot, which is a separate partition. Anyway, I've got: # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da0p2 da1p2 mirror/swap COMPLETE da0p3 da1p3 mirror/var COMPLETE da1p4 da0p4 mirror/tmp COMPLETE da1p5 da0p5 mirror/usr DEGRADED da1p6 da0p6 (24%) # I'll try to write up my experience and post later. thanks again -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From office at adaptcom.ro Sat Jul 4 10:10:04 2009 From: office at adaptcom.ro (Theodor Chirana) Date: Sat Jul 4 10:10:16 2009 Subject: ia64/136314: FreeBSD IA64 iso's wil not boot Message-ID: <200907041008.n64A8X43031384@www.freebsd.org> >Number: 136314 >Category: ia64 >Synopsis: FreeBSD IA64 iso's wil not boot >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-ia64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jul 04 10:10:03 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Theodor Chirana >Release: 7.2 >Organization: >Environment: IA64 arhitecture >Description: Install discs, only boot discs written from isos will not boot and start the installer on a 32 or 64 bit machine both with a DVD or CD-rom. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From office at adaptcom.ro Sat Jul 4 17:00:09 2009 From: office at adaptcom.ro (Theodor Chirana) Date: Sat Jul 4 17:00:14 2009 Subject: ia64/136314: FreeBSD IA64 iso's wil not boot Message-ID: <200907041700.n64H08Hb015826@freefall.freebsd.org> The following reply was made to PR ia64/136314; it has been noted by GNATS. From: Theodor Chirana To: bug-followup@FreeBSD.org, office@adaptcom.ro Cc: Subject: Re: ia64/136314: FreeBSD IA64 iso's wil not boot Date: Sat, 04 Jul 2009 18:42:13 +0300 you can close this bug. It was a mistake of mine confusing IA64 with xeon 46 bit processors From rink at FreeBSD.org Sat Jul 4 17:03:35 2009 From: rink at FreeBSD.org (rink@FreeBSD.org) Date: Sat Jul 4 17:03:41 2009 Subject: ia64/136314: FreeBSD IA64 iso's wil not boot Message-ID: <200907041703.n64H3Xwk022673@freefall.freebsd.org> Synopsis: FreeBSD IA64 iso's wil not boot State-Changed-From-To: open->closed State-Changed-By: rink State-Changed-When: Sat Jul 4 17:03:18 UTC 2009 State-Changed-Why: Closed by submitters request. http://www.freebsd.org/cgi/query-pr.cgi?pr=136314 From bugmaster at FreeBSD.org Mon Jul 6 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:08:29 2009 Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org Message-ID: <200907061106.n66B6xDG010801@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ia64/120315 ia64 Backing store switch in exception_save_restart leaves o ia64/113102 ia64 [MCA] Multiple records can have the same sequence numb o ia64/86218 ia64 Mozilla / Firefox: regxpcom or regchrome broken on ia6 3 problems total. From mexas at bristol.ac.uk Mon Jul 6 20:17:41 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 20:17:47 2009 Subject: cannot partition HP 73GB disks Message-ID: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> Trying to install FBSD 8.0-snapshot 200906 on 73GB HP scsi disks: da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing Enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) and partition name appears only as "X" in disklabel editor: FreeBSD Disklabel Editor Disk: da0 Free: 0 blocks (0MB) Part Mount Size Newfs Part Mount Size Newfs ---- ----- ---- ----- ---- ----- ---- ----- X /efi 100MB EFI Y X / 512MB UFS2 Y X swap 4055MB SWAP X /var 3051MB UFS2+S Y X /tmp 512MB UFS2+S Y X /usr 61776MB UFS2+S Y automatic or manual - doesn't matter, all partitions are named X, and the installation fails with "cannot create partition /dev/X" or similar. With some seagate 17GB disks works fine. Please advise -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From securityAlerts at a248.boa.aka_mai.com Mon Jul 6 20:37:16 2009 From: securityAlerts at a248.boa.aka_mai.com (Bank of America) Date: Mon Jul 6 20:37:23 2009 Subject: Bank Of America Online Alert : Verify Your Information ID# d885f20cbd1f2d7442e324bc1bcdb689 Message-ID: <200907061800.n66I0JT4029139@web04.triwdata.ch> [mhd_reg_logo.gif] [em_title_red.gif] Dear customer, Protecting the security of our customers and the Bank of America ! network , as a preventative measure, we have temporarily limited access to sensitive account features. To restore your account access, please take the following steps to ensure that your account has not been compromised: After updates : 1.Login to your Bank of America Online Banking account. In case you are not enrolled for Online Banking, you will have to fill in all the required information, including your name and you account number. 2. Review your recent account history for any unauthorized withdrawals or deposits, and check you account profile to make sure not changes have been made. If any unauthorized activity has taken place on your account, report this to Bank of America staff immediately. To get started, please click the link below: ! [1]https://sitekey.bankofamerica.com/sas/signon.do?&detect=3&p=d41d8cd 98f00b204e9800998ecf8427e3265464 _________________________________________________________________ This alert has been sent to you based on your preferences. If you would like to make any changes to your Online Banking Alerts service, please sign in to Online Banking and visit the Manage Alerts section. Because your reply will not be transmitted via secure e-mail, the e-mail address that generated this alert will not accept replies. If you would like to contact Bank of America with questions or comments, please sign in to Online Banking and visit the customer service section. _________________________________________________________________ Bank of America, N.A. Member FDIC. Equal Housing Lender © 2009 Bank of America Corporation. All rights reserved d885f20cbd1f2d7442e324bc1bcdb689 _________________________________________________________________ References 1. http://indietones.net/preview/Onlineid.bankofameri!ca.com/cgi-bini/668d93445065081fa9f2b085cbde792e0d2e0da50a9b4260a03c403a83c60055efdf4a1c/c7206040b068b58cba7fadd6a5b4e341/bofa/ibdIAS/bankofamerica/signon.php?section=signinpage&update=&cookiecheck=yes&destination=nba/signin From mexas at bristol.ac.uk Mon Jul 6 20:51:31 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 20:51:44 2009 Subject: cannot partition HP 73GB disks In-Reply-To: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> Message-ID: <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 09:17:33PM +0100, Anton Shterenlikht wrote: > Trying to install FBSD 8.0-snapshot 200906 on 73GB HP scsi disks: > > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > da0: Command Queueing Enabled > da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > da1 at mpt0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > da1: Command Queueing Enabled > da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > > > and partition name appears only as "X" in disklabel editor: > > > FreeBSD Disklabel Editor > > Disk: da0 Free: 0 blocks (0MB) > > Part Mount Size Newfs Part Mount Size Newfs > ---- ----- ---- ----- ---- ----- ---- ----- > X /efi 100MB EFI Y > X / 512MB UFS2 Y > X swap 4055MB SWAP > X /var 3051MB UFS2+S Y > X /tmp 512MB UFS2+S Y > X /usr 61776MB UFS2+S Y > > > automatic or manual - doesn't matter, all partitions are named X, > and the installation fails with "cannot create partition /dev/X" or > similar. > > With some seagate 17GB disks works fine. > > Please advise This thread mentiones a somewhat similar problem - the installation program cannot "write data to disk" in 5.2 and 6.1. It's on zx6000 itanium, which is very similar to my rx2600, and again 73GB scsi disks are used: http://lists.freebsd.org/pipermail/freebsd-ia64/2006-December/001191.html no solution was found then. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 6 22:22:37 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 22:22:44 2009 Subject: cannot partition HP 73GB disks In-Reply-To: <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> Message-ID: <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 09:51:25PM +0100, Anton Shterenlikht wrote: > On Mon, Jul 06, 2009 at 09:17:33PM +0100, Anton Shterenlikht wrote: > > Trying to install FBSD 8.0-snapshot 200906 on 73GB HP scsi disks: > > > > da0 at mpt0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-3 device > > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > > da0: Command Queueing Enabled > > da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > > da1 at mpt0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-3 device > > da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > > da1: Command Queueing Enabled > > da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > > > > > > and partition name appears only as "X" in disklabel editor: > > > > > > FreeBSD Disklabel Editor > > > > Disk: da0 Free: 0 blocks (0MB) > > > > Part Mount Size Newfs Part Mount Size Newfs > > ---- ----- ---- ----- ---- ----- ---- ----- > > X /efi 100MB EFI Y > > X / 512MB UFS2 Y > > X swap 4055MB SWAP > > X /var 3051MB UFS2+S Y > > X /tmp 512MB UFS2+S Y > > X /usr 61776MB UFS2+S Y > > > > > > automatic or manual - doesn't matter, all partitions are named X, > > and the installation fails with "cannot create partition /dev/X" or > > similar. > > > > With some seagate 17GB disks works fine. > > > > Please advise > > This thread mentiones a somewhat similar problem > - the installation program cannot "write data to > disk" in 5.2 and 6.1. It's on zx6000 itanium, > which is very similar to my rx2600, and again > 73GB scsi disks are used: > > http://lists.freebsd.org/pipermail/freebsd-ia64/2006-December/001191.html > > no solution was found then. Using livefs cd I was able to gpart one disk. Then booting from the installation disk1 I can set: FreeBSD Disklabel Editor Disk: da0 Free: 0 blocks (0MB) Part Mount Size Newfs Part Mount Size Newfs ---- ----- ---- ----- ---- ----- ---- ----- da0p1 /efi 400MB EFI N da0p2 / 512MB UFS2 N da0p3 swap 2048MB SWAP da0p4 /var 1024MB UFS2+S N da0p5 /tmp 1024MB UFS2+S N da0p6 /usr 64999MB UFS2+S N However, when the installaiton starts I get several warnings, something about fsck returning error 8 on checking root partition, and then this error: Error mounting /dev/da0p2 on /mnt : Invalid argument -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 6 22:44:46 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 22:44:53 2009 Subject: SOLVED: Re: cannot partition HP 73GB disks In-Reply-To: <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> Message-ID: <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 11:22:29PM +0100, Anton Shterenlikht wrote: > On Mon, Jul 06, 2009 at 09:51:25PM +0100, Anton Shterenlikht wrote: > > On Mon, Jul 06, 2009 at 09:17:33PM +0100, Anton Shterenlikht wrote: > > > Trying to install FBSD 8.0-snapshot 200906 on 73GB HP scsi disks: > > > > > > da0 at mpt0 bus 0 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-3 device > > > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > > > da0: Command Queueing Enabled > > > da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > > > da1 at mpt0 bus 0 target 1 lun 0 > > > da1: Fixed Direct Access SCSI-3 device > > > da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > > > da1: Command Queueing Enabled > > > da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) > > > > > > > > > and partition name appears only as "X" in disklabel editor: > > > > > > > > > FreeBSD Disklabel Editor > > > > > > Disk: da0 Free: 0 blocks (0MB) > > > > > > Part Mount Size Newfs Part Mount Size Newfs > > > ---- ----- ---- ----- ---- ----- ---- ----- > > > X /efi 100MB EFI Y > > > X / 512MB UFS2 Y > > > X swap 4055MB SWAP > > > X /var 3051MB UFS2+S Y > > > X /tmp 512MB UFS2+S Y > > > X /usr 61776MB UFS2+S Y > > > > > > > > > automatic or manual - doesn't matter, all partitions are named X, > > > and the installation fails with "cannot create partition /dev/X" or > > > similar. > > > > > > With some seagate 17GB disks works fine. > > > > > > Please advise > > > > This thread mentiones a somewhat similar problem > > - the installation program cannot "write data to > > disk" in 5.2 and 6.1. It's on zx6000 itanium, > > which is very similar to my rx2600, and again > > 73GB scsi disks are used: > > > > http://lists.freebsd.org/pipermail/freebsd-ia64/2006-December/001191.html > > > > no solution was found then. > > Using livefs cd I was able to gpart one disk. Then booting from the > installation disk1 I can set: > > FreeBSD Disklabel Editor > > Disk: da0 Free: 0 blocks (0MB) > > Part Mount Size Newfs Part Mount Size Newfs > ---- ----- ---- ----- ---- ----- ---- ----- > da0p1 /efi 400MB EFI N > da0p2 / 512MB UFS2 N > da0p3 swap 2048MB SWAP > da0p4 /var 1024MB UFS2+S N > da0p5 /tmp 1024MB UFS2+S N > da0p6 /usr 64999MB UFS2+S N > > > However, when the installaiton starts I get several warnings, something > about fsck returning error 8 on checking root partition, and then this > error: > > Error mounting /dev/da0p2 on /mnt : Invalid argument In the partitioning part of the installation program I had to delete all partitions and create them again. Somehow this time round partition names were created fine, and the installation then proceeded ok. It seems all that was needed was gpart create -s gpt da0 from the livefs, then the installation cd could be used. not sure why this happened with 73GB disks and didn't happen with 17GB disks. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 6 23:19:09 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 23:19:15 2009 Subject: SOLVED: Re: cannot partition HP 73GB disks In-Reply-To: <4A5283BC.2000107@gmail.com> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> <4A5283BC.2000107@gmail.com> Message-ID: <20090706231902.GA23937@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 05:07:40PM -0600, ToyoRunner wrote: > > BTW, did you have any luck with gmirror? yes, I posted some success results. This was a gmirror on 17GB disks. I now got a pair of 73GB 15000rpm disks and am doing a mirror right now. Will let you know. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 6 23:25:58 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 6 23:26:05 2009 Subject: SOLVED: Re: cannot partition HP 73GB disks In-Reply-To: <4A5283BC.2000107@gmail.com> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> <4A5283BC.2000107@gmail.com> Message-ID: <20090706232552.GA23964@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 05:07:40PM -0600, ToyoRunner wrote: > > BTW, did you have any luck with gmirror? # gpart show => 34 143374671 da0 GPT (68G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 133118287 6 freebsd-ufs (63G) => 34 143374671 da1 GPT (68G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 133118287 6 freebsd-ufs (63G) # # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da1p2 da0p2 mirror/swap COMPLETE da1p3 da0p3 mirror/usr DEGRADED da0p6 da1p6 (25%) mirror/tmp COMPLETE da0p5 da1p5 mirror/var COMPLETE da0p4 da1p4 # why is rebuilding such a slow process? there are less than 300MB of data on /usr as of fresh minimal install. However the partition is 63GB. But does the partition size matter? I'd imagine only data need to be rebuild. I've got to 25% after about 10 minutes. The data transfer rate for these disks supposed to be 300 MB/s according to dmesg: da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) I'm surely missing something simple. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From toyorunner at gmail.com Mon Jul 6 23:29:47 2009 From: toyorunner at gmail.com (ToyoRunner) Date: Mon Jul 6 23:29:55 2009 Subject: SOLVED: Re: cannot partition HP 73GB disks In-Reply-To: <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> Message-ID: <4A5283BC.2000107@gmail.com> Anton Shterenlikht wrote: > On Mon, Jul 06, 2009 at 11:22:29PM +0100, Anton Shterenlikht wrote: > >> On Mon, Jul 06, 2009 at 09:51:25PM +0100, Anton Shterenlikht wrote: >> >>> On Mon, Jul 06, 2009 at 09:17:33PM +0100, Anton Shterenlikht wrote: >>> >>>> Trying to install FBSD 8.0-snapshot 200906 on 73GB HP scsi disks: >>>> >>>> da0 at mpt0 bus 0 target 0 lun 0 >>>> da0: Fixed Direct Access SCSI-3 device >>>> da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) >>>> da0: Command Queueing Enabled >>>> da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) >>>> da1 at mpt0 bus 0 target 1 lun 0 >>>> da1: Fixed Direct Access SCSI-3 device >>>> da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) >>>> da1: Command Queueing Enabled >>>> da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) >>>> >>>> >>>> and partition name appears only as "X" in disklabel editor: >>>> >>>> >>>> FreeBSD Disklabel Editor >>>> >>>> Disk: da0 Free: 0 blocks (0MB) >>>> >>>> Part Mount Size Newfs Part Mount Size Newfs >>>> ---- ----- ---- ----- ---- ----- ---- ----- >>>> X /efi 100MB EFI Y >>>> X / 512MB UFS2 Y >>>> X swap 4055MB SWAP >>>> X /var 3051MB UFS2+S Y >>>> X /tmp 512MB UFS2+S Y >>>> X /usr 61776MB UFS2+S Y >>>> >>>> >>>> automatic or manual - doesn't matter, all partitions are named X, >>>> and the installation fails with "cannot create partition /dev/X" or >>>> similar. >>>> >>>> With some seagate 17GB disks works fine. >>>> >>>> Please advise >>>> >>> This thread mentiones a somewhat similar problem >>> - the installation program cannot "write data to >>> disk" in 5.2 and 6.1. It's on zx6000 itanium, >>> which is very similar to my rx2600, and again >>> 73GB scsi disks are used: >>> >>> http://lists.freebsd.org/pipermail/freebsd-ia64/2006-December/001191.html >>> >>> no solution was found then. >>> >> Using livefs cd I was able to gpart one disk. Then booting from the >> installation disk1 I can set: >> >> FreeBSD Disklabel Editor >> >> Disk: da0 Free: 0 blocks (0MB) >> >> Part Mount Size Newfs Part Mount Size Newfs >> ---- ----- ---- ----- ---- ----- ---- ----- >> da0p1 /efi 400MB EFI N >> da0p2 / 512MB UFS2 N >> da0p3 swap 2048MB SWAP >> da0p4 /var 1024MB UFS2+S N >> da0p5 /tmp 1024MB UFS2+S N >> da0p6 /usr 64999MB UFS2+S N >> >> >> However, when the installaiton starts I get several warnings, something >> about fsck returning error 8 on checking root partition, and then this >> error: >> >> Error mounting /dev/da0p2 on /mnt : Invalid argument >> > > In the partitioning part of the installation program I had to delete > all partitions and create them again. Somehow this time round partition > names were created fine, and the installation then proceeded ok. > > It seems all that was needed was > gpart create -s gpt da0 > > from the livefs, then the installation cd could be used. > > not sure why this happened with 73GB disks and didn't happen with 17GB disks. > > I have encountered the same problem. I don't know what causes it but basically if you want to make a partition change in the installer you have to remove all the existing partitions and re add them. The installer will not newfs the existing partitions. It fails the with "Invalid argument" error. BTW, did you have any luck with gmirror? From mexas at bristol.ac.uk Tue Jul 7 09:12:55 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 09:13:01 2009 Subject: gmirror per partition on ia64 - handbook incorrect In-Reply-To: <4A5296F2.80800@gmail.com> References: <20090706201733.GA17827@mech-cluster238.men.bris.ac.uk> <20090706205125.GA18002@mech-cluster238.men.bris.ac.uk> <20090706222229.GA23689@mech-cluster238.men.bris.ac.uk> <20090706224435.GA23791@mech-cluster238.men.bris.ac.uk> <4A5283BC.2000107@gmail.com> <20090706232552.GA23964@mech-cluster238.men.bris.ac.uk> <4A5296F2.80800@gmail.com> Message-ID: <20090707091234.GA39999@mech-cluster238.men.bris.ac.uk> On Mon, Jul 06, 2009 at 06:29:38PM -0600, ToyoRunner wrote: > Anton Shterenlikht wrote: > > On Mon, Jul 06, 2009 at 05:07:40PM -0600, ToyoRunner wrote: > > > >> BTW, did you have any luck with gmirror? > >> > > > > # gpart show > > => 34 143374671 da0 GPT (68G) > > 34 819200 1 efi (400M) > > 819234 1048576 2 freebsd-ufs (512M) > > 1867810 4194304 3 freebsd-swap (2.0G) > > 6062114 2097152 4 freebsd-ufs (1.0G) > > 8159266 2097152 5 freebsd-ufs (1.0G) > > 10256418 133118287 6 freebsd-ufs (63G) > > > > => 34 143374671 da1 GPT (68G) > > 34 819200 1 efi (400M) > > 819234 1048576 2 freebsd-ufs (512M) > > 1867810 4194304 3 freebsd-swap (2.0G) > > 6062114 2097152 4 freebsd-ufs (1.0G) > > 8159266 2097152 5 freebsd-ufs (1.0G) > > 10256418 133118287 6 freebsd-ufs (63G) > > > > # > > > > > > # gmirror status > > Name Status Components > > mirror/efi COMPLETE da0p1 > > da1p1 > > mirror/root COMPLETE da1p2 > > da0p2 > > mirror/swap COMPLETE da1p3 > > da0p3 > > mirror/usr DEGRADED da0p6 > > da1p6 (25%) > > mirror/tmp COMPLETE da0p5 > > da1p5 > > mirror/var COMPLETE da0p4 > > da1p4 > > # > > > > why is rebuilding such a slow process? there are less than 300MB of > > data on /usr as of fresh minimal install. However the partition is > > 63GB. But does the partition size matter? I'd imagine only data need > > to be rebuild. I've got to 25% after about 10 minutes. The data > > transfer rate for these disks supposed to be 300 MB/s according to > > dmesg: > > > > da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) > > > > I'm surely missing something simple. > > > > > Actually, I believe the whole disks need to be indexed regardless. Who > knows which zero block is the zero block you need. > > Could you post the steps you took to get your mirror operating correctly > to the list? I would bow before you. See below, sorry if it's too much detail. Some steps are related to install on my particular box, i.e. not generic ia64 requirements. It seems quite complicated, requiring two reboots. Please see if you can shorten or simplify the procedure. I'd like to write a section on RAID-1 on ia64 for the handbook based on this, because existing advice is incorrect when it comes to ia64. So, I welcome any suggestions on these quidelines. This example is based on setting up gmirror on rx2600 with two directly attached scsi disks, da0 and da1. 1. preliminary: read man pages for gpart(8), gmirror(8), geom(4), geom(8), dump(8), restore(8). use # gpart show # gmirror status # gmirror list between the steps to see partitions and mirror state. 2. fresh FBSD install on da0, as default, but: a) /efi is 400MB b) set up at least one network interface c) create at least one user and add him to group wheel (b) and (c) are necessary because /etc/ttys by default does not open getty on console via MP, so ssh connection is required. 3. (optional, possibly for my box only): add hw.ata.atapi_dma=0 to /boot/device.hints 4. (optional) enable extra debug messages: # sysctl kern.geom.debugflags=17 5. partition a spare disk, da1, exactly as the boot disk: # gpart create -s gpt da1 # gpart add ... so that the results look like: # gpart show => 34 143374671 da0 GPT (68G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 133118287 6 freebsd-ufs (63G) => 34 143374671 da1 GPT (68G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 133118287 6 freebsd-ufs (63G) # 6. load gmirror kernel module # gmirror load 7. create mirror for EFI partition: a) unmount /efi because GEOM manipulations can be performed only on unmounted, not in use, partition: # umount /efi b) create efi mirror on the boot(!) disk: # gmirror label -vb round-robin efi da0p1 c) add spare disk's efi partition to the mirror: # gmirror insert efi da1p1 rebuilding should start, check progress with # gmirror status after rebuilding is complete you should see: # gmirror status efi Name Status Components mirror/efi COMPLETE da0p1 da1p1 # d) mount mirror efi: # mount -t msdosfs /dev/mirror/efi /efi # df Filesystem 1K-blocks Used Avail Capacity Mounted on ... /dev/mirror/efi 409504 163264 246240 40% /efi # 8. create mirror for root (/) partition. This involves extra steps since / cannot be unmounted. a) create mirror on the spare disk: # gmirror label -vb round-robin root da1p2 b) create ufs filesystem on the mirror: # newfs /dev/mirror/root c) mount root mirror temporarily, say under /mnt: # mount /dev/mirror/root /mnt d) now copy / onto /mnt (actually onto the root mirror, /dev/mirror/root). Use a combination of dump(8) and restore(8). No other copying tool will do it right: # cd /mnt # dump 0aLf - / | restore rf - (check the man pages for more details on the options) 9. update fstab on the mirror(!) Edit /mnt/etc/fstab and change da0p1 into mirror/efi and da0p2 into mirror/root. 10. update /boot/loader.conf a) put this line at the very beginning: geom_mirror_load="YES" f) In this line: vfs.root.mountfrom="ufs:/dev/da0p2" replace da0p2 with mirror/root, so that it is: vfs.root.mountfrom="ufs:/dev/mirror/root" 11. reboot into single user(!) mode on shutdown you should see root and efi mirrors destroyed. 12. on boot you should see gmirror loaded, /dev/mirror/root and /dev/mirror/efi started and /dev/mirror/root is used as a boot device, 13. now that you have booted from /dev/da1p2, da0p2 is not mounted, so it can be inserted into root mirror: # gmirror insert root da0p2 14. create mirrors for all other partitions of da0, which are now not mounted: # gmirror label -vb round-robin swap da0p3 # gmirror label -vb round-robin var da0p4 # gmirror label -vb round-robin tmp da0p5 # gmirror label -vb round-robin usr da0p6 15. edit /etc/fstab and change da0p3 into mirrior/swap da0p4 into mirrior/var da0p5 into mirrior/tmp da0p6 into mirrior/usr 16. reboot 17. on startup add spare disks to mirrors: # gmirror insert swap da1p3 # gmirror insert var da1p4 # gmirror insert tmp da1p5 # gmirror insert usr da1p6 18. done! -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Tue Jul 7 09:48:14 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 09:48:26 2009 Subject: buildworld panic on ia64 Message-ID: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> this is FreeBSD 8.0-current 200906 snapshot on ia64. Updated src this morning, following the standard procedure, on make -j6 buildworld the process stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c on the console I get: panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 0 KDB: enter: panic [thread pid 67078 tid 100097 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From rink at FreeBSD.org Tue Jul 7 09:49:57 2009 From: rink at FreeBSD.org (Rink Springer) Date: Tue Jul 7 09:50:04 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707095058.GC7827@rink.nu> On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; Do you have a backtrace ? Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From mexas at bristol.ac.uk Tue Jul 7 12:44:19 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 12:44:34 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707095058.GC7827@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> Message-ID: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 67078 tid 100097 ] > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > Do you have a backtrace ? no, sorry, I was too quick to reboot. I tried to reproduce the error, got this on the way: # XXX: bogusly disabled high FP regs which is reported from by sys/ia64/ia64/trap.c, and then this error (but no panic this time): ===> usr.bin/yacc (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/error.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lalr.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lr0.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/mkpar.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/output.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/reader.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/main.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/skeleton .c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/symtab.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/verbose. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/warshall .c gzip -cn /usr/src/usr.bin/yacc/yacc.1 > yacc.1.gz gzip -cn /usr/src/usr.bin/yacc/yyfix.1 > yyfix.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o ===> usr.bin/yes (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yes/yes.c gzip -cn /usr/src/usr.bin/yes/yes.1 > yes.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yes yes.o ===> usr.bin/ypcat (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypcat/ypcat.c gzip -cn /usr/src/usr.bin/ypcat/ypcat.1 > ypcat.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypcat ypcat.o ===> usr.bin/ypmatch (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypmatch/ypmat ch.c gzip -cn /usr/src/usr.bin/ypmatch/ypmatch.1 > ypmatch.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypmatch ypmatch.o ===> usr.bin/ypwhich (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypwhich/ypwhi ch.c gzip -cn /usr/src/usr.bin/ypwhich/ypwhich.1 > ypwhich.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o 1 error *** Error code 2 1 error *** Error code 2 1 error # ********************** Below are dmesg and make.conf, if it matters. There are several backtraces in dmesg, but I'm not sure now at what stage they appeared. many thanks ********************** GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT-200906 #0: Fri Jun 12 22:56:41 UTC 2009 root@hob.lan.xcllnt.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison (1500.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 2126766080 (2028 MB) avail memory = 2013437952 (1920 MB) FPSWA Revision = 0x10012, Entry = 0xe00000407fe60050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: SAPIC Id=1, SAPIC Eid=0 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 20090521 tbfadt-625 ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 20090521 tbfadt-625 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ohci0: mem 0x80023000-0x80023fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x80022000-0x80022fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x80021000-0x800210ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 atapci0: port 0xd58-0xd5f,0xd64-0xd67,0xd50-0xd57,0xd60-0xd63,0xd40-0xd4f irq 21 at device 2.0 on pci0 atapci0: [ITHREAD] atapci0: HW has secondary channel disabled ata2: on atapci0 ata2: [ITHREAD] fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:0a:31:d6:ec fxp0: [ITHREAD] pcib1: on acpi0 pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x90840000-0x9084ffff,0x90830000-0x9083ffff irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90820000-0x9082ffff,0x90810000-0x9081ffff irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 bge0: mem 0x90800000-0x9080ffff irq 29 at device 2.0 on pci32 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:0a:31:36:40 bge0: [ITHREAD] pcib2: on acpi0 pci64: on pcib2 pcib3: on acpi0 pci96: on pcib3 pcib4: on acpi0 pci128: on pcib4 pcib5: on acpi0 pci192: on pcib5 pcib6: on acpi0 pci224: on pcib6 uart0: <16550 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: mem 0xf4050000-0xf4050fff,0xf4020000-0xf403ffff irq 82 at device 1.1 on pci224 puc0: [FILTER] uart1: on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: on puc0 uart2: [FILTER] vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf3ffffff,0xf4040000-0xf404ffff at device 2.0 on pci224 uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart3: [FILTER] uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart4: [FILTER] uart4: debug port (9600,n,8,1) cpu0: on acpi0 cpu1: on acpi0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DVDROM at ata2-master PIO4 Waiting 5 seconds for SCSI devices to settle uhub1: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 5 ports with 5 removable, self powered WARNING: WITNESS option enabled, expect reduced performance. da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing Enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device mirror/efi launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/tmp launched (1/2). GEOM_MIRROR: Device tmp: rebuilding provider da0p5. GEOM_MIRROR: Device mirror/usr launched (1/2). GEOM_MIRROR: Device usr: rebuilding provider da0p6. Trying to mount root from ufs:/dev/mirror/root WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted /tmp: mount pending error: blocks 24 files 6 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted GEOM_MIRROR: Device tmp: rebuilding provider da0p5 finished. lock order reversal: 1st 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xe000000010792448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010792448, 0x9, 0x0, 0x220, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010792448, 0x80100, 0xe000000010792470, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x220) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010792448, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe0000000045d5b90) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe0000000107923b0, 0x80100, 0xe000000004b71740, 0x220, 0xe0000000107923c0, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xe0000000107923b0, 0xe000000010792470, 0x1, 0x0, 0xa00000000037a000, 0x0) at ffs_snapshot+0x2280 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010a2a330, 0x9, 0xffffffffffffffff, 0x319, 0xe0000000109596e0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010a2a330, 0x80400, 0xe0000000109596e0, 0xe000000004b717a8, 0x50, 0x33, 0xe000000004b71740, 0x319) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010a2a330, 0x80400) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe000000004b51bb0) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe000000010959620, 0x80400, 0xe000000004b71740, 0x319, 0xe000000010959630, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xa000000032a78e08, 0xe0000000107ae000, 0xe00000001096d100, 0x0, 0xe00000001062a030, 0xe00000001096d000) at ffs_snapshot+0x3f50 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:295 2nd 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe0000000109596b8, 0x9, 0xffffffffffffffff, 0x633, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000109596b8, 0x80000, 0x0, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x633) at __lockmgr_args+0xe10 ffs_snapremove(0xe000000010959620, 0xe000000004b71740, 0xe000000004b55ab8, 0xe0000000109596b8) at ffs_snapremove+0x200 softdep_releasefile(0xe00000001086f6f8, 0xa000000032a792d0, 0x29f, 0xe000000004a12470, 0x48e) at softdep_releasefile+0x90 ufs_inactive(0xe000000010886000, 0xe00000001086f6f8, 0xe000000010959710) at ufs_inactive+0x400 VOP_INACTIVE_APV(0xe000000004cc21c0, 0xa000000032a792e0, 0xe000000004b54550, 0xe00000000470f940) at VOP_INACTIVE_APV+0x1c0 vinactive(0xe000000010959620, 0xe000000010886000, 0x800, 0xe0000000109596e0) at vinactive+0x110 vput(0xe000000010959620, 0xa000000032a79308, 0xe000000004b55ab8, 0xe0000000109596e0) at vput+0x3f0 vn_close(0xe000000010959620, 0x1, 0xe000000010363c00, 0xe000000010886000) at vn_close+0x310 vn_closefile(0xe000000010723590, 0xe000000010886000, 0xe000000010959620) at vn_closefile+0x1e0 _fdrop(0xe000000010723590, 0xe000000010886000, 0xe000000004589d10, 0xb9b) at _fdrop+0xb0 closef(0xe000000010723590, 0xe000000010886000, 0x0, 0xe00000000458a4c0) at closef+0x570 kern_close(0xe000000010886000, 0xe000000004b3c520) at kern_close+0x270 close(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at close+0x30 syscall(0xa000000032a79400, 0x6, 0x0, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c95468, 0x6, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return GEOM_MIRROR: Device usr: rebuilding provider da0p6 finished. lock order reversal: 1st 0xa00000001e6a59c8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe0000000107bcc00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b73fd0) at _witness_debugger+0x60 witness_checkorder(0xe0000000107bcc00, 0x9, 0xffffffffffffffff, 0x11d, 0x0) at witness_checkorder+0x12c0 _sx_xlock(0xe0000000107bcc00, 0x0, 0xe000000004b73fd0, 0x11d) at _sx_xlock+0xc0 ufsdirhash_acquire(0xe000000010abbd88, 0xe0000000107bcc00, 0xe000000004a0ef40, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000000010abbd88, 0xa000000023710018, 0x18, 0xa000000032a79328) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000000012b997f8, 0xe000000010bee2a0, 0x0, 0x1, 0xa000000023710018) at ufs_dirremove+0x240 ufs_rmdir(0xa000000032a79390, 0xe000000010bee2a0, 0xe000000010abbd88) at ufs_rmdir+0x230 VOP_RMDIR_APV(0xe000000004cc21c0, 0xa000000032a793d8, 0x2, 0xe00000000471aff0) at VOP_RMDIR_APV+0x1c0 kern_rmdirat(0xe000000010886000, 0xffffffffffffff9c, 0x200000004041a508, 0x0) at kern_rmdirat+0x340 kern_rmdir(0xe000000010886000, 0x200000004041a508, 0x0) at kern_rmdir+0x30 rmdir(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at rmdir+0x30 syscall(0xa000000032a79400, 0x89, 0x200000004041a400, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c96cf8, 0x89, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return XXX: bogusly disabled high FP regs --->>> make.conf <<<--- # $FreeBSD: src/share/examples/etc/make.conf,v 1.279 2007/01/17 12:43:06 des Exp $ # copied from /usr/share/examples/etc/make.conf # # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 # (Intel CPUs) core2 core nocona pentium4m pentium4 prescott # pentium3m pentium3 pentium-m pentium2 # pentiumpro pentium-mmx pentium i486 i386 # (Via CPUs) c3 c3-2 # Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4 # AMD64 architecture: opteron, athlon64, nocona, prescott, core2 # Intel ia64 architecture: itanium2, itanium # # (?= allows to buildworld for a different CPUTYPE.) # CPUTYPE=ia64 #NO_CPU_CFLAGS= # Don't add -march= to CFLAGS automatically #NO_CPU_COPTFLAGS= # Don't add -march= to COPTFLAGS automatically # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" or "-O2 -fno-strict-aliasing" # before submitting bug reports without patches to the developers. # # Compiling with -fstrict-aliasing optimization breaks some [notable] ports. # GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so # explicitly turn it off when using compiling with the -O2 optimization level. # CFLAGS= -O2 -fno-strict-aliasing -pipe # # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # CXXFLAGS+= -fconserve-space # # MAKE_SHELL controls the shell used internally by make(1) to process the # command scripts in makefiles. Three shells are supported, sh, ksh, and # csh. Using sh is most common, and advised. Using ksh *may* work, but is # not guaranteed to. Using csh is absurd. The default is to use sh. # MAKE_SHELL=sh # # BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested # for use in developing FreeBSD and testing changes. They can be used by # putting "CFLAGS+=${BDECFLAGS}" in /etc/make.conf. -Wconversion is not # included here due to compiler bugs, e.g., mkdir()'s mode_t argument. # BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ -Wcast-qual -Wchar-subscripts -Winline \ -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings # # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # COPTFLAGS= -O -pipe # # Compare before install INSTALL=install -C # # Mtree will follow symlinks #MTREE_FOLLOWS_SYMLINKS= -L # # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= # # To enable installing newgrp(1) with the setuid bit turned on. # Without the setuid bit, newgrp cannot change users' groups. #ENABLE_SUID_NEWGRP= # # To avoid building various parts of the base system: #NO_MODULES= # do not build modules with the kernel #NO_SHARE= # do not go into the share subdir #NO_SHARED= # build /bin and /sbin statically linked (bad idea) # # Variables that control how ppp(8) is built. #PPP_NO_NAT= # do not build with NAT support (see make.conf(5)) #PPP_NO_NETGRAPH= # do not build with Netgraph support #PPP_NO_RADIUS= # do not build with RADIUS support #PPP_NO_SUID= # build with normal permissions # #TRACEROUTE_NO_IPSEC= # do not build traceroute(8) with IPSEC support # # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD= # do not build modules when building kernel # # The list of modules to build instead of all of them. MODULES_OVERRIDE= # # The list of modules to never build, applied *after* MODULES_OVERRIDE. #WITHOUT_MODULES= bktr plip # # If you do not want unformatted manual pages to be compressed # when they are installed: # #NO_MANCOMPRESS= # # # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # #PRINTERDEVICE= ps # # # How long to wait for a console keypress before booting the default kernel. # This value is approximately in milliseconds. Keypresses are accepted by the # BIOS before booting from disk, making it possible to give custom boot # parameters even when this is set to 0. # #BOOTWAIT=0 #BOOTWAIT=30000 # # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. # # By default we use COM1 as our serial console port *if* we're going to use # a serial port as our console at all. Alter as necessary. # # COM1: = 0x3F8, COM2: = 0x2F8, COM3: = 0x3E8, COM4: = 0x2E8 # #BOOT_COMCONSOLE_PORT= 0x3F8 # # The default serial console speed is 9600. Set the speed to a larger value # for better interactive response. # #BOOT_COMCONSOLE_SPEED= 115200 # # By default the 'pxeboot' loader retrieves the kernel via NFS. Defining # this and recompiling /usr/src/sys/boot will cause it to retrieve the kernel # via TFTP. This allows pxeboot to load a custom BOOTP diskless kernel yet # still mount the server's '/' (i.e. rather than load the server's kernel). # #LOADER_TFTP_SUPPORT= YES # # # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= # # # CVSup update flags. Edit SUPFILE settings to reflect whichever distribution # file(s) you use on your site (see /usr/share/examples/cvsup/README for more # information on CVSup and these files). To use, do "make update" in /usr/src. # #SUP_UPDATE= # #SUP= /usr/bin/csup #SUPFLAGS= -g -L 2 #SUPHOST= cvsup.uk.FreeBSD.org #SUPFILE= /usr/share/examples/cvsup/standard-supfile #PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile #DOCSUPFILE= /usr/share/examples/cvsup/doc-supfile # # top(1) uses a hash table for the user names. The size of this hash # can be tuned to match the number of local users. The table size should # be a prime number approximately twice as large as the number of lines in # /etc/passwd. The default number is 20011. # #TOP_TABLE_SIZE= 101 # # Documentation # # The list of languages and encodings to build and install # DOC_LANG= en_US.ISO8859-1 # # # sendmail # # The following sets the default m4 configuration file to use at # install time. Use with caution as a make install will overwrite # any existing /etc/mail/sendmail.cf. Note that SENDMAIL_CF is now # deprecated. The value should be a fully qualified path name. # #SENDMAIL_MC=/etc/mail/myconfig.mc # # The following sets the default m4 configuration file for mail # submission to use at install time. Use with caution as a make # install will overwrite any existing /etc/mail/submit.cf. The # value should be a fully qualified path name. # #SENDMAIL_SUBMIT_MC=/etc/mail/mysubmit.mc # # If you need to build additional .cf files during a make buildworld, # include the full paths to the .mc files in SENDMAIL_ADDITIONAL_MC. # #SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc # # The following overrides the default location for the m4 configuration # files used to build a .cf file from a .mc file. # #SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf # # Setting the following variable modifies the flags passed to m4 when # building a .cf file from a .mc file. It can be used to enable # features disabled by default. # #SENDMAIL_M4_FLAGS= # # Setting the following variables modifies the build environment for # sendmail and its related utilities. For example, SASL support can be # added with settings such as: # # with SASLv1: # SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl # # with SASLv2: # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl2 # # Note: If you are using Cyrus SASL with other applications which require # access to the sasldb file, you should add the following to your # sendmail.mc file: # # define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') # #SENDMAIL_CFLAGS= #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= # # Setting SENDMAIL_SET_USER_ID will install the sendmail binary as a # set-user-ID root binary instead of a set-group-ID smmsp binary and will # prevent the installation of /etc/mail/submit.cf. # This is a deprecated mode of operation. See etc/mail/README for more # information. # #SENDMAIL_SET_USER_ID= # # The permissions to use on alias and map databases generated using # /etc/mail/Makefile. Defaults to 0640. # #SENDMAIL_MAP_PERMS= -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From rink at FreeBSD.org Tue Jul 7 13:35:10 2009 From: rink at FreeBSD.org (Rink Springer) Date: Tue Jul 7 13:35:22 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707133611.GA66072@rink.nu> On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. Shame... well, if you hit it again, please let me know. Haven't yet gotten it myself on my rx2600. > I tried to reproduce the error, got this on the way: > > # XXX: bogusly disabled high FP regs I get this message quite often as well; I intend to figure out what's going on. Marcel, if you have any idea, please let me know. Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From mexas at bristol.ac.uk Tue Jul 7 14:42:25 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 14:42:31 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707133611.GA66072@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> Message-ID: <20090707144208.GA49582@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 03:36:11PM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > Shame... well, if you hit it again, please let me know. Haven't yet > gotten it myself on my rx2600. > > > I tried to reproduce the error, got this on the way: > > > > # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. got it again. Note that I was doing "make -j10 buildworld", and when I got it first time I did "make -j6 buildworld". When I only run one process "make buildworld" I didn't get the panic, but stopped at some other error message. So, buildworld stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c and on the console (MP via LAN on rx2600): # panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 1 KDB: enter: panic [thread pid 46793 tid 100148 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> bt Tracing pid 46793 tid 100148 td 0xe000000011b22760 kdb_enter(0xe000000004b43148, 0xe000000004b43148, 0xe0000000045f2a20, 0x793) at kdb_enter+0x92 panic(0xe000000004b41618, 0xe000000004b810c0, 0x2a8, 0xe000000011b229dc, 0xe0000 00011b229da) at panic+0x2f0 _mtx_lock_spin_flags(0xe000000015220a70, 0x0, 0xe000000004b810c0, 0x2a8, 0x20000 00000072200, 0x2000000040107010, 0xe000000004ac1c30, 0x716) at _mtx_lock_spin_fl ags+0x90 trap(0x19, 0xa000000032c09400) at trap+0xdb0 ivt_Disabled_FP_Register() at ivt_Disabled_FP_Register+0x30 db> I'Il try to start just 2 processes and see what happens. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Tue Jul 7 15:00:59 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 7 15:01:11 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707144554.GF5574@dan.emsphone.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> Message-ID: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > In the last episode (Jul 07), Anton Shterenlikht said: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > I tried to reproduce the error, got this on the way: > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > trace automatically on every panic. actually, I'll rebuild a kernel first, and then try to rebuid world. I'll put this in as well. Do I still need options KDB # Enable kernel debugger support if I put options KDB_TRACE? > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > There are no errors in this output; just make reporting that there was an > error. At -j6, the error message itself may be hundreds of lines back. > Make lets all remaining parallel jobs finish before exiting. ok, thanks, will keep in mind. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From dnelson at allantgroup.com Tue Jul 7 15:15:50 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Jul 7 15:15:56 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707144554.GF5574@dan.emsphone.com> In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. > I tried to reproduce the error, got this on the way: If you add "options KDB_TRACE" to your kernel config, you'll get a stack trace automatically on every panic. > # XXX: bogusly disabled high FP regs > > which is reported from by sys/ia64/ia64/trap.c, and then this error > (but no panic this time): > > ===> usr.bin/yacc (all) > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure.c [...] > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error There are no errors in this output; just make reporting that there was an error. At -j6, the error message itself may be hundreds of lines back. Make lets all remaining parallel jobs finish before exiting. -- Dan Nelson dnelson@allantgroup.com From dnelson at allantgroup.com Tue Jul 7 18:16:43 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Jul 7 18:16:49 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> Message-ID: <20090707175735.GG5574@dan.emsphone.com> In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > > In the last episode (Jul 07), Anton Shterenlikht said: > > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > > cpuid = 0 > > > > > KDB: enter: panic > > > > > [thread pid 67078 tid 100097 ] > > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > > > Do you have a backtrace ? > > > > > > no, sorry, I was too quick to reboot. I tried to reproduce the error, > > > got this on the way: > > > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > > trace automatically on every panic. > > actually, I'll rebuild a kernel first, and then try to rebuid world. I'll > put this in as well. Do I still need > > options KDB # Enable kernel debugger support > > if I put options KDB_TRACE? I always have both, so I don't know if one requires the other. You should get a compile error if KDB is required and it's not listed. -- Dan Nelson dnelson@allantgroup.com From xcllnt at mac.com Wed Jul 8 00:13:21 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 00:13:32 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> Message-ID: On Jul 7, 2009, at 2:48 AM, Anton Shterenlikht wrote: > on the console I get: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/ > trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl > r14=0xffffffffffe2a8e8,gp ;; > db> This is already fixed. Just update your sources, build a new kernel, install it and reboot. Then you can continue the buildworld safely... FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Wed Jul 8 00:29:09 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 00:29:15 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090707133611.GA66072@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> Message-ID: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >> I tried to reproduce the error, got this on the way: >> >> # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. It's a race condition. The high FP registers are lazily context-switched and this error is emitted when a thread wants to use the high FP registers when they are disabled and the CPU onto which the thread is running has the high FP registers corresponding to that thread in registers. In that scenario the high FP registers should not even be disabled. In the above case the kernel simply enables the high FP registers and continues the thread. For the most part the condition is harmless, but I've been looking at a panic that's the result of inconsistency in the high FP state, so the race is potentially fatal. BTW: I never got the error when doing a buildworld. I think Anton's non-standard compiler options make GCC much more FP intensive and thus prone to causing the race. FYI, -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Wed Jul 8 11:40:26 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 11:40:33 2009 Subject: buildworld panic on ia64 In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> Message-ID: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. hey, my compiler options are just a copy from /usr/share/examples/etc/make.conf with obvious changes, e.g. CPUTYPE=itanium2 The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. Which non-standard options did you spot? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 8 11:49:32 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 11:49:39 2009 Subject: buildworld panic on ia64 In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> Message-ID: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. Marcel, sorry, I probably misunderstood "compiler options" in the previous reply. Did you mean -j option in make -j10 buildworld? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 8 13:19:30 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 8 13:19:43 2009 Subject: is it safe to reboot while gmirror is rebuilding? Message-ID: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which takes quite a long time to rebuild, perhaps 30 min. Is it safe to reboot, or write to this filesystem, while it is being rebuilt (gmirror status DEGRADED) ? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Wed Jul 8 13:40:18 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Jul 8 13:40:24 2009 Subject: is it safe to reboot while gmirror is rebuilding? In-Reply-To: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> References: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> Message-ID: <4A549D9F.9030209@haruhiism.net> Anton Shterenlikht wrote: > On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which > takes quite a long time to rebuild, perhaps 30 min. Is it > safe to reboot, or write to this filesystem, while it is > being rebuilt (gmirror status DEGRADED) ? > > Doesn't matter which version it is; gmirror checkpoints the rebuild process so you can safely reboot/write/etc. -- Kamigishi Rei KREI-RIPE From xcllnt at mac.com Wed Jul 8 16:20:11 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 16:20:23 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> Message-ID: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > hey, my compiler options are just a copy from > /usr/share/examples/etc/make.conf > > with obvious changes, e.g. CPUTYPE=itanium2 > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > Which non-standard options did you spot? All of them :-) There is no /etc/make.conf by default, so the existence of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them non-standard. As a special warning: /usr/share/examples/etc/make.conf is inherently i386 biases (like most of the examples and documentation I might add). It's unwise to copy flags from there and expect good results. Even warnings-only examples can cause build breakages (due to -Werror), because compilers for different architectures emit different warnings or emit the same warning at different times. By all means: experiment. But be very careful not to make the assumption that if the code compiles, it'll also run. The weirder the set of compiler options, the more likely you trip over optimization bugs and end up with an unstable system. And I'm not even talking about whether the set of options give you more optimal code in general. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Wed Jul 8 16:26:15 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 8 16:26:26 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> Message-ID: On Jul 8, 2009, at 4:49 AM, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: >> >> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >>>> I tried to reproduce the error, got this on the way: >>>> >>>> # XXX: bogusly disabled high FP regs >>> >>> I get this message quite often as well; I intend to figure out >>> what's >>> going on. Marcel, if you have any idea, please let me know. >> >> It's a race condition. The high FP registers are lazily >> context-switched and this error is emitted when a thread >> wants to use the high FP registers when they are disabled >> and the CPU onto which the thread is running has the high >> FP registers corresponding to that thread in registers. >> In that scenario the high FP registers should not even be >> disabled. >> >> In the above case the kernel simply enables the high FP >> registers and continues the thread. For the most part the >> condition is harmless, but I've been looking at a panic >> that's the result of inconsistency in the high FP state, >> so the race is potentially fatal. >> >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > Marcel, sorry, I probably misunderstood "compiler options" > in the previous reply. Did you mean -j option in > make -j10 buildworld? -j is a make option. Modulo the FP race you're perfectly fine with any -j value that matches the number of CPUs in your box (with 4xNCPUS a rule-of-thumb maximum probably). If the compiler isn't FP intensive, then even -j128 on a dual- CPU box is not causing you problems (it's pointless though :-) FYI, -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Thu Jul 9 08:50:26 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 9 08:50:32 2009 Subject: buildworld panic on ia64 In-Reply-To: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> Message-ID: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> On Wed, Jul 08, 2009 at 09:19:33AM -0700, Marcel Moolenaar wrote: > > On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: > > >> BTW: I never got the error when doing a buildworld. I > >> think Anton's non-standard compiler options make GCC much > >> more FP intensive and thus prone to causing the race. > > > > hey, my compiler options are just a copy from > > /usr/share/examples/etc/make.conf > > > > with obvious changes, e.g. CPUTYPE=itanium2 > > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > > > Which non-standard options did you spot? > > All of them :-) > > There is no /etc/make.conf by default, so the existence > of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them > non-standard. > > As a special warning: /usr/share/examples/etc/make.conf > is inherently i386 biases (like most of the examples and > documentation I might add). It's unwise to copy flags > from there and expect good results. Even warnings-only > examples can cause build breakages (due to -Werror), > because compilers for different architectures emit > different warnings or emit the same warning at different > times. > > By all means: experiment. But be very careful not to make > the assumption that if the code compiles, it'll also run. > The weirder the set of compiler options, the more likely > you trip over optimization bugs and end up with an unstable > system. And I'm not even talking about whether the set > of options give you more optimal code in general. I see.. Is there any advice for compiler options on ia64? Perhaps a sample make.conf for ia64? Or would you recommend leaving these options empty: CFLAGS, COPTFLAGS, CXXFLAGS ? I'm sorry if I'm asking obvious questions. Perhaps this is documented/disucced somewhere already? I'm new to ia64, most of my FBSD experience is from alpha and i386. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Thu Jul 9 16:39:50 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 9 16:40:04 2009 Subject: buildworld panic on ia64 In-Reply-To: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> Message-ID: <8B6FE903-10E5-4A32-8E2E-482595D8F495@mac.com> On Jul 9, 2009, at 1:50 AM, Anton Shterenlikht wrote: >> By all means: experiment. But be very careful not to make >> the assumption that if the code compiles, it'll also run. >> The weirder the set of compiler options, the more likely >> you trip over optimization bugs and end up with an unstable >> system. And I'm not even talking about whether the set >> of options give you more optimal code in general. > > I see.. > > Is there any advice for compiler options on ia64? My advise at this time is to not change from the default. I haven't done any kind of experimentation or know of any- one else who did, to make any kind of claim as to the effectiveness or harm of various compiler options. I'm not talking cleanroom experiments here. I'm sure that there have been plenty of people looking at SPECcpu and who came up with a very creative set of compiler options that make SPECcpu perform "optimally" (for each program). This normally also includes fixing the compiler (and even adding special case code) to have correct code generated in that case. I'm talking about a safe set of options that people can use and that yields correct code 99.9% of the time and gives acceptable (if not good) code. I cannot stress the importance of having the toolchain generate correct code when working on a FreeBSD port to a different architecture. > I'm sorry if I'm asking obvious questions. > Perhaps this is documented/disucced somewhere > already? I'm new to ia64, most of my FBSD > experience is from alpha and i386. These aren't obvious questions. Compiler options, if they are being discussed, are primarily discussed for i386 or amd64. -- Marcel Moolenaar xcllnt@mac.com From mailing at gaturkey.com Thu Jul 9 16:54:46 2009 From: mailing at gaturkey.com (Global Access Travel) Date: Thu Jul 9 16:54:52 2009 Subject: Fam Trip to TURKEY for $999 (Refundable) Message-ID: [http://www.turkeycallingus.com/] Exclusive Boutique Enterprise Turkey FAM ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI 9 Nights / 11 Days $999 ? 5 Continents ? 150 Countries Worldwide ? 100.000 Hotels ? Instant Confirmation [http://www.turkeycallingus.com] [http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm] Global Access proudly presents the biggest FAM Trip of the year, teaming with Turkish Airlines and Turkish Ministry of Tourism and Culture. As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey is likely to be the one of the most popular destinations in 2010. Those who act early and get to know this beautiful country better will be able to give a better insight to their clients and secure more bookings. Our specially selected travel agents will stay in best hotels in each town, be escorted by professional, top tour guides, taste exceptionally good examples of Turkish Cuisine, and get to know Turkey in elegant way. Join us for a luxury FAM adventure and be our special guest in our beautiful country! COMBINE WITH World Travel Market! One of the biggest travel shows of Europe and the world, WTM, will be held in London between 9-12 November 2009. Combine your London trip with Turkey and benefit from great agent rates to see one of the most popular tourist destinations from USA and Canada. WE WILL REFUND YOUR MONEY BACK ! Upon booking your 20th passenger on a Global Access Travel Service, we will refund you the whole tour price that you?ve paid for the FAM Trip. If you book 20 or more people on a Global Access Travel Service before the FAM Trip starts, then you will travel for free! About Us Global Access Travel (GA) was founded in Turkey by a group of tourism professionals and marketing experts who recognized the needs to offer online services for accommodations, car rentals, and other travel related services to travel agencies. Through its sophisticated online reservation services, GA offers more than 100,000 hotels, motels, resorts, clubs and apartments all around the world. Other services of GA include car rentals, transfers, special tours, luxury services, city breaks, flight tickets and other services such as tailor made tour packages, exhibition organizations, incentives and other travel related services around the globe at competitive rates. [http://www.TurkeyCallingus.com] www.TurkeyCalling.us [http://www.turkeycallingus.com/turkey-calling-contact-us.htm] Global Access Travel Tel: +90 212 258 58 29 Fax: +90 212 258 34 47 E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com Website: [http://www.turkeycallingus.com/] www.TurkeyCalling.Us This message was sent by: FamTrit turkey, N?zhetiye Cad., istanbul, besiktas 34357, Turkey To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=47129457&l=82243&s=8OKP&m=578549&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=578549&s=47129457&c=8OKP&cid=305227 From tinderbox at freebsd.org Fri Jul 10 13:46:30 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Jul 10 13:46:50 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090710134627.B7D027302F@freebsd-current.sentex.ca> TB --- 2009-07-10 12:22:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-10 12:22:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-07-10 12:22:05 - cleaning the object tree TB --- 2009-07-10 12:22:51 - cvsupping the source tree TB --- 2009-07-10 12:22:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-07-10 12:23:02 - building world TB --- 2009-07-10 12:23:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-10 12:23:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-10 12:23:02 - TARGET=ia64 TB --- 2009-07-10 12:23:02 - TARGET_ARCH=ia64 TB --- 2009-07-10 12:23:02 - TZ=UTC TB --- 2009-07-10 12:23:02 - __MAKE_CONF=/dev/null TB --- 2009-07-10 12:23:02 - cd /src TB --- 2009-07-10 12:23:02 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 10 12:23:04 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/ia64/src/tmp/usr/lib/libc.a /obj/ia64/src/tmp/usr/lib/libcam.a /obj/ia64/src/tmp/usr/lib/libsbuf.a /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'ataidentify': /src/sbin/camcontrol/camcontrol.c:1195: warning: cast increases required alignment of target type /src/sbin/camcontrol/camcontrol.c:1196: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-10 13:46:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-10 13:46:27 - ERROR: failed to build world TB --- 2009-07-10 13:46:27 - 4063.59 user 327.13 system 5062.35 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From mexas at bristol.ac.uk Fri Jul 10 16:10:16 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 10 16:10:29 2009 Subject: proposed handbook section -> gmirror per partition - required on ia64 Message-ID: <20090710161006.GA97228@mech-cluster238.men.bris.ac.uk> Please have a look at my proposed new section "Mirroring individual partitions", 19.4.2: http://eis.bris.ac.uk/~mexas/geom-mirror.html and give me some feedback. gmirror per partition is the only(?) mirror option on ia64 (any other architectures?). many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From Toby at IACmusic.com Sat Jul 11 08:53:07 2009 From: Toby at IACmusic.com (Toby@IACmusic.com) Date: Sat Jul 11 08:54:38 2009 Subject: Finally, a song contest that is free to enter. $27, 000+ in prizes too! Message-ID: Hi, IACmusic.com has started a major song contest and this one you can enter for free! &n throwing a party that Got a song be a lot of It's our [1]YEAR OF THE I "Indiependents" Day July 4th!&nb categories to choose from to enter your song in, including Songwri ting. The Grand Prize is a huge package that includes $1000 wor th of musical equipment (whatever you need), 2 weeks stay in a c ondo suite at your choice of a number of US vacation spots, an i Pod Shuffle, and a IAC Prime Perpetual Lifetime membership. But there are also 3 nice prizes in each of 16 categories and you can en exposur competition. He will hit Go [3]here Good luc The Staff at IACmusic.com (the Ind References 1. file://localhost/tmp/3D"htt 2. 3D"http://iacmusic.com/quickSignup.aspx" 3. file://localhost/tmp/3D From mexas at bristol.ac.uk Sat Jul 11 23:09:35 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sat Jul 11 23:09:48 2009 Subject: proposed handbook section -> gmirror per partition - required on ia64 In-Reply-To: References: <20090710161006.GA97228@mech-cluster238.men.bris.ac.uk> Message-ID: <20090711230930.GA8077@mech-cluster238.men.bris.ac.uk> On Fri, Jul 10, 2009 at 11:00:01AM -0600, ToyoRunner wrote: > In section 2 of 19.4.2 you may wish to add the additional command to > create the whole partition scheme. Specifically, show that the type > will change from efi, ufs and swap. I know it might seem excessive but > for someone just starting out it would save them from missing this and > not being able to proceed. done, have a look: http://eis.bris.ac.uk/~mexas/geom-mirror.html > Also, perhaps a troubleshooting section on what one should do if the > system will not boot(ie say someone missed step 8, what should they do > to tell the bootloader to set the vfs.root.mountfrom variable)? yes, good idea, I'll take this step out and capture the exact dialog, and then add this to the note. > The only other issue would be that the whole 19.4.2 section has very > specific commands which refer to the partition map which someone may > wish to deviate from. Perhaps a warning about this fact? yes, it needs some change, but I say in the beginning that this example is from ia64. > Other than these points (which may be just my own prejudice) this is > just the ticket for gmirroring a GPT partition map. > > My hat to you, sir. thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 10:38:43 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 10:38:52 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP Message-ID: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> On FreeBSD 8.0-BETA1 ia64 with 2 CPUs port lang/perl5.10 built with threads fails thread-related tests (full details below) Failed 8 tests out of 1433, 99.44% okay. ../ext/threads/shared/t/cond.t ../ext/threads/shared/t/stress.t ../ext/threads/t/blocks.t ../ext/threads/t/exit.t ../ext/threads/t/free.t ../ext/threads/t/free2.t ../ext/threads/t/join.t op/filetest.t The error message typically is (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... Please advise many thanks anton **************************************************** # make showconfig ===> The following configuration options are available for perl-threaded-5.10.0_ 4: DEBUGGING=on "Build with debugging support" GDBM=off "Build GDBM_File extension" PERL_MALLOC=off "Use Perl malloc" PERL_64BITINT=on "Use 64 bit integers (on i386)" THREADS=on "Build threaded perl" MULTIPLICITY=off "Use multiplicity" SUIDPERL=off "Build set-user-id suidperl binary" SITECUSTOMIZE=off "Run-time customization of @INC" USE_PERL=on "Rewrite links in /usr/bin" ===> Use 'make config' to modify these settings # # script log make test # cat log Script started on Sun Jul 12 11:00:52 2009 AutoSplitting perl library LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*/*.pm make lib/re.pm `lib/re.pm' is up to date. Making utilities Making DynaLoader (static_pic) Making Compress::Zlib (nonxs) Making Errno (nonxs) Making IO_Compress_Base (nonxs) Making IO_Compress_Zlib (nonxs) cd lib/unicore && LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ../../miniperl -I../../lib mktables -w touch uni.data rm -f libperl.so cc -o libperl.so -shared -L/usr/local/lib gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o perl.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o DynaLoader.o -lm -lcrypt -lutil LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 cc -o perl -pthread -Wl,-E -L/usr/local/lib -Wl,-R/usr/local/lib/perl5/5.10.0/mach/CORE perlmain.o libperl.so `cat ext.libs` -lm -lcrypt -lutil LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ./miniperl -Ilib mkppport ppport.h in ext/Time/HiRes is up-to-date ppport.h in ext/Win32API/File is up-to-date Making B (dynamic) Making Compress::Raw::Zlib (dynamic) Making Cwd (dynamic) Making DB_File (dynamic) Making Data::Dumper (dynamic) Making Devel::DProf (dynamic) Making Devel::PPPort (dynamic) Making Devel::Peek (dynamic) Making Digest::MD5 (dynamic) Making Digest::SHA (dynamic) Making Encode (dynamic) Making Fcntl (dynamic) Making File::Glob (dynamic) Making Filter::Util::Call (dynamic) Making Hash::Util (dynamic) Making I18N::Langinfo (dynamic) Making IO (dynamic) Making IPC::SysV (dynamic) Making List::Util (dynamic) Making MIME::Base64 (dynamic) Making Math::BigInt::FastCalc (dynamic) Making NDBM_File (dynamic) Making Opcode (dynamic) Making POSIX (dynamic) Making PerlIO::encoding (dynamic) Making PerlIO::scalar (dynamic) Making PerlIO::via (dynamic) Making SDBM_File (dynamic) Making Socket (dynamic) Making Storable (dynamic) Making Sys::Hostname (dynamic) Making Sys::Syslog (dynamic) Making Text::Soundex (dynamic) Making Time::HiRes (dynamic) Making Time::Piece (dynamic) Making Unicode::Normalize (dynamic) Making XS::APItest (dynamic) Making XS::Typemap (dynamic) Making attrs (dynamic) Making re (dynamic) Making threads (dynamic) Making threads::shared (dynamic) Making Hash::Util::FieldHash (dynamic) PERL=./perl make _test_prep LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ./miniperl -Ilib uupacktool.pl -u -m cd t && (rm -f ./perl; /bin/ln -s .././perl ./perl) PERL=./perl make _test if (true /dev/null 2>&1; then make TEST_ARGS= TESTFILE=TEST _test_tty ; else make TEST_ARGS= TESTFILE=TEST _test_notty ; fi cd t && LD_LIBRARY_PATH=/usr/ports/lang/perl5.10/work/perl-5.10.0 ./perl TEST =80%) of the tests succeeded. ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`:$LD_LIBRARY_PATH; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. u=8.13 s=8.61 cu=1004.64 cs=198.81 scripts=1433 tests=190232 *** Error code 1 Stop in /usr/ports/lang/perl5.10/work/perl-5.10.0. *** Error code 1 Stop in /usr/ports/lang/perl5.10/work/perl-5.10.0. *** Error code 1 Stop in /usr/ports/lang/perl5.10/work/perl-5.10.0. *** Error code 1 Stop in /usr/ports/lang/perl5.10. Script done on Sun Jul 12 11:25:58 2009 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From award at googleinc.com Sun Jul 12 11:03:35 2009 From: award at googleinc.com (Google Incorporations Promotion Team) Date: Sun Jul 12 11:03:41 2009 Subject: GUK/877/798/2009 Message-ID: <200907120940.n6C9ec6Q078879@king6.kingsnake.com> Google Incorporations. Stamford New Road, Altrincham Cheshire, WA14 1EP London, United Kingdom. Winning No: GUK/877/798/2009 Ticket No: GUK/699/33/2009 Notification Date: 10/07/2009 GOOGLE ANNIVERSARY WINNING NOTIFICATION. We wish to congratulate you once again on this note, for being part of our winners selected this year. This promotion was set-up to encourage the active users of the Google search engine and the Google ancillary services. Hence we do believe with your winning prize, you will continue to be active and patronage to the Google search engine. Google is now the biggest search engine worldwide and in an effort to make sure that it remains the most widely used search engine, we ran an online e-mail beta test which your email address won ?450,000. {Four Hundred And Fifty Thousand Great British Pounds Sterling} We wish to formally announce to you that you have successfully passed the requirements, statutory obligations, verifications, validations and satisfactory report Test conducted for all online winners. A winning cheque will be issued in your name by Google Promotion Award Team, You have therefore won the entire sum of ?450,000.00 {Four Hundred And Fifty Thousand Great British Pounds Sterling} and also a certificate of prize claims will be sent along side your winning cheque. Sir.Anderson Clarks Google Promotion Award Team Email: sir.anderson_clarks@live.co.uk You are advised to contact your Foreign Transfer Manager with the following details to avoid unnecessary delay and complications: VERIFICATION AND FUNDS RELEASE FORM. (1) Your contact address. (2) Your Tel/Fax numbers. (3) Your Nationality/Country. (4) Your Full Name/Sex. (5) Occupation/Age. (6) Ever won an online lottery? (7) Your Preferred Method of Receiving Your Prize (From Below) Mode Of Prize Remittance. (1)Cash Pick-Up (You coming Down to United Kingdom Personally to Pick Your Prize). (2)Courier Delivery Of your Certified Winning Cheque Name and other Winning Documents safely to you. The Google Promotion Award Team has discovered a huge number of double claims due to winners informing close friends relatives and third parties about their winning and also sharing their pin numbers. As a result of this, these friends try to claim the lottery on behalf of the real winners. The Google Promotion Award Team has reached a decision from headquarters that any double claim discovered by the Lottery Board will result to the canceling of that particular winning, making a loss for both the double claimer and the real winner, as it is taken that the real winner was the informer to the double claimer about the lottery. So you are hereby strongly advised once more to keep your winnings strictly confidential until you claim your prize. Congratulations from the Staffs & Members of the Google interactive Lotteries Board Commission. Sincerely, Dr. Leslie Spears. Google Promotion Award Team From mexas at bristol.ac.uk Sun Jul 12 11:06:21 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 11:06:32 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> Message-ID: <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> On Sun, Jul 12, 2009 at 11:38:38AM +0100, Anton Shterenlikht wrote: > On FreeBSD 8.0-BETA1 ia64 with 2 CPUs > port lang/perl5.10 built with threads > fails thread-related tests (full details below) > > Failed 8 tests out of 1433, 99.44% okay. > ../ext/threads/shared/t/cond.t > ../ext/threads/shared/t/stress.t > ../ext/threads/t/blocks.t > ../ext/threads/t/exit.t > ../ext/threads/t/free.t > ../ext/threads/t/free2.t > ../ext/threads/t/join.t > op/filetest.t > > The error message typically is > > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... some more stats; doing ./perl harness in the `t' directory gives: Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- ../ext/threads/shared/t/cond.t 29 7424 32 36 15-32 ../ext/threads/shared/t/stress.t 29 7424 1 0 ?? ../ext/threads/t/blocks.t 5 8 1-3 5-9 ../ext/threads/t/exit.t 29 7424 18 1 5 ../ext/threads/t/free.t 0 139 29 56 2-29 ../ext/threads/t/free2.t 29 7424 78 106 26-78 ../ext/threads/t/join.t 29 7424 20 4 19-20 op/filetest.t 13 3328 24 38 6-24 (1 subtest UNEXPECTEDLY SUCCEEDED), 29 tests and 790 subtests skipped. Failed 8/1465 test scripts. 120/190245 subtests failed. Files=1465, Tests=190245, 1484 wallclock secs (977.48 cusr + 198.20 csys = 1175. 69 CPU) Failed 8/1465 test programs. 120/190245 subtests failed. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 13:18:23 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 13:18:30 2009 Subject: kernel options PREEMPTION - good idea? Message-ID: <20090712131817.GA7494@mech-cluster238.men.bris.ac.uk> ia64 GENERIC kernel config. file doesn't include `options PREEMPTION'. Alpha GENERIC kernel config. file has this warning: # PREEMPTION appears to have a negative impact on stability # (locking related panics) at least on SMP machines. Does the same advice apply to ia64? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 14:54:18 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 14:54:24 2009 Subject: LOR #261 Message-ID: <20090712145405.GA23614@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 LOR below looks like LOR #261, but the line numbers are different. What does state "cannot deadlock" mean in your table? many thanks anton ************************* lock order reversal: 1st 0xa00000001e5adcf0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe000000010866a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048ac640) at _witness_debugger+0x60 witness_checkorder(0xe000000010866a00, 0x9, 0xffffffffffffffff, 0x11d, 0x0) at witness_checkorder+0x12c0 _sx_xlock(0xe000000010866a00, 0x0, 0xe0000000048ac640, 0x11d) at _sx_xlock+0xc0 ufsdirhash_acquire(0xe000000010a9a348, 0xe000000010866a00, 0xe00000000477eaf0, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000000010a9a348, 0xa00000001f760018, 0x18, 0xa000000032b45308) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000000010b46760, 0xe000000010a39d88, 0x0, 0x0) at ufs_dirremove+0x240 ufs_remove(0xa000000032b453d8, 0xe000000010a39d88, 0xe0000000045096f0) at ufs_remove+0xe0 VOP_REMOVE_APV(0xe0000000049acdd0, 0xa000000032b453d8, 0xe000000010b459d0, 0xe000000004509760) at VOP_REMOVE_APV+0x1c0 kern_unlinkat(0xe000000010850b10, 0xffffffffffffff9c, 0x200000004041b048, 0x0) at kern_unlinkat+0x2f0 kern_unlink(0xe000000010850b10, 0x200000004041b048, 0x0) at kern_unlink+0x30 unlink(0xe000000010850b10, 0xa000000032b454e8, 0xe0000000048283e0, 0x58f) at unlink+0x30 syscall(0xa000000032b45400, 0xa, 0x200000004041af40, 0xe000000010850b10, 0xe000000010848cd8, 0xe000000004982690, 0xa, 0xa000000032b454e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 15:11:25 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 15:11:32 2009 Subject: LOR #266 Message-ID: <20090712151117.GA35998@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 Looks like LOR 266, but different line numbers: lock order reversal: 1st 0xe000000013abcd80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 2nd 0xa00000001e6f1f68 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6170 3rd 0xe0000000159f54e0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe000000004891318) at _witness_debugger+0x60 witness_checkorder(0xe0000000159f54e0, 0x9, 0x0, 0x823, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000159f54e0, 0x80100, 0xe0000000159f5508, 0xe000000004876a38, 0x50, 0x33, 0xe000000004891318, 0x823) at __lockmgr_args+0xe60 ffs_lock(0xa000000032bbcf70, 0xe0000000159f54e0, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe0000000049ac600, 0xa000000032bbcf50, 0xe0000000048905f0) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe0000000159f5448, 0x80100, 0xe000000004891318, 0x823) at _vn_lock+0xf0 vget(0xe0000000159f5448, 0x80100, 0xe00000001084e000, 0x50) at vget+0x160 vfs_hash_get(0xe000000010763490, 0xb82a, 0xe0000000159f5448, 0xe00000001084e000, 0xa000000032bbcfa8, 0x0, 0x0, 0xe0000000048905f0) at vfs_hash_get+0x180 ffs_vgetf(0xe000000010763490, 0xb82a, 0x80000, 0xa000000032bbcfa8, 0x1, 0xea5, 0xea5, 0xe000000004b9e0d8) at ffs_vgetf+0x50 softdep_sync_metadata(0xe000000013abcce8, 0xe00000001144481a, 0xe0000000048aa3b8, 0x146, 0xe000000004777600, 0xe000000011444800, 0xb82a, 0xe0000000048aa3b8) at softdep_sync_metadata+0xb10 ffs_syncvnode(0xe000000013abcce8, 0x0, 0x0, 0xa00000001e6f1f68, 0xea3, 0xe0000000048ac138) at ffs_syncvnode+0x760 ffs_truncate(0xe000000013abcce8, 0x1000, 0x880, 0xe000000010868800, 0xe00000001084e000, 0x0) at ffs_truncate+0x990 ufs_direnter(0xe000000013abcce8, 0xe0000000159f5448, 0xa000000032bbd148, 0xa000000032bbd388, 0xa00000001e769e28, 0xa00000002235498c) at ufs_direnter+0x14d0 ufs_mkdir(0xa000000032bbd3d0, 0xa000000032bbd148, 0xe0000000159bd458) at ufs_mkdir+0x12d0 VOP_MKDIR_APV(0xe0000000049acdd0, 0xa000000032bbd3d0, 0xa000000032bbd388, 0xe000000004508480) at VOP_MKDIR_APV+0x1c0 kern_mkdirat(0xe00000001084e000, 0xffffffffffffff9c, 0x9fffffffffffeb36, 0x0, 0x1ff) at kern_mkdirat+0x460 kern_mkdir(0xe00000001084e000, 0x9fffffffffffeb36, 0x0, 0x1ff) at kern_mkdir+0x40 mkdir(0xe00000001084e000, 0xa000000032bbd4e8, 0xe0000000048283e0, 0x58f) at mkdir+0x30 syscall(0xa000000032bbd400, 0x88, 0x8, 0xe00000001084e000, 0xe0000000118759b0, 0xe000000004983e30, 0x88, 0xa000000032bbd4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 15:34:23 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 15:34:30 2009 Subject: LOR #285 Message-ID: <20090712153418.GA67479@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 Looks like LOR #285, but different line numbers: lock order reversal: 1st 0xe000000011d4f6b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xa00000001e77d0b0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xe00000001083b308 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe00000001083b308, 0x9, 0x0, 0x220, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe00000001083b308, 0x80100, 0xe00000001083b330, 0xe000000004876a38, 0x50, 0x33, 0xe0000000048a9da8, 0x220) at __lockmgr_args+0xe60 ffs_lock(0xa000000032bcadd0, 0xe00000001083b308, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe0000000049ac600, 0xa000000032bcadb0, 0xe0000000043bb800) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe00000001083b270, 0x80100, 0xe0000000048a9da8, 0x220, 0xe00000001083b280, 0xa000000032bcadd0, 0xa000000032bcadc8, 0xa000000032bcadc0) at _vn_lock+0xf0 ffs_snapshot(0xe000000010777780, 0xa000000032bcafc8, 0xe00000001083b270, 0xe00000001083b330, 0x1, 0x0, 0xa0000000003b2000, 0x0) at ffs_snapshot+0x2280 ffs_mount(0x0, 0xe0000000048abc50, 0xa000000032bcb100, 0xa000000032bcb100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe000000010787300) at vfs_donmount+0x1d80 nmount(0xe000000010b663b0, 0xa000000032bcb4e8, 0x0, 0xe0000000048283e0) at nmount+0xf0 syscall(0xa000000032bcb400, 0x17a, 0x201000, 0xe000000010b663b0, 0xe000000010b4f568, 0xe000000004986b90, 0x17a, 0xa000000032bcb4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 15:43:52 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 15:44:04 2009 Subject: LOR #240 Message-ID: <20090712154347.GA67867@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 Looks like LOR #240, with different line numbers: lock order reversal: 1st 0xe000000011d82a30 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:296 2nd 0xe000000011d4f6b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe000000011d4f6b8, 0x9, 0xffffffffffffffff, 0x633, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000011d4f6b8, 0x80000, 0x0, 0xe000000004876a38, 0x50, 0x33, 0xe0000000048a9da8, 0x633) at __lockmgr_args+0xe60 ffs_snapremove(0xe000000011d4f620, 0xe0000000048a9da8, 0xe000000004892880, 0xe000000011d4f6b8) at ffs_snapremove+0x200 softdep_releasefile(0xe000000011d3db90, 0xa000000032bcb2d0, 0x29f, 0xe000000004782080, 0x48e) at softdep_releasefile+0x90 ufs_inactive(0xe000000010b663b0, 0xe000000011d3db90, 0xe000000011d4f710) at ufs_inactive+0x400 VOP_INACTIVE_APV(0xe0000000049acdd0, 0xa000000032bcb2e0, 0xe000000004891318, 0xe0000000044fc820) at VOP_INACTIVE_APV+0x1c0 vinactive(0xe000000011d4f620, 0xe000000010b663b0, 0x800, 0xe000000011d4f6e0) at vinactive+0x110 vput(0xe000000011d4f620, 0xa000000032bcb308, 0xe000000004892880, 0xe000000011d4f6e0) at vput+0x3f0 vn_close(0xe000000011d4f620, 0x1, 0xe00000001035bc00, 0xe000000010b663b0) at vn_close+0x310 vn_closefile(0xe0000000107bba90, 0xe000000010b663b0, 0xe000000011d4f620) at vn_closefile+0x1e0 _fdrop(0xe0000000107bba90, 0xe000000010b663b0, 0xe00000000436eb60, 0xb9b) at _fdrop+0xb0 closef(0xe0000000107bba90, 0xe000000010b663b0, 0x0, 0xe00000000436f310) at closef+0x570 kern_close(0xe000000010b663b0, 0xe000000004878dd0) at kern_close+0x270 close(0xe000000010b663b0, 0xa000000032bcb4e8, 0xe0000000048283e0, 0x58f) at close+0x30 syscall(0xa000000032bcb400, 0x6, 0x0, 0xe000000010b663b0, 0xe000000010b4f568, 0xe0000000049825d0, 0x6, 0xa000000032bcb4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 16:55:06 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 16:55:14 2009 Subject: mpt Message-ID: <20090712165459.GA92924@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 I see lots of these messages (full dmesg below) on boot after a cold reset: mpt0: completing timedout/aborted req 0xa0000000000d0f40:42081 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d12a0:42084 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt is a SCSI driver. Is this something to do with gmirror? I also get this: /usr: mount pending error: blocks 756 files 13 Should I be worried? many thanks anton full dmesg: GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #0: Sun Jul 12 15:15:30 BST 2009 mexas@tzav.vms.org:/usr/obj/usr/src/sys/TZAV WARNING: WITNESS option enabled, expect reduced performance. module_register: module probe already exists! Module probe failed to register: 17 CPU: Madison (1500.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 2126766080 (2028 MB) avail memory = 2017198080 (1923 MB) FPSWA Revision = 0x10012, Entry = 0xe00000407fe60050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: SAPIC Id=1, SAPIC Eid=0 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 20090521 tbfadt-625 ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 20090521 tbfadt-625 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ohci0: mem 0x80023000-0x80023fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x80022000-0x80022fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x80021000-0x800210ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 atapci0: port 0xd58-0xd5f,0xd64-0xd67,0xd50-0xd57,0xd60-0xd63,0xd40-0xd4f irq 21 at device 2.0 on pci0 atapci0: [ITHREAD] atapci0: HW has secondary channel disabled ata2: on atapci0 ata2: [ITHREAD] fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:0a:31:d6:ec fxp0: [ITHREAD] pcib1: on acpi0 pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x90840000-0x9084ffff,0x90830000-0x9083ffff irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90820000-0x9082ffff,0x90810000-0x9081ffff irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 bge0: mem 0x90800000-0x9080ffff irq 29 at device 2.0 on pci32 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:0a:31:36:40 bge0: [ITHREAD] pcib2: on acpi0 pci64: on pcib2 pcib3: on acpi0 pci96: on pcib3 pcib4: on acpi0 pci128: on pcib4 pcib5: on acpi0 pci192: on pcib5 pcib6: on acpi0 pci224: on pcib6 uart0: <8250 or 16450 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: mem 0xf4050000-0xf4050fff,0xf4020000-0xf403ffff irq 82 at device 1.1 on pci224 puc0: [FILTER] uart1: on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: on puc0 uart2: [FILTER] uart3: on puc0 uart3: [FILTER] vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf3ffffff,0xf4040000-0xf404ffff at device 2.0 on pci224 uart4: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart4: [FILTER] uart5: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart5: [FILTER] uart5: debug port (9600,n,8,1) cpu0: on acpi0 cpu1: on acpi0 Timecounters tick every 1.000 msec IP Filter: v4.1.28 initialized. Default = block all, Logging = enabled Waiting 5 seconds for SCSI devices to settle usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DVDROM at ata2-master PIO4 uhub1: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 5 ports with 5 removable, self powered WARNING: WITNESS option enabled, expect reduced performance. da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device mirror/efi launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/tmp launched (2/2). GEOM_MIRROR: Device mirror/usr launched (1/2). GEOM_MIRROR: Device usr: rebuilding provider da0p6. Trying to mount root from ufs:/dev/mirror/root WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 756 files 13 WARNING: /var was not properly dismounted lock order reversal: 1st 0xe000000010a64448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xa00000001e5a6340 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xe0000000107a4098 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe0000000107a4098, 0x9, 0x0, 0x220, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000107a4098, 0x80100, 0xe0000000107a40c0, 0xe000000004876a38, 0x50, 0x33, 0xe0000000048a9da8, 0x220) at __lockmgr_args+0xe60 ffs_lock(0xa000000032c1cdd0, 0xe0000000107a4098, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe0000000049ac600, 0xa000000032c1cdb0, 0xe0000000043bb800) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe0000000107a4000, 0x80100, 0xe0000000048a9da8, 0x220, 0xe0000000107a4010, 0xa000000032c1cdd0, 0xa000000032c1cdc8, 0xa000000032c1cdc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000106e9490, 0xa000000032c1cfc8, 0xe0000000107a4000, 0xe0000000107a40c0, 0x1, 0x0, 0xa000000000416000, 0x0) at ffs_snapshot+0x2280 ffs_mount(0x0, 0xe0000000048abc50, 0xa000000032c1d100, 0xa000000032c1d100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000107df400) at vfs_donmount+0x1d80 nmount(0xe000000010a34b10, 0xa000000032c1d4e8, 0x0, 0xe0000000048283e0) at nmount+0xf0 syscall(0xa000000032c1d400, 0x17a, 0x201000, 0xe000000010a34b10, 0xe000000010a29120, 0xe000000004986b90, 0x17a, 0xa000000032c1d4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xa00000001e56b8c8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe000000010a30830 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2223 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe000000010a30830, 0x9, 0xffffffffffffffff, 0x8af, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010a30830, 0x80900, 0xe0000000107a5c68, 0xe0000000048a9e10, 0x50, 0x33, 0xe0000000048a9da8, 0x8af) at __lockmgr_args+0xe60 ffs_copyonwrite(0xe0000000107a5ba8, 0xa00000001e56ba08) at ffs_copyonwrite+0x490 ffs_geom_strategy(0xe0000000107a5cc0, 0xa00000001e56ba08, 0x375) at ffs_geom_strategy+0x2b0 bufwrite(0xa00000001e56ba08, 0x4, 0x0, 0xe00000000476da70, 0x38c) at bufwrite+0x300 ffs_bufwrite(0xa00000001e56ba08, 0xe0000000048abc50) at ffs_bufwrite+0x4c0 bawrite(0xa00000001e56ba08, 0xe00000000476f5d0, 0xa9b, 0xe000000004bb9ea0) at bawrite+0xf0 ffs_sbupdate(0xe0000000107ba000, 0x3, 0x0, 0xa00000001e56ba08, 0x800, 0xe000000010638000) at ffs_sbupdate+0x2a0 ffs_sync(0xe0000000106e9490, 0x3, 0xe0000000107a5ba8, 0xe0000000107a5cc0) at ffs_sync+0x850 sync_fsync(0xe000000004891318, 0xe000000004891318, 0xe0000000048330b0) at sync_fsync+0x2f0 VOP_FSYNC_APV(0xe00000000499c9a8, 0xa0000000306b7518, 0xe000000004891318, 0xe000000004504560) at VOP_FSYNC_APV+0x1c0 sync_vnode(0xe0000000104702d0, 0xa0000000306b7540, 0xe000000010500760, 0xa0000000306b7520, 0xa0000000306b7518) at sync_vnode+0x260 sched_sync(0xe0000000104702d8, 0x1a, 0xe0000000104702d0, 0x1b) at sched_sync+0x4d0 fork_exit(0xe0000000048c4130, 0x0, 0xa0000000306b7550) at fork_exit+0x110 enter_userland() at enter_userland mpt0: request 0xa0000000000cec60:42042 timed out for ccb 0xe0000000106e4000 (req->ccb 0xe0000000106e4000) mpt0: request 0xa0000000000ce120:42043 timed out for ccb 0xe000000010b1c000 (req->ccb 0xe000000010b1c000) mpt0: request 0xa0000000000d0760:42044 timed out for ccb 0xe000000010a01000 (req->ccb 0xe000000010a01000) mpt0: request 0xa0000000000d0490:42045 timed out for ccb 0xe000000010626800 (req->ccb 0xe000000010626800) mpt0: request 0xa0000000000cfdd0:42046 timed out for ccb 0xe00000001069c800 (req->ccb 0xe00000001069c800) mpt0: request 0xa0000000000d05b0:42047 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000cf9e0:42048 timed out for ccb 0xe00000001061c000 (req->ccb 0xe00000001061c000) mpt0: completing timedout/aborted req 0xa0000000000cec60:42042 mpt0: completing timedout/aborted req 0xa0000000000ce120:42043 mpt0: completing timedout/aborted req 0xa0000000000d0760:42044 mpt0: completing timedout/aborted req 0xa0000000000d0490:42045 mpt0: completing timedout/aborted req 0xa0000000000cf9e0:42048 mpt0: completing timedout/aborted req 0xa0000000000cfdd0:42046 mpt0: completing timedout/aborted req 0xa0000000000d05b0:42047 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d0d90:42053 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000d1c30:42054 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000cf5f0:42055 timed out for ccb 0xe00000001069c800 (req->ccb 0xe00000001069c800) mpt0: request 0xa0000000000d00a0:42056 timed out for ccb 0xe00000001061c000 (req->ccb 0xe00000001061c000) mpt0: request 0xa0000000000d0370:42057 timed out for ccb 0xe000000010626800 (req->ccb 0xe000000010626800) mpt0: request 0xa0000000000cf7a0:42058 timed out for ccb 0xe000000010a01000 (req->ccb 0xe000000010a01000) mpt0: request 0xa0000000000d1180:42059 timed out for ccb 0xe000000010b1c000 (req->ccb 0xe000000010b1c000) mpt0: completing timedout/aborted req 0xa0000000000cf7a0:42058 mpt0: completing timedout/aborted req 0xa0000000000d0d90:42053 mpt0: completing timedout/aborted req 0xa0000000000d1c30:42054 mpt0: completing timedout/aborted req 0xa0000000000d1180:42059 mpt0: completing timedout/aborted req 0xa0000000000cf5f0:42055 mpt0: completing timedout/aborted req 0xa0000000000d00a0:42056 mpt0: completing timedout/aborted req 0xa0000000000d0370:42057 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d17b0:42060 timed out for ccb 0xe00000001069c800 (req->ccb 0xe00000001069c800) mpt0: request 0xa0000000000cfcb0:42061 timed out for ccb 0xe000000010b1c000 (req->ccb 0xe000000010b1c000) mpt0: request 0xa0000000000d0880:42062 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000d0640:42063 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000cfb00:42064 timed out for ccb 0xe000000010a01000 (req->ccb 0xe000000010a01000) mpt0: request 0xa0000000000d0910:42065 timed out for ccb 0xe000000010683000 (req->ccb 0xe000000010683000) mpt0: request 0xa0000000000cfef0:42066 timed out for ccb 0xe00000001069e800 (req->ccb 0xe00000001069e800) mpt0: completing timedout/aborted req 0xa0000000000cfb00:42064 mpt0: completing timedout/aborted req 0xa0000000000d17b0:42060 mpt0: completing timedout/aborted req 0xa0000000000cfcb0:42061 mpt0: completing timedout/aborted req 0xa0000000000d0880:42062 mpt0: completing timedout/aborted req 0xa0000000000d0640:42063 mpt0: completing timedout/aborted req 0xa0000000000cfef0:42066 mpt0: completing timedout/aborted req 0xa0000000000d0910:42065 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d0250:42067 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000d0be0:42068 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000d2b60:42069 timed out for ccb 0xe000000010b1c000 (req->ccb 0xe000000010b1c000) mpt0: request 0xa0000000000d19f0:42070 timed out for ccb 0xe00000001069c800 (req->ccb 0xe00000001069c800) mpt0: request 0xa0000000000d0d00:42071 timed out for ccb 0xe000000010a01000 (req->ccb 0xe000000010a01000) mpt0: request 0xa0000000000d2800:42072 timed out for ccb 0xe000000010626800 (req->ccb 0xe000000010626800) mpt0: request 0xa0000000000d1060:42073 timed out for ccb 0xe00000001061c000 (req->ccb 0xe00000001061c000) mpt0: request 0xa0000000000d13c0:42074 timed out for ccb 0xe0000000106e4000 (req->ccb 0xe0000000106e4000) mpt0: request 0xa0000000000d1450:42075 timed out for ccb 0xe000000010b19000 (req->ccb 0xe000000010b19000) mpt0: completing timedout/aborted req 0xa0000000000d2800:42072 mpt0: completing timedout/aborted req 0xa0000000000d13c0:42074 mpt0: completing timedout/aborted req 0xa0000000000d0250:42067 mpt0: completing timedout/aborted req 0xa0000000000d0be0:42068 mpt0: completing timedout/aborted req 0xa0000000000d1450:42075 mpt0: completing timedout/aborted req 0xa0000000000d2b60:42069 mpt0: completing timedout/aborted req 0xa0000000000d19f0:42070 mpt0: completing timedout/aborted req 0xa0000000000d0d00:42071 mpt0: completing timedout/aborted req 0xa0000000000d1060:42073 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d1840:42076 timed out for ccb 0xe000000010b19000 (req->ccb 0xe000000010b19000) mpt0: request 0xa0000000000d1210:42077 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000d2fe0:42078 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000d2650:42079 timed out for ccb 0xe0000000106e4000 (req->ccb 0xe0000000106e4000) mpt0: request 0xa0000000000d1720:42080 timed out for ccb 0xe000000010626800 (req->ccb 0xe000000010626800) mpt0: request 0xa0000000000d0f40:42081 timed out for ccb 0xe000000010683000 (req->ccb 0xe000000010683000) mpt0: request 0xa0000000000d2ec0:42082 timed out for ccb 0xe00000001069e800 (req->ccb 0xe00000001069e800) mpt0: completing timedout/aborted req 0xa0000000000d1720:42080 mpt0: completing timedout/aborted req 0xa0000000000d2ec0:42082 mpt0: completing timedout/aborted req 0xa0000000000d1840:42076 mpt0: completing timedout/aborted req 0xa0000000000d1210:42077 mpt0: completing timedout/aborted req 0xa0000000000d2fe0:42078 mpt0: completing timedout/aborted req 0xa0000000000d2650:42079 mpt0: completing timedout/aborted req 0xa0000000000d0f40:42081 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d12a0:42084 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000d1b10:42085 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000d41e0:42086 timed out for ccb 0xe000000010b19000 (req->ccb 0xe000000010b19000) mpt0: request 0xa0000000000d07f0:42087 timed out for ccb 0xe00000001069e800 (req->ccb 0xe00000001069e800) mpt0: request 0xa0000000000d3a00:42088 timed out for ccb 0xe000000010626800 (req->ccb 0xe000000010626800) mpt0: request 0xa0000000000d0c70:42089 timed out for ccb 0xe00000001061c000 (req->ccb 0xe00000001061c000) mpt0: request 0xa0000000000d1330:42090 timed out for ccb 0xe000000010a01000 (req->ccb 0xe000000010a01000) mpt0: request 0xa0000000000d38e0:42091 timed out for ccb 0xe00000001069c800 (req->ccb 0xe00000001069c800) mpt0: completing timedout/aborted req 0xa0000000000d0c70:42089 mpt0: completing timedout/aborted req 0xa0000000000d12a0:42084 mpt0: completing timedout/aborted req 0xa0000000000d1b10:42085 mpt0: completing timedout/aborted req 0xa0000000000d41e0:42086 mpt0: completing timedout/aborted req 0xa0000000000d07f0:42087 mpt0: completing timedout/aborted req 0xa0000000000d38e0:42091 mpt0: completing timedout/aborted req 0xa0000000000d3a00:42088 mpt0: completing timedout/aborted req 0xa0000000000d1330:42090 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xa0000000000d2770:42092 timed out for ccb 0xe00000001069e800 (req->ccb 0xe00000001069e800) mpt0: request 0xa0000000000d06d0:42093 timed out for ccb 0xe000000010b19000 (req->ccb 0xe000000010b19000) mpt0: request 0xa0000000000d24a0:42094 timed out for ccb 0xe00000001061c800 (req->ccb 0xe00000001061c800) mpt0: request 0xa0000000000d2140:42095 timed out for ccb 0xe000000010b16800 (req->ccb 0xe000000010b16800) mpt0: request 0xa0000000000d44b0:42096 timed out for ccb 0xe00000001061c000 (req->ccb 0xe00000001061c000) mpt0: request 0xa0000000000d40c0:42097 timed out for ccb 0xe000000010a1f800 (req->ccb 0xe000000010a1f800) mpt0: request 0xa0000000000d1f00:42098 timed out for ccb 0xe000000010683000 (req->ccb 0xe000000010683000) mpt0: completing timedout/aborted req 0xa0000000000d2770:42092 mpt0: completing timedout/aborted req 0xa0000000000d2140:42095 mpt0: completing timedout/aborted req 0xa0000000000d44b0:42096 mpt0: completing timedout/aborted req 0xa0000000000d40c0:42097 mpt0: completing timedout/aborted req 0xa0000000000d06d0:42093 mpt0: completing timedout/aborted req 0xa0000000000d1f00:42098 mpt0: completing timedout/aborted req 0xa0000000000d24a0:42094 mpt0: Timedout requests already complete. Interrupts may not be functioning. lock order reversal: 1st 0xe000000010a30830 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:296 2nd 0xe000000010a64448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe000000010a64448, 0x9, 0xffffffffffffffff, 0x633, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010a64448, 0x80000, 0x0, 0xe000000004876a38, 0x50, 0x33, 0xe0000000048a9da8, 0x633) at __lockmgr_args+0xe60 ffs_snapremove(0xe000000010a643b0, 0xe0000000048a9da8, 0xe000000004892880, 0xe000000010a64448) at ffs_snapremove+0x200 softdep_releasefile(0xe000000010a5ad20, 0xa000000032c1d2d0, 0x29f, 0xe000000004782080, 0x48e) at softdep_releasefile+0x90 ufs_inactive(0xe000000010a34b10, 0xe000000010a5ad20, 0xe000000010a644a0) at ufs_inactive+0x400 VOP_INACTIVE_APV(0xe0000000049acdd0, 0xa000000032c1d2e0, 0xe000000004891318, 0xe0000000044fc820) at VOP_INACTIVE_APV+0x1c0 vinactive(0xe000000010a643b0, 0xe000000010a34b10, 0x800, 0xe000000010a64470) at vinactive+0x110 vput(0xe000000010a643b0, 0xa000000032c1d308, 0xe000000004892880, 0xe000000010a64470) at vput+0x3f0 vn_close(0xe000000010a643b0, 0x1, 0xe000000010363c00, 0xe000000010a34b10) at vn_close+0x310 vn_closefile(0xe000000010720c80, 0xe000000010a34b10, 0xe000000010a643b0) at vn_closefile+0x1e0 _fdrop(0xe000000010720c80, 0xe000000010a34b10, 0xe00000000436eb60, 0xb9b) at _fdrop+0xb0 closef(0xe000000010720c80, 0xe000000010a34b10, 0x0, 0xe00000000436f310) at closef+0x570 kern_close(0xe000000010a34b10, 0xe000000004878dd0) at kern_close+0x270 close(0xe000000010a34b10, 0xa000000032c1d4e8, 0xe0000000048283e0, 0x58f) at close+0x30 syscall(0xa000000032c1d400, 0x6, 0x0, 0xe000000010a34b10, 0xe000000010a29120, 0xe0000000049825d0, 0x6, 0xa000000032c1d4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xa00000001e5baf20 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe00000001069ba00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048ac640) at _witness_debugger+0x60 witness_checkorder(0xe00000001069ba00, 0x9, 0xffffffffffffffff, 0x11d, 0x0) at witness_checkorder+0x12c0 _sx_xlock(0xe00000001069ba00, 0x0, 0xe0000000048ac640, 0x11d) at _sx_xlock+0xc0 ufsdirhash_acquire(0xe000000013265650, 0xe00000001069ba00, 0xe00000000477eaf0, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000000013265650, 0xa00000001f929788, 0x1788, 0xa000000032c0d308) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000000010ac0b10, 0xe00000001215a5e8, 0x0, 0x0) at ufs_dirremove+0x240 ufs_remove(0xa000000032c0d3d8, 0xe00000001215a5e8, 0xe0000000045096f0) at ufs_remove+0xe0 VOP_REMOVE_APV(0xe0000000049acdd0, 0xa000000032c0d3d8, 0xe00000001216cb10, 0xe000000004509760) at VOP_REMOVE_APV+0x1c0 kern_unlinkat(0xe00000001064d620, 0xffffffffffffff9c, 0x9fffffffffffebae, 0x0) at kern_unlinkat+0x2f0 kern_unlink(0xe00000001064d620, 0x9fffffffffffebae, 0x0) at kern_unlink+0x30 unlink(0xe00000001064d620, 0xa000000032c0d4e8, 0xe0000000048283e0, 0x58f) at unlink+0x30 syscall(0xa000000032c0d400, 0xa, 0x8, 0xe00000001064d620, 0xe000000010a299b0, 0xe000000004982690, 0xa, 0xa000000032c0d4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Jul 12 17:50:25 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 17:51:53 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> Message-ID: <20090712175020.GA93782@mech-cluster238.men.bris.ac.uk> On Sun, Jul 12, 2009 at 12:06:13PM +0100, Anton Shterenlikht wrote: > On Sun, Jul 12, 2009 at 11:38:38AM +0100, Anton Shterenlikht wrote: > > On FreeBSD 8.0-BETA1 ia64 with 2 CPUs > > port lang/perl5.10 built with threads > > fails thread-related tests (full details below) > > > > Failed 8 tests out of 1433, 99.44% okay. > > ../ext/threads/shared/t/cond.t > > ../ext/threads/shared/t/stress.t > > ../ext/threads/t/blocks.t > > ../ext/threads/t/exit.t > > ../ext/threads/t/free.t > > ../ext/threads/t/free2.t > > ../ext/threads/t/join.t > > op/filetest.t > > > > The error message typically is > > > > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... > > some more stats; > doing ./perl harness in the `t' directory gives: > > Failed Test Stat Wstat Total Fail List of Failed > ------------------------------------------------------------------------------- > ../ext/threads/shared/t/cond.t 29 7424 32 36 15-32 > ../ext/threads/shared/t/stress.t 29 7424 1 0 ?? > ../ext/threads/t/blocks.t 5 8 1-3 5-9 > ../ext/threads/t/exit.t 29 7424 18 1 5 > ../ext/threads/t/free.t 0 139 29 56 2-29 > ../ext/threads/t/free2.t 29 7424 78 106 26-78 > ../ext/threads/t/join.t 29 7424 20 4 19-20 > op/filetest.t 13 3328 24 38 6-24 > (1 subtest UNEXPECTEDLY SUCCEEDED), 29 tests and 790 subtests skipped. > Failed 8/1465 test scripts. 120/190245 subtests failed. > Files=1465, Tests=190245, 1484 wallclock secs (977.48 cusr + 198.20 csys = 1175. > 69 CPU) > Failed 8/1465 test programs. 120/190245 subtests failed. twice my system froze and required cold reboot at this point during tests: ../ext/threads/t/libc............................................ok ../ext/threads/t/list............................................ok ../ext/threads/t/problems........................................ok ../ext/threads/t/stack...........................................ok ../ext/threads/t/stack_env.......................................ok ../ext/threads/t/state...........................................ok 45/59panic: MUTEX_DESTROY (16) [shared.xs:192]. ../ext/threads/t/state...........................................dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 54-59 Failed 6/59 tests, 89.83% okay ../ext/threads/t/stress_cv.......................................ok ../ext/threads/t/stress_re.......................................ok ../ext/threads/t/stress_string...................................ok ../ext/threads/t/thread..........................................ok 13/34 (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/threads/t/thre ad.t line 118. (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/thread s/t/thread.t line 169. ../ext/threads/t/thread..........................................ok ../ext/Time/HiRes/t/HiRes........................................ok 11/38 then freeze. I had to cycle power via MP. Importantly, it froze twice at the same test. Can somebody with rx26xx verify this: #cd /usr/ports/lang/perl5.10 #make test many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From toyorunner at gmail.com Sun Jul 12 20:29:14 2009 From: toyorunner at gmail.com (ToyoRunner) Date: Sun Jul 12 20:29:21 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <20090712175020.GA93782@mech-cluster238.men.bris.ac.uk> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> <20090712175020.GA93782@mech-cluster238.men.bris.ac.uk> Message-ID: <4A5A4793.2030009@gmail.com> Anton Shterenlikht wrote: > On Sun, Jul 12, 2009 at 12:06:13PM +0100, Anton Shterenlikht wrote: > >> On Sun, Jul 12, 2009 at 11:38:38AM +0100, Anton Shterenlikht wrote: >> >>> On FreeBSD 8.0-BETA1 ia64 with 2 CPUs >>> port lang/perl5.10 built with threads >>> fails thread-related tests (full details below) >>> >>> Failed 8 tests out of 1433, 99.44% okay. >>> ../ext/threads/shared/t/cond.t >>> ../ext/threads/shared/t/stress.t >>> ../ext/threads/t/blocks.t >>> ../ext/threads/t/exit.t >>> ../ext/threads/t/free.t >>> ../ext/threads/t/free2.t >>> ../ext/threads/t/join.t >>> op/filetest.t >>> >>> The error message typically is >>> >>> (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... >>> >> some more stats; >> doing ./perl harness in the `t' directory gives: >> >> Failed Test Stat Wstat Total Fail List of Failed >> ------------------------------------------------------------------------------- >> ../ext/threads/shared/t/cond.t 29 7424 32 36 15-32 >> ../ext/threads/shared/t/stress.t 29 7424 1 0 ?? >> ../ext/threads/t/blocks.t 5 8 1-3 5-9 >> ../ext/threads/t/exit.t 29 7424 18 1 5 >> ../ext/threads/t/free.t 0 139 29 56 2-29 >> ../ext/threads/t/free2.t 29 7424 78 106 26-78 >> ../ext/threads/t/join.t 29 7424 20 4 19-20 >> op/filetest.t 13 3328 24 38 6-24 >> (1 subtest UNEXPECTEDLY SUCCEEDED), 29 tests and 790 subtests skipped. >> Failed 8/1465 test scripts. 120/190245 subtests failed. >> Files=1465, Tests=190245, 1484 wallclock secs (977.48 cusr + 198.20 csys = 1175. >> 69 CPU) >> Failed 8/1465 test programs. 120/190245 subtests failed. >> > > twice my system froze and required cold reboot at this point during tests: > > ../ext/threads/t/libc............................................ok > ../ext/threads/t/list............................................ok > ../ext/threads/t/problems........................................ok > ../ext/threads/t/stack...........................................ok > ../ext/threads/t/stack_env.......................................ok > ../ext/threads/t/state...........................................ok 45/59panic: > MUTEX_DESTROY (16) [shared.xs:192]. > ../ext/threads/t/state...........................................dubious > Test returned status 29 (wstat 7424, 0x1d00) > DIED. FAILED tests 54-59 > Failed 6/59 tests, 89.83% okay > ../ext/threads/t/stress_cv.......................................ok > ../ext/threads/t/stress_re.......................................ok > ../ext/threads/t/stress_string...................................ok > ../ext/threads/t/thread..........................................ok 13/34 > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/threads/t/thre > ad.t line 118. > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/thread > s/t/thread.t line 169. > ../ext/threads/t/thread..........................................ok > ../ext/Time/HiRes/t/HiRes........................................ok 11/38 > > > then freeze. I had to cycle power via MP. > Importantly, it froze twice at the same test. > > Can somebody with rx26xx verify this: > > #cd /usr/ports/lang/perl5.10 > #make test > > many thanks > anton > > Running make test produced no errors. t/Module_Pluggable/01use......................................ok t/Module_Pluggable/02alsoworks................................ok t/Module_Pluggable/02works....................................ok t/Module_Pluggable/02works_taint..............................ok t/Module_Pluggable/03diffname.................................ok t/Module_Pluggable/04acmedir..................................ok t/Module_Pluggable/04acmedir_single...........................ok t/Module_Pluggable/04acmepath.................................ok t/Module_Pluggable/04acmepath_single..........................ok t/Module_Pluggable/05postpath.................................ok t/Module_Pluggable/06multipath................................ok t/Module_Pluggable/07instantiate..............................ok t/Module_Pluggable/08nothing..................................ok t/Module_Pluggable/09require..................................ok t/Module_Pluggable/10innerpack................................ok t/Module_Pluggable/10innerpack_inner..........................ok t/Module_Pluggable/10innerpack_noinner........................ok t/Module_Pluggable/10innerpack_override.......................ok t/Module_Pluggable/11usetwice.................................ok t/Module_Pluggable/12only.....................................ok t/Module_Pluggable/12onlyarray................................ok t/Module_Pluggable/12onlyregex................................ok t/Module_Pluggable/13except...................................ok t/Module_Pluggable/13exceptarray..............................ok t/Module_Pluggable/13exceptregex..............................ok t/Module_Pluggable/14package..................................ok t/Module_Pluggable/15topicsafe................................ok t/Module_Pluggable/16different_extension......................ok t/Module_Pluggable/17devel_inner_package......................ok t/Module_Pluggable/18skipped_package..........................ok t/Module_Pluggable/19can_ok_clobber...........................ok t/Module_Pluggable/20dodgy_files..............................ok t/pod/emptycmd................................................ok t/pod/find....................................................ok t/pod/for.....................................................ok t/pod/headings................................................ok t/pod/include.................................................ok t/pod/included................................................ok t/pod/lref....................................................ok t/pod/multiline_items.........................................ok t/pod/nested_items............................................ok t/pod/nested_seqs.............................................ok t/pod/oneline_cmds............................................ok t/pod/plainer.................................................ok t/pod/pod2usage...............................................ok t/pod/pod2usage2..............................................ok t/pod/poderrs.................................................ok t/pod/podselect...............................................ok t/pod/special_seqs............................................ok t/pod/twice...................................................ok t/x2p/s2p.....................................................ok All tests successful. u=4.27 s=7.52 cu=453.84 cs=186.80 scripts=1389 tests=188371 [1:11pm]tamar/usr/ports/lang/perl5.10 # From mexas at bristol.ac.uk Sun Jul 12 20:32:39 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Jul 12 20:32:46 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <4A5A4793.2030009@gmail.com> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> <20090712175020.GA93782@mech-cluster238.men.bris.ac.uk> <4A5A4793.2030009@gmail.com> Message-ID: <20090712203232.GA96904@mech-cluster238.men.bris.ac.uk> On Sun, Jul 12, 2009 at 02:29:07PM -0600, ToyoRunner wrote: > Anton Shterenlikht wrote: > > On Sun, Jul 12, 2009 at 12:06:13PM +0100, Anton Shterenlikht wrote: > > > >> On Sun, Jul 12, 2009 at 11:38:38AM +0100, Anton Shterenlikht wrote: > >> > >>> On FreeBSD 8.0-BETA1 ia64 with 2 CPUs > >>> port lang/perl5.10 built with threads > >>> fails thread-related tests (full details below) > >>> > >>> Failed 8 tests out of 1433, 99.44% okay. > >>> ../ext/threads/shared/t/cond.t > >>> ../ext/threads/shared/t/stress.t > >>> ../ext/threads/t/blocks.t > >>> ../ext/threads/t/exit.t > >>> ../ext/threads/t/free.t > >>> ../ext/threads/t/free2.t > >>> ../ext/threads/t/join.t > >>> op/filetest.t > >>> > >>> The error message typically is > >>> > >>> (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... > >>> > >> some more stats; > >> doing ./perl harness in the `t' directory gives: > >> > >> Failed Test Stat Wstat Total Fail List of Failed > >> ------------------------------------------------------------------------------- > >> ../ext/threads/shared/t/cond.t 29 7424 32 36 15-32 > >> ../ext/threads/shared/t/stress.t 29 7424 1 0 ?? > >> ../ext/threads/t/blocks.t 5 8 1-3 5-9 > >> ../ext/threads/t/exit.t 29 7424 18 1 5 > >> ../ext/threads/t/free.t 0 139 29 56 2-29 > >> ../ext/threads/t/free2.t 29 7424 78 106 26-78 > >> ../ext/threads/t/join.t 29 7424 20 4 19-20 > >> op/filetest.t 13 3328 24 38 6-24 > >> (1 subtest UNEXPECTEDLY SUCCEEDED), 29 tests and 790 subtests skipped. > >> Failed 8/1465 test scripts. 120/190245 subtests failed. > >> Files=1465, Tests=190245, 1484 wallclock secs (977.48 cusr + 198.20 csys = 1175. > >> 69 CPU) > >> Failed 8/1465 test programs. 120/190245 subtests failed. > >> > > > > twice my system froze and required cold reboot at this point during tests: > > > > ../ext/threads/t/libc............................................ok > > ../ext/threads/t/list............................................ok > > ../ext/threads/t/problems........................................ok > > ../ext/threads/t/stack...........................................ok > > ../ext/threads/t/stack_env.......................................ok > > ../ext/threads/t/state...........................................ok 45/59panic: > > MUTEX_DESTROY (16) [shared.xs:192]. > > ../ext/threads/t/state...........................................dubious > > Test returned status 29 (wstat 7424, 0x1d00) > > DIED. FAILED tests 54-59 > > Failed 6/59 tests, 89.83% okay > > ../ext/threads/t/stress_cv.......................................ok > > ../ext/threads/t/stress_re.......................................ok > > ../ext/threads/t/stress_string...................................ok > > ../ext/threads/t/thread..........................................ok 13/34 > > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/threads/t/thre > > ad.t line 118. > > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ../ext/thread > > s/t/thread.t line 169. > > ../ext/threads/t/thread..........................................ok > > ../ext/Time/HiRes/t/HiRes........................................ok 11/38 > > > > > > then freeze. I had to cycle power via MP. > > Importantly, it froze twice at the same test. > > > > Can somebody with rx26xx verify this: > > > > #cd /usr/ports/lang/perl5.10 > > #make test > > > > many thanks > > anton > > > > > Running make test produced no errors. > > t/Module_Pluggable/01use......................................ok > t/Module_Pluggable/02alsoworks................................ok > t/Module_Pluggable/02works....................................ok > t/Module_Pluggable/02works_taint..............................ok > t/Module_Pluggable/03diffname.................................ok > t/Module_Pluggable/04acmedir..................................ok > t/Module_Pluggable/04acmedir_single...........................ok > t/Module_Pluggable/04acmepath.................................ok > t/Module_Pluggable/04acmepath_single..........................ok > t/Module_Pluggable/05postpath.................................ok > t/Module_Pluggable/06multipath................................ok > t/Module_Pluggable/07instantiate..............................ok > t/Module_Pluggable/08nothing..................................ok > t/Module_Pluggable/09require..................................ok > t/Module_Pluggable/10innerpack................................ok > t/Module_Pluggable/10innerpack_inner..........................ok > t/Module_Pluggable/10innerpack_noinner........................ok > t/Module_Pluggable/10innerpack_override.......................ok > t/Module_Pluggable/11usetwice.................................ok > t/Module_Pluggable/12only.....................................ok > t/Module_Pluggable/12onlyarray................................ok > t/Module_Pluggable/12onlyregex................................ok > t/Module_Pluggable/13except...................................ok > t/Module_Pluggable/13exceptarray..............................ok > t/Module_Pluggable/13exceptregex..............................ok > t/Module_Pluggable/14package..................................ok > t/Module_Pluggable/15topicsafe................................ok > t/Module_Pluggable/16different_extension......................ok > t/Module_Pluggable/17devel_inner_package......................ok > t/Module_Pluggable/18skipped_package..........................ok > t/Module_Pluggable/19can_ok_clobber...........................ok > t/Module_Pluggable/20dodgy_files..............................ok > t/pod/emptycmd................................................ok > t/pod/find....................................................ok > t/pod/for.....................................................ok > t/pod/headings................................................ok > t/pod/include.................................................ok > t/pod/included................................................ok > t/pod/lref....................................................ok > t/pod/multiline_items.........................................ok > t/pod/nested_items............................................ok > t/pod/nested_seqs.............................................ok > t/pod/oneline_cmds............................................ok > t/pod/plainer.................................................ok > t/pod/pod2usage...............................................ok > t/pod/pod2usage2..............................................ok > t/pod/poderrs.................................................ok > t/pod/podselect...............................................ok > t/pod/special_seqs............................................ok > t/pod/twice...................................................ok > t/x2p/s2p.....................................................ok > All tests successful. > u=4.27 s=7.52 cu=453.84 cs=186.80 scripts=1389 tests=188371 > [1:11pm]tamar/usr/ports/lang/perl5.10 # have you built perl-threaded? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 13 08:27:28 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 13 08:27:35 2009 Subject: LOR #269 Message-ID: <20090713082722.GA94038@mech-cluster238.men.bris.ac.uk> FreeBSD 8.0-BETA1 ia64 Looks like LOR #269, with different line numbers: lock order reversal: 1st 0xa00000001e599c20 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe0000000106de7b0 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self(0xe000000004135d60) at db_trace_self+0x20 db_trace_self_wrapper(0xe00000000443add0) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe0000000049da960, 0xe0000000044639d0) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004888610, 0xe000000004465270, 0x999, 0xe0000000048a9da8) at _witness_debugger+0x60 witness_checkorder(0xe0000000106de7b0, 0x9, 0xffffffffffffffff, 0x319, 0xe000000010a06298) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000106de7b0, 0x80400, 0xe000000010a06298, 0xe0000000048a9e10, 0x50, 0x33, 0xe0000000048a9da8, 0x319) at __lockmgr_args+0xe60 ffs_lock(0xa000000032b3cdd0, 0xe0000000106de7b0, 0x80400) at ffs_lock+0x130 VOP_LOCK1_APV(0xe0000000049ac600, 0xa000000032b3cdb0, 0xe00000000488e978) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe000000010a061d8, 0x80400, 0xe0000000048a9da8, 0x319, 0xe000000010a061e8, 0xa000000032b3cdd0, 0xa000000032b3cdc8, 0xa000000032b3cdc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000106fb780, 0xa000000032b3cfc8, 0xa000000032b3ce08, 0xe0000000107b4000, 0xe00000001094a700, 0x0, 0xe000000010693030, 0xe00000001094a900) at ffs_snapshot+0x3f50 ffs_mount(0x0, 0xe0000000048abc50, 0xa000000032b3d100, 0xa000000032b3d100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe00000001094a000) at vfs_donmount+0x1d80 nmount(0xe00000001064d270, 0xa000000032b3d4e8, 0x0, 0xe0000000048283e0) at nmount+0xf0 syscall(0xa000000032b3d400, 0x17a, 0x201000, 0xe00000001064d270, 0xe0000000107c3120, 0xe000000004986b90, 0x17a, 0xa000000032b3d4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From bugmaster at FreeBSD.org Mon Jul 13 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:08:36 2009 Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org Message-ID: <200907131106.n6DB6uIC040634@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ia64/120315 ia64 Backing store switch in exception_save_restart leaves o ia64/113102 ia64 [MCA] Multiple records can have the same sequence numb o ia64/86218 ia64 Mozilla / Firefox: regxpcom or regchrome broken on ia6 3 problems total. From mexas at bristol.ac.uk Mon Jul 13 14:27:47 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 13 14:27:54 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <4A5A4793.2030009@gmail.com> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> <20090712110613.GA93647@mech-cluster238.men.bris.ac.uk> <20090712175020.GA93782@mech-cluster238.men.bris.ac.uk> <4A5A4793.2030009@gmail.com> Message-ID: <20090713142740.GA75696@mech-cluster238.men.bris.ac.uk> On Sun, Jul 12, 2009 at 02:29:07PM -0600, ToyoRunner wrote: > Anton Shterenlikht wrote: > > On Sun, Jul 12, 2009 at 12:06:13PM +0100, Anton Shterenlikht wrote: > > > >> On Sun, Jul 12, 2009 at 11:38:38AM +0100, Anton Shterenlikht wrote: > >> > >>> On FreeBSD 8.0-BETA1 ia64 with 2 CPUs > >>> port lang/perl5.10 built with threads > >>> fails thread-related tests (full details below) > >>> > >>> Failed 8 tests out of 1433, 99.44% okay. > >>> ../ext/threads/shared/t/cond.t > >>> ../ext/threads/shared/t/stress.t > >>> ../ext/threads/t/blocks.t > >>> ../ext/threads/t/exit.t > >>> ../ext/threads/t/free.t > >>> ../ext/threads/t/free2.t > >>> ../ext/threads/t/join.t > >>> op/filetest.t more testing on FreeBSD 8.0-BETA1 ia64 I've rebuilt world and kernel several times with /etc/make.conf having only NO_MODULES=yes. Except for several LORs on boot and shutdown, all went well. I reinstalled perl-threaded with these options: # make showconfig ===> The following configuration options are available for perl-threaded-5.10.0_ 4: DEBUGGING=on "Build with debugging support" GDBM=off "Build GDBM_File extension" PERL_MALLOC=off "Use Perl malloc" PERL_64BITINT=off "Use 64 bit integers (on i386)" THREADS=on "Build threaded perl" MULTIPLICITY=off "Use multiplicity" SUIDPERL=off "Build set-user-id suidperl binary" SITECUSTOMIZE=off "Run-time customization of @INC" USE_PERL=on "Rewrite links in /usr/bin" ===> Use 'make config' to modify these settings # On make test I still get these errors, all to do with threads: Failed 7 tests out of 1433, 99.51% okay. ../ext/threads/shared/t/cond.t ../ext/threads/shared/t/stress.t ../ext/threads/t/blocks.t ../ext/threads/t/exit.t ../ext/threads/t/free.t ../ext/threads/t/free2.t ../ext/threads/t/join.t As before all errors are: (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Mon Jul 13 21:27:48 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Jul 13 21:27:56 2009 Subject: port perl-threaded-5.10.0.4 fails tests on ia64 SMP In-Reply-To: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> References: <20090712103838.GA93079@mech-cluster238.men.bris.ac.uk> Message-ID: <63995550-67D8-4AE3-B1D8-C22C88232BAF@mac.com> On Jul 12, 2009, at 3:38 AM, Anton Shterenlikht wrote: > On FreeBSD 8.0-BETA1 ia64 with 2 CPUs > port lang/perl5.10 built with threads > fails thread-related tests (full details below) > > Failed 8 tests out of 1433, 99.44% okay. > ../ext/threads/shared/t/cond.t > ../ext/threads/shared/t/stress.t > ../ext/threads/t/blocks.t > ../ext/threads/t/exit.t > ../ext/threads/t/free.t > ../ext/threads/t/free2.t > ../ext/threads/t/join.t > op/filetest.t > > The error message typically is > > (in cleanup) panic: MUTEX_DESTROY (16) [threads.xs:219] at ... > > Please advise I could reproduce this. The perl 5.8 port has the same issue. An UP i386 machine passes all tests, I still need to check if an SMP i386 passes all tests. If yes, then this definitely looks like an ia64 issue. If not, then it could be a generic issue with a threaded perl. FYI, -- Marcel Moolenaar xcllnt@mac.com From sukhjinder.hayer at hp.com Wed Jul 15 18:08:30 2009 From: sukhjinder.hayer at hp.com (Hayer, Sukhjinder) Date: Wed Jul 15 18:08:37 2009 Subject: FW: 8.0 BETA1 boot problem Message-ID: Hi, Iam trying to boot 8.0 BETA1 on the IA 64 integrity server platform and I see some Mpt0 not being able to initiliaze. Does any one have an idea as to what might be the problem. Below Is the part of the boot output with "boot_verbose=2" being set. pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: child uart0 requested type 4 for rid 0x14, but the BAR says it isuart0: mem 0x88033000-0x88033fff irq 16 at device 1.2 on pci0 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) ohci0: mem 0x88032000-0x88032fff irq 17 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x88032000 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x88031000-0x88031fff irq 18 at device 2.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x88031000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x88030000-0x880300ff irq 19 at device 2.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x88030000 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 vgapci0: port 0x1000-0x10ff mem 0x80000000-0x87ffffff,0x88020000-0x8802ffff at device 3.0 on pci0 pcib1: on acpi0 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1000, dev=0x0054, revid=0x01 domain=0, bus=1, slot=1, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0230, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x0a (2500 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0x1000, size 8, enabled map[14]: type Memory, range 64, base 0xa0470000, size 14, enabled map[1c]: type Memory, range 64, base 0xa0460000, size 16, enabled pcib1: matched entry for 1.1.INTA pcib1: slot 1 INTA hardwired to IRQ 27 found-> vendor=0x14e4, dev=0x1648, revid=0x10 domain=0, bus=1, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=29 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xa0450000, size 16, enabled pcib1: matched entry for 1.2.INTA pcib1: slot 2 INTA hardwired to IRQ 29 found-> vendor=0x14e4, dev=0x1648, revid=0x10 domain=0, bus=1, slot=2, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=b, irq=30 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xa0440000, size 16, enabled pcib1: matched entry for 1.2.INTB pcib1: slot 2 INTB hardwired to IRQ 30 mpt0: mem 0xa0470000-0xa0473fff,0xa0460000-0xa046ffff irq 27 at device 1.0 on pci1 mpt0: Lazy allocation of 0x100 bytes rid 0x10 type 4 at 0x1100 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1100 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xa0470000 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: soft reset failed: device not running mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt0: mpt_reset: failed hard reset (0:0) mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt0: mpt_reset: failed hard reset (0:1) mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt0: mpt_reset: failed hard reset (0:2) mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt0: mpt_reset: failed hard reset (0:3) mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt0: mpt_reset: failed hard reset (0:4) mpt0: soft reset failed: device not running mpt0: WARNING - Failed hard reset! Trying to initialize anyway. Thanks Sukhjinder From bugmaster at FreeBSD.org Mon Jul 20 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:08:32 2009 Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org Message-ID: <200907201106.n6KB6uST002309@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ia64/120315 ia64 Backing store switch in exception_save_restart leaves o ia64/113102 ia64 [MCA] Multiple records can have the same sequence numb o ia64/86218 ia64 Mozilla / Firefox: regxpcom or regchrome broken on ia6 3 problems total. From mexas at bristol.ac.uk Thu Jul 23 23:49:12 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 23 23:49:18 2009 Subject: FW: 8.0 BETA1 boot problem In-Reply-To: References: Message-ID: <20090723233257.GC55841@mech-cluster238.men.bris.ac.uk> On Wed, Jul 15, 2009 at 05:49:34PM +0000, Hayer, Sukhjinder wrote: > Hi, > Iam trying to boot 8.0 BETA1 on the IA 64 integrity server platform and I see some Mpt0 not being able to initiliaze. Does any one have an idea as to what might be the problem. Below > Is the part of the boot output with "boot_verbose=2" being set. > > pci0: at device 1.0 (no driver attached) > pci0: at device 1.1 (no driver attached) > pci0: child uart0 requested type 4 for rid 0x14, but the BAR says it isuart0: mem 0x88033000-0x88033fff irq 16 at device 1.2 on pci0 > uart0: [FILTER] > uart0: fast interrupt > uart0: console (9600,n,8,1) > ohci0: mem 0x88032000-0x88032fff irq 17 at device 2.0 on pci0 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x88032000 > ohci0: [MPSAFE] > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0x88031000-0x88031fff irq 18 at device 2.1 on pci0 > ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x88031000 > ohci1: [MPSAFE] > ohci1: [ITHREAD] > usbus1: on ohci1 > ehci0: mem 0x88030000-0x880300ff irq 19 at device 2.2 on pci0 > ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x88030000 > ehci0: [MPSAFE] > ehci0: [ITHREAD] > usbus2: EHCI version 1.0 > usbus2: on ehci0 > vgapci0: port 0x1000-0x10ff mem 0x80000000-0x87ffffff,0x88020000-0x8802ffff at device 3.0 on pci0 > pcib1: on acpi0 > pci1: on pcib1 > pci1: domain=0, physical bus=1 > found-> vendor=0x1000, dev=0x0054, revid=0x01 > domain=0, bus=1, slot=1, func=0 > class=01-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0147, statreg=0x0230, cachelnsz=32 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x0a (2500 ns) > intpin=a, irq=0 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 1 message in map 0x14 > map[10]: type I/O Port, range 32, base 0x1000, size 8, enabled > map[14]: type Memory, range 64, base 0xa0470000, size 14, enabled > map[1c]: type Memory, range 64, base 0xa0460000, size 16, enabled > pcib1: matched entry for 1.1.INTA > pcib1: slot 1 INTA hardwired to IRQ 27 > found-> vendor=0x14e4, dev=0x1648, revid=0x10 > domain=0, bus=1, slot=2, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=29 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xa0450000, size 16, enabled > pcib1: matched entry for 1.2.INTA > pcib1: slot 2 INTA hardwired to IRQ 29 > found-> vendor=0x14e4, dev=0x1648, revid=0x10 > domain=0, bus=1, slot=2, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=30 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xa0440000, size 16, enabled > pcib1: matched entry for 1.2.INTB > pcib1: slot 2 INTB hardwired to IRQ 30 > mpt0: mem 0xa0470000-0xa0473fff,0xa0460000-0xa046ffff irq 27 at device 1.0 on pci1 > mpt0: Lazy allocation of 0x100 bytes rid 0x10 type 4 at 0x1100 > mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1100 > mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xa0470000 > mpt0: [MPSAFE] > mpt0: [ITHREAD] > mpt0: soft reset failed: device not running > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. > mpt0: mpt_reset: failed hard reset (0:0) > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. > mpt0: mpt_reset: failed hard reset (0:1) > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. > mpt0: mpt_reset: failed hard reset (0:2) > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. > mpt0: mpt_reset: failed hard reset (0:3) > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. > mpt0: mpt_reset: failed hard reset (0:4) > mpt0: soft reset failed: device not running > mpt0: WARNING - Failed hard reset! Trying to initialize anyway. mpt is a SCSI driver. Have you updated your firmware? Mine is SYSREV Current firmware revisions MP FW : E.03.32 BMC FW : 01.53 EFI FW : 01.22 System FW : 02.31 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From bugmaster at FreeBSD.org Mon Jul 27 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:08:38 2009 Subject: Current problem reports assigned to freebsd-ia64@FreeBSD.org Message-ID: <200907271106.n6RB6tYN018969@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ia64/120315 ia64 Backing store switch in exception_save_restart leaves o ia64/113102 ia64 [MCA] Multiple records can have the same sequence numb o ia64/86218 ia64 Mozilla / Firefox: regxpcom or regchrome broken on ia6 3 problems total. From mexas at bristol.ac.uk Mon Jul 27 21:04:36 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 27 21:04:44 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <4A6E0620.6070200@mail.zedat.fu-berlin.de> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> Message-ID: <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > Kamigishi Rei wrote: > > O. Hartmann wrote: > >> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on > >> all of our SMP boxes. Is there an issue known at the moment? If not, I > >> will prepare the kernel for whitnessing and provide more informations, > >> if you wish. > > A quick question: what is in the crash message, i.e. the backtrace? > > And what kind of crash is it - a panic() or a fatal trap? > > On the 8-core server box, I sometimes see : > > Fatal trap 12: page fault while in kernel mode > fault code = supervisor read, page not present Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes under load every so often. E.g buildworld -j8 is likely to crash the box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. If load is less heavy, e.g. fewer processes and some idle time, the problem doesn't seem to appear. I'm happy to do any further testing, if suggested. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Jul 27 21:17:57 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Jul 27 21:18:17 2009 Subject: bsdstats - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) Message-ID: <20090727211751.GA76851@mech-cluster241.men.bris.ac.uk> On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, I get this error: # /usr/local/etc/periodic/monthly/300.statistics /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? 0 : 34) == 0) failed [: 1: unexpected operator # I recall some mutex errors reported by perl-10 tests. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mel.flynn+fbsd.questions at mailing.thruhere.net Mon Jul 27 22:27:39 2009 From: mel.flynn+fbsd.questions at mailing.thruhere.net (Mel Flynn) Date: Mon Jul 27 22:27:46 2009 Subject: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) In-Reply-To: <20090727211751.GA76851@mech-cluster241.men.bris.ac.uk> References: <20090727211751.GA76851@mech-cluster241.men.bris.ac.uk> Message-ID: <200907271407.45243.mel.flynn+fbsd.questions@mailing.thruhere.net> On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: > On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, > I get this error: > > # /usr/local/etc/periodic/monthly/300.statistics > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal > error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? 0 > : 34) == 0) failed That error from bind, > [: 1: unexpected operator Is not handled gracefully in the bsdstats script. The annoyance is that ISC Bind finds it not useful to print errno, which is what you'd need to figure out why this lock can't be destroyed. It is however a programming error in bind, or a rare case of stack corruption by the kernel. If you see this error a lot or can reliably reproduce it, I'd file a PR. -- Mel From freebsd at hub.org Tue Jul 28 02:50:40 2009 From: freebsd at hub.org (Marc G. Fournier) Date: Tue Jul 28 02:50:52 2009 Subject: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) In-Reply-To: <200907271407.45243.mel.flynn+fbsd.questions@mailing.thruhere.net> References: <20090727211751.GA76851@mech-cluster241.men.bris.ac.uk> <200907271407.45243.mel.flynn+fbsd.questions@mailing.thruhere.net> Message-ID: <45184C2B17C02813336AB862@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn wrote: > On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: >> On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, >> I get this error: >> >> # /usr/local/etc/periodic/monthly/300.statistics >> /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal >> error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? 0 >> : 34) == 0) failed > > That error from bind, > >> [: 1: unexpected operator > > Is not handled gracefully in the bsdstats script. Is there something I can do to improve the script to handle it better? - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpuY+UACgkQ4QvfyHIvDvOquwCdGpyNjkbx2e/jt9TB48RX6JrD mJEAoL+l0a5UI3xCX/2/F+MJB5hPgIR/ =uH7U -----END PGP SIGNATURE----- From mexas at bristol.ac.uk Tue Jul 28 10:35:53 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 28 10:36:05 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> Message-ID: <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: > On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > > Kamigishi Rei wrote: > > > O. Hartmann wrote: > > >> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on > > >> all of our SMP boxes. Is there an issue known at the moment? If not, I > > >> will prepare the kernel for whitnessing and provide more informations, > > >> if you wish. > > > A quick question: what is in the crash message, i.e. the backtrace? > > > And what kind of crash is it - a panic() or a fatal trap? > > > > On the 8-core server box, I sometimes see : > > > > Fatal trap 12: page fault while in kernel mode > > fault code = supervisor read, page not present > > Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and > later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes > under load every so often. E.g buildworld -j8 is likely to crash the > box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. > > If load is less heavy, e.g. fewer processes and some idle time, the > problem doesn't seem to appear. > > I'm happy to do any further testing, if suggested. my ia64 8.0-beta1 SMP box died again on make -j8 buildworld with no panic or log entries. Is it possible that some kernel variable needs to be increased? E.g. kern.maxproc, kern.maxfiles, etc. Or perhaps I'm talking complete rubbish.. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Tue Jul 28 14:46:01 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 28 14:46:17 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <4A6F09BA.2020703@zedat.fu-berlin.de> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> Message-ID: <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: > Anton Shterenlikht wrote: > > On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: > >> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > >>> Kamigishi Rei wrote: > >>>> O. Hartmann wrote: > >>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on > >>>>> all of our SMP boxes. Is there an issue known at the moment? If not, I > >>>>> will prepare the kernel for whitnessing and provide more informations, > >>>>> if you wish. > >>>> A quick question: what is in the crash message, i.e. the backtrace? > >>>> And what kind of crash is it - a panic() or a fatal trap? > >>> On the 8-core server box, I sometimes see : > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> fault code = supervisor read, page not present > >> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and > >> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes > >> under load every so often. E.g buildworld -j8 is likely to crash the > >> box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. > >> > >> If load is less heavy, e.g. fewer processes and some idle time, the > >> problem doesn't seem to appear. > >> > >> I'm happy to do any further testing, if suggested. > > > > my ia64 8.0-beta1 SMP box died again on > > make -j8 buildworld > > with no panic or log entries. > > > > Is it possible that some kernel variable needs to > > be increased? E.g. kern.maxproc, kern.maxfiles, etc. > > Or perhaps I'm talking complete rubbish.. > > > > I suggest you try again with a UP kernel - a suggestion from a > kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they are > really slowish although they have modern Intel C2D/Penryn cores. I need SMP for OpenMP codes. It's a shame if SMP is buggy, but I guess all is down to small user base.. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From ohartman at zedat.fu-berlin.de Tue Jul 28 14:48:32 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Jul 28 14:48:38 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> Message-ID: <4A6F09BA.2020703@zedat.fu-berlin.de> Anton Shterenlikht wrote: > On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: >> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: >>> Kamigishi Rei wrote: >>>> O. Hartmann wrote: >>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on >>>>> all of our SMP boxes. Is there an issue known at the moment? If not, I >>>>> will prepare the kernel for whitnessing and provide more informations, >>>>> if you wish. >>>> A quick question: what is in the crash message, i.e. the backtrace? >>>> And what kind of crash is it - a panic() or a fatal trap? >>> On the 8-core server box, I sometimes see : >>> >>> Fatal trap 12: page fault while in kernel mode >>> fault code = supervisor read, page not present >> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and >> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes >> under load every so often. E.g buildworld -j8 is likely to crash the >> box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. >> >> If load is less heavy, e.g. fewer processes and some idle time, the >> problem doesn't seem to appear. >> >> I'm happy to do any further testing, if suggested. > > my ia64 8.0-beta1 SMP box died again on > make -j8 buildworld > with no panic or log entries. > > Is it possible that some kernel variable needs to > be increased? E.g. kern.maxproc, kern.maxfiles, etc. > Or perhaps I'm talking complete rubbish.. > > I suggest you try again with a UP kernel - a suggestion from a kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they are really slowish although they have modern Intel C2D/Penryn cores. Regards, Oliver From mexas at bristol.ac.uk Tue Jul 28 14:49:06 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 28 14:49:19 2009 Subject: 8.0-beta2 buildworld fails Message-ID: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> On ia64 8.0-beta1 SMP, I get buildworld failures at random points, and with very terse error message, e.g.: [skip] cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/ usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texi nfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -o texindex texindex.o /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/ texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../ ../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/ texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../ ../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo. txi texinfo.texi gzip -cn info.info > info.info.gz makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/ texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 1 error *** Error code 2 Any advice? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Tue Jul 28 14:54:00 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Tue Jul 28 14:54:10 2009 Subject: 8.0-beta2 buildworld fails In-Reply-To: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> References: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> Message-ID: <4A6F1105.4000304@haruhiism.net> Anton Shterenlikht wrote: > On ia64 8.0-beta1 SMP, I get buildworld failures at random points, > and with very terse error message, e.g.: > > 1 error > *** Error code 2 > Any advice? > As it was mentioned here multiple times, remove -jX from your make buildworld command as the output from other threads hides the error. You can use "make -DNO_CLEAN buildworld" to skip rebuild of everything there is, and get right to the error. -- Kamigishi Rei KREI-RIPE From xcllnt at mac.com Tue Jul 28 15:33:13 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jul 28 15:33:20 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 28, 2009, at 3:35 AM, Anton Shterenlikht wrote: > On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: >> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: >>> Kamigishi Rei wrote: >>>> O. Hartmann wrote: >>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under >>>>> load on >>>>> all of our SMP boxes. Is there an issue known at the moment? If >>>>> not, I >>>>> will prepare the kernel for whitnessing and provide more >>>>> informations, >>>>> if you wish. >>>> A quick question: what is in the crash message, i.e. the backtrace? >>>> And what kind of crash is it - a panic() or a fatal trap? >>> >>> On the 8-core server box, I sometimes see : >>> >>> Fatal trap 12: page fault while in kernel mode >>> fault code = supervisor read, page not present >> >> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current >> and >> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes >> under load every so often. E.g buildworld -j8 is likely to crash the >> box. No messages, just a sudden freeze, no backtrace or panic, and >> then reboot. >> >> If load is less heavy, e.g. fewer processes and some idle time, the >> problem doesn't seem to appear. >> >> I'm happy to do any further testing, if suggested. > > my ia64 8.0-beta1 SMP box died again on > make -j8 buildworld > with no panic or log entries. Do you have MCA records? > > Is it possible that some kernel variable needs to > be increased? E.g. kern.maxproc, kern.maxfiles, etc. No need. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Tue Jul 28 15:35:24 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jul 28 15:35:36 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 28, 2009, at 7:45 AM, Anton Shterenlikht wrote: > On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: >> Anton Shterenlikht wrote: >>> On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: >>>> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: >>>>> Kamigishi Rei wrote: >>>>>> O. Hartmann wrote: >>>>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under >>>>>>> load on >>>>>>> all of our SMP boxes. Is there an issue known at the moment? >>>>>>> If not, I >>>>>>> will prepare the kernel for whitnessing and provide more >>>>>>> informations, >>>>>>> if you wish. >>>>>> A quick question: what is in the crash message, i.e. the >>>>>> backtrace? >>>>>> And what kind of crash is it - a panic() or a fatal trap? >>>>> On the 8-core server box, I sometimes see : >>>>> >>>>> Fatal trap 12: page fault while in kernel mode >>>>> fault code = supervisor read, page not present >>>> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0- >>>> current and >>>> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting >>>> crashes >>>> under load every so often. E.g buildworld -j8 is likely to crash >>>> the >>>> box. No messages, just a sudden freeze, no backtrace or panic, >>>> and then reboot. >>>> >>>> If load is less heavy, e.g. fewer processes and some idle time, the >>>> problem doesn't seem to appear. >>>> >>>> I'm happy to do any further testing, if suggested. >>> >>> my ia64 8.0-beta1 SMP box died again on >>> make -j8 buildworld >>> with no panic or log entries. >>> >>> Is it possible that some kernel variable needs to >>> be increased? E.g. kern.maxproc, kern.maxfiles, etc. >>> Or perhaps I'm talking complete rubbish.. >>> >> >> I suggest you try again with a UP kernel - a suggestion from a >> kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they >> are >> really slowish although they have modern Intel C2D/Penryn cores. > > I need SMP for OpenMP codes. It's a shame if SMP is buggy, but > I guess all is down to small user base.. I have no problems with SMP. If you don't have a panic, then you may have a hardware problem. Check for MCA records. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Tue Jul 28 15:37:10 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jul 28 15:37:22 2009 Subject: 8.0-beta2 buildworld fails In-Reply-To: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> References: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 28, 2009, at 7:48 AM, Anton Shterenlikht wrote: > On ia64 8.0-beta1 SMP, I get buildworld failures at random points, > and with very terse error message, e.g.: > > [skip] > > cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/ > usr/src/gnu/ > usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/ > usr.bin/texi > nfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -o > texindex texindex.o > /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a > ===> gnu/usr.bin/texinfo/doc (all) > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/ > gnu/usr.bin/ > texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/ > texinfo/doc/../ > ../../../contrib/texinfo/doc/info.texi -o info.info > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/ > gnu/usr.bin/ > texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/ > texinfo/doc/../ > ../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info > ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/ > doc/texinfo. > txi texinfo.texi > gzip -cn info.info > info.info.gz > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/ > gnu/usr.bin/ > texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info > gzip -cn info-stnd.info > info-stnd.info.gz > gzip -cn texinfo.info > texinfo.info.gz > 1 error > *** Error code 2 > > Any advice? I would replace your DDR/memory to see if you have a bad DIMM. -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Tue Jul 28 16:13:07 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 28 16:13:14 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> Message-ID: <20090728161255.GA38375@mech-cluster241.men.bris.ac.uk> On Tue, Jul 28, 2009 at 08:34:52AM -0700, Marcel Moolenaar wrote: > > On Jul 28, 2009, at 7:45 AM, Anton Shterenlikht wrote: > > > On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: > >> Anton Shterenlikht wrote: > >>> On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: > >>>> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > >>>>> Kamigishi Rei wrote: > >>>>>> O. Hartmann wrote: > >>>>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under > >>>>>>> load on > >>>>>>> all of our SMP boxes. Is there an issue known at the moment? > >>>>>>> If not, I > >>>>>>> will prepare the kernel for whitnessing and provide more > >>>>>>> informations, > >>>>>>> if you wish. > >>>>>> A quick question: what is in the crash message, i.e. the > >>>>>> backtrace? > >>>>>> And what kind of crash is it - a panic() or a fatal trap? > >>>>> On the 8-core server box, I sometimes see : > >>>>> > >>>>> Fatal trap 12: page fault while in kernel mode > >>>>> fault code = supervisor read, page not present > >>>> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0- > >>>> current and > >>>> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting > >>>> crashes > >>>> under load every so often. E.g buildworld -j8 is likely to crash > >>>> the > >>>> box. No messages, just a sudden freeze, no backtrace or panic, > >>>> and then reboot. > >>>> > >>>> If load is less heavy, e.g. fewer processes and some idle time, the > >>>> problem doesn't seem to appear. > >>>> > >>>> I'm happy to do any further testing, if suggested. > >>> > >>> my ia64 8.0-beta1 SMP box died again on > >>> make -j8 buildworld > >>> with no panic or log entries. > >>> > >>> Is it possible that some kernel variable needs to > >>> be increased? E.g. kern.maxproc, kern.maxfiles, etc. > >>> Or perhaps I'm talking complete rubbish.. > >>> > >> > >> I suggest you try again with a UP kernel - a suggestion from a > >> kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they > >> are > >> really slowish although they have modern Intel C2D/Penryn cores. > > > > I need SMP for OpenMP codes. It's a shame if SMP is buggy, but > > I guess all is down to small user base.. > > I have no problems with SMP. If you don't have a panic, then > you may have a hardware problem. yes.. I thought of this myself. I guess I ought to check the Event Logs available from MP on rx2600. But those messages are so cryptic.. > Check for MCA records. # mca mca: no error records found # sysctl hw.mca hw.mca.last: 0 hw.mca.first: 0 hw.mca.count: 0 Faulty DIMMs, as you've suggested, would explain a lot of my problems.. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Tue Jul 28 16:48:44 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jul 28 16:48:51 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090728161255.GA38375@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <20090728161255.GA38375@mech-cluster241.men.bris.ac.uk> Message-ID: <0C915045-02B9-4E88-8FA8-B2405B8712A6@mac.com> On Jul 28, 2009, at 9:12 AM, Anton Shterenlikht wrote: > On Tue, Jul 28, 2009 at 08:34:52AM -0700, Marcel Moolenaar wrote: >> >> On Jul 28, 2009, at 7:45 AM, Anton Shterenlikht wrote: >> >>> On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: >>>> Anton Shterenlikht wrote: >>>>> On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht >>>>> wrote: >>>>>> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: >>>>>>> Kamigishi Rei wrote: >>>>>>>> O. Hartmann wrote: >>>>>>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under >>>>>>>>> load on >>>>>>>>> all of our SMP boxes. Is there an issue known at the moment? >>>>>>>>> If not, I >>>>>>>>> will prepare the kernel for whitnessing and provide more >>>>>>>>> informations, >>>>>>>>> if you wish. >>>>>>>> A quick question: what is in the crash message, i.e. the >>>>>>>> backtrace? >>>>>>>> And what kind of crash is it - a panic() or a fatal trap? >>>>>>> On the 8-core server box, I sometimes see : >>>>>>> >>>>>>> Fatal trap 12: page fault while in kernel mode >>>>>>> fault code = supervisor read, page not present >>>>>> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0- >>>>>> current and >>>>>> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting >>>>>> crashes >>>>>> under load every so often. E.g buildworld -j8 is likely to crash >>>>>> the >>>>>> box. No messages, just a sudden freeze, no backtrace or panic, >>>>>> and then reboot. >>>>>> >>>>>> If load is less heavy, e.g. fewer processes and some idle time, >>>>>> the >>>>>> problem doesn't seem to appear. >>>>>> >>>>>> I'm happy to do any further testing, if suggested. >>>>> >>>>> my ia64 8.0-beta1 SMP box died again on >>>>> make -j8 buildworld >>>>> with no panic or log entries. >>>>> >>>>> Is it possible that some kernel variable needs to >>>>> be increased? E.g. kern.maxproc, kern.maxfiles, etc. >>>>> Or perhaps I'm talking complete rubbish.. >>>>> >>>> >>>> I suggest you try again with a UP kernel - a suggestion from a >>>> kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they >>>> are >>>> really slowish although they have modern Intel C2D/Penryn cores. >>> >>> I need SMP for OpenMP codes. It's a shame if SMP is buggy, but >>> I guess all is down to small user base.. >> >> I have no problems with SMP. If you don't have a panic, then >> you may have a hardware problem. > > yes.. I thought of this myself. I guess I ought to check > the Event Logs available from MP on rx2600. But those messages > are so cryptic.. The event logs are also mostly useless IMO. They fill up the log buffer and then cause warnings during the boot. I typically use the errdump command in EFI to see if there's anything fishy. > >> Check for MCA records. > > # mca > mca: no error records found > > # sysctl hw.mca > hw.mca.last: 0 > hw.mca.first: 0 > hw.mca.count: 0 Hmmmm... I don't know what to make of this yet. I've always had MCAs when there were spontaneous reboots. The lack of MCAs can point to something else than hardware... -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Tue Jul 28 18:06:32 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Jul 28 18:06:48 2009 Subject: 8.0-beta2 buildworld fails In-Reply-To: <4A6F1105.4000304@haruhiism.net> References: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> <4A6F1105.4000304@haruhiism.net> Message-ID: <20090728180625.GA39638@mech-cluster241.men.bris.ac.uk> On Tue, Jul 28, 2009 at 06:53:57PM +0400, Kamigishi Rei wrote: > Anton Shterenlikht wrote: > > On ia64 8.0-beta1 SMP, I get buildworld failures at random points, > > and with very terse error message, e.g.: > > > > 1 error > > *** Error code 2 > > Any advice? > > > As it was mentioned here multiple times, remove -jX from your make > buildworld command as the output from other threads hides the error. > You can use "make -DNO_CLEAN buildworld" to skip rebuild of everything > there is, and get right to the error. thank you, this is the error message: [skip] ===> share/man/man1 (all) ===> share/man/man3 (all) ===> share/man/man4 (all) ===> share/man/man5 (all) ===> share/man/man6 (all) ===> share/man/man7 (all) ===> share/man/man8 (all) ===> share/man/man9 (all) ===> share/me (all) ===> share/misc (all) ===> share/mk (all) ===> share/mklocale (all) mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src am_ET.UTF-8.out: Inappropriate ioctl for device *** Error code 1 Stop in /usr/src/share/mklocale. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Tue Jul 28 18:32:08 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jul 28 18:32:20 2009 Subject: 8.0-beta2 buildworld fails In-Reply-To: <20090728180625.GA39638@mech-cluster241.men.bris.ac.uk> References: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> <4A6F1105.4000304@haruhiism.net> <20090728180625.GA39638@mech-cluster241.men.bris.ac.uk> Message-ID: <0C407EE8-41CD-4D26-A7F4-0A3743ABE11B@mac.com> On Jul 28, 2009, at 11:06 AM, Anton Shterenlikht wrote: > On Tue, Jul 28, 2009 at 06:53:57PM +0400, Kamigishi Rei wrote: >> Anton Shterenlikht wrote: >>> On ia64 8.0-beta1 SMP, I get buildworld failures at random points, >>> and with very terse error message, e.g.: >>> >>> 1 error >>> *** Error code 2 >>> Any advice? >>> >> As it was mentioned here multiple times, remove -jX from your make >> buildworld command as the output from other threads hides the error. >> You can use "make -DNO_CLEAN buildworld" to skip rebuild of >> everything >> there is, and get right to the error. > > thank you, this is the error message: > > [skip] > > ===> share/man/man1 (all) > ===> share/man/man3 (all) > ===> share/man/man4 (all) > ===> share/man/man5 (all) > ===> share/man/man6 (all) > ===> share/man/man7 (all) > ===> share/man/man8 (all) > ===> share/man/man9 (all) > ===> share/me (all) > ===> share/misc (all) > ===> share/mk (all) > ===> share/mklocale (all) > mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src > am_ET.UTF-8.out: Inappropriate ioctl for device > *** Error code 1 This is a known issue. I forgot how to fix it, though... -- Marcel Moolenaar xcllnt@mac.com From serenity at exscape.org Tue Jul 28 18:36:21 2009 From: serenity at exscape.org (Thomas Backman) Date: Tue Jul 28 18:36:27 2009 Subject: 8.0-beta2 buildworld fails In-Reply-To: <20090728180625.GA39638@mech-cluster241.men.bris.ac.uk> References: <20090728144856.GA75540@mech-cluster241.men.bris.ac.uk> <4A6F1105.4000304@haruhiism.net> <20090728180625.GA39638@mech-cluster241.men.bris.ac.uk> Message-ID: <50B42ED9-E367-48B4-9923-19C57F26413E@exscape.org> On Jul 28, 2009, at 20:06, Anton Shterenlikht wrote: > > mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src > am_ET.UTF-8.out: Inappropriate ioctl for device > *** Error code 1 Have a look at the archives, this comes up about once a day. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/thread.html Short version: rebuild mklocale manually (cd /usr/src/usr.bin/ mklocale; make clean; make; make install), then rebuild world. Regards, Thomas From mexas at bristol.ac.uk Wed Jul 29 17:24:40 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 29 17:24:53 2009 Subject: virtually no free memory left on buildworld Message-ID: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> I just installed new 4GB RAM in ia64 rx2600 box. On make -j8 buildworld I see with "top -PISu": last pid: 69791; load averages: 8.42, 8.44, 8.59 up 0+02:04:49 18:18:17 154 processes: 11 running, 125 sleeping, 18 waiting CPU 0: 88.8% user, 0.0% nice, 11.0% system, 0.1% interrupt, 0.0% idle CPU 1: 92.5% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle Mem: 856M Active, 2414M Inact, 492M Wired, 136M Cache, 417M Buf, 17M Free Swap: 2048M Total, 2048M Free PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 63039 0 1 102 0 455M 452M RUN 1 3:14 31.49% cc1 69612 0 1 101 0 71760K 69288K RUN 1 0:06 25.88% cc1 69449 0 1 101 0 103M 101M RUN 0 0:11 24.46% cc1 69437 0 1 101 0 115M 113M RUN 0 0:11 23.88% cc1 69626 0 1 100 0 66688K 64760K RUN 0 0:05 20.36% cc1 69774 0 1 96 0 23072K 21336K RUN 0 0:00 4.69% cc1 69775 0 1 70 0 4296K 2984K piperd 0 0:00 0.20% as 69772 0 1 76 0 6280K 2896K wait 1 0:00 0.10% sh 69773 0 1 76 0 2248K 968K wait 1 0:00 0.10% cc 69784 0 1 96 0 19104K 16872K CPU1 1 0:00 0.00% cc1 69785 0 1 76 0 4296K 2968K piperd 1 0:00 0.00% as Is it normal that there is virtually no free memory left, while there are 2GB of inactive memory? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mel.flynn+fbsd.current at mailing.thruhere.net Wed Jul 29 17:52:40 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Jul 29 17:55:36 2009 Subject: virtually no free memory left on buildworld In-Reply-To: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> References: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> Message-ID: <200907290935.02504.mel.flynn+fbsd.current@mailing.thruhere.net> On Wednesday 29 July 2009 09:24:31 Anton Shterenlikht wrote: > I just installed new 4GB RAM in ia64 rx2600 box. > On make -j8 buildworld I see with "top -PISu": > > > last pid: 69791; load averages: 8.42, 8.44, 8.59 up 0+02:04:49 > 18:18:17 154 processes: 11 running, 125 sleeping, 18 waiting > CPU 0: 88.8% user, 0.0% nice, 11.0% system, 0.1% interrupt, 0.0% idle > CPU 1: 92.5% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle > Mem: 856M Active, 2414M Inact, 492M Wired, 136M Cache, 417M Buf, 17M Free > Swap: 2048M Total, 2048M Free Good, 2G of filesystem information cached and no swap used. Think of free memory as wasted memory. -- Mel From mexas at bristol.ac.uk Wed Jul 29 17:53:07 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 29 17:55:47 2009 Subject: virtually no free memory left on buildworld In-Reply-To: <200907290935.02504.mel.flynn+fbsd.current@mailing.thruhere.net> References: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> <200907290935.02504.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <20090729175301.GA87838@mech-cluster241.men.bris.ac.uk> On Wed, Jul 29, 2009 at 09:35:02AM -0800, Mel Flynn wrote: > On Wednesday 29 July 2009 09:24:31 Anton Shterenlikht wrote: > > I just installed new 4GB RAM in ia64 rx2600 box. > > On make -j8 buildworld I see with "top -PISu": > > > > > > last pid: 69791; load averages: 8.42, 8.44, 8.59 up 0+02:04:49 > > 18:18:17 154 processes: 11 running, 125 sleeping, 18 waiting > > CPU 0: 88.8% user, 0.0% nice, 11.0% system, 0.1% interrupt, 0.0% idle > > CPU 1: 92.5% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle > > Mem: 856M Active, 2414M Inact, 492M Wired, 136M Cache, 417M Buf, 17M Free > > Swap: 2048M Total, 2048M Free > > Good, 2G of filesystem information cached and no swap used. Think of free > memory as wasted memory. ok, so I completely misunderstood free and inactive. Where can I read more on this (active, inactive, wired, cashe, buf, free)? The top man page doesn't explain these memory states. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Wed Jul 29 18:24:23 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Jul 29 18:24:30 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <0C915045-02B9-4E88-8FA8-B2405B8712A6@mac.com> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <20090728161255.GA38375@mech-cluster241.men.bris.ac.uk> <0C915045-02B9-4E88-8FA8-B2405B8712A6@mac.com> Message-ID: <20090729182417.GA935@mech-cluster241.men.bris.ac.uk> On Tue, Jul 28, 2009 at 09:48:39AM -0700, Marcel Moolenaar wrote: > > On Jul 28, 2009, at 9:12 AM, Anton Shterenlikht wrote: > > >On Tue, Jul 28, 2009 at 08:34:52AM -0700, Marcel Moolenaar wrote: > >> > >>On Jul 28, 2009, at 7:45 AM, Anton Shterenlikht wrote: > >> > >>>On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: > >>>>Anton Shterenlikht wrote: > >>>>>On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton > >>>>>Shterenlikht wrote: > >>>>>>On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > >>>>>>>Kamigishi Rei wrote: > >>>>>>>>O. Hartmann wrote: > >>>>>>>>>I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under > >>>>>>>>>load on > >>>>>>>>>all of our SMP boxes. Is there an issue known at the moment? > >>>>>>>>>If not, I > >>>>>>>>>will prepare the kernel for whitnessing and provide more > >>>>>>>>>informations, > >>>>>>>>>if you wish. > >>>>>>>>A quick question: what is in the crash message, i.e. the > >>>>>>>>backtrace? > >>>>>>>>And what kind of crash is it - a panic() or a fatal trap? > >>>>>>>On the 8-core server box, I sometimes see : > >>>>>>> > >>>>>>>Fatal trap 12: page fault while in kernel mode > >>>>>>>fault code = supervisor read, page not present > >>>>>>Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0- > >>>>>>current and > >>>>>>later with 8.0-beta1 (I havent' built beta2 yet) I'm getting > >>>>>>crashes > >>>>>>under load every so often. E.g buildworld -j8 is likely to crash > >>>>>>the > >>>>>>box. No messages, just a sudden freeze, no backtrace or panic, > >>>>>>and then reboot. > >>>>>> > >>>>>>If load is less heavy, e.g. fewer processes and some > >>>>>>idle time, the > >>>>>>problem doesn't seem to appear. > >>>>>> > >>>>>>I'm happy to do any further testing, if suggested. > >>>>> > >>>>>my ia64 8.0-beta1 SMP box died again on > >>>>>make -j8 buildworld > >>>>>with no panic or log entries. > >>>>> > >>>>>Is it possible that some kernel variable needs to > >>>>>be increased? E.g. kern.maxproc, kern.maxfiles, etc. > >>>>>Or perhaps I'm talking complete rubbish.. > >>>>> > >>>> > >>>>I suggest you try again with a UP kernel - a suggestion from a > >>>>kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they > >>>>are > >>>>really slowish although they have modern Intel C2D/Penryn cores. > >>> > >>>I need SMP for OpenMP codes. It's a shame if SMP is buggy, but > >>>I guess all is down to small user base.. > >> > >>I have no problems with SMP. If you don't have a panic, then > >>you may have a hardware problem. > > > >yes.. I thought of this myself. I guess I ought to check > >the Event Logs available from MP on rx2600. But those messages > >are so cryptic.. > > The event logs are also mostly useless IMO. They fill > up the log buffer and then cause warnings during the > boot. I typically use the errdump command in EFI to > see if there's anything fishy. I had a look at errdump, but the output is cryptic for me as well. errdump mca, errdump init had some lines which appeared to be errors, but nothing about memory, at least nothing obvious to me. > > > >>Check for MCA records. > > > ># mca > >mca: no error records found > > > ># sysctl hw.mca > >hw.mca.last: 0 > >hw.mca.first: 0 > >hw.mca.count: 0 > > Hmmmm... I don't know what to make of this yet. I've > always had MCAs when there were spontaneous reboots. > The lack of MCAs can point to something else than > hardware... I installed new 4GB memory and got to beta2 with make -j8 buildworld, so perhaps it was bad memory.. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From julian at elischer.org Wed Jul 29 18:26:36 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Jul 29 18:26:43 2009 Subject: virtually no free memory left on buildworld In-Reply-To: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> References: <20090729172431.GA69866@mech-cluster241.men.bris.ac.uk> Message-ID: <4A7091CE.9000608@elischer.org> Anton Shterenlikht wrote: > I just installed new 4GB RAM in ia64 rx2600 box. > On make -j8 buildworld I see with "top -PISu": > > > last pid: 69791; load averages: 8.42, 8.44, 8.59 up 0+02:04:49 18:18:17 > 154 processes: 11 running, 125 sleeping, 18 waiting > CPU 0: 88.8% user, 0.0% nice, 11.0% system, 0.1% interrupt, 0.0% idle > CPU 1: 92.5% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle > Mem: 856M Active, 2414M Inact, 492M Wired, 136M Cache, 417M Buf, 17M Free > Swap: 2048M Total, 2048M Free > > PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 63039 0 1 102 0 455M 452M RUN 1 3:14 31.49% cc1 > 69612 0 1 101 0 71760K 69288K RUN 1 0:06 25.88% cc1 > 69449 0 1 101 0 103M 101M RUN 0 0:11 24.46% cc1 > 69437 0 1 101 0 115M 113M RUN 0 0:11 23.88% cc1 > 69626 0 1 100 0 66688K 64760K RUN 0 0:05 20.36% cc1 > 69774 0 1 96 0 23072K 21336K RUN 0 0:00 4.69% cc1 > 69775 0 1 70 0 4296K 2984K piperd 0 0:00 0.20% as > 69772 0 1 76 0 6280K 2896K wait 1 0:00 0.10% sh > 69773 0 1 76 0 2248K 968K wait 1 0:00 0.10% cc > 69784 0 1 96 0 19104K 16872K CPU1 1 0:00 0.00% cc1 > 69785 0 1 76 0 4296K 2968K piperd 1 0:00 0.00% as > > > Is it normal that there is virtually no free memory left, while there > are 2GB of inactive memory? inactive memory IS free memory. It just happens to contain information that, should you want it again, can be instantly made valid again. > > many thanks > From xcllnt at mac.com Wed Jul 29 18:41:54 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Jul 29 18:41:59 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090729182417.GA935@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <20090728161255.GA38375@mech-cluster241.men.bris.ac.uk> <0C915045-02B9-4E88-8FA8-B2405B8712A6@mac.com> <20090729182417.GA935@mech-cluster241.men.bris.ac.uk> Message-ID: <6B71DFCE-CE2C-4D71-9FEE-5560104360D9@mac.com> On Jul 29, 2009, at 11:24 AM, Anton Shterenlikht wrote: >> Hmmmm... I don't know what to make of this yet. I've >> always had MCAs when there were spontaneous reboots. >> The lack of MCAs can point to something else than >> hardware... > > I installed new 4GB memory and got to beta2 with make -j8 buildworld, > so perhaps it was bad memory.. Thanks for the update. Let me know if you run into more problems... -- Marcel Moolenaar xcllnt@mac.com From info at omegaworldclass.org Wed Jul 29 21:52:55 2009 From: info at omegaworldclass.org (Customer Insights) Date: Wed Jul 29 21:53:44 2009 Subject: 'Mastering Customer Insights & Superior Marketing Strategies" Workshop 2009, 2 September @ Conrad Hotel, Bangkok Message-ID: <20090730045244.416770375@omegaworldclass.org> From gaijin.k at gmail.com Wed Jul 29 22:58:10 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Jul 29 22:58:16 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> Message-ID: <1248906855.1459.8.camel@RabbitsDen> On Tue, 2009-07-28 at 15:45 +0100, Anton Shterenlikht wrote: > On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: > > Anton Shterenlikht wrote: > > > On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: > > >> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > > >>> Kamigishi Rei wrote: > > >>>> O. Hartmann wrote: > > >>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on > > >>>>> all of our SMP boxes. Is there an issue known at the moment? If not, I > > >>>>> will prepare the kernel for whitnessing and provide more informations, > > >>>>> if you wish. > > >>>> A quick question: what is in the crash message, i.e. the backtrace? > > >>>> And what kind of crash is it - a panic() or a fatal trap? > > >>> On the 8-core server box, I sometimes see : > > >>> > > >>> Fatal trap 12: page fault while in kernel mode > > >>> fault code = supervisor read, page not present > > >> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and > > >> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes > > >> under load every so often. E.g buildworld -j8 is likely to crash the > > >> box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. > > >> > > >> If load is less heavy, e.g. fewer processes and some idle time, the > > >> problem doesn't seem to appear. > > >> > > >> I'm happy to do any further testing, if suggested. > > > > > > my ia64 8.0-beta1 SMP box died again on > > > make -j8 buildworld > > > with no panic or log entries. > > > > > > Is it possible that some kernel variable needs to > > > be increased? E.g. kern.maxproc, kern.maxfiles, etc. > > > Or perhaps I'm talking complete rubbish.. > > > > > > > I suggest you try again with a UP kernel - a suggestion from a > > kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they are > > really slowish although they have modern Intel C2D/Penryn cores. > > I need SMP for OpenMP codes. It's a shame if SMP is buggy, but > I guess all is down to small user base.. > Before you go down that path, which, IMHO, is as counterproductive as it is incorrect, could you, please, show the output of sysctl debug | grep panic and check whether output of savecore -vC makes sense to you. -- Alexandre Kovalenko (????????? ?????????) From mexas at bristol.ac.uk Thu Jul 30 07:30:47 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 07:30:54 2009 Subject: port lang/gcc44 fails to build on ia64 8.0-BETA2 Message-ID: <20090730073040.GA71538@mech-cluster241.men.bris.ac.uk> On ia64 8.0-BETA2 port lang/gcc44 build stops at: [skip] /usr/ports/lang/gcc44/work/build/./gcc/xgcc -B/usr/ports/lang/gcc44/work/build/. /gcc/ -B/usr/local/ia64-portbld-freebsd8.0/bin/ -B/usr/local/ia64-portbld-freebs d8.0/lib/ -isystem /usr/local/ia64-portbld-freebsd8.0/include -isystem /usr/loca l/ia64-portbld-freebsd8.0/sys-include -g -O2 -pipe -I/usr/local/include -fno-str ict-aliasing -O2 -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qua l -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEF AULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../.././../ gcc-4.4-20090721/libgcc -I../.././../gcc-4.4-20090721/libgcc/. -I../.././../gcc- 4.4-20090721/libgcc/../gcc -I../.././../gcc-4.4-20090721/libgcc/../include -DHA VE_CC_TLS -o emutls_s.o -MT emutls_s.o -MD -MP -MF emutls_s.dep -DSHARED -fexcep tions -c ../.././../gcc-4.4-20090721/libgcc/../gcc/emutls.c # Recursively invoke make in the GCC directory to build any # startfiles (for now). We must do this just once, passing # it all the GCC_EXTRA_PARTS as simultaneous goal targets, # so that rules which cannot execute simultaneously are properly # serialized. We indirect through T_TARGET in case any multilib # directories contain an equals sign, to prevent make from # interpreting any of the goals as variable assignments. # We must use cd && make rather than make -C, or else the stage # number will be embedded in debug information. T=`${PWDCMD-pwd}`/ \ && cd ../.././gcc \ && gmake GCC_FOR_TARGET="/usr/ports/lang/gcc44/work/build/./gcc/xgcc -B/ usr/ports/lang/gcc44/work/build/./gcc/ -B/usr/local/ia64-portbld-freebsd8.0/bin/ -B/usr/local/ia64-portbld-freebsd8.0/lib/ -isystem /usr/local/ia64-portbld-free bsd8.0/include -isystem /usr/local/ia64-portbld-freebsd8.0/sys-include" \ MULTILIB_CFLAGS="-g -O2 -pipe -I/usr/local/include -fno-strict-aliasin g" \ T=$T \ T_TARGET="${T}crtbegin.o ${T}crtbeginS.o ${T}crtend.o ${T}crtendS.o ${ T}crtfastmath.o" \ T_TARGET gmake[4]: Entering directory `/usr/ports/lang/gcc44/work/build/gcc' gmake[4]: *** No rule to make target `/usr/ports/lang/gcc44/work/build/ia64-port bld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop. gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/usr/ports/lang/gcc44/work/build/gcc' gmake[3]: *** [gcc-extra-parts] Error 2 Any advice? I know it's marked not for ia64, but it's also marked not for alpha where it builds fine, though under 6.4-stable. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Thu Jul 30 09:06:00 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 09:06:13 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <1248906855.1459.8.camel@RabbitsDen> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> Message-ID: <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> On Wed, Jul 29, 2009 at 06:34:15PM -0400, Alexandre Sunny Kovalenko wrote: > On Tue, 2009-07-28 at 15:45 +0100, Anton Shterenlikht wrote: > > On Tue, Jul 28, 2009 at 02:22:50PM +0000, O. Hartmann wrote: > > > Anton Shterenlikht wrote: > > > > On Mon, Jul 27, 2009 at 10:04:28PM +0100, Anton Shterenlikht wrote: > > > >> On Mon, Jul 27, 2009 at 09:55:12PM +0200, O. Hartmann wrote: > > > >>> Kamigishi Rei wrote: > > > >>>> O. Hartmann wrote: > > > >>>>> I have the problem of crashing FreeBSD 8.0-BETA2/amd64 under load on > > > >>>>> all of our SMP boxes. Is there an issue known at the moment? If not, I > > > >>>>> will prepare the kernel for whitnessing and provide more informations, > > > >>>>> if you wish. > > > >>>> A quick question: what is in the crash message, i.e. the backtrace? > > > >>>> And what kind of crash is it - a panic() or a fatal trap? > > > >>> On the 8-core server box, I sometimes see : > > > >>> > > > >>> Fatal trap 12: page fault while in kernel mode > > > >>> fault code = supervisor read, page not present > > > >> Not sure if it's related, but on ia64 SMP (2 cpus) with 8.0-current and > > > >> later with 8.0-beta1 (I havent' built beta2 yet) I'm getting crashes > > > >> under load every so often. E.g buildworld -j8 is likely to crash the > > > >> box. No messages, just a sudden freeze, no backtrace or panic, and then reboot. > > > >> > > > >> If load is less heavy, e.g. fewer processes and some idle time, the > > > >> problem doesn't seem to appear. > > > >> > > > >> I'm happy to do any further testing, if suggested. > > > > > > > > my ia64 8.0-beta1 SMP box died again on > > > > make -j8 buildworld > > > > with no panic or log entries. > > > > > > > > Is it possible that some kernel variable needs to > > > > be increased? E.g. kern.maxproc, kern.maxfiles, etc. > > > > Or perhaps I'm talking complete rubbish.. > > > > > > > > > > I suggest you try again with a UP kernel - a suggestion from a > > > kernel-nnob, sorry. My SMP boxes work now with UP-kernel, but they are > > > really slowish although they have modern Intel C2D/Penryn cores. > > > > I need SMP for OpenMP codes. It's a shame if SMP is buggy, but > > I guess all is down to small user base.. > > > Before you go down that path, which, IMHO, is as counterproductive as it > is incorrect, could you, please, show the output of > > sysctl debug | grep panic > sysctl debug|grep panic debug.ddb.textdump.do_panic: 1 debug.trace_on_panic: 1 debug.debugger_on_panic: 1 debug.kdb.panic: 0 > > and check whether output of > > savecore -vC # savecore -vC unable to open bounds file, using 0 checking for kernel dump on device /dev/mirror/swap mediasize = 2147483136 sectorsize = 512 magic mismatch on last dump header on /dev/mirror/swap No dump exists # dumpdev wasn't configured.. I've configured it now, will try crash dump next time. By the way, are these two FreeBSD docs up to date: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html In particular, it is still true that minidump is a default dump type? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Thu Jul 30 11:46:30 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Thu Jul 30 11:46:36 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> Message-ID: <4A718816.2080404@haruhiism.net> Anton Shterenlikht wrote: > # savecore -vC > unable to open bounds file, using 0 > checking for kernel dump on device /dev/mirror/swap > mediasize = 2147483136 > sectorsize = 512 > magic mismatch on last dump header on /dev/mirror/swap > No dump exists > # > dumpdev wasn't configured.. > I've configured it now, will try crash dump next time. > Keep in mind, however, that you won't get a valid dump if your dumpdev is on a GEOM_MIRROR device. -- Kamigishi Rei KREI-RIPE From mexas at bristol.ac.uk Thu Jul 30 11:55:35 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 11:55:47 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <4A718816.2080404@haruhiism.net> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> <4A718816.2080404@haruhiism.net> Message-ID: <20090730115528.GA1242@mech-cluster241.men.bris.ac.uk> On Thu, Jul 30, 2009 at 03:46:30PM +0400, Kamigishi Rei wrote: > Anton Shterenlikht wrote: > ># savecore -vC > >unable to open bounds file, using 0 > >checking for kernel dump on device /dev/mirror/swap > >mediasize = 2147483136 > >sectorsize = 512 > >magic mismatch on last dump header on /dev/mirror/swap > >No dump exists > ># > >dumpdev wasn't configured.. > >I've configured it now, will try crash dump next time. > > Keep in mind, however, that you won't get a valid dump if your > dumpdev is on a GEOM_MIRROR device. Could you please elaborate on this? thank you -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Thu Jul 30 11:59:51 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Thu Jul 30 12:00:03 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090730115528.GA1242@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> <4A718816.2080404@haruhiism.net> <20090730115528.GA1242@mech-cluster241.men.bris.ac.uk> Message-ID: <4A718B39.3030707@haruhiism.net> Anton Shterenlikht wrote: >> Keep in mind, however, that you won't get a valid dump if your >> dumpdev is on a GEOM_MIRROR device. >> > Could you please elaborate on this? > There were multiple threads in -current (and not only) about this issue. Myself, I have been unable to produce a valid crash dump with dumpdev on a GEOM_MIRROR device (even with "prefer" set for the first component; then again if the order in which the consumers are detected changes during boot accidentally, prefer won't work as well). -- Kamigishi Rei KREI-RIPE From mexas at bristol.ac.uk Thu Jul 30 14:25:22 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 14:25:31 2009 Subject: firefox3 build fails on ia64 Message-ID: <20090730142502.GA11369@mech-cluster241.men.bris.ac.uk> On ia64 SMP 8.0-beta2, firefox3 build fails with: [skip] gmake[8]: Entering directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix' xptcstubs_ipf64.cpp c++ -o xptcstubs_ipf64.o -c -fvisibility=hidden -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD8\" -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../xptinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../dist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -O2 -pipe -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcstubs_ipf64.cpp In file included from xptcstubs_ipf64.cpp:185: ../../../../../../dist/include/xpcom/xptcstubsdef.inc:1: error: prototype for 'nsresult nsXPTCStubBase::Stub3(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:1: error: candidate is: virtual nsresult nsXPTCStubBase::Stub3() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:2: error: prototype for 'nsresult nsXPTCStubBase::Stub4(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:2: error: candidate is: virtual nsresult nsXPTCStubBase::Stub4() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:3: error: prototype for 'nsresult nsXPTCStubBase::Stub5(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:3: error: candidate is: virtual nsresult nsXPTCStubBase::Stub5() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:4: error: prototype for 'nsresult nsXPTCStubBase::Stub6(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:4: error: candidate is: virtual nsresult nsXPTCStubBase::Stub6() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:5: error: prototype for 'nsresult nsXPTCStubBase::Stub7(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:5: error: candidate is: virtual nsresult nsXPTCStubBase::Stub7() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:6: error: prototype for 'nsresult nsXPTCStubBase::Stub8(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:6: error: candidate is: virtual nsresult nsXPTCStubBase::Stub8() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:7: error: prototype for 'nsresult nsXPTCStubBase::Stub9(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:7: error: candidate is: virtual nsresult nsXPTCStubBase::Stub9() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:8: error: prototype for 'nsresult nsXPTCStubBase::Stub10(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:8: error: candidate is: virtual nsresult nsXPTCStubBase::Stub10() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:9: error: prototype for 'nsresult nsXPTCStubBase::Stub11(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:9: error: candidate is: virtual nsresult nsXPTCStubBase::Stub11() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:10: error: prototype for 'nsresult nsXPTCStubBase::Stub12(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:10: error: candidate is: virtual nsresult nsXPTCStubBase::Stub12() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:11: error: prototype for 'nsresult nsXPTCStubBase::Stub13(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:11: error: candidate is: virtual nsresult nsXPTCStubBase::Stub13() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:12: error: prototype for 'nsresult nsXPTCStubBase::Stub14(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:12: error: candidate is: virtual nsresult nsXPTCStubBase::Stub14() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:13: error: prototype for 'nsresult nsXPTCStubBase::Stub15(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:13: error: candidate is: virtual nsresult nsXPTCStubBase::Stub15() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:14: error: prototype for 'nsresult nsXPTCStubBase::Stub16(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:14: error: candidate is: virtual nsresult nsXPTCStubBase::Stub16() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:15: error: prototype for 'nsresult nsXPTCStubBase::Stub17(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:15: error: candidate is: virtual nsresult nsXPTCStubBase::Stub17() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:16: error: prototype for 'nsresult nsXPTCStubBase::Stub18(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:16: error: candidate is: virtual nsresult nsXPTCStubBase::Stub18() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:17: error: prototype for 'nsresult nsXPTCStubBase::Stub19(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:17: error: candidate is: virtual nsresult nsXPTCStubBase::Stub19() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:18: error: prototype for 'nsresult nsXPTCStubBase::Stub20(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:18: error: candidate is: virtual nsresult nsXPTCStubBase::Stub20() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:19: error: prototype for 'nsresult nsXPTCStubBase::Stub21(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:19: error: candidate is: virtual nsresult nsXPTCStubBase::Stub21() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:20: error: prototype for 'nsresult nsXPTCStubBase::Stub22(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:20: error: candidate is: virtual nsresult nsXPTCStubBase::Stub22() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:21: error: prototype for 'nsresult nsXPTCStubBase::Stub23(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:21: error: candidate is: virtual nsresult nsXPTCStubBase::Stub23() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:22: error: prototype for 'nsresult nsXPTCStubBase::Stub24(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:22: error: candidate is: virtual nsresult nsXPTCStubBase::Stub24() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:23: error: prototype for 'nsresult nsXPTCStubBase::Stub25(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:23: error: candidate is: virtual nsresult nsXPTCStubBase::Stub25() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:24: error: prototype for 'nsresult nsXPTCStubBase::Stub26(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:24: error: candidate is: virtual nsresult nsXPTCStubBase::Stub26() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:25: error: prototype for 'nsresult nsXPTCStubBase::Stub27(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:25: error: candidate is: virtual nsresult nsXPTCStubBase::Stub27() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:26: error: prototype for 'nsresult nsXPTCStubBase::Stub28(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:26: error: candidate is: virtual nsresult nsXPTCStubBase::Stub28() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:27: error: prototype for 'nsresult nsXPTCStubBase::Stub29(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:27: error: candidate is: virtual nsresult nsXPTCStubBase::Stub29() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:28: error: prototype for 'nsresult nsXPTCStubBase::Stub30(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:28: error: candidate is: virtual nsresult nsXPTCStubBase::Stub30() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:29: error: prototype for 'nsresult nsXPTCStubBase::Stub31(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:29: error: candidate is: virtual nsresult nsXPTCStubBase::Stub31() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:30: error: prototype for 'nsresult nsXPTCStubBase::Stub32(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:30: error: candidate is: virtual nsresult nsXPTCStubBase::Stub32() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:31: error: prototype for 'nsresult nsXPTCStubBase::Stub33(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:31: error: candidate is: virtual nsresult nsXPTCStubBase::Stub33() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:32: error: prototype for 'nsresult nsXPTCStubBase::Stub34(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:32: error: candidate is: virtual nsresult nsXPTCStubBase::Stub34() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:33: error: prototype for 'nsresult nsXPTCStubBase::Stub35(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:33: error: candidate is: virtual nsresult nsXPTCStubBase::Stub35() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:34: error: prototype for 'nsresult nsXPTCStubBase::Stub36(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:34: error: candidate is: virtual nsresult nsXPTCStubBase::Stub36() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:35: error: prototype for 'nsresult nsXPTCStubBase::Stub37(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:35: error: candidate is: virtual nsresult nsXPTCStubBase::Stub37() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:36: error: prototype for 'nsresult nsXPTCStubBase::Stub38(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:36: error: candidate is: virtual nsresult nsXPTCStubBase::Stub38() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:37: error: prototype for 'nsresult nsXPTCStubBase::Stub39(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:37: error: candidate is: virtual nsresult nsXPTCStubBase::Stub39() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:38: error: prototype for 'nsresult nsXPTCStubBase::Stub40(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:38: error: candidate is: virtual nsresult nsXPTCStubBase::Stub40() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:39: error: prototype for 'nsresult nsXPTCStubBase::Stub41(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:39: error: candidate is: virtual nsresult nsXPTCStubBase::Stub41() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:40: error: prototype for 'nsresult nsXPTCStubBase::Stub42(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:40: error: candidate is: virtual nsresult nsXPTCStubBase::Stub42() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:41: error: prototype for 'nsresult nsXPTCStubBase::Stub43(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:41: error: candidate is: virtual nsresult nsXPTCStubBase::Stub43() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:42: error: prototype for 'nsresult nsXPTCStubBase::Stub44(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:42: error: candidate is: virtual nsresult nsXPTCStubBase::Stub44() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:43: error: prototype for 'nsresult nsXPTCStubBase::Stub45(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:43: error: candidate is: virtual nsresult nsXPTCStubBase::Stub45() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:44: error: prototype for 'nsresult nsXPTCStubBase::Stub46(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:44: error: candidate is: virtual nsresult nsXPTCStubBase::Stub46() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:45: error: prototype for 'nsresult nsXPTCStubBase::Stub47(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:45: error: candidate is: virtual nsresult nsXPTCStubBase::Stub47() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:46: error: prototype for 'nsresult nsXPTCStubBase::Stub48(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:46: error: candidate is: virtual nsresult nsXPTCStubBase::Stub48() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:47: error: prototype for 'nsresult nsXPTCStubBase::Stub49(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:47: error: candidate is: virtual nsresult nsXPTCStubBase::Stub49() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:48: error: prototype for 'nsresult nsXPTCStubBase::Stub50(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:48: error: candidate is: virtual nsresult nsXPTCStubBase::Stub50() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:49: error: prototype for 'nsresult nsXPTCStubBase::Stub51(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:49: error: candidate is: virtual nsresult nsXPTCStubBase::Stub51() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:50: error: prototype for 'nsresult nsXPTCStubBase::Stub52(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:50: error: candidate is: virtual nsresult nsXPTCStubBase::Stub52() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:51: error: prototype for 'nsresult nsXPTCStubBase::Stub53(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:51: error: candidate is: virtual nsresult nsXPTCStubBase::Stub53() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:52: error: prototype for 'nsresult nsXPTCStubBase::Stub54(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:52: error: candidate is: virtual nsresult nsXPTCStubBase::Stub54() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:53: error: prototype for 'nsresult nsXPTCStubBase::Stub55(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:53: error: candidate is: virtual nsresult nsXPTCStubBase::Stub55() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:54: error: prototype for 'nsresult nsXPTCStubBase::Stub56(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:54: error: candidate is: virtual nsresult nsXPTCStubBase::Stub56() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:55: error: prototype for 'nsresult nsXPTCStubBase::Stub57(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:55: error: candidate is: virtual nsresult nsXPTCStubBase::Stub57() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:56: error: prototype for 'nsresult nsXPTCStubBase::Stub58(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:56: error: candidate is: virtual nsresult nsXPTCStubBase::Stub58() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:57: error: prototype for 'nsresult nsXPTCStubBase::Stub59(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:57: error: candidate is: virtual nsresult nsXPTCStubBase::Stub59() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:58: error: prototype for 'nsresult nsXPTCStubBase::Stub60(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:58: error: candidate is: virtual nsresult nsXPTCStubBase::Stub60() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:59: error: prototype for 'nsresult nsXPTCStubBase::Stub61(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:59: error: candidate is: virtual nsresult nsXPTCStubBase::Stub61() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:60: error: prototype for 'nsresult nsXPTCStubBase::Stub62(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:60: error: candidate is: virtual nsresult nsXPTCStubBase::Stub62() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:61: error: prototype for 'nsresult nsXPTCStubBase::Stub63(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:61: error: candidate is: virtual nsresult nsXPTCStubBase::Stub63() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:62: error: prototype for 'nsresult nsXPTCStubBase::Stub64(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:62: error: candidate is: virtual nsresult nsXPTCStubBase::Stub64() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:63: error: prototype for 'nsresult nsXPTCStubBase::Stub65(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:63: error: candidate is: virtual nsresult nsXPTCStubBase::Stub65() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:64: error: prototype for 'nsresult nsXPTCStubBase::Stub66(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:64: error: candidate is: virtual nsresult nsXPTCStubBase::Stub66() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:65: error: prototype for 'nsresult nsXPTCStubBase::Stub67(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:65: error: candidate is: virtual nsresult nsXPTCStubBase::Stub67() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:66: error: prototype for 'nsresult nsXPTCStubBase::Stub68(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:66: error: candidate is: virtual nsresult nsXPTCStubBase::Stub68() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:67: error: prototype for 'nsresult nsXPTCStubBase::Stub69(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:67: error: candidate is: virtual nsresult nsXPTCStubBase::Stub69() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:68: error: prototype for 'nsresult nsXPTCStubBase::Stub70(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:68: error: candidate is: virtual nsresult nsXPTCStubBase::Stub70() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:69: error: prototype for 'nsresult nsXPTCStubBase::Stub71(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:69: error: candidate is: virtual nsresult nsXPTCStubBase::Stub71() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:70: error: prototype for 'nsresult nsXPTCStubBase::Stub72(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:70: error: candidate is: virtual nsresult nsXPTCStubBase::Stub72() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:71: error: prototype for 'nsresult nsXPTCStubBase::Stub73(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:71: error: candidate is: virtual nsresult nsXPTCStubBase::Stub73() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:72: error: prototype for 'nsresult nsXPTCStubBase::Stub74(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:72: error: candidate is: virtual nsresult nsXPTCStubBase::Stub74() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:73: error: prototype for 'nsresult nsXPTCStubBase::Stub75(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:73: error: candidate is: virtual nsresult nsXPTCStubBase::Stub75() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:74: error: prototype for 'nsresult nsXPTCStubBase::Stub76(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:74: error: candidate is: virtual nsresult nsXPTCStubBase::Stub76() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:75: error: prototype for 'nsresult nsXPTCStubBase::Stub77(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:75: error: candidate is: virtual nsresult nsXPTCStubBase::Stub77() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:76: error: prototype for 'nsresult nsXPTCStubBase::Stub78(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:76: error: candidate is: virtual nsresult nsXPTCStubBase::Stub78() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:77: error: prototype for 'nsresult nsXPTCStubBase::Stub79(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:77: error: candidate is: virtual nsresult nsXPTCStubBase::Stub79() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:78: error: prototype for 'nsresult nsXPTCStubBase::Stub80(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:78: error: candidate is: virtual nsresult nsXPTCStubBase::Stub80() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:79: error: prototype for 'nsresult nsXPTCStubBase::Stub81(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:79: error: candidate is: virtual nsresult nsXPTCStubBase::Stub81() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:80: error: prototype for 'nsresult nsXPTCStubBase::Stub82(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:80: error: candidate is: virtual nsresult nsXPTCStubBase::Stub82() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:81: error: prototype for 'nsresult nsXPTCStubBase::Stub83(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:81: error: candidate is: virtual nsresult nsXPTCStubBase::Stub83() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:82: error: prototype for 'nsresult nsXPTCStubBase::Stub84(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:82: error: candidate is: virtual nsresult nsXPTCStubBase::Stub84() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:83: error: prototype for 'nsresult nsXPTCStubBase::Stub85(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:83: error: candidate is: virtual nsresult nsXPTCStubBase::Stub85() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:84: error: prototype for 'nsresult nsXPTCStubBase::Stub86(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:84: error: candidate is: virtual nsresult nsXPTCStubBase::Stub86() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:85: error: prototype for 'nsresult nsXPTCStubBase::Stub87(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:85: error: candidate is: virtual nsresult nsXPTCStubBase::Stub87() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:86: error: prototype for 'nsresult nsXPTCStubBase::Stub88(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:86: error: candidate is: virtual nsresult nsXPTCStubBase::Stub88() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:87: error: prototype for 'nsresult nsXPTCStubBase::Stub89(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:87: error: candidate is: virtual nsresult nsXPTCStubBase::Stub89() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:88: error: prototype for 'nsresult nsXPTCStubBase::Stub90(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:88: error: candidate is: virtual nsresult nsXPTCStubBase::Stub90() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:89: error: prototype for 'nsresult nsXPTCStubBase::Stub91(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:89: error: candidate is: virtual nsresult nsXPTCStubBase::Stub91() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:90: error: prototype for 'nsresult nsXPTCStubBase::Stub92(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:90: error: candidate is: virtual nsresult nsXPTCStubBase::Stub92() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:91: error: prototype for 'nsresult nsXPTCStubBase::Stub93(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:91: error: candidate is: virtual nsresult nsXPTCStubBase::Stub93() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:92: error: prototype for 'nsresult nsXPTCStubBase::Stub94(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:92: error: candidate is: virtual nsresult nsXPTCStubBase::Stub94() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:93: error: prototype for 'nsresult nsXPTCStubBase::Stub95(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:93: error: candidate is: virtual nsresult nsXPTCStubBase::Stub95() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:94: error: prototype for 'nsresult nsXPTCStubBase::Stub96(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:94: error: candidate is: virtual nsresult nsXPTCStubBase::Stub96() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:95: error: prototype for 'nsresult nsXPTCStubBase::Stub97(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:95: error: candidate is: virtual nsresult nsXPTCStubBase::Stub97() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:96: error: prototype for 'nsresult nsXPTCStubBase::Stub98(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:96: error: candidate is: virtual nsresult nsXPTCStubBase::Stub98() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:97: error: prototype for 'nsresult nsXPTCStubBase::Stub99(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:97: error: candidate is: virtual nsresult nsXPTCStubBase::Stub99() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:98: error: prototype for 'nsresult nsXPTCStubBase::Stub100(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:98: error: candidate is: virtual nsresult nsXPTCStubBase::Stub100() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:99: error: prototype for 'nsresult nsXPTCStubBase::Stub101(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:99: error: candidate is: virtual nsresult nsXPTCStubBase::Stub101() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:100: error: prototype for 'nsresult nsXPTCStubBase::Stub102(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:100: error: candidate is: virtual nsresult nsXPTCStubBase::Stub102() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:101: error: prototype for 'nsresult nsXPTCStubBase::Stub103(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:101: error: candidate is: virtual nsresult nsXPTCStubBase::Stub103() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:102: error: prototype for 'nsresult nsXPTCStubBase::Stub104(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:102: error: candidate is: virtual nsresult nsXPTCStubBase::Stub104() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:103: error: prototype for 'nsresult nsXPTCStubBase::Stub105(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:103: error: candidate is: virtual nsresult nsXPTCStubBase::Stub105() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:104: error: prototype for 'nsresult nsXPTCStubBase::Stub106(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:104: error: candidate is: virtual nsresult nsXPTCStubBase::Stub106() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:105: error: prototype for 'nsresult nsXPTCStubBase::Stub107(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:105: error: candidate is: virtual nsresult nsXPTCStubBase::Stub107() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:106: error: prototype for 'nsresult nsXPTCStubBase::Stub108(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:106: error: candidate is: virtual nsresult nsXPTCStubBase::Stub108() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:107: error: prototype for 'nsresult nsXPTCStubBase::Stub109(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:107: error: candidate is: virtual nsresult nsXPTCStubBase::Stub109() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:108: error: prototype for 'nsresult nsXPTCStubBase::Stub110(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:108: error: candidate is: virtual nsresult nsXPTCStubBase::Stub110() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:109: error: prototype for 'nsresult nsXPTCStubBase::Stub111(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:109: error: candidate is: virtual nsresult nsXPTCStubBase::Stub111() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:110: error: prototype for 'nsresult nsXPTCStubBase::Stub112(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:110: error: candidate is: virtual nsresult nsXPTCStubBase::Stub112() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:111: error: prototype for 'nsresult nsXPTCStubBase::Stub113(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:111: error: candidate is: virtual nsresult nsXPTCStubBase::Stub113() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:112: error: prototype for 'nsresult nsXPTCStubBase::Stub114(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:112: error: candidate is: virtual nsresult nsXPTCStubBase::Stub114() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:113: error: prototype for 'nsresult nsXPTCStubBase::Stub115(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:113: error: candidate is: virtual nsresult nsXPTCStubBase::Stub115() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:114: error: prototype for 'nsresult nsXPTCStubBase::Stub116(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:114: error: candidate is: virtual nsresult nsXPTCStubBase::Stub116() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:115: error: prototype for 'nsresult nsXPTCStubBase::Stub117(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:115: error: candidate is: virtual nsresult nsXPTCStubBase::Stub117() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:116: error: prototype for 'nsresult nsXPTCStubBase::Stub118(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:116: error: candidate is: virtual nsresult nsXPTCStubBase::Stub118() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:117: error: prototype for 'nsresult nsXPTCStubBase::Stub119(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:117: error: candidate is: virtual nsresult nsXPTCStubBase::Stub119() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:118: error: prototype for 'nsresult nsXPTCStubBase::Stub120(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:118: error: candidate is: virtual nsresult nsXPTCStubBase::Stub120() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:119: error: prototype for 'nsresult nsXPTCStubBase::Stub121(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:119: error: candidate is: virtual nsresult nsXPTCStubBase::Stub121() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:120: error: prototype for 'nsresult nsXPTCStubBase::Stub122(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:120: error: candidate is: virtual nsresult nsXPTCStubBase::Stub122() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:121: error: prototype for 'nsresult nsXPTCStubBase::Stub123(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:121: error: candidate is: virtual nsresult nsXPTCStubBase::Stub123() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:122: error: prototype for 'nsresult nsXPTCStubBase::Stub124(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:122: error: candidate is: virtual nsresult nsXPTCStubBase::Stub124() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:123: error: prototype for 'nsresult nsXPTCStubBase::Stub125(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:123: error: candidate is: virtual nsresult nsXPTCStubBase::Stub125() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:124: error: prototype for 'nsresult nsXPTCStubBase::Stub126(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:124: error: candidate is: virtual nsresult nsXPTCStubBase::Stub126() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:125: error: prototype for 'nsresult nsXPTCStubBase::Stub127(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:125: error: candidate is: virtual nsresult nsXPTCStubBase::Stub127() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:126: error: prototype for 'nsresult nsXPTCStubBase::Stub128(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:126: error: candidate is: virtual nsresult nsXPTCStubBase::Stub128() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:127: error: prototype for 'nsresult nsXPTCStubBase::Stub129(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:127: error: candidate is: virtual nsresult nsXPTCStubBase::Stub129() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:128: error: prototype for 'nsresult nsXPTCStubBase::Stub130(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:128: error: candidate is: virtual nsresult nsXPTCStubBase::Stub130() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:129: error: prototype for 'nsresult nsXPTCStubBase::Stub131(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:129: error: candidate is: virtual nsresult nsXPTCStubBase::Stub131() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:130: error: prototype for 'nsresult nsXPTCStubBase::Stub132(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:130: error: candidate is: virtual nsresult nsXPTCStubBase::Stub132() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:131: error: prototype for 'nsresult nsXPTCStubBase::Stub133(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:131: error: candidate is: virtual nsresult nsXPTCStubBase::Stub133() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:132: error: prototype for 'nsresult nsXPTCStubBase::Stub134(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:132: error: candidate is: virtual nsresult nsXPTCStubBase::Stub134() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:133: error: prototype for 'nsresult nsXPTCStubBase::Stub135(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:133: error: candidate is: virtual nsresult nsXPTCStubBase::Stub135() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:134: error: prototype for 'nsresult nsXPTCStubBase::Stub136(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:134: error: candidate is: virtual nsresult nsXPTCStubBase::Stub136() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:135: error: prototype for 'nsresult nsXPTCStubBase::Stub137(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:135: error: candidate is: virtual nsresult nsXPTCStubBase::Stub137() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:136: error: prototype for 'nsresult nsXPTCStubBase::Stub138(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:136: error: candidate is: virtual nsresult nsXPTCStubBase::Stub138() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:137: error: prototype for 'nsresult nsXPTCStubBase::Stub139(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:137: error: candidate is: virtual nsresult nsXPTCStubBase::Stub139() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:138: error: prototype for 'nsresult nsXPTCStubBase::Stub140(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:138: error: candidate is: virtual nsresult nsXPTCStubBase::Stub140() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:139: error: prototype for 'nsresult nsXPTCStubBase::Stub141(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:139: error: candidate is: virtual nsresult nsXPTCStubBase::Stub141() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:140: error: prototype for 'nsresult nsXPTCStubBase::Stub142(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:140: error: candidate is: virtual nsresult nsXPTCStubBase::Stub142() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:141: error: prototype for 'nsresult nsXPTCStubBase::Stub143(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:141: error: candidate is: virtual nsresult nsXPTCStubBase::Stub143() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:142: error: prototype for 'nsresult nsXPTCStubBase::Stub144(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:142: error: candidate is: virtual nsresult nsXPTCStubBase::Stub144() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:143: error: prototype for 'nsresult nsXPTCStubBase::Stub145(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:143: error: candidate is: virtual nsresult nsXPTCStubBase::Stub145() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:144: error: prototype for 'nsresult nsXPTCStubBase::Stub146(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:144: error: candidate is: virtual nsresult nsXPTCStubBase::Stub146() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:145: error: prototype for 'nsresult nsXPTCStubBase::Stub147(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:145: error: candidate is: virtual nsresult nsXPTCStubBase::Stub147() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:146: error: prototype for 'nsresult nsXPTCStubBase::Stub148(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:146: error: candidate is: virtual nsresult nsXPTCStubBase::Stub148() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:147: error: prototype for 'nsresult nsXPTCStubBase::Stub149(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:147: error: candidate is: virtual nsresult nsXPTCStubBase::Stub149() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:148: error: prototype for 'nsresult nsXPTCStubBase::Stub150(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:148: error: candidate is: virtual nsresult nsXPTCStubBase::Stub150() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:149: error: prototype for 'nsresult nsXPTCStubBase::Stub151(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:149: error: candidate is: virtual nsresult nsXPTCStubBase::Stub151() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:150: error: prototype for 'nsresult nsXPTCStubBase::Stub152(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:150: error: candidate is: virtual nsresult nsXPTCStubBase::Stub152() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:151: error: prototype for 'nsresult nsXPTCStubBase::Stub153(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:151: error: candidate is: virtual nsresult nsXPTCStubBase::Stub153() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:152: error: prototype for 'nsresult nsXPTCStubBase::Stub154(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:152: error: candidate is: virtual nsresult nsXPTCStubBase::Stub154() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:153: error: prototype for 'nsresult nsXPTCStubBase::Stub155(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:153: error: candidate is: virtual nsresult nsXPTCStubBase::Stub155() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:154: error: prototype for 'nsresult nsXPTCStubBase::Stub156(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:154: error: candidate is: virtual nsresult nsXPTCStubBase::Stub156() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:155: error: prototype for 'nsresult nsXPTCStubBase::Stub157(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:155: error: candidate is: virtual nsresult nsXPTCStubBase::Stub157() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:156: error: prototype for 'nsresult nsXPTCStubBase::Stub158(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:156: error: candidate is: virtual nsresult nsXPTCStubBase::Stub158() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:157: error: prototype for 'nsresult nsXPTCStubBase::Stub159(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:157: error: candidate is: virtual nsresult nsXPTCStubBase::Stub159() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:158: error: prototype for 'nsresult nsXPTCStubBase::Stub160(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:158: error: candidate is: virtual nsresult nsXPTCStubBase::Stub160() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:159: error: prototype for 'nsresult nsXPTCStubBase::Stub161(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:159: error: candidate is: virtual nsresult nsXPTCStubBase::Stub161() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:160: error: prototype for 'nsresult nsXPTCStubBase::Stub162(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:160: error: candidate is: virtual nsresult nsXPTCStubBase::Stub162() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:161: error: prototype for 'nsresult nsXPTCStubBase::Stub163(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:161: error: candidate is: virtual nsresult nsXPTCStubBase::Stub163() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:162: error: prototype for 'nsresult nsXPTCStubBase::Stub164(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:162: error: candidate is: virtual nsresult nsXPTCStubBase::Stub164() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:163: error: prototype for 'nsresult nsXPTCStubBase::Stub165(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:163: error: candidate is: virtual nsresult nsXPTCStubBase::Stub165() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:164: error: prototype for 'nsresult nsXPTCStubBase::Stub166(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:164: error: candidate is: virtual nsresult nsXPTCStubBase::Stub166() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:165: error: prototype for 'nsresult nsXPTCStubBase::Stub167(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:165: error: candidate is: virtual nsresult nsXPTCStubBase::Stub167() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:166: error: prototype for 'nsresult nsXPTCStubBase::Stub168(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:166: error: candidate is: virtual nsresult nsXPTCStubBase::Stub168() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:167: error: prototype for 'nsresult nsXPTCStubBase::Stub169(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:167: error: candidate is: virtual nsresult nsXPTCStubBase::Stub169() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:168: error: prototype for 'nsresult nsXPTCStubBase::Stub170(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:168: error: candidate is: virtual nsresult nsXPTCStubBase::Stub170() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:169: error: prototype for 'nsresult nsXPTCStubBase::Stub171(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:169: error: candidate is: virtual nsresult nsXPTCStubBase::Stub171() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:170: error: prototype for 'nsresult nsXPTCStubBase::Stub172(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:170: error: candidate is: virtual nsresult nsXPTCStubBase::Stub172() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:171: error: prototype for 'nsresult nsXPTCStubBase::Stub173(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:171: error: candidate is: virtual nsresult nsXPTCStubBase::Stub173() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:172: error: prototype for 'nsresult nsXPTCStubBase::Stub174(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:172: error: candidate is: virtual nsresult nsXPTCStubBase::Stub174() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:173: error: prototype for 'nsresult nsXPTCStubBase::Stub175(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:173: error: candidate is: virtual nsresult nsXPTCStubBase::Stub175() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:174: error: prototype for 'nsresult nsXPTCStubBase::Stub176(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:174: error: candidate is: virtual nsresult nsXPTCStubBase::Stub176() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:175: error: prototype for 'nsresult nsXPTCStubBase::Stub177(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:175: error: candidate is: virtual nsresult nsXPTCStubBase::Stub177() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:176: error: prototype for 'nsresult nsXPTCStubBase::Stub178(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:176: error: candidate is: virtual nsresult nsXPTCStubBase::Stub178() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:177: error: prototype for 'nsresult nsXPTCStubBase::Stub179(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:177: error: candidate is: virtual nsresult nsXPTCStubBase::Stub179() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:178: error: prototype for 'nsresult nsXPTCStubBase::Stub180(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:178: error: candidate is: virtual nsresult nsXPTCStubBase::Stub180() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:179: error: prototype for 'nsresult nsXPTCStubBase::Stub181(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:179: error: candidate is: virtual nsresult nsXPTCStubBase::Stub181() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:180: error: prototype for 'nsresult nsXPTCStubBase::Stub182(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:180: error: candidate is: virtual nsresult nsXPTCStubBase::Stub182() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:181: error: prototype for 'nsresult nsXPTCStubBase::Stub183(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:181: error: candidate is: virtual nsresult nsXPTCStubBase::Stub183() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:182: error: prototype for 'nsresult nsXPTCStubBase::Stub184(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:182: error: candidate is: virtual nsresult nsXPTCStubBase::Stub184() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:183: error: prototype for 'nsresult nsXPTCStubBase::Stub185(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:183: error: candidate is: virtual nsresult nsXPTCStubBase::Stub185() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:184: error: prototype for 'nsresult nsXPTCStubBase::Stub186(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:184: error: candidate is: virtual nsresult nsXPTCStubBase::Stub186() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:185: error: prototype for 'nsresult nsXPTCStubBase::Stub187(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:185: error: candidate is: virtual nsresult nsXPTCStubBase::Stub187() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:186: error: prototype for 'nsresult nsXPTCStubBase::Stub188(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:186: error: candidate is: virtual nsresult nsXPTCStubBase::Stub188() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:187: error: prototype for 'nsresult nsXPTCStubBase::Stub189(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:187: error: candidate is: virtual nsresult nsXPTCStubBase::Stub189() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:188: error: prototype for 'nsresult nsXPTCStubBase::Stub190(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:188: error: candidate is: virtual nsresult nsXPTCStubBase::Stub190() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:189: error: prototype for 'nsresult nsXPTCStubBase::Stub191(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:189: error: candidate is: virtual nsresult nsXPTCStubBase::Stub191() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:190: error: prototype for 'nsresult nsXPTCStubBase::Stub192(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:190: error: candidate is: virtual nsresult nsXPTCStubBase::Stub192() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:191: error: prototype for 'nsresult nsXPTCStubBase::Stub193(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:191: error: candidate is: virtual nsresult nsXPTCStubBase::Stub193() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:192: error: prototype for 'nsresult nsXPTCStubBase::Stub194(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:192: error: candidate is: virtual nsresult nsXPTCStubBase::Stub194() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:193: error: prototype for 'nsresult nsXPTCStubBase::Stub195(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:193: error: candidate is: virtual nsresult nsXPTCStubBase::Stub195() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:194: error: prototype for 'nsresult nsXPTCStubBase::Stub196(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:194: error: candidate is: virtual nsresult nsXPTCStubBase::Stub196() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:195: error: prototype for 'nsresult nsXPTCStubBase::Stub197(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:195: error: candidate is: virtual nsresult nsXPTCStubBase::Stub197() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:196: error: prototype for 'nsresult nsXPTCStubBase::Stub198(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:196: error: candidate is: virtual nsresult nsXPTCStubBase::Stub198() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:197: error: prototype for 'nsresult nsXPTCStubBase::Stub199(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:197: error: candidate is: virtual nsresult nsXPTCStubBase::Stub199() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:198: error: prototype for 'nsresult nsXPTCStubBase::Stub200(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:198: error: candidate is: virtual nsresult nsXPTCStubBase::Stub200() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:199: error: prototype for 'nsresult nsXPTCStubBase::Stub201(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:199: error: candidate is: virtual nsresult nsXPTCStubBase::Stub201() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:200: error: prototype for 'nsresult nsXPTCStubBase::Stub202(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:200: error: candidate is: virtual nsresult nsXPTCStubBase::Stub202() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:201: error: prototype for 'nsresult nsXPTCStubBase::Stub203(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:201: error: candidate is: virtual nsresult nsXPTCStubBase::Stub203() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:202: error: prototype for 'nsresult nsXPTCStubBase::Stub204(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:202: error: candidate is: virtual nsresult nsXPTCStubBase::Stub204() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:203: error: prototype for 'nsresult nsXPTCStubBase::Stub205(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:203: error: candidate is: virtual nsresult nsXPTCStubBase::Stub205() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:204: error: prototype for 'nsresult nsXPTCStubBase::Stub206(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:204: error: candidate is: virtual nsresult nsXPTCStubBase::Stub206() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:205: error: prototype for 'nsresult nsXPTCStubBase::Stub207(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:205: error: candidate is: virtual nsresult nsXPTCStubBase::Stub207() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:206: error: prototype for 'nsresult nsXPTCStubBase::Stub208(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:206: error: candidate is: virtual nsresult nsXPTCStubBase::Stub208() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:207: error: prototype for 'nsresult nsXPTCStubBase::Stub209(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:207: error: candidate is: virtual nsresult nsXPTCStubBase::Stub209() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:208: error: prototype for 'nsresult nsXPTCStubBase::Stub210(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:208: error: candidate is: virtual nsresult nsXPTCStubBase::Stub210() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:209: error: prototype for 'nsresult nsXPTCStubBase::Stub211(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:209: error: candidate is: virtual nsresult nsXPTCStubBase::Stub211() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:210: error: prototype for 'nsresult nsXPTCStubBase::Stub212(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:210: error: candidate is: virtual nsresult nsXPTCStubBase::Stub212() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:211: error: prototype for 'nsresult nsXPTCStubBase::Stub213(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:211: error: candidate is: virtual nsresult nsXPTCStubBase::Stub213() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:212: error: prototype for 'nsresult nsXPTCStubBase::Stub214(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:212: error: candidate is: virtual nsresult nsXPTCStubBase::Stub214() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:213: error: prototype for 'nsresult nsXPTCStubBase::Stub215(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:213: error: candidate is: virtual nsresult nsXPTCStubBase::Stub215() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:214: error: prototype for 'nsresult nsXPTCStubBase::Stub216(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:214: error: candidate is: virtual nsresult nsXPTCStubBase::Stub216() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:215: error: prototype for 'nsresult nsXPTCStubBase::Stub217(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:215: error: candidate is: virtual nsresult nsXPTCStubBase::Stub217() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:216: error: prototype for 'nsresult nsXPTCStubBase::Stub218(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:216: error: candidate is: virtual nsresult nsXPTCStubBase::Stub218() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:217: error: prototype for 'nsresult nsXPTCStubBase::Stub219(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:217: error: candidate is: virtual nsresult nsXPTCStubBase::Stub219() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:218: error: prototype for 'nsresult nsXPTCStubBase::Stub220(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:218: error: candidate is: virtual nsresult nsXPTCStubBase::Stub220() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:219: error: prototype for 'nsresult nsXPTCStubBase::Stub221(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:219: error: candidate is: virtual nsresult nsXPTCStubBase::Stub221() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:220: error: prototype for 'nsresult nsXPTCStubBase::Stub222(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:220: error: candidate is: virtual nsresult nsXPTCStubBase::Stub222() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:221: error: prototype for 'nsresult nsXPTCStubBase::Stub223(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:221: error: candidate is: virtual nsresult nsXPTCStubBase::Stub223() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:222: error: prototype for 'nsresult nsXPTCStubBase::Stub224(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:222: error: candidate is: virtual nsresult nsXPTCStubBase::Stub224() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:223: error: prototype for 'nsresult nsXPTCStubBase::Stub225(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:223: error: candidate is: virtual nsresult nsXPTCStubBase::Stub225() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:224: error: prototype for 'nsresult nsXPTCStubBase::Stub226(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:224: error: candidate is: virtual nsresult nsXPTCStubBase::Stub226() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:225: error: prototype for 'nsresult nsXPTCStubBase::Stub227(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:225: error: candidate is: virtual nsresult nsXPTCStubBase::Stub227() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:226: error: prototype for 'nsresult nsXPTCStubBase::Stub228(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:226: error: candidate is: virtual nsresult nsXPTCStubBase::Stub228() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:227: error: prototype for 'nsresult nsXPTCStubBase::Stub229(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:227: error: candidate is: virtual nsresult nsXPTCStubBase::Stub229() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:228: error: prototype for 'nsresult nsXPTCStubBase::Stub230(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:228: error: candidate is: virtual nsresult nsXPTCStubBase::Stub230() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:229: error: prototype for 'nsresult nsXPTCStubBase::Stub231(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:229: error: candidate is: virtual nsresult nsXPTCStubBase::Stub231() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:230: error: prototype for 'nsresult nsXPTCStubBase::Stub232(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:230: error: candidate is: virtual nsresult nsXPTCStubBase::Stub232() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:231: error: prototype for 'nsresult nsXPTCStubBase::Stub233(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:231: error: candidate is: virtual nsresult nsXPTCStubBase::Stub233() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:232: error: prototype for 'nsresult nsXPTCStubBase::Stub234(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:232: error: candidate is: virtual nsresult nsXPTCStubBase::Stub234() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:233: error: prototype for 'nsresult nsXPTCStubBase::Stub235(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:233: error: candidate is: virtual nsresult nsXPTCStubBase::Stub235() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:234: error: prototype for 'nsresult nsXPTCStubBase::Stub236(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:234: error: candidate is: virtual nsresult nsXPTCStubBase::Stub236() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:235: error: prototype for 'nsresult nsXPTCStubBase::Stub237(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:235: error: candidate is: virtual nsresult nsXPTCStubBase::Stub237() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:236: error: prototype for 'nsresult nsXPTCStubBase::Stub238(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:236: error: candidate is: virtual nsresult nsXPTCStubBase::Stub238() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:237: error: prototype for 'nsresult nsXPTCStubBase::Stub239(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:237: error: candidate is: virtual nsresult nsXPTCStubBase::Stub239() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:238: error: prototype for 'nsresult nsXPTCStubBase::Stub240(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:238: error: candidate is: virtual nsresult nsXPTCStubBase::Stub240() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:239: error: prototype for 'nsresult nsXPTCStubBase::Stub241(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:239: error: candidate is: virtual nsresult nsXPTCStubBase::Stub241() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:240: error: prototype for 'nsresult nsXPTCStubBase::Stub242(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:240: error: candidate is: virtual nsresult nsXPTCStubBase::Stub242() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:241: error: prototype for 'nsresult nsXPTCStubBase::Stub243(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:241: error: candidate is: virtual nsresult nsXPTCStubBase::Stub243() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:242: error: prototype for 'nsresult nsXPTCStubBase::Stub244(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:242: error: candidate is: virtual nsresult nsXPTCStubBase::Stub244() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:243: error: prototype for 'nsresult nsXPTCStubBase::Stub245(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:243: error: candidate is: virtual nsresult nsXPTCStubBase::Stub245() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:244: error: prototype for 'nsresult nsXPTCStubBase::Stub246(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:244: error: candidate is: virtual nsresult nsXPTCStubBase::Stub246() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:245: error: prototype for 'nsresult nsXPTCStubBase::Stub247(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:245: error: candidate is: virtual nsresult nsXPTCStubBase::Stub247() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:246: error: prototype for 'nsresult nsXPTCStubBase::Stub248(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:246: error: candidate is: virtual nsresult nsXPTCStubBase::Stub248() ../../../../../../dist/include/xpcom/xptcstubsdef.inc:247: error: prototype for 'nsresult nsXPTCStubBase::Stub249(PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64, PRUint64)' does not match any in class 'nsXPTCStubBase' ../../../../../../dist/include/xpcom/xptcstubsdef.inc:247: error: candidate is: virtual nsresult nsXPTCStubBase::Stub249() gmake[8]: *** [xptcstubs_ipf64.o] Error 1 gmake[8]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix' gmake[7]: *** [libs] Error 2 gmake[7]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md' gmake[6]: *** [libs] Error 2 gmake[6]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src' gmake[5]: *** [libs] Error 2 gmake[5]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom' gmake[2]: *** [libs_tier_xpcom] Error 2 gmake[2]: Leaving directory `/usr/ports/www/firefox3/work/mozilla' gmake[1]: *** [tier_xpcom] Error 2 gmake[1]: Leaving directory `/usr/ports/www/firefox3/work/mozilla' gmake: *** [default] Error 2 *** Error code 1 Stop in /usr/ports/www/firefox3. *** Error code 1 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Thu Jul 30 17:03:30 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 30 17:03:43 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 30, 2009, at 2:05 AM, Anton Shterenlikht wrote: > By the way, are these two FreeBSD docs up to date: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > In particular, it is still true that minidump is a default dump type? ia64 doesn't yet have minidumps. In fact, changes to GDB that happened a year ago or so broke the ability to read ia64 core files. I plan on implementing minidumps after 8.0-RELEASE. FYI, -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Thu Jul 30 17:09:37 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 17:09:46 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> Message-ID: <20090730170930.GA74245@mech-cluster241.men.bris.ac.uk> On Thu, Jul 30, 2009 at 10:02:29AM -0700, Marcel Moolenaar wrote: > > On Jul 30, 2009, at 2:05 AM, Anton Shterenlikht wrote: > >By the way, are these two FreeBSD docs up to date: > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > > >In particular, it is still true that minidump is a default dump type? > > ia64 doesn't yet have minidumps. In fact, changes to GDB that > happened a year ago or so broke the ability to read ia64 core > files. I plan on implementing minidumps after 8.0-RELEASE. you mean, even if I get a dump, I wouldn't be able to read it? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From xcllnt at mac.com Thu Jul 30 17:16:37 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 30 17:16:48 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <20090730170930.GA74245@mech-cluster241.men.bris.ac.uk> References: <4A6DB30B.20705@zedat.fu-berlin.de> <4A6DB9F1.7050404@haruhiism.net> <4A6E0620.6070200@mail.zedat.fu-berlin.de> <20090727210428.GA30253@mech-cluster241.men.bris.ac.uk> <20090728103545.GA22380@mech-cluster241.men.bris.ac.uk> <4A6F09BA.2020703@zedat.fu-berlin.de> <20090728144555.GD75439@mech-cluster241.men.bris.ac.uk> <1248906855.1459.8.camel@RabbitsDen> <20090730090554.GA64840@mech-cluster241.men.bris.ac.uk> <20090730170930.GA74245@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 30, 2009, at 10:09 AM, Anton Shterenlikht wrote: > On Thu, Jul 30, 2009 at 10:02:29AM -0700, Marcel Moolenaar wrote: >> >> On Jul 30, 2009, at 2:05 AM, Anton Shterenlikht wrote: >>> By the way, are these two FreeBSD docs up to date: >>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING >>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html >>> >>> In particular, it is still true that minidump is a default dump >>> type? >> >> ia64 doesn't yet have minidumps. In fact, changes to GDB that >> happened a year ago or so broke the ability to read ia64 core >> files. I plan on implementing minidumps after 8.0-RELEASE. > > you mean, even if I get a dump, I wouldn't be able to read it? Correct. The change that broke it is: http://svn.FreeBSD.org/viewvc/base?view=revision&revision=178670 -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Thu Jul 30 17:18:33 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 17:18:51 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 Message-ID: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> On ia64 SMP 8.0-beta2, firefox-2.0.0.20_8,1 causes this panic: KDB: enter: panic [thread pid 74296 tid 100167 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1f0d0,gp ;; db> trace Tracing pid 74296 tid 100167 td 0xe000000019cfcb10 kdb_enter(0xe00000000482af58, 0xe00000000482af58, 0xe00000000438ac80, 0x793) at kdb_enter+0x92 panic(0xe000000004863330, 0x0, 0xe000000004863308, 0x5cf) at panic+0x2f0 ia64_highfp_drop(0xe000000019cfcb10) at ia64_highfp_drop+0x100 cpu_thread_exit(0xe000000019cfcb10, 0xe0000000043a7be0, 0x50e, 0x15a) at cpu_thr ead_exit+0x20 thread_exit(0xe00000000482c388, 0xe00000000482b008, 0xe00000001614a4f0, 0xe00000 0019cfcb10) at thread_exit+0x130 thr_exit(0xe00000001614a468, 0xe00000001614a540, 0xe00000000482c360, 0xe00000001 614a448) at thr_exit+0x120 syscall(0xa0000000c3abb400, 0x1af, 0x2000000041d9c7b0, 0xe000000019cfcb10, 0xe00 000001614a448, 0xe000000004926ef8, 0x1af, 0xa0000000c3abb4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Thu Jul 30 17:27:08 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Jul 30 17:27:14 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 In-Reply-To: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> References: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> Message-ID: <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> On Thu, Jul 30, 2009 at 06:18:20PM +0100, Anton Shterenlikht wrote: > On ia64 SMP 8.0-beta2, firefox-2.0.0.20_8,1 causes this panic: > > KDB: enter: panic > [thread pid 74296 tid 100167 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1f0d0,gp ;; > db> trace > Tracing pid 74296 tid 100167 td 0xe000000019cfcb10 > kdb_enter(0xe00000000482af58, 0xe00000000482af58, 0xe00000000438ac80, 0x793) at > kdb_enter+0x92 > panic(0xe000000004863330, 0x0, 0xe000000004863308, 0x5cf) at panic+0x2f0 > ia64_highfp_drop(0xe000000019cfcb10) at ia64_highfp_drop+0x100 > cpu_thread_exit(0xe000000019cfcb10, 0xe0000000043a7be0, 0x50e, 0x15a) at cpu_thr > > ead_exit+0x20 > thread_exit(0xe00000000482c388, 0xe00000000482b008, 0xe00000001614a4f0, 0xe00000 > > 0019cfcb10) at thread_exit+0x130 > thr_exit(0xe00000001614a468, 0xe00000001614a540, 0xe00000000482c360, 0xe00000001 > > 614a448) at thr_exit+0x120 > syscall(0xa0000000c3abb400, 0x1af, 0x2000000041d9c7b0, 0xe000000019cfcb10, 0xe00 > > 000001614a448, 0xe000000004926ef8, 0x1af, 0xa0000000c3abb4e8) at syscall+0x3e0 > epc_syscall_return() at epc_syscall_return > db> forgot to add the beginning. Also to confirm that this panic is reproducible. panic: Inconsistent high FP state cpuid = 0 KDB: stack backtrace: db_trace_self(0xe0000000041371e0) at db_trace_self+0x20 db_trace_self_wrapper(0xe0000000043ec010) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004976240, 0xe00000000438ac30, 0x793, 0xe000000004b57190) at kdb_backtrace+0xc0 panic(0xe000000004863330, 0x0, 0xe000000004863308, 0x5cf) at panic+0x2a0 ia64_highfp_drop(0xe0000000141d6000) at ia64_highfp_drop+0x100 cpu_thread_exit(0xe0000000141d6000, 0xe0000000043a7be0, 0x50e, 0x15a) at cpu_thr ead_exit+0x20 thread_exit(0xe00000000482c388, 0xe00000000482b008, 0xe00000001187ad80, 0xe00000 00141d6000) at thread_exit+0x130 thr_exit(0xe00000001187acf8, 0xe00000001187add0, 0xe00000000482c360, 0xe00000001 187acd8) at thr_exit+0x120 syscall(0xa0000000c39ab400, 0x1af, 0x2000000041d9c7b0, 0xe0000000141d6000, 0xe00 000001187acd8, 0xe000000004926ef8, 0x1af, 0xa0000000c39ab4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return KDB: enter: panic [thread pid 1126 tid 100133 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1f0d0,gp ;; db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From tinderbox at freebsd.org Thu Jul 30 22:44:50 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jul 30 22:45:02 2009 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20090730224447.75BC81B5060@freebsd-stable.sentex.ca> TB --- 2009-07-30 21:13:26 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-07-30 21:13:26 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-07-30 21:13:26 - cleaning the object tree TB --- 2009-07-30 21:13:47 - cvsupping the source tree TB --- 2009-07-30 21:13:47 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-07-30 21:13:55 - building world TB --- 2009-07-30 21:13:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-30 21:13:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-30 21:13:55 - TARGET=ia64 TB --- 2009-07-30 21:13:55 - TARGET_ARCH=ia64 TB --- 2009-07-30 21:13:55 - TZ=UTC TB --- 2009-07-30 21:13:55 - __MAKE_CONF=/dev/null TB --- 2009-07-30 21:13:55 - cd /src TB --- 2009-07-30 21:13:55 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 30 21:13:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 30 22:39:47 UTC 2009 TB --- 2009-07-30 22:39:47 - generating LINT kernel config TB --- 2009-07-30 22:39:47 - cd /src/sys/ia64/conf TB --- 2009-07-30 22:39:47 - /usr/bin/make -B LINT TB --- 2009-07-30 22:39:47 - building LINT kernel TB --- 2009-07-30 22:39:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-30 22:39:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-30 22:39:47 - TARGET=ia64 TB --- 2009-07-30 22:39:47 - TARGET_ARCH=ia64 TB --- 2009-07-30 22:39:47 - TZ=UTC TB --- 2009-07-30 22:39:47 - __MAKE_CONF=/dev/null TB --- 2009-07-30 22:39:47 - cd /src TB --- 2009-07-30 22:39:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 30 22:39:47 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/an/if_an_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/an/if_an_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/an/if_an_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/ata-all.c /src/sys/dev/ata/ata-all.c: In function 'ata_device_ioctl': /src/sys/dev/ata/ata-all.c:454: error: request for member 'max_iosize' in something not a structure or union /src/sys/dev/ata/ata-all.c:454: error: request for member 'max_iosize' in something not a structure or union *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-30 22:44:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-30 22:44:47 - ERROR: failed to build lint kernel TB --- 2009-07-30 22:44:47 - 4752.06 user 384.24 system 5480.51 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From xcllnt at mac.com Fri Jul 31 04:20:27 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jul 31 04:20:34 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 In-Reply-To: <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> References: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> Message-ID: On Jul 30, 2009, at 10:27 AM, Anton Shterenlikht wrote: > > forgot to add the beginning. Also to confirm that this panic is > reproducible. Good. This is one panic I've been trying to catch in the act. I'll build firefox2 and try to reproduce. FYI, -- Marcel Moolenaar xcllnt@mac.com From mexas at bristol.ac.uk Fri Jul 31 08:18:39 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 31 08:18:51 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 In-Reply-To: References: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> Message-ID: <20090731081723.GB54196@mech-cluster241.men.bris.ac.uk> On Thu, Jul 30, 2009 at 09:20:23PM -0700, Marcel Moolenaar wrote: > > On Jul 30, 2009, at 10:27 AM, Anton Shterenlikht wrote: > > > >forgot to add the beginning. Also to confirm that this panic is > >reproducible. > > Good. This is one panic I've been trying to catch in > the act. I'll build firefox2 and try to reproduce. > FYI, good?? or dear me.. all I ever wanted is to use FBSD, I'm a mechanical engineer, nuts and bolts, etc. Look what I've dragged myself into.. Seriously though, are there any SSL/https web browsers known to work on ia64? many thanks as ever -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Jul 31 08:39:15 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 31 08:39:33 2009 Subject: gmirror / crash dumps In-Reply-To: <6201873e0907302246r10033969p1651104b6e0598cf@mail.gmail.com> References: <4A7271DE.7070702@p6m7g8.com> <6201873e0907302246r10033969p1651104b6e0598cf@mail.gmail.com> Message-ID: <20090731083857.GA58821@mech-cluster241.men.bris.ac.uk> On Fri, Jul 31, 2009 at 12:46:32AM -0500, Adam Vande More wrote: > On Thu, Jul 30, 2009 at 11:23 PM, Philip M. Gollucci > wrote: > > > Hi, > > > > Say I've got the following: > > /dev/mirror/gm0s1b none swap sw > > > > /dev/mirror/gm0s1a 989M 390M 520M 43% / > > /dev/mirror/gm0s1g 15G 1.7G 12G 13% /usr > > /dev/mirror/gm0s1h 544G 1.8M 501G 0% /usr/home > > /dev/mirror/gm0s1d 1.9G 500M 1.3G 27% /usr/src > > /dev/mirror/gm0s1e 1.9G 1.1G 733M 60% /usr/obj > > /dev/mirror/gm0s1f 97G 2.0K 89G 0% /var > > > > Well I'm trying to get my kernel panics to cause dumps > > 1) /etc/rc.conf > > dumpdev=AUTO > > crashinfo_enable="YES" > > > > 2) sudo chmod 700 /var/crash > > > > 3) 8GB RAM, 16GB of swap, /var/crash is 16GB < 97GB > > > > 4) I have the following in my 7-stable kernel > > makeoptions DEBUG=-g > > options AUDIT > > options KTRACE > > options KDB > > options KDB_TRACE > > options DDB > > options GDB > > options BREAK_TO_DEBUGGER > > options INVARIANTS > > options INVARIANT_SUPPORT > > options WITNESS > > options DEBUG_LOCKS > > options DEBUG_VFS_LOCKS > > options LOCK_PROFILING > > options DIAGNOSTIC > > > > The long and the short of it is I don't get any dumps. > > > > I read somewhere that you can't dump onto a gmirror device. > > > That is incorrect, but I don't know the cause of your problem. I run > nothing but gmirror and dumps happen here. I was also told that "you won't get a valid dump if your dumpdev is on a GEOM_MIRROR device" http://lists.freebsd.org/pipermail/freebsd-ia64/2009-July/002205.html -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From spambox at haruhiism.net Fri Jul 31 08:56:04 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Fri Jul 31 08:56:17 2009 Subject: gmirror / crash dumps In-Reply-To: <20090731083857.GA58821@mech-cluster241.men.bris.ac.uk> References: <4A7271DE.7070702@p6m7g8.com> <6201873e0907302246r10033969p1651104b6e0598cf@mail.gmail.com> <20090731083857.GA58821@mech-cluster241.men.bris.ac.uk> Message-ID: <4A72B1A7.3090806@haruhiism.net> Anton Shterenlikht wrote: >>> 4) I have the following in my 7-stable kernel >>> The long and the short of it is I don't get any dumps. >>> I read somewhere that you can't dump onto a gmirror device. >>> >> That is incorrect, but I don't know the cause of your problem. I run >> nothing but gmirror and dumps happen here. >> > I was also told that > "you won't get a valid dump if your dumpdev > is on a GEOM_MIRROR device" > On 7.x, you have a 'legal' way to run gmirror -v prefer before savecore is run. In -current, the corresponding rc file (alas, I forgot its name) is removed. I tried adding "gmirror -v prefer /dev/mirror0" to savecore rc.d file, but to no such luck. The problem here is the order of startup for the drives inside the mirror; the first drive in the array that started during the boot when the panic occurred has to be the preferred device during savecore - and when this condition is met, you will get a valid dump. i.e. let's assume that the system boots like GEOM_MIRROR: Device gm0: provider ada0 detected. GEOM_MIRROR: Device gm0: provider ada0 activated. GEOM_MIRROR: Device gm0: provider ada1 detected. GEOM_MIRROR: Device gm0: provider ada1 activated. GEOM_MIRROR: Device gm0: provider mirror/mirror0 launched. This makes us think that ada0 is the first drive to launch. Therefore, it's the drive where the dump will be saved during a panic. So we add gmirror configure -v prefer /dev/mirror/mirror0 /dev/ada0 (correct my syntax if I'm wrong here; tried it a month ago) to /etc/rc.d/savecore right before the savecore call. We do stuff, configure, build kernels, rebuild 'em, etc, reboot, and the system comes up GEOM_MIRROR: Device gm0: provider ada1 detected. GEOM_MIRROR: Device gm0: provider ada1 activated. GEOM_MIRROR: Device gm0: provider ada0 detected. GEOM_MIRROR: Device gm0: provider ada0 activated. GEOM_MIRROR: Device gm0: provider mirror/mirror0 launched. without us noticing. And that's it; if it panics now, savecore won't save the crash dump because ada0 doesn't have it. -- Kamigishi Rei KREI-RIPE From mexas at bristol.ac.uk Fri Jul 31 10:29:38 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 31 10:29:44 2009 Subject: dbus, hal over xdmcp? In-Reply-To: <96c9d6a80906202149q3bdaf42dv88c303b49051f03c@mail.gmail.com> References: <20090430142744.GA32844@mech-cluster238.men.bris.ac.uk> <1241301413.33649.110.camel@shumai.marcuscom.com> <20090616095729.GA98713@mech-cluster238.men.bris.ac.uk> <1245183702.71590.6.camel@shumai.marcuscom.com> <20090617101407.GB84905@mech-cluster238.men.bris.ac.uk> <96c9d6a80906170914i78c0d1fas5ffa77020ec28c36@mail.gmail.com> <20090618152536.GA24358@mech-cluster238.men.bris.ac.uk> <96c9d6a80906180940k7626e581g60c7f1a68006089a@mail.gmail.com> <20090619093836.GA72981@mech-cluster238.men.bris.ac.uk> <96c9d6a80906202149q3bdaf42dv88c303b49051f03c@mail.gmail.com> Message-ID: <20090731102926.GA73358@mech-cluster241.men.bris.ac.uk> On Sat, Jun 20, 2009 at 10:49:10PM -0600, Nathan wrote: > On Fri, Jun 19, 2009 at 3:38 AM, Anton Shterenlikht wrote: > >> 5. ?And add this line right below it: > >> > >> ? ? ? exec gnome-session > > > > I see. So your users don't have $HOME/.xsession files? > > Not that I know of. > > >> 7. ?Edit /etc/ttys so that the ttyv8 line has on instead of off so it > >> looks like: > >> > >> ? ? ? ttyv8 ? "/usr/local/bin/xdm -nodaemon" ?xterm ? on ?secure > > > > I start xdm manually. I was under the impression the above line > > wouldn't work on a headless box. > > Works fine on my headless box. > > > Few more questions, if you please: > > > > What architecture are your XDMCP server and the desktops? > > Do the users start X with -query ? > > server is 7.2-RELEASE-amd64. Clients are HP/NeoWare e90 thin clients. > I don't know the specs exactly. > > The thin clients use their built-in gui, but from my mac I can connect > fine with "X -query (ip) -once" I think I finally got this working, after half a year of trying. I replaced alpha 6.4-stable with ia64 8.0-beta2. All xdm, dbus and hal config options were replicated from the alpha configuration. This would suggest that hal, dbus and XDMCP are not interacting correctly under 6.4 alpha. Now I can get kazekahase to work. many thanks to all who contributed to this thread. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Jul 31 11:03:54 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Jul 31 11:04:00 2009 Subject: ImageMagick warnings: libz.so.4, librpcsvc.so.4 may conflict with *.so.5 Message-ID: <20090731110344.GA44708@mech-cluster241.men.bris.ac.uk> On ia64 SMP 8.0-beta2, building ImageMagick # cd /usr/ports/graphics/ImageMagick # make I get these warnings: /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may confli ct with libz.so.5 /usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may c onflict with librpcsvc.so.5 Usually warnings about different versions of libraries mean that something ought to be updated? Please advise many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From info at tranexp.com Fri Jul 31 12:23:38 2009 From: info at tranexp.com (Translation Experts) Date: Fri Jul 31 12:23:45 2009 Subject: MULTILINGUAL DICTIONARY linking examples without leaving your web pages Message-ID: <20090731115906.7924020B02C7@ls265.t-com.hr> Dear Sir/Madam, We have now upgraded our MULTILINGUAL DICTIONARY linking examples so that your users will no longer leave your web pages. For more information, please go to: http://www.tranexp.com/intertran/linking.cgi?31 We will be very happy to answer any queries you might have. Best regards, Translation Experts From jhb at freebsd.org Fri Jul 31 14:03:50 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Jul 31 14:03:56 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: References: <4A6DB30B.20705@zedat.fu-berlin.de> <20090730170930.GA74245@mech-cluster241.men.bris.ac.uk> Message-ID: <200907310846.34200.jhb@freebsd.org> On Thursday 30 July 2009 1:16:32 pm Marcel Moolenaar wrote: > > On Jul 30, 2009, at 10:09 AM, Anton Shterenlikht wrote: > > > On Thu, Jul 30, 2009 at 10:02:29AM -0700, Marcel Moolenaar wrote: > >> > >> On Jul 30, 2009, at 2:05 AM, Anton Shterenlikht wrote: > >>> By the way, are these two FreeBSD docs up to date: > >>> > >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING > >>> > >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > >>> > >>> In particular, it is still true that minidump is a default dump > >>> type? > >> > >> ia64 doesn't yet have minidumps. In fact, changes to GDB that > >> happened a year ago or so broke the ability to read ia64 core > >> files. I plan on implementing minidumps after 8.0-RELEASE. > > > > you mean, even if I get a dump, I wouldn't be able to read it? > > Correct. > > The change that broke it is: > http://svn.FreeBSD.org/viewvc/base?view=revision&revision=178670 Wait, how did that break ia64 but not other architectures? -- John Baldwin From xcllnt at mac.com Fri Jul 31 16:41:00 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jul 31 16:41:12 2009 Subject: FreeBSD 8.0-BETA2/amd64 crashes on SMP under load In-Reply-To: <200907310846.34200.jhb@freebsd.org> References: <4A6DB30B.20705@zedat.fu-berlin.de> <20090730170930.GA74245@mech-cluster241.men.bris.ac.uk> <200907310846.34200.jhb@freebsd.org> Message-ID: <718AFBEF-DA22-4A5B-8E9A-8C3C2E18DB47@mac.com> On Jul 31, 2009, at 5:46 AM, John Baldwin wrote: > On Thursday 30 July 2009 1:16:32 pm Marcel Moolenaar wrote: >> >> On Jul 30, 2009, at 10:09 AM, Anton Shterenlikht wrote: >> >>> On Thu, Jul 30, 2009 at 10:02:29AM -0700, Marcel Moolenaar wrote: >>>> >>>> On Jul 30, 2009, at 2:05 AM, Anton Shterenlikht wrote: >>>>> By the way, are these two FreeBSD docs up to date: >>>>> >>>>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING >>>>> >>>>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html >>>>> >>>>> In particular, it is still true that minidump is a default dump >>>>> type? >>>> >>>> ia64 doesn't yet have minidumps. In fact, changes to GDB that >>>> happened a year ago or so broke the ability to read ia64 core >>>> files. I plan on implementing minidumps after 8.0-RELEASE. >>> >>> you mean, even if I get a dump, I wouldn't be able to read it? >> >> Correct. >> >> The change that broke it is: >> http://svn.FreeBSD.org/viewvc/base?view=revision&revision=178670 > > Wait, how did that break ia64 but not other architectures? hob% sudo kgdb -n 1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-marcel-freebsd"... GDB can't read core files on this machine. (kgdb) info target Symbols from "/usr/obj/nfs/freebsd/base/head/sys/HOB/kernel.debug". Local exec file: `/usr/obj/nfs/freebsd/base/head/sys/HOB/kernel.debug', file type elf64-ia64-little. Entry point: 0xe000000004068000 0xe000000004000190 - 0xe00000000400019d is .interp 0xe0000000040001a0 - 0xe00000000400b100 is .hash 0xe00000000400b100 - 0xe000000004034cc8 is .dynsym 0xe000000004034cc8 - 0xe0000000040505f3 is .dynstr 0xe0000000040505f8 - 0xe000000004061518 is .rela.data 0xe000000004061518 - 0xe000000004062ad8 is .rela.got 0xe000000004062ad8 - 0xe000000004062af0 is .rela.sdata 0xe000000004068000 - 0xe00000000469fcc0 is .text 0xe00000000469fcc0 - 0xe000000004715884 is .rodata 0xe000000004715890 - 0xe00000000471f350 is .opd 0xe00000000471f350 - 0xe00000000475c0c0 is .IA_64.unwind_info 0xe00000000475c0c0 - 0xe00000000478bc40 is .IA_64.unwind 0xe00000000478e000 - 0xe0000000047f1868 is .data 0xe0000000047f1868 - 0xe0000000047f3a70 is set_sysctl_set 0xe0000000047f3a80 - 0xe0000000047f4780 is set_pcpu 0xe0000000047f4780 - 0xe0000000047f5c48 is set_sysinit_set 0xe0000000047f5c48 - 0xe0000000047f6610 is set_sysuninit_set 0xe0000000047f6610 - 0xe0000000047f70a0 is set_modmetadata_set 0xe0000000047f70a0 - 0xe0000000047f70b8 is set_kdb_dbbe_set 0xe0000000047f70b8 - 0xe0000000047f70c8 is set_gdb_dbgport_set ---Type to continue, or q to quit--- 0xe0000000047f70c8 - 0xe0000000047f70e0 is set_cons_set 0xe0000000047f70e0 - 0xe0000000047f7200 is .dynamic 0xe0000000047f7200 - 0xe000000004810bc8 is .got 0xe000000004810bc8 - 0xe0000000048124dc is .sdata 0xe0000000048124e0 - 0xe000000004814a00 is .sbss 0xe000000004814a00 - 0xe0000000049d52f0 is .bss (kgdb) The stratum of the kgdb target was changed from highest (thread_stratum) to lowest (core_stratum). As such, rather than hide kernel core file details from GDB we became dependent upon them. Simply changing the stratum from core_stratum to thread_stratum shows what's going on: hob% sudo kgdb -n 1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-marcel-freebsd"... warning: "/var/crash/vmcore.1": no core file handler recognizes format, using default In other words: kgdb was designed to hide FreeBSD specifics from the core GDB code, because core GDB doesn't know how to deal with all FreeBSD details. Revision 178670 created a stronger dependency on core GDB and as such broke architectures that core GDB doesn't support for FreeBSD. FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Fri Jul 31 18:11:08 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jul 31 18:11:14 2009 Subject: No 8.0-BETA3 for ia64 & powerpc Message-ID: <84BEFCFB-4E8E-4483-95D4-0D570663E3EF@mac.com> All, I'm on vacation for the next 10 days and that's right at the time of BETA3 unfortunately. So there will be no BETA3 for ia64 and powerpc (unless someone steps up). Keep the testing going and keep reporting problems. They will all be addressed in time for 8.0-RC1!!! Cheers, -- Marcel Moolenaar xcllnt@mac.com From andreast-list at fgznet.ch Fri Jul 31 19:58:16 2009 From: andreast-list at fgznet.ch (Andreas Tobler) Date: Fri Jul 31 19:58:22 2009 Subject: No 8.0-BETA3 for ia64 & powerpc In-Reply-To: <84BEFCFB-4E8E-4483-95D4-0D570663E3EF@mac.com> References: <84BEFCFB-4E8E-4483-95D4-0D570663E3EF@mac.com> Message-ID: <4A7344B4.9060402@fgznet.ch> Hi Marcel, Marcel Moolenaar wrote: > I'm on vacation for the next 10 days and that's right at the time > of BETA3 unfortunately. So there will be no BETA3 for ia64 and > powerpc (unless someone steps up). > > Keep the testing going and keep reporting problems. They will all > be addressed in time for 8.0-RC1!!! Is it sufficent to build (kernel & world) and test -CURRENT svn on powerpc? I did not have the time to test a real BETAx image on powerpc so far, on i386 yes. But if there is a real demand to test a BETA image on ppc I can try to find another disk/machine to test on. Regards, Andreas From xcllnt at mac.com Fri Jul 31 21:45:36 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jul 31 21:45:48 2009 Subject: No 8.0-BETA3 for ia64 & powerpc In-Reply-To: <4A7344B4.9060402@fgznet.ch> References: <84BEFCFB-4E8E-4483-95D4-0D570663E3EF@mac.com> <4A7344B4.9060402@fgznet.ch> Message-ID: <4BB87807-BDD3-45DA-B82A-AAB05F877C4A@mac.com> On Jul 31, 2009, at 12:23 PM, Andreas Tobler wrote: > Hi Marcel, > > Marcel Moolenaar wrote: > >> I'm on vacation for the next 10 days and that's right at the time >> of BETA3 unfortunately. So there will be no BETA3 for ia64 and >> powerpc (unless someone steps up). >> Keep the testing going and keep reporting problems. They will all >> be addressed in time for 8.0-RC1!!! > > Is it sufficent to build (kernel & world) and test -CURRENT svn on > powerpc? Yes, definitely. Just make sure to run... # make delete-old # make delete-old-libs # mergemaster -U ...after the install. That should cleanup some old stuff that may prevent good testing. BTW: A lot of libraries got their version bumped, so all ports/packages need to be rebuilt. FYI, -- Marcel Moolenaar xcllnt@mac.com