From anderson at freebsd.org Sun Feb 1 18:48:09 2009 From: anderson at freebsd.org (Eric Anderson) Date: Sun Feb 1 18:48:15 2009 Subject: Performance numbers? In-Reply-To: References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> Message-ID: <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> On Jan 30, 2009, at 2:50 PM, Ivan Voras wrote: > Eric Anderson wrote: >> Hi GEOMers! >> >> Does anyone have any benchmarks or numbers relating to GEOM >> performance? >> >> I tried doing some on my own, but I didn't get very satisfactory >> results, so I'm curious what others have seen or used. >> >> My hardware is a Core 2 Quad, with 4GB of ram. >> >> First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I >> tried running such tools as rawio, and diskinfo. rawio fails with >> input/output errors, and diskinfo wants a larger device to give the >> full >> stats. I ended up using purely dd since that worked. Interestingly >> enough, dd'ing to the malloc device results in about 1000 >> operations per >> second, regardless of a blocksize of 512bytes or 1MB. > > It's a good idea for testing. > > 1000 ops/s looks suspiciously like HZ, though I don't know why HZ > would > influence GEOM (AFAIK context switches between threads, including GEOM > threads do not depend on it) - can you try ruling out HZ? > Is there a way to pump the data through the GEOM layers without doing a mdconfig'd disk? Also, are you thinking setting the hz to some other setting, and rerunning? What setting were you thinking? I can easily try anything. Thanks! Eric From ivoras at freebsd.org Mon Feb 2 01:16:53 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Feb 2 01:17:00 2009 Subject: Performance numbers? In-Reply-To: <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> Message-ID: Eric Anderson wrote: > > On Jan 30, 2009, at 2:50 PM, Ivan Voras wrote: > >> Eric Anderson wrote: >>> Hi GEOMers! >>> >>> Does anyone have any benchmarks or numbers relating to GEOM performance? >>> >>> I tried doing some on my own, but I didn't get very satisfactory >>> results, so I'm curious what others have seen or used. >>> >>> My hardware is a Core 2 Quad, with 4GB of ram. >>> >>> First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. Then, I >>> tried running such tools as rawio, and diskinfo. rawio fails with >>> input/output errors, and diskinfo wants a larger device to give the full >>> stats. I ended up using purely dd since that worked. Interestingly >>> enough, dd'ing to the malloc device results in about 1000 operations per >>> second, regardless of a blocksize of 512bytes or 1MB. >> >> It's a good idea for testing. >> >> 1000 ops/s looks suspiciously like HZ, though I don't know why HZ would >> influence GEOM (AFAIK context switches between threads, including GEOM >> threads do not depend on it) - can you try ruling out HZ? > > Is there a way to pump the data through the GEOM layers without doing a > mdconfig'd disk? You could use gzero, it ignores written data and produces read data with memset. > Also, are you thinking setting the hz to some other setting, and > rerunning? What setting were you thinking? I can easily try anything. Yes. Try 1500. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090202/7bae22a9/signature.pgp From bugmaster at FreeBSD.org Mon Feb 2 03:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 2 03:07:54 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200902021106.n12B6otd094424@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 kern/131037 geom [geli] Unable to create disklabel on .eli-Device o bin/130632 geom [patch] gpart(8) assert failure if used from FreeBSD L o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 45 problems total. From lulf at FreeBSD.org Mon Feb 2 11:09:34 2009 From: lulf at FreeBSD.org (lulf@FreeBSD.org) Date: Mon Feb 2 11:09:41 2009 Subject: bin/130632: [patch] gpart(8) assert failure if used from FreeBSD Live CD Message-ID: <200902021909.n12J9YWp061635@freefall.freebsd.org> Synopsis: [patch] gpart(8) assert failure if used from FreeBSD Live CD Responsible-Changed-From-To: freebsd-geom->lulf Responsible-Changed-By: lulf Responsible-Changed-When: Mon Feb 2 19:08:39 UTC 2009 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=130632 From anderson at freebsd.org Tue Feb 3 05:08:05 2009 From: anderson at freebsd.org (Eric Anderson) Date: Tue Feb 3 05:08:12 2009 Subject: Performance numbers? In-Reply-To: References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> Message-ID: On Feb 2, 2009, at 3:16 AM, Ivan Voras wrote: > Eric Anderson wrote: >> >> On Jan 30, 2009, at 2:50 PM, Ivan Voras wrote: >> >>> Eric Anderson wrote: >>>> Hi GEOMers! >>>> >>>> Does anyone have any benchmarks or numbers relating to GEOM >>>> performance? >>>> >>>> I tried doing some on my own, but I didn't get very satisfactory >>>> results, so I'm curious what others have seen or used. >>>> >>>> My hardware is a Core 2 Quad, with 4GB of ram. >>>> >>>> First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. >>>> Then, I >>>> tried running such tools as rawio, and diskinfo. rawio fails with >>>> input/output errors, and diskinfo wants a larger device to give >>>> the full >>>> stats. I ended up using purely dd since that worked. >>>> Interestingly >>>> enough, dd'ing to the malloc device results in about 1000 >>>> operations per >>>> second, regardless of a blocksize of 512bytes or 1MB. >>> >>> It's a good idea for testing. >>> >>> 1000 ops/s looks suspiciously like HZ, though I don't know why HZ >>> would >>> influence GEOM (AFAIK context switches between threads, including >>> GEOM >>> threads do not depend on it) - can you try ruling out HZ? >> >> Is there a way to pump the data through the GEOM layers without >> doing a >> mdconfig'd disk? > > You could use gzero, it ignores written data and produces read data > with > memset. Ok, I tried gzero, and now the numbers are *much* different. I'm getting roughly 60,000 ops/s now single threaded, or about 140,000 ops/ s using 4 threads. Much better! :) I could not for the life of me remember geom_zero, so thanks for the reminder. > > >> Also, are you thinking setting the hz to some other setting, and >> rerunning? What setting were you thinking? I can easily try >> anything. > > Yes. Try 1500. > I think I'll skip that now that I have gzero working giving me more realistic numbers. Eric From anderson at vnode.org Tue Feb 3 05:38:08 2009 From: anderson at vnode.org (Eric Anderson) Date: Tue Feb 3 05:38:15 2009 Subject: Performance numbers? In-Reply-To: References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> Message-ID: <4E34132B-9EFF-4108-8E50-80A5CE186EAB@vnode.org> On Feb 2, 2009, at 3:16 AM, Ivan Voras wrote: > Eric Anderson wrote: >> >> On Jan 30, 2009, at 2:50 PM, Ivan Voras wrote: >> >>> Eric Anderson wrote: >>>> Hi GEOMers! >>>> >>>> Does anyone have any benchmarks or numbers relating to GEOM >>>> performance? >>>> >>>> I tried doing some on my own, but I didn't get very satisfactory >>>> results, so I'm curious what others have seen or used. >>>> >>>> My hardware is a Core 2 Quad, with 4GB of ram. >>>> >>>> First, I made an mdconfig'ed malloc backed 'disk' of 1.5GB. >>>> Then, I >>>> tried running such tools as rawio, and diskinfo. rawio fails with >>>> input/output errors, and diskinfo wants a larger device to give >>>> the full >>>> stats. I ended up using purely dd since that worked. >>>> Interestingly >>>> enough, dd'ing to the malloc device results in about 1000 >>>> operations per >>>> second, regardless of a blocksize of 512bytes or 1MB. >>> >>> It's a good idea for testing. >>> >>> 1000 ops/s looks suspiciously like HZ, though I don't know why HZ >>> would >>> influence GEOM (AFAIK context switches between threads, including >>> GEOM >>> threads do not depend on it) - can you try ruling out HZ? >> >> Is there a way to pump the data through the GEOM layers without >> doing a >> mdconfig'd disk? > > You could use gzero, it ignores written data and produces read data > with > memset. Ok, I tried gzero, and now the numbers are *much* different. I'm getting roughly 60,000 ops/s now single threaded, or about 140,000 ops/ s using 4 threads. Much better! :) I could not for the life of me remember geom_zero, so thanks for the reminder. > > >> Also, are you thinking setting the hz to some other setting, and >> rerunning? What setting were you thinking? I can easily try >> anything. > > Yes. Try 1500. > I think I'll skip that now that I have gzero working giving me more realistic numbers. Eric From anderson at freebsd.org Tue Feb 3 06:19:03 2009 From: anderson at freebsd.org (Eric Anderson) Date: Tue Feb 3 06:19:09 2009 Subject: Performance numbers? In-Reply-To: <9bbcef730902030554m501e961clf755fefc299aac75@mail.gmail.com> References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> <9bbcef730902030554m501e961clf755fefc299aac75@mail.gmail.com> Message-ID: On Feb 3, 2009, at 7:54 AM, Ivan Voras wrote: > 2009/2/3 Eric Anderson : > >> Ok, I tried gzero, and now the numbers are *much* different. I'm >> getting >> roughly 60,000 ops/s now single threaded, or about 140,000 ops/s >> using 4 >> threads. Much better! :) I could not for the life of me remember >> geom_zero, so thanks for the reminder. > > What do you mean by "4 threads"? 4 parallel instances of dd? Yes. Eric From ivoras at freebsd.org Tue Feb 3 06:27:41 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Feb 3 06:27:48 2009 Subject: Performance numbers? In-Reply-To: References: <6612C205-C346-4493-9DA4-3B5A73E9A4F7@freebsd.org> <9C533E30-BD08-4938-8D1A-5CE046FB6BF6@freebsd.org> Message-ID: <9bbcef730902030554m501e961clf755fefc299aac75@mail.gmail.com> 2009/2/3 Eric Anderson : > Ok, I tried gzero, and now the numbers are *much* different. I'm getting > roughly 60,000 ops/s now single threaded, or about 140,000 ops/s using 4 > threads. Much better! :) I could not for the life of me remember > geom_zero, so thanks for the reminder. What do you mean by "4 threads"? 4 parallel instances of dd? From davej at wsnet.co.za Wed Feb 4 04:33:46 2009 From: davej at wsnet.co.za (Dave Johnson) Date: Wed Feb 4 04:33:51 2009 Subject: Different size drives Message-ID: <1233747202.20913.9.camel@susedesk> Hi All Is there a way to get geom to ignore the size of the 2nd drive? Both drives are 250GB The "slave" is a 100k larger. Regards From ulf.lilleengen at gmail.com Wed Feb 4 07:33:43 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Wed Feb 4 07:33:49 2009 Subject: Different size drives In-Reply-To: <1233747202.20913.9.camel@susedesk> References: <1233747202.20913.9.camel@susedesk> Message-ID: <20090204163416.GB1293@carrot.BalPol.Local> On ons, feb 04, 2009 at 01:33:22pm +0200, Dave Johnson wrote: > Hi All > > Is there a way to get geom to ignore the size of the 2nd drive? > > Both drives are 250GB > In what context? -- Ulf Lilleengen From ivoras at freebsd.org Wed Feb 4 07:46:39 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Feb 4 07:46:45 2009 Subject: Different size drives In-Reply-To: <1233747202.20913.9.camel@susedesk> References: <1233747202.20913.9.camel@susedesk> Message-ID: Dave Johnson wrote: > Hi All > > Is there a way to get geom to ignore the size of the 2nd drive? > > Both drives are 250GB > > The "slave" is a 100k larger. If you're asking about gmirror, it should automatically "just work". I have a configuration like that (different drive manufacturers, different sector counts): ~> gmirror list Geom name: gm0 State: COMPLETE Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 0 SyncID: 2 ID: 468895920 Providers: 1. Name: mirror/gm0 Mediasize: 80026361344 (75G) Sectorsize: 512 Mode: r7w7e8 Consumers: 1. Name: ad0 Mediasize: 80026361856 (75G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 2 ID: 1459003038 2. Name: ad2 Mediasize: 81964302336 (76G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 2 ID: 1951693847 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090204/85b54266/signature.pgp From ulf.lilleengen at gmail.com Wed Feb 4 08:10:26 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Wed Feb 4 08:10:32 2009 Subject: Different size drives In-Reply-To: <1233762664.20913.53.camel@susedesk> References: <1233747202.20913.9.camel@susedesk> <20090204163416.GB1293@carrot.BalPol.Local> <1233762664.20913.53.camel@susedesk> Message-ID: <20090204171056.GA36355@carrot.BalPol.Local> On Wed, Feb 04, 2009 at 05:51:03PM +0200, Dave Johnson wrote: > Hi > > Thanks for the reply > > > Example > > master drive(ad0) 100014 > > slave(ad1) 100000 > > We need to "clone" from master to slave > > geom comes back with > > mail# gmirror insert gm0 /dev/ad1 > gmirror: Provider ad1 too small. Oh, hmm. You have already a filesystem setup and everything on the "master" mirror? If so, I'm not sure if you can do this without recreating the gmirror, as the filesystem expects a provider of the master size, and attaching a smaller slave which can't mirror all the master data won't really work. The other way around is ofcourse much easier. -- Ulf Lilleengen From bugmaster at FreeBSD.org Mon Feb 9 03:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 9 03:07:59 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200902091106.n19B6oj5009105@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 kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 44 problems total. From gavin at FreeBSD.org Wed Feb 11 03:47:28 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Feb 11 03:47:39 2009 Subject: kern/131575: [geom_label] [msdosfs] [umass] Immediate crash after plug of an USB key Message-ID: <200902111147.n1BBlR4w095688@freefall.freebsd.org> Old Synopsis: Immediate crash after plug of an USB key New Synopsis: [geom_label] [msdosfs] [umass] Immediate crash after plug of an USB key Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Wed Feb 11 11:45:49 UTC 2009 Responsible-Changed-Why: I suspect this is something to do with geom_label, over to maintainer(s) to analyze further http://www.freebsd.org/cgi/query-pr.cgi?pr=131575 From dfilter at FreeBSD.ORG Wed Feb 11 10:20:05 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Feb 11 10:20:12 2009 Subject: kern/131575: commit references a PR Message-ID: <200902111820.n1BIK4JT087517@freefall.freebsd.org> The following reply was made to PR kern/131575; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131575: commit references a PR Date: Wed, 11 Feb 2009 18:13:35 +0000 (UTC) Author: lulf Date: Wed Feb 11 18:13:20 2009 New Revision: 188492 URL: http://svn.freebsd.org/changeset/base/188492 Log: - Use the correct argument when determining the buffer size. PR: kern/131575 MFC after: 2 days Modified: head/sys/geom/label/g_label_msdosfs.c Modified: head/sys/geom/label/g_label_msdosfs.c ============================================================================== --- head/sys/geom/label/g_label_msdosfs.c Wed Feb 11 17:33:36 2009 (r188491) +++ head/sys/geom/label/g_label_msdosfs.c Wed Feb 11 18:13:20 2009 (r188492) @@ -186,7 +186,7 @@ g_label_msdosfs_taste(struct g_consumer FAT_DES_ATTR_VOLUME_ID) { strlcpy(label, pfat_entry->DIR_Name, MIN(size, - sizeof(pfat_bsbpb->BS_VolLab) + 1)); + sizeof(pfat_entry->DIR_Name) + 1)); goto endofchecks; } } while((uint8_t *)(++pfat_entry) < _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From ulf.lilleengen at gmail.com Wed Feb 11 11:00:14 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Wed Feb 11 11:00:25 2009 Subject: kern/131575: commit references a PR Message-ID: <200902111900.n1BJ082k017147@freefall.freebsd.org> The following reply was made to PR kern/131575; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@freebsd.org Cc: Subject: Re: kern/131575: commit references a PR Date: Wed, 11 Feb 2009 19:36:29 +0000 On Wednesday 11 February 2009 18:20:04 dfilter service wrote: > The following reply was made to PR kern/131575; it has been noted by GNATS. > > From: dfilter@FreeBSD.ORG (dfilter service) > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/131575: commit references a PR > Date: Wed, 11 Feb 2009 18:13:35 +0000 (UTC) > > Author: lulf > Date: Wed Feb 11 18:13:20 2009 > New Revision: 188492 > URL: http://svn.freebsd.org/changeset/base/188492 > > Log: > - Use the correct argument when determining the buffer size. > > PR: kern/131575 > MFC after: 2 days > I think this might fix the issue, as it was in this line was in the backtrace. -- Ulf Lilleengen From dfilter at FreeBSD.ORG Fri Feb 13 11:50:07 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Feb 13 11:50:25 2009 Subject: kern/131575: commit references a PR Message-ID: <200902131950.n1DJo7Pd079137@freefall.freebsd.org> The following reply was made to PR kern/131575; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131575: commit references a PR Date: Fri, 13 Feb 2009 19:49:52 +0000 (UTC) Author: lulf Date: Fri Feb 13 19:49:35 2009 New Revision: 188596 URL: http://svn.freebsd.org/changeset/base/188596 Log: MFC r188492: - Use the correct argument when determining the buffer size. PR: kern/131575 Modified: stable/7/sys/ (props changed) stable/7/sys/contrib/pf/ (props changed) stable/7/sys/dev/ath/ath_hal/ (props changed) stable/7/sys/dev/cxgb/ (props changed) stable/7/sys/geom/label/g_label_msdosfs.c Modified: stable/7/sys/geom/label/g_label_msdosfs.c ============================================================================== --- stable/7/sys/geom/label/g_label_msdosfs.c Fri Feb 13 19:25:35 2009 (r188595) +++ stable/7/sys/geom/label/g_label_msdosfs.c Fri Feb 13 19:49:35 2009 (r188596) @@ -186,7 +186,7 @@ g_label_msdosfs_taste(struct g_consumer FAT_DES_ATTR_VOLUME_ID) { strlcpy(label, pfat_entry->DIR_Name, MIN(size, - sizeof(pfat_bsbpb->BS_VolLab) + 1)); + sizeof(pfat_entry->DIR_Name) + 1)); goto endofchecks; } } while((uint8_t *)(++pfat_entry) < _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Feb 16 03:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 16 03:07:58 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200902161106.n1GB6oCi096115@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 kern/131575 geom [geom_label] [msdosfs] [umass] Immediate crash after p o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 45 problems total. From ota at j.email.ne.jp Wed Feb 18 22:20:04 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Wed Feb 18 22:20:10 2009 Subject: kern/130528: gjournal fsck during boot Message-ID: <200902190620.n1J6K2L0095472@freefall.freebsd.org> The following reply was made to PR kern/130528; it has been noted by GNATS. From: Yoshihiro Ota To: bug-followup@FreeBSD.org Cc: barzog@telecom.by Subject: Re: kern/130528: gjournal fsck during boot Date: Thu, 19 Feb 2009 01:18:02 -0500 Hi, Oleg. Can you run "cat /etc/fstab" and "tunefs -p /dev/da0.journal" to get more information? I think I had similar issues like this due to inappropriate fstab entry. Thanks, Hiro From barzog at telecom.by Thu Feb 19 00:00:06 2009 From: barzog at telecom.by (Oleg Gawriloff) Date: Thu Feb 19 00:00:13 2009 Subject: kern/130528: gjournal fsck during boot Message-ID: <200902190800.n1J805dF001323@freefall.freebsd.org> The following reply was made to PR kern/130528; it has been noted by GNATS. From: Oleg Gawriloff To: bug-followup@FreeBSD.org, ota@j.email.ne.jp Cc: Subject: Re: kern/130528: gjournal fsck during boot Date: Thu, 19 Feb 2009 09:50:13 +0200 This is a cryptographically signed message in MIME format. --------------ms070400070203000509010903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit [barzog@albatros2 ~]$ cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1d /tmp ufs rw 2 2 /dev/mirror/gm0s1e /usr ufs rw 2 2 /dev/mirror/gm0s1f /var ufs rw 2 2 /dev/da0.journal /mnt/StorageA ufs rw,async 0 0 /dev/da1.journal /mnt/StorageB ufs rw,async 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 martin:/usr/ports /usr/ports nfs rw,noauto 0 0 172.16.2.1:/var/tmp/backup2 /mnt/backup2 nfs rw,noauto 0 0 [barzog@albatros2 ~]$ sudo tunefs -p /dev/da0.journal tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: gjournal: (-J) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) [barzog@albatros2 ~]$ sudo tunefs -p /dev/da1.journal tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: gjournal: (-J) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) --------------ms070400070203000509010903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHtDCC A9YwggM/oAMCAQICAgJSMA0GCSqGSIb3DQEBBAUAMIGYMQswCQYDVQQGEwJCWTEQMA4GA1UE CBMHQmVsYXJ1czEOMAwGA1UEBxMFTWluc2sxFzAVBgNVBAoTDkF0bGFudC1UZWxlY29tMRcw FQYDVQQLEw5BdGxhbnQtVGVsZWNvbTETMBEGA1UEAxMKdGVsZWNvbS5ieTEgMB4GCSqGSIb3 DQEJARYRYmFyem9nQHRlbGVjb20uYnkwHhcNMDgwNzMwMTIxMjQzWhcNMDkwNzMwMTIxMjQz WjCBnzELMAkGA1UEBhMCQlkxEDAOBgNVBAgTB0JlbGFydXMxDjAMBgNVBAcTBU1pbnNrMRcw FQYDVQQKEw5BdGxhbnQtVGVsZWNvbTEXMBUGA1UECxMOQXRsYW50LVRlbGVjb20xGjAYBgNV BAMUEWJhcnpvZ0B0ZWxlY29tLmJ5MSAwHgYJKoZIhvcNAQkBFhFiYXJ6b2dAdGVsZWNvbS5i eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuFEB0E3OhT/9NkCYZLGgM3PQfiJfTO2b kLfqnAneaC1+/U9WY9c5dleB3KpMxAl/Y9HWo3ClaVZ2Z56V3nj0f9KUTd1Up9G5LgGvP8VJ s5NLiiRqJ9isPx44yEuHTwEhGl/zotlTD0rRLVHfqof1cqDe3TobsaevJv0uX1MORRUCAwEA AaOCASQwggEgMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVk IENlcnRpZmljYXRlMB0GA1UdDgQWBBSGPX6kqHA5V5oSbuhmF4Nzx9GNjjCBxQYDVR0jBIG9 MIG6gBQ1Q0N4+R+9Wg0AAlfWqtErWCUf9aGBnqSBmzCBmDELMAkGA1UEBhMCQlkxEDAOBgNV BAgTB0JlbGFydXMxDjAMBgNVBAcTBU1pbnNrMRcwFQYDVQQKEw5BdGxhbnQtVGVsZWNvbTEX MBUGA1UECxMOQXRsYW50LVRlbGVjb20xEzARBgNVBAMTCnRlbGVjb20uYnkxIDAeBgkqhkiG 9w0BCQEWEWJhcnpvZ0B0ZWxlY29tLmJ5ggEAMA0GCSqGSIb3DQEBBAUAA4GBACyUjVy0C0C7 6Wt9w5dAfxLtFXLPIn+dxRWK0r6G/F4a7mLmSHy2fDzn/PSNEDLh+KUpNQNfvXwVdY3ftLVS L6gkSNNnbgkiXH2MxlvGHFH+NWbLkNE+t16/OUSIh2iRu1paEKZPtA7f6VviSZ10dTsuKszC a85hdq+9cP8Ph3EuMIID1jCCAz+gAwIBAgICAlIwDQYJKoZIhvcNAQEEBQAwgZgxCzAJBgNV BAYTAkJZMRAwDgYDVQQIEwdCZWxhcnVzMQ4wDAYDVQQHEwVNaW5zazEXMBUGA1UEChMOQXRs YW50LVRlbGVjb20xFzAVBgNVBAsTDkF0bGFudC1UZWxlY29tMRMwEQYDVQQDEwp0ZWxlY29t LmJ5MSAwHgYJKoZIhvcNAQkBFhFiYXJ6b2dAdGVsZWNvbS5ieTAeFw0wODA3MzAxMjEyNDNa Fw0wOTA3MzAxMjEyNDNaMIGfMQswCQYDVQQGEwJCWTEQMA4GA1UECBMHQmVsYXJ1czEOMAwG A1UEBxMFTWluc2sxFzAVBgNVBAoTDkF0bGFudC1UZWxlY29tMRcwFQYDVQQLEw5BdGxhbnQt VGVsZWNvbTEaMBgGA1UEAxQRYmFyem9nQHRlbGVjb20uYnkxIDAeBgkqhkiG9w0BCQEWEWJh cnpvZ0B0ZWxlY29tLmJ5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4UQHQTc6FP/02 QJhksaAzc9B+Il9M7ZuQt+qcCd5oLX79T1Zj1zl2V4HcqkzECX9j0dajcKVpVnZnnpXeePR/ 0pRN3VSn0bkuAa8/xUmzk0uKJGon2Kw/HjjIS4dPASEaX/Oi2VMPStEtUd+qh/VyoN7dOhux p68m/S5fUw5FFQIDAQABo4IBJDCCASAwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3Bl blNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFIY9fqSocDlXmhJu6GYXg3PH 0Y2OMIHFBgNVHSMEgb0wgbqAFDVDQ3j5H71aDQACV9aq0StYJR/1oYGepIGbMIGYMQswCQYD VQQGEwJCWTEQMA4GA1UECBMHQmVsYXJ1czEOMAwGA1UEBxMFTWluc2sxFzAVBgNVBAoTDkF0 bGFudC1UZWxlY29tMRcwFQYDVQQLEw5BdGxhbnQtVGVsZWNvbTETMBEGA1UEAxMKdGVsZWNv bS5ieTEgMB4GCSqGSIb3DQEJARYRYmFyem9nQHRlbGVjb20uYnmCAQAwDQYJKoZIhvcNAQEE BQADgYEALJSNXLQLQLvpa33Dl0B/Eu0Vcs8if53FFYrSvob8XhruYuZIfLZ8POf89I0QMuH4 pSk1A1+9fBV1jd+0tVIvqCRI02duCSJcfYzGW8YcUf41ZsuQ0T63Xr85RIiHaJG7WloQpk+0 Dt/pW+JJnXR1Oy4qzMJrzmF2r71w/w+HcS4xggNjMIIDXwIBATCBnzCBmDELMAkGA1UEBhMC QlkxEDAOBgNVBAgTB0JlbGFydXMxDjAMBgNVBAcTBU1pbnNrMRcwFQYDVQQKEw5BdGxhbnQt VGVsZWNvbTEXMBUGA1UECxMOQXRsYW50LVRlbGVjb20xEzARBgNVBAMTCnRlbGVjb20uYnkx IDAeBgkqhkiG9w0BCQEWEWJhcnpvZ0B0ZWxlY29tLmJ5AgICUjAJBgUrDgMCGgUAoIICGTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMTkwNzUwMTNa MCMGCSqGSIb3DQEJBDEWBBQ9krIA8stZsySWj9jzaawBn6XxETBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCBsAYJKwYBBAGCNxAEMYGiMIGfMIGYMQswCQYDVQQGEwJCWTEQMA4G A1UECBMHQmVsYXJ1czEOMAwGA1UEBxMFTWluc2sxFzAVBgNVBAoTDkF0bGFudC1UZWxlY29t MRcwFQYDVQQLEw5BdGxhbnQtVGVsZWNvbTETMBEGA1UEAxMKdGVsZWNvbS5ieTEgMB4GCSqG SIb3DQEJARYRYmFyem9nQHRlbGVjb20uYnkCAgJSMIGyBgsqhkiG9w0BCRACCzGBoqCBnzCB mDELMAkGA1UEBhMCQlkxEDAOBgNVBAgTB0JlbGFydXMxDjAMBgNVBAcTBU1pbnNrMRcwFQYD VQQKEw5BdGxhbnQtVGVsZWNvbTEXMBUGA1UECxMOQXRsYW50LVRlbGVjb20xEzARBgNVBAMT CnRlbGVjb20uYnkxIDAeBgkqhkiG9w0BCQEWEWJhcnpvZ0B0ZWxlY29tLmJ5AgICUjANBgkq hkiG9w0BAQEFAASBgLYZJ7X0bZ6fJj2/L6MDv6l2SaunuM4dlLJfeaQ/ul89uavMToeQQb3X dkcTLxMvAkdvO+qXExXXsCAETqq5Dc4dC1LDmMdZYCey4gYSEg+9Mg1ZiPpRIwe7rvPm+/V9 tTs69Y5Rw5TfSeS+s0TD+XdN2yu6zKsiyhqGvjnlWrMkAAAAAAAA --------------ms070400070203000509010903-- From ota at j.email.ne.jp Thu Feb 19 19:50:03 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Thu Feb 19 19:50:09 2009 Subject: kern/130528: gjournal fsck during boot Message-ID: <200902200350.n1K3o3tr003559@freefall.freebsd.org> The following reply was made to PR kern/130528; it has been noted by GNATS. From: Yoshihiro Ota To: bug-followup@FreeBSD.org Cc: barzog@telecom.by Subject: Re: kern/130528: gjournal fsck during boot Date: Thu, 19 Feb 2009 22:46:37 -0500 Hi, Oleg. Pass# being set to 0 is the cause of the problem. Set them to 2 and try. /dev/da0.journal /mnt/StorageA ufs rw,async 0 =>0<= /dev/da1.journal /mnt/StorageB ufs rw,async 0 =>0<= Even with journaled-fs, fs needs to be verified that if it is clean, or if is consistent in case of crash. Setting them to 2 will enable this. Check this one first; this explains what is going on very well: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=59690+0+archive/2008/freebsd-geom/20080831.freebsd-geom Then, related posts in the following page. http://docs.freebsd.org/mail/archive/2008/freebsd-geom/20080831.freebsd-geom.html I think these will help you to understand gjournal. Regards, Hiro From bugmaster at FreeBSD.org Mon Feb 23 03:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 23 03:07:46 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200902231106.n1NB6pGW055493@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 kern/131575 geom [geom_label] [msdosfs] [umass] Immediate crash after p o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 45 problems total. From listat at apz.fi Wed Feb 25 15:09:10 2009 From: listat at apz.fi (=?ISO-8859-1?Q?Ari_Sovij=E4rvi?=) Date: Wed Feb 25 15:09:17 2009 Subject: GEOM_ELI with device crypto makes root unmountable Message-ID: <49A5CBEC.4000905@apz.fi> Hi all! I have a Sparc64 FreeBSD 7.1 system running on Fire V100 with root on a Gmirror device. I recently read about GELI and decided to encrypt one of the partitions on that machine. My kernel config is basically generic with quota being the only added option. The system worked perfectly fine, until I recompiled the kernel with the following options added (as instructed by the handbook): device crypto options GEOM_ELI With those 2 options, the system completely skips detecting almost all of the hardware (including the HDD controller) and then fails as it can't find root. Apparently something is very wrong, but I can't figure out what's the cause. Any ideas? Here's the dmesg up to the point where it can't find the root partition: Sun Fire V100 (UltraSPARC-IIe 548MHz), No Keyboard OpenBoot 4.0, 1024 MB memory installed, Serial #54159000. Ethernet address 0:3:ba:3a:00:00, Host ID: 833a0000. Executing last command: boot /pci@1f,0/ide@d/disk@0,0:a Boot device: /pci@1f,0/ide@d/disk@0,0:a File and args: >> FreeBSD/sparc64 boot block Boot path: /pci@1f,0/ide@d/disk@0,0:a Boot loader: /boot/loader Consoles: Open Firmware console Booting with sun4u support. FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@basestar2, Fri Jan 30 22:41:13 EET 2009) bootpath="/pci@1f,0/ide@d/disk@0,0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x491f48+0x60328 syms=[0x8+0x5f8c8+0x8+0x53869] /boot/kernel/geom_mirror.ko text=0x36440 data=0x5c8+0x18 syms=[0x8+0x1548+0x8+0x1005] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc0060000. 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 7.1-RELEASE-p3 #2: Wed Feb 25 22:05:18 EET 2009 root@basestar2:/usr/obj/usr/src/sys/RAINFALL Timecounter "tick" frequency 548000000 Hz quality 1000 real memory = 1073741824 (1024 MB) avail memory = 1035673600 (987 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (548.00 MHz CPU) kbd0 at kbdmux0 nexus0: cryptosoft1: mem 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe010 cryptosoft0: on nexus0 nexus0: type unknown (no driver attached) Timecounters tick every 1.000 msec Trying to mount root from ufs:/dev/mirror/raid0a Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input mountroot> ufs:/dev/mirror/raid0a Trying to mount root from ufs:/dev/mirror/raid0a Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input mountroot> panic: Root mount failed, startup aborted. -- Ari Sovij?rvi From server at apz.fi Wed Feb 25 17:44:10 2009 From: server at apz.fi (=?ISO-8859-1?Q?Ari_Sovij=E4rvi?=) Date: Wed Feb 25 17:44:16 2009 Subject: GEOM_ELI with device crypto makes root unmountable Message-ID: <49A5F04C.1060302@apz.fi> Hi again! I managed to debug the problem a bit further and it'd seem it's not GEOM_ELI, but the 'device crypto'-line that causes the problem. Apparently the same problem exists in other platforms aswell; I found a post about identical problem in PowerPC. Anyway, false alarm, sorry :) -- Ari Sovij?rvi From ota at j.email.ne.jp Wed Feb 25 19:06:24 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Wed Feb 25 19:06:31 2009 Subject: GEOM_ELI with device crypto makes root unmountable In-Reply-To: <49A5F04C.1060302@apz.fi> References: <49A5F04C.1060302@apz.fi> Message-ID: <20090225214818.bb3e6d2c.ota@j.email.ne.jp> On Thu, 26 Feb 2009 03:28:44 +0200 Ari Sovij?rvi wrote: > Hi again! > > I managed to debug the problem a bit further and it'd seem it's not GEOM_ELI, > but the 'device crypto'-line that causes the problem. Apparently the same > problem exists in other platforms aswell; I found a post about identical > problem in PowerPC. > > Anyway, false alarm, sorry :) That may be something you need to send a PR. By the way, I use geli with geom_geli_load="YES" in /boot/loeader.conf. I never had such problems. Regards, Hiro From listat at apz.fi Wed Feb 25 20:55:20 2009 From: listat at apz.fi (=?UTF-8?B?QXJpIFNvdmlqw6Rydmk=?=) Date: Wed Feb 25 20:55:27 2009 Subject: GEOM_ELI with device crypto makes root unmountable In-Reply-To: <20090225214818.bb3e6d2c.ota@j.email.ne.jp> References: <49A5F04C.1060302@apz.fi> <20090225214818.bb3e6d2c.ota@j.email.ne.jp> Message-ID: <49A620B2.4070307@apz.fi> Yoshihiro Ota wrote: > That may be something you need to send a PR. > By the way, I use geli with geom_geli_load="YES" in /boot/loeader.conf. > I never had such problems. I will send a PR about this. You might not have been hit by this bug if you're not a PowerPC or Sparc user. I've been reading up about the problem all night and it'd seem it was first discovered in 7.0, but for some reason the fix never got into 7.1. -- Ari Sovij?rvi From avg at freebsd.org Thu Feb 26 08:41:45 2009 From: avg at freebsd.org (Andriy Gapon) Date: Thu Feb 26 08:41:52 2009 Subject: gpart bootcode and /boot/boot In-Reply-To: <4978C24D.9040706@icyb.net.ua> References: <4978C24D.9040706@icyb.net.ua> Message-ID: <49A6C33E.70402@freebsd.org> on 22/01/2009 21:00 Andriy Gapon said the following: > Sorry for being lazy - what is "gpart bootcode" equivalent of bsdlabel > -B [-b boot] ? > Marcel, guys, I am still curious. disklabel -B refuses do to anything because of what it thinks is incorrect partition info. And the following command gets "Operation not permitted" when it opens ad6s1 for writing: gpart bootcode -p /boot/boot -i 1 ad6 This is amd64, stable/7, gpart-only kernel (gpart_mbr, gpart_bsd). -- Andriy Gapon From xcllnt at mac.com Thu Feb 26 09:54:39 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Feb 26 09:54:46 2009 Subject: gpart bootcode and /boot/boot In-Reply-To: <49A6C33E.70402@freebsd.org> References: <4978C24D.9040706@icyb.net.ua> <49A6C33E.70402@freebsd.org> Message-ID: On Feb 26, 2009, at 8:28 AM, Andriy Gapon wrote: > on 22/01/2009 21:00 Andriy Gapon said the following: >> Sorry for being lazy - what is "gpart bootcode" equivalent of >> bsdlabel >> -B [-b boot] ? >> > > Marcel, guys, I am still curious. > > disklabel -B refuses do to anything because of what it thinks is > incorrect > partition info. > > And the following command gets "Operation not permitted" when it > opens ad6s1 for > writing: > gpart bootcode -p /boot/boot -i 1 ad6 Don't you mean "gpart bootcode -b /boot/boot ad6s1" If you say "-i 1 ad6", then what you want is bootcode in a partition that is controlled by the scheme on ad6 (the scheme on ad6 is the MBR). You can't do that, because that partition is sub-partitioned by the BSD scheme. Since you want bootcode in the BSD scheme, you need to add bootcode to ad6s1. > > This is amd64, stable/7, gpart-only kernel (gpart_mbr, gpart_bsd). Bootcode for the BSD scheme is not present in 7-STABLE yet. I just recently added that to -CURRENT (I must have missed it) and I need to get around MFCing it. Feel free to do the MFC for me. The code has been in -CURRENT long enough to do a MFC. FYI, -- Marcel Moolenaar xcllnt@mac.com