Re: minphys woes
is it something msdos isnt doing that ffs does? On 29 Aug 2014, at 15:55, Stefan Fritsch wrote: > On Friday 29 August 2014 10:34:20, David Gwynne wrote: >> are you expecting minphys to appear in that backtrace? > > > No. In that trace minphys should have limited the transfer size and I > had put an KASSERT() into vioblk_scsi_cmd() which verified that xs- >> datalen is not larger than that limit. A call to bread() causes the > KASSERT to trigger.
Re: newfs.8
On Fri, Aug 29, 2014 at 12:13:58AM -0400, Navan Carson wrote: > disklabel is not required for mount_mfs > > Index: newfs.8 > === > RCS file: /cvs/src/sbin/newfs/newfs.8,v > retrieving revision 1.70 > diff -u -p -r1.70 newfs.8 > --- newfs.8 23 May 2011 10:56:17 - 1.70 > +++ newfs.8 29 Aug 2014 04:10:54 - > @@ -72,9 +72,7 @@ > .Ek > .Sh DESCRIPTION > Before running > -.Nm > -or > -.Nm mount_mfs , > +.Nm , > the disk must be labeled using > .Xr disklabel 8 . > .Nm > is this correct? i'm not a user myself, but the text states that "special", for mount_mfs, is "typically that of the primary swap area". how would you even define the swap area without a disklabel? jmc
Re: minphys woes
On Friday 29 August 2014 10:34:20, David Gwynne wrote: > are you expecting minphys to appear in that backtrace? No. In that trace minphys should have limited the transfer size and I had put an KASSERT() into vioblk_scsi_cmd() which verified that xs- >datalen is not larger than that limit. A call to bread() causes the KASSERT to trigger.
newfs.8
disklabel is not required for mount_mfs Index: newfs.8 === RCS file: /cvs/src/sbin/newfs/newfs.8,v retrieving revision 1.70 diff -u -p -r1.70 newfs.8 --- newfs.8 23 May 2011 10:56:17 - 1.70 +++ newfs.8 29 Aug 2014 04:10:54 - @@ -72,9 +72,7 @@ .Ek .Sh DESCRIPTION Before running -.Nm -or -.Nm mount_mfs , +.Nm , the disk must be labeled using .Xr disklabel 8 . .Nm
Re: minphys woes
are you expecting minphys to appear in that backtrace? On 29 Aug 2014, at 5:07, Stefan Fritsch wrote: > Hi, > > while debugging some problems on a virtio host that supports only few dma > segments per request, I noticed that the minphys function is not called in > all code paths. It is only used for physio but not for other (cached) disk > operations. An example trace is below. > > Am I missing something or is this as broken as I think it is? I thought > the minphys function is a way for a driver to say that it does not support > larger transfers and that transfers are split accordingly. What's the > purpose of the minphys mechanism if it does not affect all code paths? > > Cheers, > Stefan > > > panic() at 0x1027bcf5 panic+0x1a5/0x1061006f0 > vioblk_scsi_cmd() at 0x103ecccf vioblk_scsi_cmd+0x8ff/0x106100770 > sdstart() at 0x103bc4d6 sdstart+0x176/0x1061007b0 > scsi_ioh_runqueue() at 0x103b3c05 scsi_ioh_runqueue+0x55/0x1061007e0 > scsi_xsh_runqueue() at 0x103b3d72 scsi_xsh_runqueue+0x132/0x106100800 > sdstrategy() at 0x103bc6bf sdstrategy+0x10f/0x106100830 > spec_strategy() at 0x102a8b3b spec_strategy+0x5b/0x106100850 > VOP_STRATEGY() at 0x102a75be VOP_STRATEGY+0x2e/0x106100870 > bio_doread() at 0x102991fc bio_doread+0xbc/0x1061008a0 > bread() at 0x102992c3 bread+0x13/0x1061008c0 > fillinusemap() at 0x102ad6d9 fillinusemap+0xb9/0x106100920 > msdosfs_mountfs() at 0x102af78d msdosfs_mountfs+0x59d/0x106100990 > msdosfs_mount() at 0x102afcf6 msdosfs_mount+0x3e6/0x106100b70 > sys_mount() at 0x102a6a3c sys_mount+0x36c/0x106100d90 >
Re: bge(4) Jumbo support for newer chipsets
On 28 Aug 2014, at 11:05 pm, Mike Belopuhov wrote: > On 28 August 2014 12:32, David Gwynne wrote: >> >> On 28 Aug 2014, at 3:02 am, Mike Belopuhov wrote: >> >>> On 27 August 2014 08:25, Brad Smith wrote: Looking for some testing of the following diff to add Jumbo support for the BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 chipsets. >>> >>> i have tested this on "Broadcom BCM5719" rev 0x01, unknown BCM5719 >>> (0x5719001), >>> APE firmware NCSI 1.1.15.0 and "Broadcom BCM5714" rev 0xa3, BCM5715 >>> A3 (0x9003). >>> >>> it works, however i'm not strictly a fan of switching the cluster pool to >>> larger one for 5714. wasting another 8k page (on sparc for example) for >>> every rx cluster in 90% cases sounds kinda wrong to me. but ymmv. >> >> this is what MCLGETI was invented to solve though. comparing pre mclgeti to >> what this does: >> > > that doesn't make my point invalid though. > >> a 5714 right now without jumbos would have 512 rings entries with 2048 bytes >> on each. 2048 * 512 is a 1024k of ram. if we bumped the std ring up to >> jumbos by default, 9216 * 512 would eat 4608k of ram. >> > > your calculation is a bit off. it's not 9216 * 512, in case of sparc64 it's > 8k * 2 * 512 which is 8M. on archs with 4k pages arts large pool code puts 9k frames on 12k pages, so 3k waste per cluster. on archs with and 8k pages 9k clusters land on on 64k pages, so the memory waste per 9k cluster is about 146 bytes. on archs with 16k pages you get a 7k waste per 9k cluster. im proposing that the large page code in pools change so it puts at least 8 items on a "page", and "pages" are always powers of two. that would mean 9k clusters would always end up on a 128k page, which works out so every arch only gets the 146 bytes of waste per 9k cluster. less if i put the pool page headers on the same page. > but my concern is different: you ask uvm to do more work for every cluster > since now you need 2 consequent pages of memory for one cluster instead of > just one that fits 8k/2k = 4 clusters. see above. it is also worth noting that the current mbuf cluster allocator sets a low watermark that for a lot of workloads means we never return clusters to uvm. my proposed code changes would get rid of that low watermark, but would age fully free pages so theyre only returned to uvm if theyve been idle for a second. if you have a fairly consistent workload you dont move pages in and out of uvm a lot. on my production firewalls, the result of the above (128k pages for 9k clusters and free page idling) is i have allocated mbuf clusters 74009152525 times, but only allocated pages 8172372 times and returned pages to uvm 8172233 times. that works out to be about 9000 uses of the pages per uvm allocation. that particular box has been up for a fortnight so some of those counters may have wrapped, so take the numbers with a grain of salt. > >> my boxes with bge with mclgeti generally sit around 40 clusters, but >> sometimes end up around 80. 80 * 9216 is 720k. we can have jumbos and still >> be ahead. >> >> if you compare the nics with split rings: 512 * 2048 + 256 * 9216 is ~3.3M. >> the same chip with mclgeti and only doing a 1500 byte workload would be 80 * >> 2048 + 17 * 9216, or 300k. >> >>> >>> apart from that there's a deficiency in the diff itself. you probably want >>> to change MCLBYTES in bge_rxrinfo to bge_rx_std_len otherwise statistics >>> look wrong. >> >> yeah. >> >> i have tested both 1500 and 9000 mtus on a 5714 and it is working well. as >> you say, 5719 seems to be fine too, but ive only tested it with mtu 1500. >> ill test 9k tomorrow. >> >> it needs tests on older chips too though.
Re: changing ffs mount between rw and ro while preserving softdep
On 08/28/14 23:06, Paul de Weerd wrote: On Thu, Aug 28, 2014 at 06:27:48PM +, Miod Vallat wrote: | > >Which is why the current way to remove softdep from a filesystem is a | > >rw+softdep -> ro -> rw transition, which would no longer work with your | > >diff. | > | > It would work, but you'd have to explicitly disable softdep, as one might | > expect to be required when removing softdep: | | Oh, indeed. | | Then it's a matter of deciding whether we want mount -u to simply update | flags (and then only toggle ro/rw, and leave softdep unchanged) or to | update behaviour (and then clear softdep on rw->ro transition as softdep | do not apply to read-only filesystems). You're in favour of the former, | I am in favour of the latter. Who wants to be the referee? I wouldn't expect any flags to change unless I ask for it, be it noexec, async, softdep or whatever. /Alexander I hardly qualify as a referee but I'll add that I think Boudewijn's approach makes more sense to me. Even though I quite often use -ur/-uw to drop softdep from filesystems. Especially given Boudewijn's point that putting ro,softdep in fstab results in a filesystem that would get (still have) softdep after -uw. I don't have very strong feelings on the matter (but, yes, strong enough to write this e-mail ;) Cheers, Paul 'WEiRD' de Weerd
Re: changing ffs mount between rw and ro while preserving softdep
On Thu, Aug 28, 2014 at 06:27:48PM +, Miod Vallat wrote: | > >Which is why the current way to remove softdep from a filesystem is a | > >rw+softdep -> ro -> rw transition, which would no longer work with your | > >diff. | > | > It would work, but you'd have to explicitly disable softdep, as one might | > expect to be required when removing softdep: | | Oh, indeed. | | Then it's a matter of deciding whether we want mount -u to simply update | flags (and then only toggle ro/rw, and leave softdep unchanged) or to | update behaviour (and then clear softdep on rw->ro transition as softdep | do not apply to read-only filesystems). You're in favour of the former, | I am in favour of the latter. Who wants to be the referee? I hardly qualify as a referee but I'll add that I think Boudewijn's approach makes more sense to me. Even though I quite often use -ur/-uw to drop softdep from filesystems. Especially given Boudewijn's point that putting ro,softdep in fstab results in a filesystem that would get (still have) softdep after -uw. I don't have very strong feelings on the matter (but, yes, strong enough to write this e-mail ;) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
minphys woes
Hi, while debugging some problems on a virtio host that supports only few dma segments per request, I noticed that the minphys function is not called in all code paths. It is only used for physio but not for other (cached) disk operations. An example trace is below. Am I missing something or is this as broken as I think it is? I thought the minphys function is a way for a driver to say that it does not support larger transfers and that transfers are split accordingly. What's the purpose of the minphys mechanism if it does not affect all code paths? Cheers, Stefan panic() at 0x1027bcf5 panic+0x1a5/0x1061006f0 vioblk_scsi_cmd() at 0x103ecccf vioblk_scsi_cmd+0x8ff/0x106100770 sdstart() at 0x103bc4d6 sdstart+0x176/0x1061007b0 scsi_ioh_runqueue() at 0x103b3c05 scsi_ioh_runqueue+0x55/0x1061007e0 scsi_xsh_runqueue() at 0x103b3d72 scsi_xsh_runqueue+0x132/0x106100800 sdstrategy() at 0x103bc6bf sdstrategy+0x10f/0x106100830 spec_strategy() at 0x102a8b3b spec_strategy+0x5b/0x106100850 VOP_STRATEGY() at 0x102a75be VOP_STRATEGY+0x2e/0x106100870 bio_doread() at 0x102991fc bio_doread+0xbc/0x1061008a0 bread() at 0x102992c3 bread+0x13/0x1061008c0 fillinusemap() at 0x102ad6d9 fillinusemap+0xb9/0x106100920 msdosfs_mountfs() at 0x102af78d msdosfs_mountfs+0x59d/0x106100990 msdosfs_mount() at 0x102afcf6 msdosfs_mount+0x3e6/0x106100b70 sys_mount() at 0x102a6a3c sys_mount+0x36c/0x106100d90
Re: changing ffs mount between rw and ro while preserving softdep
> >Which is why the current way to remove softdep from a filesystem is a > >rw+softdep -> ro -> rw transition, which would no longer work with your > >diff. > > It would work, but you'd have to explicitly disable softdep, as one might > expect to be required when removing softdep: Oh, indeed. Then it's a matter of deciding whether we want mount -u to simply update flags (and then only toggle ro/rw, and leave softdep unchanged) or to update behaviour (and then clear softdep on rw->ro transition as softdep do not apply to read-only filesystems). You're in favour of the former, I am in favour of the latter. Who wants to be the referee? Miod
Re: dlopen after dlclose crash
> > The issue is the change in ld.so/library_subr.c rev 1.34. If you back that > > change out, the crash disappears. > > > > The problem is that no one makes changes to the linkages inside ld.so out > > of boredom: there was some previous program that crashed without that > > change, but the details weren't documented or preserved in a regress/ > > program. I've made a couple stabs at reproducing the original program so > > that we can be sure to keep it fixed when fixing this, but haven't been > > able to pin down a case where the committed change solved the problem. If > > you can figure that out, I would gladly buy you a beer or three. Elsewise > > we're reaching the point where we back that change out and wait for someone > > complain... :-( > > I managed to come up with a case where a double decrement takes place [..] Hello again. I just adjusted the case, trying to make it appropriate for inclusion under src/regress. I also added a (currently failing) regression test for my original problem. The tarball contains two directories, test3 and test4, which ought to go under /usr/src/regress/libexec/ld.so/dlclose. Does it look ok? Don't forget to add the subdirs in the Makefile. http://guu.fi/ldtest-new.tgz Fwiw, I've also come up with a potential fix, but I'll have to test it a bit more. -Henri
sysmerge w/ local sets
sysmerge hangs while fetching the SHA256.sig file when working with local sets,
ie.:
#export SM_PATH=/nas2/public/OpenBSD/snapshots/amd64
#cd $SM_PATH
#ls -l SHA256.sig xetc56.tgz
-rw-r--r-- 1 rd rd 1977 Aug 26 23:39 SHA256.sig
-rw-r--r-- 1 rd rd 69066 Aug 6 16:10 xetc56.tgz
#sysmerge -bd -x $SM_PATH/xetc56.tgz
===> Fetching file:///usr/share/sysmerge/etc.tgz
===> Fetching file:///nas2/public/OpenBSD/snapshots/amd64/xetc56.tgz
===> Fetching /nas2/public/OpenBSD/snapshots/amd64/SHA256.sig
ftp: /nas2/public/OpenBSD/snapshots/amd64/SHA256.sig: no address associated
with name
The following fixes it for me:
Index: sysmerge.sh
===
RCS file: /pub2/cvsroot/OpenBSD/src/usr.sbin/sysmerge/sysmerge.sh,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 sysmerge.sh
--- sysmerge.sh 27 Aug 2014 14:44:42 - 1.154
+++ sysmerge.sh 28 Aug 2014 15:41:56 -
@@ -145,7 +145,12 @@ sm_fetch_and_verify() {
done
if [ -z "${NOSIGCHECK}" -a -n "${XTGZ}" ]; then
echo "===> Fetching ${XTGZ%/*}/SHA256.sig"
- /usr/bin/ftp -Vm -k "${FTP_KEEPALIVE-0}" -o
"${WRKDIR}/SHA256.sig" "${XTGZ%/*}/SHA256.sig" >/dev/null || \
+ _url=${XTGZ%/*}/SHA256.sig
+ [[ -f ${_url} ]] && _url="file://$(readlink -f ${_url})"
+ _file=${WRKDIR}/${_url##*/}
+ [[ ${_url} == @(file|ftp|http|https)://*/*[!/] ]] ||
+ error_rm_wrkdir "${_url}: invalid URL"
+ /usr/bin/ftp -Vm -k "${FTP_KEEPALIVE-0}" -o "${_file}"
"${_url}" >/dev/null || \
error_rm_wrkdir "could not retrieve SHA256.sig"
echo "===> Verifying ${XTGZ##*/} against ${_key}"
(cd ${WRKDIR} && /usr/bin/signify -qC -p ${_key} -x SHA256.sig
${XTGZ##*/}) || \
Re: bge(4) Jumbo support for newer chipsets
On 28 August 2014 12:32, David Gwynne wrote: > > On 28 Aug 2014, at 3:02 am, Mike Belopuhov wrote: > >> On 27 August 2014 08:25, Brad Smith wrote: >>> Looking for some testing of the following diff to add Jumbo support for the >>> BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 >>> chipsets. >>> >>> >> >> i have tested this on "Broadcom BCM5719" rev 0x01, unknown BCM5719 >> (0x5719001), >> APE firmware NCSI 1.1.15.0 and "Broadcom BCM5714" rev 0xa3, BCM5715 >> A3 (0x9003). >> >> it works, however i'm not strictly a fan of switching the cluster pool to >> larger one for 5714. wasting another 8k page (on sparc for example) for >> every rx cluster in 90% cases sounds kinda wrong to me. but ymmv. > > this is what MCLGETI was invented to solve though. comparing pre mclgeti to > what this does: > that doesn't make my point invalid though. > a 5714 right now without jumbos would have 512 rings entries with 2048 bytes > on each. 2048 * 512 is a 1024k of ram. if we bumped the std ring up to jumbos > by default, 9216 * 512 would eat 4608k of ram. > your calculation is a bit off. it's not 9216 * 512, in case of sparc64 it's 8k * 2 * 512 which is 8M. but my concern is different: you ask uvm to do more work for every cluster since now you need 2 consequent pages of memory for one cluster instead of just one that fits 8k/2k = 4 clusters. > my boxes with bge with mclgeti generally sit around 40 clusters, but > sometimes end up around 80. 80 * 9216 is 720k. we can have jumbos and still > be ahead. > > if you compare the nics with split rings: 512 * 2048 + 256 * 9216 is ~3.3M. > the same chip with mclgeti and only doing a 1500 byte workload would be 80 * > 2048 + 17 * 9216, or 300k. > >> >> apart from that there's a deficiency in the diff itself. you probably want >> to change MCLBYTES in bge_rxrinfo to bge_rx_std_len otherwise statistics >> look wrong. > > yeah. > > i have tested both 1500 and 9000 mtus on a 5714 and it is working well. as > you say, 5719 seems to be fine too, but ive only tested it with mtu 1500. ill > test 9k tomorrow. > > it needs tests on older chips too though.
i386/isa/clock.c Y2K complexities
Until we start to worry about Y2K1, does it really matter what the
NVRAM_CENTURY byte says?
--- /usr/src/sys/arch/i386/isa/clock.c.orig Mon May 6 02:15:11 2013
+++ /usr/src/sys/arch/i386/isa/clock.c Wed Aug 27 19:02:46 2014
@@ -502,85 +502,6 @@
static int timeset;
/*
- * check whether the CMOS layout is "standard"-like (ie, not PS/2-like),
- * to be called at splclock()
- */
-int cmoscheck(void);
-int
-cmoscheck(void)
-{
- int i;
- unsigned short cksum = 0;
-
- for (i = 0x10; i <= 0x2d; i++)
- cksum += mc146818_read(NULL, i); /* XXX softc */
-
- return (cksum == (mc146818_read(NULL, 0x2e) << 8)
- + mc146818_read(NULL, 0x2f));
-}
-
-/*
- * patchable to control century byte handling:
- * 1: always update
- * -1: never touch
- * 0: try to figure out itself
- */
-int rtc_update_century = 0;
-
-/*
- * Expand a two-digit year as read from the clock chip
- * into full width.
- * Being here, deal with the CMOS century byte.
- */
-int clock_expandyear(int);
-int
-clock_expandyear(int clockyear)
-{
- int s, clockcentury, cmoscentury;
-
- clockcentury = (clockyear < 70) ? 20 : 19;
- clockyear += 100 * clockcentury;
-
- if (rtc_update_century < 0)
- return (clockyear);
-
- s = splclock();
- if (cmoscheck())
- cmoscentury = mc146818_read(NULL, NVRAM_CENTURY);
- else
- cmoscentury = 0;
- splx(s);
- if (!cmoscentury) {
-#ifdef DIAGNOSTIC
- printf("clock: unknown CMOS layout\n");
-#endif
- return (clockyear);
- }
- cmoscentury = hexdectodec(cmoscentury);
-
- if (cmoscentury != clockcentury) {
- /* XXX note: saying "century is 20" might confuse the naive. */
- printf("WARNING: NVRAM century is %d but RTC year is %d\n",
- cmoscentury, clockyear);
-
- /* Kludge to roll over century. */
- if ((rtc_update_century > 0) ||
- ((cmoscentury == 19) && (clockcentury == 20) &&
-(clockyear == 2000))) {
- printf("WARNING: Setting NVRAM century to %d\n",
- clockcentury);
- s = splclock();
- mc146818_write(NULL, NVRAM_CENTURY,
- dectohexdec(clockcentury));
- splx(s);
- }
- } else if (cmoscentury == 19 && rtc_update_century == 0)
- rtc_update_century = 1; /* will update later in resettodr() */
-
- return (clockyear);
-}
-
-/*
* Initialize the time of day register, based on the time base which is, e.g.
* from a filesystem.
*/
@@ -622,7 +543,7 @@
dt.dt_hour = hexdectodec(rtclk[MC_HOUR]);
dt.dt_day = hexdectodec(rtclk[MC_DOM]);
dt.dt_mon = hexdectodec(rtclk[MC_MONTH]);
- dt.dt_year = clock_expandyear(hexdectodec(rtclk[MC_YEAR]));
+ dt.dt_year = 2000 + hexdectodec(rtclk[MC_YEAR]);
/*
@@ -676,7 +597,6 @@
mc_todregs rtclk;
struct clock_ymdhms dt;
int diff;
- int century;
int s;
/*
@@ -705,10 +625,6 @@
rtclk[MC_DOM] = dectohexdec(dt.dt_day);
s = splclock();
rtcput(&rtclk);
- if (rtc_update_century > 0) {
- century = dectohexdec(dt.dt_year / 100);
- mc146818_write(NULL, NVRAM_CENTURY, century); /* XXX softc */
- }
splx(s);
}
--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: bge(4) Jumbo support for newer chipsets
On 28 Aug 2014, at 3:02 am, Mike Belopuhov wrote: > On 27 August 2014 08:25, Brad Smith wrote: >> Looking for some testing of the following diff to add Jumbo support for the >> BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 >> chipsets. >> >> > > i have tested this on "Broadcom BCM5719" rev 0x01, unknown BCM5719 > (0x5719001), > APE firmware NCSI 1.1.15.0 and "Broadcom BCM5714" rev 0xa3, BCM5715 > A3 (0x9003). > > it works, however i'm not strictly a fan of switching the cluster pool to > larger one for 5714. wasting another 8k page (on sparc for example) for > every rx cluster in 90% cases sounds kinda wrong to me. but ymmv. this is what MCLGETI was invented to solve though. comparing pre mclgeti to what this does: a 5714 right now without jumbos would have 512 rings entries with 2048 bytes on each. 2048 * 512 is a 1024k of ram. if we bumped the std ring up to jumbos by default, 9216 * 512 would eat 4608k of ram. my boxes with bge with mclgeti generally sit around 40 clusters, but sometimes end up around 80. 80 * 9216 is 720k. we can have jumbos and still be ahead. if you compare the nics with split rings: 512 * 2048 + 256 * 9216 is ~3.3M. the same chip with mclgeti and only doing a 1500 byte workload would be 80 * 2048 + 17 * 9216, or 300k. > > apart from that there's a deficiency in the diff itself. you probably want > to change MCLBYTES in bge_rxrinfo to bge_rx_std_len otherwise statistics > look wrong. yeah. i have tested both 1500 and 9000 mtus on a 5714 and it is working well. as you say, 5719 seems to be fine too, but ive only tested it with mtu 1500. ill test 9k tomorrow. it needs tests on older chips too though.
Re: changing ffs mount between rw and ro while preserving softdep
Op Thu, 28 Aug 2014 11:51:32 +0200 schreef Miod Vallat : Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. That was already broken; rw->rw is not affected as per the enclosing if-block. Which is why the current way to remove softdep from a filesystem is a rw+softdep -> ro -> rw transition, which would no longer work with your diff. It would work, but you'd have to explicitly disable softdep, as one might expect to be required when removing softdep: # mount -vuw /usr/obj /dev/sd0f on /usr/obj type ffs (rw, local, nodev, nosuid, softdep, ctime=Thu Aug 28 11:58:27 2014) # mount -vur -onosoftdep /usr/obj /dev/sd0f on /usr/obj type ffs (local, nodev, nosuid, read-only, ctime=Thu Aug 28 11:58:40 2014) # mount -vuw /usr/obj /dev/sd0f on /usr/obj type ffs (rw, local, nodev, nosuid, ctime=Thu Aug 28 11:58:50 2014) Basically, I made my diff so that (mount -uw;mount -ur) cycles retain softdep. Without my diff, one would have to append -osoftdep depending on the fs-type and what was defined in /etc/fstab. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: changing ffs mount between rw and ro while preserving softdep
Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. That was already broken; rw->rw is not affected as per the enclosing if-block. Which is why the current way to remove softdep from a filesystem is a rw+softdep -> ro -> rw transition, which would no longer work with your diff. Miod
Re: changing ffs mount between rw and ro while preserving softdep
Op Wed, 27 Aug 2014 20:50:34 +0200 schreef Miod Vallat : Why not keep the softdep flag when updating rw->ro? E.g. via mount -ur /usr/obj fstab(5) already allows ro+softdep. Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. That was already broken; rw->rw is not affected as per the enclosing if-block. I just tried this on 5.5 (GENERIC, without my diff): # mount -vu -onosoftdep /usr/obj/ /dev/wd0f on /home type ffs (rw, local, noatime, nodev, nosuid, softdep, ctime=Thu Aug 28 11:04:07 2014) And then after un-mounting and re-mounting without softdep: # mount -vu -osoftdep /usr/obj/ /dev/sd0f on /usr/obj type ffs (rw, local, nodev, nosuid, ctime=Thu Aug 28 11:12:57 2014) So, currently it doesn't seem possible to turn softdep on or off with an rw mount. My diff doesn't change that. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: Bug in gethostbyaddr and patch to solve
On Mon, Aug 25, 2014 at 10:39:59PM -0500, Vladimir Támara Patiño wrote: > Using tcpdump in a firewall with 5.5 (also happens with 5.4 and I guess with > current) and certain addres of the LAN I got always a segfault. > > It is a bug within the function gethostbyaddr. It can be reproduced with > the minimal test program available at: > http://openbsd.7691.n7.nabble.com/problem-with-gethostbyaddr-on-OBSD-5-4-td242329.html > and the following steps: > > 1. Create a entry in /etc/hosts with IP address but without name, for example: > echo 192.168.1.89 >> /etc/hosts > 2. Compile the test program of the link > cc -o gethostbyaddr gethostbyaddr.c > 3. Run de test program with the address added to /etc/hosts without name: > ./gethostbyaddr 192.168.1.89 > This bug was fixed some times ago. http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/lib/libc/asr/gethostnamadr_async.c.diff?r1=1.28&r2=1.29&f=h Eric.
