Re: Beating a dead horse

[Michael van Elst]

On Thu, Nov 26, 2015 at 07:43:50PM +0700, Robert Elz wrote:
> 
>   | LVM scans for devices and has a filter regex configured in
>   | /etc/lvm/lvm.conf.
> 
> OK, I think that wasn't the problem ... I tried everything I could think
> of as the filter list in there, with and without /dev/ (and with and
> without /dev/ as the arg to lvcreate and nothing made a difference).


This list will scan only wedges for PVs.

filter = [ "a|rdk[0-9]*|", "r|.*|" ]


> That's enough for me to conclude that lvm doesn't work (properly) with
> 4k sector size disks either - that is, I made a vg, on the pv, and looked
> at its size and it (just like cgd) is 1/8 of the size that it should be.


The LVM code (function _dev_get_size_dev) only determines the sector count
but assumes 512 byte sectors.

But you can fake the value with pvcreate --setphysicalvolumesize.
This is written into the LVM label and that's the only thing that
the rest of the LVM code is interested in.

sd0 is a disk with 1k sectors.

gpt add -l pv1 -s 10m -t linux-lvm sd0
gpt add -l pv2 -s 10m -t linux-lvm sd0
gpt add -l pv3 -s 10m -t linux-lvm sd0
dkctl sd0 makewedges

creates

dk8 at sd0: pv1
dk8: 10240 blocks at 1618, type: 
dk10 at sd0: pv2
dk10: 10240 blocks at 16010258, type: 
dk12 at sd0: pv3
dk12: 10240 blocks at 16020498, type: 

This labels the PVs

lvm pvcreate --setphysicalvolumesize 10m /dev/rdk{8,10,12}

  PV VG   Fmt  Attr PSize PFree
  /dev/rdk10 vg1  lvm2 a-   8.00m0 
  /dev/rdk12 vg1  lvm2 a-   8.00m0 
  /dev/rdk5  vg0  lvm2 a-   5.46t 4.86t
  /dev/rdk6  vg0  lvm2 a-   5.46t 5.46t
  /dev/rdk8  vg1  lvm2 a-   8.00m0 

and this creates the VG and LV

lvm vgcreate vg1 /dev/rdk{8,10,12}

  VG   #PV #LV #SN Attr   VSize  VFree 
  vg02   3   0 wz--n- 10.92t 10.32t
  vg13   1   0 wz--n- 24.00m 24.00m

lvcreate -L 24m -n lv1 vg1

  LVVG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  test  vg0  -wi-a-   4.00g  
  test3 vg0  -wi-a-   4.00g  
  test4 vg0  -wi-a- 600.00g  
  lv1   vg1  -wi-a-  24.00m 




Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 23:34:37 +0100
From:Michael van Elst 
Message-ID:  <20151126223436.ga...@serpens.de>

  | This list will scan only wedges for PVs.
  | filter = [ "a|rdk[0-9]*|", "r|.*|" ]

Yes, as you may have seen from a later message, the filter list was never
really the problem, it was the "r" in rdk, which I wasn't using ... I'm
used to using block devices for anything filesystem related (raidframe
uses block devices, cgd uses block devices, ...)

It simply never occurred to me, initially anyway, to use the raw device,
and the doc, being all linux based where the distinction doesn't exist
(terrible decision on their part I think) gives no clue at all that a
char device is needed.

But once I used the raw device, that problem just went away.

  | The LVM code (function _dev_get_size_dev) only determines the sector count
  | but assumes 512 byte sectors.

Yes, figured that out.   That's what cgd does too...

  | But you can fake the value with pvcreate --setphysicalvolumesize.

Will that really work?   That is, if it is done that way, won't the
"device" (the pv or whatever) appear to be a 512 byte sector "drive" ?
If it does, what prevents i/o in 512 byte units (which the underlying
drive simply will not perform)?

kre

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 23:58:17 +0100
From:Michael van Elst 
Message-ID:  <20151126225816.gb...@serpens.de>

  | On Thu, Nov 26, 2015 at 06:29:30PM +0700, Robert Elz wrote:
  | 
  | > Just try making a ccd by combining a 512 byte sector drive and a 4K
  | > sector drive, and watch what happens... 
  | 
  | CCD is a very old device that isn't even configured "correctly" and
  | I would be very surprised if it could concat drives of different sector
  | sizes.

It can't.  Or rather, it tries, or permits it anyway, and makes a real mess.

  | After all, what fake geometry should it present to the user?

That at least is easy - it must present the more restricted geom, if any
of the components has 4K sectors (and the others are all <= 4k) then it
must present as a 4K sector size device.   That's simple, and would be
easy to get right, if ccd was really worth continuing with.

  | Yes, CGD is broken. Looks like a simple fix.

The simple fix would be do do what you suggested for lvm, and just
make it appear to have 512 byte sectors, with N * the number of sectors
it really has from the device (for a 4K sector drive, multiply the number
of sectors by 8).   I have no doubt that would kind of function, but again
it would make the cgd "drive" appear to be able to handle 512 byte reads and
writes, which it cannot, because the hardware underneath cannot.

Fixing it to present 4K sectors also looks easy, but isn't.  Doing that
causes a panic somewhere when the cgd is attempting to validate the label
(bsd disklabel) that gets written to it to allow it to be partitioned
(one day it would be nice for cgd to allow GPT labels, and handle them
for validation of the encryption, but that isn't there yet.)

Something in the label handling code is (I think - or guess) translating
units incorrectly, and failing.

Here's the traceback I got ...

vpanic() at vpanic+0x140
snprintf() at snprintf
startlwp() at startlwp
calltrap() at calltrap+0x19
bf_cbc_dec_int() at bf_cbc_dec_int+0x27
cgd_cipher_uio_cbc.isra.0() at cgd_cipher_uio_cbc.isra.0+0x79
cgd_cipher_bf_cbc() at cgd_cipher_bf_cbc+0x8d
cgd_cipher() at cgd_cipher+0x16a
cgdiodone() at cgdiodone+0xaf
biodone2() at biodone2+0x89
dkiodone() at dkiodone+0x84
biodone2() at biodone2+0x89
bdev_strategy() at bdev_strategy+0x5b
spec_strategy() at spec_strategy+0x37
VOP_STRATEGY() at VOP_STRATEGY+0x33
dkstart() at dkstart+0x2b
dkstrategy() at dkstrategy+0xd5
bdev_strategy() at bdev_strategy+0x5b
spec_strategy() at spec_strategy+0x37
VOP_STRATEGY() at VOP_STRATEGY+0x33
cgd_diskstart() at cgd_diskstart+0xb7
dk_start() at dk_start+0x9b
disk_read_sectors() at disk_read_sectors+0x3b
convertdisklabel() at convertdisklabel+0xf0
validate_label() at validate_label+0x14c
readdisklabel() at readdisklabel+0x1c8
dk_getdisklabel() at dk_getdisklabel+0xbf
dk_open() at dk_open+0xf4
cdev_open() at cdev_open+0xb2
spec_open() at spec_open+0x25d
VOP_OPEN() at VOP_OPEN+0x33
vn_open() at vn_open+0x1e3
do_open() at do_open+0x111
do_sys_openat() at do_sys_openat+0x68
sys_open() at sys_open+0x24
syscall() at syscall+0x9c
--- syscall (number 5) ---

kre

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 23:59:32 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | That's the responsibility of the upper layers. FFS will only do
  | fragment size I/O (+ 8k I/O for the superblock).

But how does the upper layer know what it is supposed to do if the
information has been buried?   FFS won't (or shouldn't) allow frag
sizes smaller than the sector size, but in order to do that it has to
be told the correct sector size.   If the underlying pseudo-device lies
to it, the upper layers cannot possibly do the correct thing.

All you can hope for is that the user knows what the issues are, and
manually makes things right .. and that's a recipe for disaster.

kre

Re: Beating a dead horse

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>  | But you can fake the value with pvcreate --setphysicalvolumesize.

>Will that really work?   That is, if it is done that way, won't the
>"device" (the pv or whatever) appear to be a 512 byte sector "drive" ?
>If it does, what prevents i/o in 512 byte units (which the underlying
>drive simply will not perform)?

That's the responsibility of the upper layers. FFS will only do
fragment size I/O (+ 8k I/O for the superblock).


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>But how does the upper layer know what it is supposed to do if the
>information has been buried?

The newfs command queries the sector size, calculates
the filesystem parameters and puts them into the superblock.


>  FFS won't (or shouldn't) allow frag
>sizes smaller than the sector size, but in order to do that it has to
>be told the correct sector size.   If the underlying pseudo-device lies
>to it, the upper layers cannot possibly do the correct thing.

FFS and other filesystems don't even try to get that information
(basically because in older times it wasn't possible or needed).
Instead, the information is stored as filesystem metadata (e.g. the
superblock).

FFS used to get the physical sector size from the superblock. In
NetBSD only userland tools still do that, the kernel code just
ignores it but pretends to address a DEV_BSIZE disk. The calculated
fragment size assures that there are no alignment issues.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Thor Lancelot Simon]

On Thu, Nov 26, 2015 at 08:57:24AM +, Michael van Elst wrote:
> w...@hiwaay.net ("William A. Mahaffey III") writes:
> 
> >H  I thought that the RAID5 would write 1 parity byte & 4 data 
> >bytes in parallel, i.e. no '1 drive bottleneck'.
> 
> That only happens when the "4 data bytes" (actually the whole stripe)
> gets written in one operation.
> 
> Unfortunately this currently requires that the filesystem sends
> a whole stripe to the RAID driver which is only possible for
> a few configurations because of the MAXPHYS limit of 64kbyte.
> 
> The limit, despite its name, also applies to the RAID driver.
> Additionally it helps when the block size (or even the fragment
> size) is as large as the stripe.
> 
> So, with a 4+1 RAID5:
> 
> sectPerSU = 32  -> 4*32 = 128 blocks = 64KByte stripe
> newfs -b 65536 -f 65536 -> format filesystem with 64k blocks and frags
> 
> To overcome this issue either MAXPHYS needs to be larger or
> the raid driver needs to coalesce multiple writes.

Both, I think.  I will try to resuscitate tls-maxphys.

Thor

Re: Beating a dead horse

[Michael van Elst]

On Thu, Nov 26, 2015 at 06:29:30PM +0700, Robert Elz wrote:

> Just try making a ccd by combining a 512 byte sector drive and a 4K
> sector drive, and watch what happens... 

CCD is a very old device that isn't even configured "correctly" and
I would be very surprised if it could concat drives of different sector
sizes. After all, what fake geometry should it present to the user?


> Or put a cgd on a 4K sector
> drive, and then attempt to fix the obvious bug.

Yes, CGD is broken. Looks like a simple fix.


> It is a mess.  Things
> still get very confused as to where inside the kernel "sectors" are
> really sectors, and where they're DEV_BSIZE units, which can lead to
> conversions happening improperly sometimes.   This isn't to say that it
> gets things wrong in the common cases, just that it is a mess...

The kernel always treats disks as having DEV_BSIZE blocks, the
translation is done by the device driver.

The userland (when accessing raw devices) obviously addresses
disks with byte positions, but the userland tools like fsck
access disks in terms of device blocks. This is how the original
UNIX kernel did it.




Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Robert Elz]

Date:Fri, 27 Nov 2015 01:15:15 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | The newfs command [...]

I'm going to reply to this, but in the thread on tech-kern ...

This thread, when it started, was on a topic appropriate for netbsd-users.
It has drifted, and no longer is.

Anyone interested should look for the thread "In-kernel units for block
numbers, etc ..." in tech-kern and continue there.

kre

Re: NetBSD/i386 7.0 hangs booting 486

[Masanobu SAITOH]

Hi, all

On 2015/11/23 5:48, Christos Zoulas wrote:
> In article <56520ee6.8050...@gmail.com>,
> Felix Deichmann   wrote:
>> Am 22.11.2015 um 17:59 schrieb Christos Zoulas:
>>> And the fix could be something like:
>>>
>>> [...]
>>
>> Just to be safe I built and installed a release with your fix and it
>> works fine on 486 and modern amd64 Phenom.
>> Thanks for your support! :)
>>
>>> Of course the llvm version needs to be fixed too, since it doesn't check
>>> at all:
>>
>> Yes, it would be nice if
>> - we could have the fixes in our tree
>> - they could be pulled-up to 7 for coming releases to work on (older)
>> 486 again (6.1.5 worked without fix for me)

Does this change fix PR#49741, right?

http://gnats.netbsd.org/49741

(PR#49741 was filed by the person who reported this problem first in
last February as you 
mentioned(https://mail-index.netbsd.org/port-i386/2015/02/06/msg003348.html))

That PR said it occured on his netbsd-6 machine, so it should be pulled
up to netbsd-6, too.


>> - they could be committed upstream to gcc and llvm
> 
> Great, I've committed to head and will ask for -7 pullups. I will
> submit them to the gcc and llvm people later.
> 
> Thanks for testing!
> 
> christos
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: Beating a dead horse

[Michael van Elst]

w...@hiwaay.net ("William A. Mahaffey III") writes:

>H  I thought that the RAID5 would write 1 parity byte & 4 data 
>bytes in parallel, i.e. no '1 drive bottleneck'.

That only happens when the "4 data bytes" (actually the whole stripe)
gets written in one operation.

Unfortunately this currently requires that the filesystem sends
a whole stripe to the RAID driver which is only possible for
a few configurations because of the MAXPHYS limit of 64kbyte.

The limit, despite its name, also applies to the RAID driver.
Additionally it helps when the block size (or even the fragment
size) is as large as the stripe.

So, with a 4+1 RAID5:

sectPerSU = 32  -> 4*32 = 128 blocks = 64KByte stripe
newfs -b 65536 -f 65536 -> format filesystem with 64k blocks and frags

To overcome this issue either MAXPHYS needs to be larger or
the raid driver needs to coalesce multiple writes.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Michael van Elst]

g...@ir.bbn.com (Greg Troxel) writes:

>Is there a clear motivation for 2048 vs 64?   Are there any known
>devices where that matters?

2048 is the Windows value. It's not unlikely that software
starts to depend on it (as it did with the previous magic
value 63).


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Beating a dead horse

[Michael van Elst]

k...@munnari.oz.au (Robert Elz) writes:

>work, it just said (something like, paraphrasing, that system isn't
>running any more) "invalid device or disabled by filtering"

LVM scans for devices and has a filter regex configured in
/etc/lvm/lvm.conf.


>The kernel does some stuff right for non 512 byte sector disks, but still
>does lots wrong.   It is still a mess in this area.

Works for me...

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Fan control on nForce430 MCP61 chipset

[Martin Husemann]

Can you show the output of the envstat command?

Martin

Re: Beating a dead horse

[Manuel Bouyer]

On Thu, Nov 26, 2015 at 06:45:04AM +0700, Robert Elz wrote:
> Date:Wed, 25 Nov 2015 15:59:29 -0600
> From:Greg Oster 
> Message-ID:  <20151125155929.2a5f2...@mickey.usask.ca>
> 
>   |  time dd if=/dev/zero of=/home/testfile bs=64k count=32768
>   |  time dd if=/dev/zero of=/home/testfile bs=10240k count=32768
>   | 
>   | so that at least you're sending 64K chunks to the disk...
> 
> Will that really work?   Wouldn't the filesystem divide the 64k writes
> from dd into 32K file blocks, and write those to raidframe?   I doubt
> those tests would be productive.

No, the filesystem can cluster writes up to MAXPHYS (64k) for sequencial
writes (and also read ahead up to 64k for reads) even if the
filesystem block size is smaller.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 09:11:22 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | LVM scans for devices and has a filter regex configured in
  | /etc/lvm/lvm.conf.

OK, thanks, I'll look ... the lvm doc looks like it is untouched from
linux, makes it very hard to know what is happening...

  | >The kernel does some stuff right for non 512 byte sector disks, but still
  | >does lots wrong.   It is still a mess in this area.
  | 
  | Works for me...

Just try making a ccd by combining a 512 byte sector drive and a 4K
sector drive, and watch what happens...   Or put a cgd on a 4K sector
drive, and then attempt to fix the obvious bug.   It is a mess.  Things
still get very confused as to where inside the kernel "sectors" are
really sectors, and where they're DEV_BSIZE units, which can lead to
conversions happening improperly sometimes.   This isn't to say that it
gets things wrong in the common cases, just that it is a mess...

kre

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 09:11:22 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | LVM scans for devices and has a filter regex configured in
  | /etc/lvm/lvm.conf.

For me, /etc/lvm is empty, there is no lvm.conf.  If I can believe
lvm,conf(5) there is no default filter list (at least it does not
say there is one) but it does say that the default is for unknown
devices to be accepted, so that filter list should not be preventing
/dev/dk13 from being permitted.

Yet it most likely is, I'll try adding an explicit accept for it
in a new lvm.conf (and hope that that one line will be, for now anyway,
sufficient to have in lvm.conf) and see what happens...

kre

Re: Beating a dead horse

[Greg Troxel]

Swift Griggs  writes:

> On Wed, 25 Nov 2015, Greg Troxel wrote:
>>  We're seeing smaller disks with 4K sectors or larger flash erase
>> blocks and 512B interfaces now.
>
> Those larger erase blocks (128k?!) would seem to be a big problem if
> you'd rather stick to a smaller alignment or file system block
> size. However, maybe I'm missing something about the interplay between

There's no good reason (other than a bit of space wastage once) not to
align (defined as fs starting on multiple of something).

fs block size is another story.  But if you want to write 8K and there's
a 128K erase block, that's how it is.  Hopefully multiple writes
coalesce.  The thing that should be avoided is writing 4K and having
that split into two 4K chunks.

> things like inode sizes and any relationship with the erase block
> size. For example, if you were using an 8K block size I'd think a 128k

inodes are actually much smaller.  We are talking about block sizes of
data.

> erase block size would blow things up nicely when you blew way past
> the 8k block you originally wanted to clear.

It is more that the flash layer needs to rerite the whole chunk.  That
becomes just the way it is with big erase blocks, mostly.  Filesystems
try to write sequential blocks when they can.   ZFS further integrates
fs and raid, but NetBSD's ZFS is old and not quite right.

>> That avoids the alignment issue, but requires filesystem/kernel
>> support. I am pretty sure netbsd-7 is ok with that but I am not sure
>> about earlier.
>
> Interesting. For some reason I have it in my head that many EMC SANs
> of various stripes (and I know for sure the XtremeIO stuff) uses 4k
> block sizes. I've used NetBSD in the past in EMC environments and seen
> moderate (but not what I'd call "high") performance vis-a-vis other
> (Linux and/or Solaris) hosts. I wonder if this was a factor. I'll have
> to test with Netbsd 7, now. Sounds fun.

With a SAN (vs NAS), presumably there is iscsi or some other SAN
protocol?  Does that *protocol* expose 4K blocks?  Maybe this works in
-6 too; I only recently have a native 4K disk (vs 4K/512),and I don't
have an EMC SAN.

> I did learn that 4k seems to be the smallest allowable size (line 141
> in fs.h #define MINBSIZE 4096). It sounds like that's the smallest
> since a cylinder group block struct needs a 4k space to be workable.

I think 4KB is not because it's the smallest that's workable efficiency
wise, but because there is a fragsize which is blocksize/8, and a single
512B sector is the smallest fragment.

>> I guess you can put it that way, saying otherwise we would always
>> start at 2048 and use 32K or even 64K blocks.
>
> That doesn't seem too wasteful to me, but I'm ready for some embedded
> systems guy to lecture me.  :-)

Back when I was young, one of the first computer I used that actually
had disks had a pair of 2.5 MB disks, with Sixth Edition Unix:

  https://en.wikipedia.org/wiki/RK05

which is about 4900 512-byte sectors on each.  Using 2048 for alignment
would have been unthinkable.  But these are just historical curiousities
now, along with the RX01 8" floppy.



signature.asc
Description: PGP signature

Re: Beating a dead horse

[Robert Elz]

Date:Thu, 26 Nov 2015 07:57:30 -0500
From:Greg Troxel 
Message-ID:  

  | I think 4KB is not because it's the smallest that's workable efficiency
  | wise, but because there is a fragsize which is blocksize/8, and a single
  | 512B sector is the smallest fragment.

Not quite, and that could not be the reason anyway, nothing says that you
must have 8 frags/block, you can have just 2, so with a 512 byte sector
as the smallest fragment (ignoring drives with smaller sector sizes - I
started out in unix using drives that had 256 byte sectors, the driver just
grouped them in units of 2...)

Back in late 1990, early 1991, I was reviewing a draft copy of what became
the answer book to the 4.3BSD design & implementation book (that book had
questions at the end of each chapter, but no answers... the answer book
filled in the gap).

One of the questions related to the minimum block size permitted, to which
the answer in the draft answer book was 4096.   My comment was that I didn't
think that was right, for just the reason I give above.

Kirk Mckusick's reply to that was ...

 | The minimum filesystem blocksize is 4096. This decision was made to ensure
 | that only double indirect blocks would be needed, and to ensure that cylinder
 | groups would be big enough to be useful (since they are by definition, 1
 | block in size). 

I am bcc'ing Kirk in this message, so if he wants to submit a revised
opinion, or something he can - bcc so he doesn't get drawn into the rest
of this (wildly drifting) thread about dead bovines...

Kirk, feel free to reply to me to be forwarded if you have anything to say
on this issue - no need if the above quote from your message of 7 Jan 1991
remains accurate...

kre

NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Emile `iMil' Heitor]

On Mon, 2 Nov 2015, Emile `iMil' Heitor wrote:


I'm trying to get rid of those hangs for weeks now, tried every mount flag
combination without success, the system would freeze randomly, leaving the 
whole
OS unresponsive. There's no log, no kernel message, the domU actually 
responds

to network solicitations (ping, telnet 22...) but once it's frozen, it is
impossible to run any command, it will just hang.

The exact same setup is successfully running since Sept 2014 on
NetBSD 6.1/amd64.

Any idea how to get some valuable information to help tracking down this
awful behaviour?


A bit of follow-up. I've been trying many workarounds during the past weeks, and
right now I'm not convinced it even is an NFS problem.
I've setup a tmpfs bulk build directory, and even that way, NetBSD 7.0 would
freeze randomly after a couple of minutes while processing `pbulk.sh'.
What I can say:

- the server is a fresh diskless NetBSD 7.0 domU (PXE/NFS)
- there's not a single information about the freeze, not even in the console
- I've only witnessed those freezes when calling `pbulk.sh' (couldn't get
  further anyway)
- cvs co pkgsrc does not freezes, I ran it many times without issues
- the domU stays up for days if no operation is made
- I started this domU on various dom0s to validate this was not a hardware
  problem, always had the same symptoms
- I tried a custom 7.0_STABLE kernel without success

If this issue _is_ NFS related, which I doubt now, it is then read-related, as
the build is done in tmpfs.

Again, as there's no log at all, what would help debugging this behaviour?


Emile `iMil' Heitor * 
  _
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org  |  - against HTML email  X
| http://gcu.info|  & vCards / \

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Emile `iMil' Heitor]

On Thu, 26 Nov 2015, Emile `iMil' Heitor wrote:


Again, as there's no log at all, what would help debugging this behaviour?


FWIW, some ddb output (ddb is triggered by hitting + on domU's console):

fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 8012e5ad cs e030 rflags 202 cr2 7f7ff6c1e049
ilevel 8 rsp a0051864cc58
curlwp 0xa00035538840 pid 0.2 lowest kstack 0xa0051864a2c0
Stopped in pid 0.2 (system) at  netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
xencons_tty_input() at netbsd:xencons_tty_input+0xb2
xencons_handler() at netbsd:xencons_handler+0x65
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x19
evtchn_do_event() at netbsd:evtchn_do_event+0x281
do_hypervisor_callback() at netbsd:do_hypervisor_callback+0x143
hypervisor_callback() at netbsd:hypervisor_callback+0x9e
idle_loop() at netbsd:idle_loop+0xe8
ds  3c80
es  c780
fs  c040
gs  7524
rdi a0003a62b330
rsi 8437d01f
rbp a0051864cc58
rbx 8437d01f
rdx 2b
rcx 2b
rax 1
r8  0
r9  805fc780cpu_info_primary
r10 cdd9f51e239cbb87
r11 246
r12 a0003d754c00
r13 8437d020
r14 a0003a62b330
r15 1
rip 8012e5adbreakpoint+0x5
cs  e030
rflags  202
rsp a0051864cc58
ss  e02b
netbsd:breakpoint+0x5:  leave
db{0}> ps
PIDLID S CPU FLAGS   STRUCT LWP *   NAME WAIT
162591 3  13 0   a0003f435080awk netio
242691 3  14 0   a0003f446a80cat nfsrcv
233011 3  1480   a0003f3f8a60 sh wait
118351 3  1480   a0003f40c0c0  bmake wait
9493 1 3  1480   a0003f26d4a0 sh wait
4831 1 3  1480   a0003f42d320  bmake wait
285131 3  1480   a0003f3f09e0 sh wait
6232 1 3  1580   a0003ed15ae0 sh wait
1172 1 3  1580   a0003f083000  bmake wait
165441 3  1580   a0003f439500 sh wait
181411 3  1580   a0003f430420 sh wait
2349 1 3  1580   a0003f448280   bash wait
490  1 3   580   a0003f447680   sshd select
2135 1 3   080   a0003f445640   sshd select
2234 1 3   480   a0003f2be580   bash ttyraw
381  1 3  1280   a0003f2be9a0   sshd select
382  1 3  1380   a0003e9cc680   sshd select
1868 1 3  15 0   a0003dca59c0  getty nfsrcv
2354 1 3   5 0   a0003ed51b00   cron nfsrcv
1675 1 3  1180   a0003edbd2e0  inetd kqueue
2105 1 3  1280   a0003ee0d720   nrpe select
2086 1 3  14   100   a0003eca46a0   qmgr nfsrcv
2033 1 3  13 0   a0003eca4ac0 pickup nfskqdet
2055 1 3   4 0   a0003edbd700 master tstile
164013 5  11  1000   a0003efff740  python2.7
1640 9 3  1180   a0003ee0db40  python2.7 kqueue
1640 8 3  1280   a0003ed152a0  python2.7 kqueue
1640 1 3   980   a0003e0f6240  python2.7 select
1555 1 3  1380   a0003e0f6660   sshd select
1407 1 3  1380   a0003dd15a20 powerd kqueue
892  1 3   280   a0003e099640  rpc.lockd select
884  1 3  1580   a0003e099a60  rpc.statd select
686  1 3   780   a0003dd151e0rpcbind select
677  1 3   5 0   a0003dd6fa40syslogd nfsrcv
11 3   880   a0003d75b100   init wait
0  131 3   3   200   a0003d75d140  nfskqpoll nfsrcv
0  129 3   4   200   a0003dc4e160   aiodoned aiodoned
0  128 3   7   200   a0003dc4e580ioflush syncer
0  127 3   0   200   a0003dc4e9a0   pgdaemon pgdaemon
0  124 3  14   200   a0003d75a920  nfsio nfsiod
0  123 3  13   200   a0003d75a500  nfsio nfsiod
0  122 3   9   200   a0003d75a0e0  nfsio nfsiod
0  121 3  15   200   a0003d75b940  nfsio nfsiod
0  120 3   0   200   a0003d75b520  cryptoret crypto_w
0  119 3   0   200   a0003d7530c0  unpgc unpgc
0  118 3   0   200   a0003d75c960xen_balloon xen_balloon
0  117 3   9   200   a0003d75c540vmem_rehash vmem_rehash
0  116 3   0   200   a0003d75d980 xenbus 

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Manuel Bouyer]

On Thu, Nov 26, 2015 at 03:55:27PM +0100, Emile `iMil' Heitor wrote:
> [...]
> Again, as there's no log at all, what would help debugging this behaviour?

Can you enter ddb on the console (on a PV domU this is with '+++',
not break which doesn't exists for xl console)

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Manuel Bouyer]

On Thu, Nov 26, 2015 at 05:22:16PM +0100, Emile `iMil' Heitor wrote:
> On Thu, 26 Nov 2015, Emile `iMil' Heitor wrote:
> 
> >Again, as there's no log at all, what would help debugging this behaviour?
> 
> FWIW, some ddb output (ddb is triggered by hitting + on domU's console):

what does 'show uvm' report ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[J. Hannken-Illjes]

On 26 Nov 2015, at 17:22, Emile `iMil' Heitor  wrote:

> 
> 242691 3  14 0   a0003f446a80cat nfsrcv

> 1868 1 3  15 0   a0003dca59c0  getty nfsrcv
> 2354 1 3   5 0   a0003ed51b00   cron nfsrcv

> 
> 2086 1 3  14   100   a0003eca46a0   qmgr nfsrcv

> 677  1 3   5 0   a0003dd6fa40syslogd nfsrcv

> 0  131 3   3   200   a0003d75d140  nfskqpoll nfsrcv

Looks like a NFS problem, too many threads in nfsrcv...

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Emile `iMil' Heitor]

On Thu, 26 Nov 2015, Manuel Bouyer wrote:


what does 'show uvm' report ?


db{0}> show uvm
Current UVM status:
  pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
, ncolors=8  7444115 VM pages: 53990 active, 1807 inactive, 1 wired, 7302474 fre
e
  pages  26626 anon, 25029 file, 4143 exec
  freemin=4096, free-target=5461, wired-max=2481371
  cpu0:
faults=2789285, traps=2796277, intrs=1396531, ctxswitch=1585247
softint=792597, syscalls=1259477
  cpu1:
faults=1696656, traps=1698017, intrs=180486, ctxswitch=127378
softint=36160, syscalls=608644
  cpu2:
faults=1207093, traps=1208093, intrs=160266, ctxswitch=65538
softint=18178, syscalls=412550
  cpu3:
faults=1434344, traps=1435516, intrs=174413, ctxswitch=100028
softint=24126, syscalls=512909
  cpu4:
faults=1273978, traps=1275187, intrs=161384, ctxswitch=68847
softint=19305, syscalls=424913
  cpu5:
faults=1622825, traps=1624084, intrs=171817, ctxswitch=105319
softint=31330, syscalls=510165
  cpu6:
faults=1734292, traps=1735749, intrs=170374, ctxswitch=99131
softint=26841, syscalls=551106
  cpu7:
faults=1392652, traps=1393985, intrs=166582, ctxswitch=81469
softint=20174, syscalls=442880
  cpu8:
faults=1492063, traps=1493265, intrs=166791, ctxswitch=88768
softint=24325, syscalls=492824
  cpu9:
faults=1579170, traps=1580406, intrs=167471, ctxswitch=89049
softint=23423, syscalls=506804
  cpu10:
faults=2153399, traps=2154831, intrs=184225, ctxswitch=149924
softint=40597, syscalls=828691
  cpu11:
faults=3136585, traps=3138031, intrs=219926, ctxswitch=251413
softint=67270, syscalls=1262227
  cpu12:
faults=4211510, traps=4213265, intrs=222549, ctxswitch=273560
softint=78470, syscalls=1584403
  cpu13:
faults=3938228, traps=3940765, intrs=252763, ctxswitch=368601
softint=110598, syscalls=1636441
  cpu14:
faults=1720207, traps=1721476, intrs=183332, ctxswitch=138148
softint=43486, syscalls=759336
  cpu15:
faults=1547431, traps=1548457, intrs=177462, ctxswitch=126099
softint=36803, syscalls=657976
  fault counts:
noram=0, noanon=0, pgwait=0, pgrele=0
ok relocks(total)=19975519(19975516), anget(retrys)=1498606(0), amapcopy=186
2658
neighbor anon/obj pg=1672558/779689, gets(lock/unlock)=20195408/19975523
cases: anon=1035657, anoncow=462949, obj=18439642, prcopy=1755801, przero=11
148433
  daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=0, swpgavail=0
swpages=0, swpginuse=0, swpgonly=0, paging=0



Emile `iMil' Heitor * 
  _
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org  |  - against HTML email  X
| http://gcu.info|  & vCards / \

Re: NetBSD/amd64 7.0 domU freezes while running pbulk.sh (was Re: Raspberry Pi 2, nfs mount hangs after some time)

[Manuel Bouyer]

On Thu, Nov 26, 2015 at 07:13:04PM +0100, Emile `iMil' Heitor wrote:
> On Thu, 26 Nov 2015, Manuel Bouyer wrote:
> 
> >what does 'show uvm' report ?
> 
> db{0}> show uvm
> Current UVM status:
>   pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
> , ncolors=8  7444115 VM pages: 53990 active, 1807 inactive, 1 wired, 7302474 
> fre

OK, so it's not a "out of memory" issue

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Fan control on nForce430 MCP61 chipset

[Tom Sweet]

On Thu, Nov 26, 2015 at 3:32 AM, Martin Husemann  wrote:
> Can you show the output of the envstat command?
>
> Martin

Thank you Martin.

# envstat -D
envstat: no drivers registered

# envstat -c /etc/envsys.conf
envstat: device `iic0' doesn't exist
envstat: please fix the configuration file!
* Note this was tried for nfsmbc0, nfsmb0, and iic0, each of which is
present in the dmesg output.

//Tom

Re: NetBSD/i386 7.0 hangs booting 486

[Felix Deichmann]

2015-11-27 8:15 GMT+01:00 Masanobu SAITOH :
> Does this change fix PR#49741, right?
>
> http://gnats.netbsd.org/49741
>
> (PR#49741 was filed by the person who reported this problem first in
> last February as you 
> mentioned(https://mail-index.netbsd.org/port-i386/2015/02/06/msg003348.html))

Yes, probably.

> That PR said it occured on his netbsd-6 machine, so it should be pulled
> up to netbsd-6, too.

No, I think he did an upgrade from 6.1_STABLE to a current 7 and
noticed the problem after that.

[quote from his e-mail to port-i386]
I was in the process of upgrading an old i486-system to a current
NetBSD/i386 (sources from about January 12th [2015]), when bad things
started to happen.
[/quote]

[quote from PR]
Release:NetBSD 6.1_STABLE
[but]
System: NetBSD darling.urc.uninett.no 7.99.4 NetBSD 7.99.4 (DARLING)
[/quote]

I tested NetBSD 6.1.5 on my affected 486 and it worked fine without patch.
Nevertheless, if you can find this or a similar problem in netbsd-6,
which is not occuring for some reason then, I do not object to fixing
it of course. :)

Felix