kernel/4942: system freezes with mfs writes

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

kernel/4942: system freezes with mfs writes

Juha Erkkila
>Number:         4942
>Category:       kernel
>Synopsis:       system freezes with mfs writes
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 17 12:40:02 GMT 2005
>Originator:     Juha Erkkila
>Release:        OpenBSD 3.8-stable
        System      : OpenBSD 3.8
        Architecture: OpenBSD.i386
        Machine     : i386

System hangs when as I write ``too much'' data to an mfs filesystem.
``Too much'' here depends on system physical memory size
(meaning main memory + swap space), and not on how large the
actual filesystem is.


I'll describe my setup in detail here, and then show how I
can freeze this system.

$ disklabel /dev/wd1c
disklabel: warning, DOS partition table with no valid OpenBSD partition
# /dev/wd1c:
type: ESDI
disk: ESDI/IDE disk
label: ST33232A        
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 6253
total sectors: 6303024
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0

16 partitions:
#             size        offset  fstype [fsize bsize  cpg]
  a:       4718385            63  4.2BSD   2048 16384  328 # Cyl     0*-  4680
  b:       1584576       4718448  4.2BSD   2048 16384  328 # Cyl  4681 -  6252
  c:       6303024             0  unused      0     0      # Cyl     0 -  6252

$ cat /etc/fstab
/dev/wd0a / ffs rw,softdep 90 1
/dev/wd0g /home ffs rw,nodev,nosuid,softdep 21 2
/dev/wd0d /tmp mfs rw,nodev,nosuid 0 0
/dev/wd0f /usr ffs rw,nodev,softdep 90 2
/dev/wd0e /var ffs rw,nodev,nosuid,softdep 90 2
/dev/wd1a /home/je/var ffs rw,nodev,nosuid,softdep 0 2
/dev/wd1b /home/je/tmp mfs rw,nodev,nosuid 0 0 # HERE, BUGS LURKING!

$ mount
/dev/wd0a on / type ffs (local, softdep)
/dev/wd0g on /home type ffs (local, nodev, nosuid, softdep)
mfs:18434 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=131040 1K-blocks)
/dev/wd0f on /usr type ffs (local, nodev, softdep)
/dev/wd0e on /var type ffs (local, nodev, nosuid, softdep)
/dev/wd1a on /home/je/var type ffs (local, nodev, nosuid, softdep)
mfs:15152 on /home/je/tmp type mfs (asynchronous, local, nodev, nosuid, size=792288 1K-blocks)

$ sysctl vm.swapencrypt.enable

$ swapctl -l
Device      1K-blocks     Used    Avail Capacity  Priority
swap_device    262080        0   262080     0%    0

The system has 128 megabytes of main memory (as can be seen from
dmesg, following later).  So far, this looks good, except for the
warning from disklabel about partitioning table.  However,
if i try to write something to /home/je/tmp like this:

$ dd if=/dev/zero of=/home/je/tmp/zero.bin

the system will freeze at some point after about 320
megabytes have been written.  I thought there must be something
to this number, so I disabled swap, after which the freeze would
occur at about 60 megabytes or so.

Also, the first time I run into this bug, the system did not freeze,
but programs started randomly segfaulting, as if they were (buggy and)
on low memory conditions.

To me this seems as if mfs would work through the kernel virtual memory
subsystem (as it should), but the VM system is still unaware of
the space available in mfs-mounted devices.


No fix.  Maybe check out some things in the VM subsystem...


OpenBSD 3.8-stable (GENERIC) #0: Sat Dec 17 13:24:54 EET 2005
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 551 MHz
cpu0: disabling processor serial number
real mem  = 133787648 (130652K)
avail mem = 115462144 (112756K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(75) BIOS, date 08/18/99, BIOS32 rev. 0 @ 0xf0530
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xbe2
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0b60/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("VIA VT82C586 ISA" rev 0x00)
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc0000/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "VIA VT82C691 PCI" rev 0x22
ppb0 at pci0 dev 1 function 0 "VIA VT82C598 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage Pro" rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 4 function 0 "VIA VT82C596A ISA" rev 0x09
pciide0 at pci0 dev 4 function 1 "VIA VT82C571 IDE" rev 0x06: ATA33, channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: <Maxtor 91021U2>
wd0: 16-sector PIO, LBA, 9770MB, 20010816 sectors
wd1 at pciide0 channel 0 drive 1: <ST33232A>
wd1: 16-sector PIO, LBA, 3077MB, 6303024 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <PLEXTOR, CD-R PX-320A, 1.03> SCSI0 5/cdrom removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
st0 at scsibus1 targ 0 lun 0: <HP, COLORADO 8GB, 2.06> SCSI2 1/sequential removable
st0: drive empty or not ready
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
st0(pciide0:1:1): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 4 function 2 "VIA VT83C572 USB" rev 0x02: irq 5
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ppb1 at pci0 dev 4 function 3 "VIA VT82C596 Power" rev 0x00
ppb1: not configured by system firmware
eap0 at pci0 dev 9 function 0 "Ensoniq AudioPCI97" rev 0x06: irq 5
ac97: codec id 0x43525913 (Cirrus Logic CS4297A rev 3)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D
audio0 at eap0
midi0 at eap0: <AudioPCI MIDI UART>
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi1 at pcppi0: <PC speaker>
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: W83781D
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
isapnp0 at isa0 port 0x279: read port 0x20b
ep1 at isapnp0 "3Com 3C509B EtherLink III, TCM5095, PNP80F7, " port 0x210/16 irq 9: address 00:50:04:23:7a:70, utp (default utp)
biomask ed65 netmask ef65 ttymask ffe7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302


Reply | Threaded
Open this post in threaded view

Re: kernel/4942: system freezes with mfs writes

Juha Erkkila
The following reply was made to PR kernel/4942; it has been noted by GNATS.

From: Juha Erkkila <[hidden email]>
To: Pedro Martelletto <[hidden email]>
Cc: [hidden email]
Subject: Re: kernel/4942: system freezes with mfs writes
Date: Sat, 17 Dec 2005 21:05:12 +0200

 On Sat, Dec 17, 2005 at 11:04:25AM -0200, Pedro Martelletto wrote:
 > When the system freezes, can you still break into ddb?
 well yes, i can still break into ddb
 but now that i look into this again, i see i'm only misusing the
 system.  as i'm trying it again, i can see clearly that the
 data i write to that mfs-filesystem does not go to /dev/wd1b as i
 first believed, but instead it is written to main memory and swap
 space.  a more careful reading of mount_mfs(8) shows:
 ``The special file is only used to read the disk label which provides
 a set of configuration parameters for the memory based file system.''
 so i guess this bug report is bogus.  nevertheless, i must say
 i think this behaviour is slightly confusing,
 and the basic idea on what i thought it would do is still sound
 (having a temporary, encrypted scratch space that does not
 interfere with the rest of the memory management)
 sorry about this, i guess i should have consulted misc instead...
 hmm... i still wonder why such a mount is allowed at boot?
 trying it once the system is up gives me this:
 $ umount /home/je/tmp
 $ mount_mfs /dev/wd1b /home/je/tmp
 mount_mfs: mmap: Cannot allocate memory
 i can send any output from ddb, in case someone wants to see it