stevens@hsi.UUCP (12/20/83)
Our new 4.2 system immediately crashes with a
panic: munhash
when the new dbx debugger is used to step through a program.
A scan of the last year's net.bugs.4bsd showed that this problem
was with 4.1c too.
Anyone fixed this yet ?
Richard Stevens
Health Systems International, New Haven, CT
{ decvax | hao | seismo | sdcsvax } ! kpno ! hsi ! stevens
ihnp4 ! hsi ! stevensmccallum@opus.UUCP (12/20/83)
The bug fix for the panic: munhash in 4.2/4.1c has been posted.
The posted fix did not explain under what conditions the panic occurs.
The problem shows up when you have a LARGE file system and use a debugger
on program that resides in the part of the file system that makes the block
number field use all 20 bits. The fix is as follows:
Path: opus!nbires!cires!hao!hplabs!sri-unix!RWS@mit-xx
From: RWS%mit-xx@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: sundry 4.2 bugs
Message-ID: <13280@sri-arpa.UUCP>
Date: Wed, 2-Nov-83 15:15:00 MST
Article-I.D.: sri-arpa.13280
Posted: Wed Nov 2 15:15:00 1983
Date-Received: Thu, 3-Nov-83 18:47:16 MST
Lines: 64
Despite claims to the contrary, the block number sign extension problem still
exists. Berkeley put in a fix that should have worked, but a C compiler bug
apparently keeps it from working. In /sys/sys/vm_mem.c in memall() the code
swapdev : mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno
should be changed to
swapdev : mount[c->c_mdev].m_dev, c->c_blkno
and in /sys/vax/vm_machdep.c in chgprot() the code
munhash(mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno);
should be changed to
munhash(mount[c->c_mdev].m_dev, c->c_blkno);
because the C compiler apparently incorrectly folds the (daddr_t) and (u_long)
together and sign extends anyway. Simply taking out the (daddr_t)(u_long)
works, although lint will probably complain about it.
chris@mddc.UUCP (Chris Maloney) (12/21/83)
---
I belive that the correction mention previously by RWS@mit-xx
will fix this problem (It did for use anyway).
Chris Maloney
7209 Dixie Highway
Fairfield, Ohio 45014
Management Decisions Development Corp.
(513)874-6464
...{ucbvax,decvax,inhp4,mhuxi}!cbosgd!qusavx!mddc!chris (uucp)
----
From qusavx!cbosgd!mhuxl!eagle!harpo!seismo!hao!hplabs!sri-unix!RWS@mit-xx Wed Dec 31 19:00:00 1969
Path: mddc!qusavx!cbosgd!mhuxl!eagle!harpo!seismo!hao!hplabs!sri-unix!RWS@mit-xx
From: RWS%mit-xx@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: sundry 4.2 bugs
Message-ID: <13280@sri-arpa.UUCP>
Date: Wed, 2-Nov-83 17:15:00 EST
Article-I.D.: sri-arpa.13280
Posted: Wed Nov 2 17:15:00 1983
Date-Received: Fri, 4-Nov-83 09:05:00 EST
Lines: 64
Status: RO
Despite claims to the contrary, the block number sign extension problem still
exists. Berkeley put in a fix that should have worked, but a C compiler bug
apparently keeps it from working. In /sys/sys/vm_mem.c in memall() the code
swapdev : mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno
should be changed to
swapdev : mount[c->c_mdev].m_dev, c->c_blkno
and in /sys/vax/vm_machdep.c in chgprot() the code
munhash(mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno);
should be changed to
munhash(mount[c->c_mdev].m_dev, c->c_blkno);
because the C compiler apparently incorrectly folds the (daddr_t) and (u_long)
together and sign extends anyway. Simply taking out the (daddr_t)(u_long)
works, although lint will probably complain about it.
---system@asuvax.UUCP (Marc Lesure) (02/11/85)
I need an explanation of what "Panic: munhash" means. We are running 4.2bsd and seem to crash daily with this panic. Also, is there any sort of documentation which explains what the different panics are and what they mean. ------------------------------------------------- Marc Lesure System Manager Engineering Computer Center Arizona State University Tempe, Arizona UUCP: ...!ucbvax!arizona!asuvax!lesure CSNET: lesure@asu
rick@seismo.UUCP (Rick Adams) (02/12/85)
From mccallum@opus.ARPA Wed Dec 21 15:14:15 1983
Date: 20 Dec 83 6:38:33-PST (Tue)
From: seismo!hplabs!hao!cires!nbires!opus!mccallum@ucb-vax
Subject: Re: panic: munhash (4.2BSD crash)
The bug fix for the panic: munhash in 4.2/4.1c has been posted.
The posted fix did not explain under what conditions the panic occurs.
The problem shows up when you have a LARGE file system and use a debugger
on program that resides in the part of the file system that makes the block
number field use all 20 bits. The fix is as follows:
Path: opus!nbires!cires!hao!hplabs!sri-unix!RWS@mit-xx
From: RWS%mit-xx@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: sundry 4.2 bugs
Message-ID: <13280@sri-arpa.UUCP>
Date: Wed, 2-Nov-83 15:15:00 MST
Article-I.D.: sri-arpa.13280
Posted: Wed Nov 2 15:15:00 1983
Date-Received: Thu, 3-Nov-83 18:47:16 MST
Lines: 64
Despite claims to the contrary, the block number sign extension problem still
exists. Berkeley put in a fix that should have worked, but a C compiler bug
apparently keeps it from working. In /sys/sys/vm_mem.c in memall() the code
swapdev : mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno
should be changed to
swapdev : mount[c->c_mdev].m_dev, c->c_blkno
and in /sys/vax/vm_machdep.c in chgprot() the code
munhash(mount[c->c_mdev].m_dev, (daddr_t)(u_long)c->c_blkno);
should be changed to
munhash(mount[c->c_mdev].m_dev, c->c_blkno);
because the C compiler apparently incorrectly folds the (daddr_t) and (u_long)
together and sign extends anyway. Simply taking out the (daddr_t)(u_long)
works, although lint will probably complain about it.ed@mtxinu.UUCP (Ed Gould) (02/15/85)
> I need an explanation of what "Panic: munhash" means. We are running > 4.2bsd and seem to crash daily with this panic. I've seen several questions lately about this and other well-known 4.2 bugs, so I'm posting this note about the Bug List. As a service to the 4.2 community, mt Xinu makes available the colection of bug reports that have been mailed to Berkeley. A tape is availatle to holders of AT&T licenses that are 32/V of newer who also have a 4.2 license from UC. To obtain a tape, send copies of the relevant pages (3 from the AT&T license, 2 from UC) and a check for $110.00 (or a purchase order for $150.00) to mt Xinu 739 Allston Way Berkeley, CA 94710 Attn: Buglist A paper copy (or a tape for the above price) that does not contain any AT&T licensed source is also available to anyone who requests it, either by US Mail to the above address or {ucbvax,decvax}!mtxinu!buglist. Please *do not* phone for information. NOTE: This list is a raw compilation of reports from members of the 4.2 community. Mt Xinu has not edited or verified *any* of the reports of proposed fixes, with the exception that duplicates may be merged, and flames without content have been removed. -- Ed Gould mt Xinu, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146