From nobody  Mon Feb  3 14:39:02 1997
Received: (from nobody@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA25284;
          Mon, 3 Feb 1997 14:39:02 -0800 (PST)
Message-Id: <199702032239.OAA25284@freefall.freebsd.org>
Date: Mon, 3 Feb 1997 14:39:02 -0800 (PST)
From: javaman@halcyon.com
To: freebsd-gnats-submit@freebsd.org
Subject: accessing floppy using wrong major number causes crash at next access
X-Send-Pr-Version: www-1.0

>Number:         2649
>Category:       kern
>Synopsis:       accessing floppy using wrong major number causes crash at next access
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb  3 14:40:01 PST 1997
>Closed-Date:    Sat Feb 8 23:19:00 MET 1997
>Last-Modified:  Sat Feb  8 23:20:41 MET 1997
>Originator:     David DeLaune
>Release:        2.2-BETA_A
>Organization:
>Environment:
FreeBSD mercury.org 2.2-BETA_A FreeBSD 2.2-BETA_A #0:
Mon Jan 27 21:03:32 PST 1997     
root@mercury.org:/usr/src/sys/compile/MYKERNEL  i386
>Description:
Accessing the floppy using the wrong /dev/fdX.XXXX will cause a crash
at the next access.  I was using mtools at the time, but I have repeated
this problem using dd as well.  I first access a 720K floppy as a 1440K
floppy which gives the following error:
# mdir 
# Feb 3 13:36:35 mercury/kernel: fd0c: hard error reading fsbn 0 of 0-3
(ST040)<abnrml> ST1 1<no_Am> ST2 0 cyl 0 hd 0 sec 1

Then I try to access the floppy using the correct device type (720K defined
in mtools.conf as drive b: file="/dev/fd0.720" exclusive)

Fatal Trap 9: general protection fault while in kernel mode
instruction pointer                         = 0x8:0xf010def1
stack pointer                               = 0x10: 0xefbffd64
frame pointer                               = 0x10: 0xefbffd8c
code segment                                = base 0x0, limit 0xfffff, type 0x1b
processor eflags                            = interrupt enabled, resume, IOPL=0
int mask                                    = net tty bio
panic: general protection fault

syncing disk 10 10 10 10 .......<several times>
giving up
>How-To-Repeat:
I can repeat this by accessing fd0 with the wrong dev for the floppy type
that is in the drive, on the second access using dd or mtools.  Have not
tried mount or fdformat, but I will.	
>Fix:

>Release-Note:
>Audit-Trail:

From: j@uriah.heep.sax.de (J Wunsch)
To: javaman@halcyon.com
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/2649: accessing floppy using wrong major number causes crash at next access
Date: Tue, 4 Feb 1997 00:26:13 +0100

 As javaman@halcyon.com wrote:
 
 > Accessing the floppy using the wrong /dev/fdX.XXXX will cause a crash
 > at the next access.  I was using mtools at the time, but I have repeated
 
 (Btw. that's the minor number, not the major number.  Nevermind.)
 
 > Fatal Trap 9: general protection fault while in kernel mode
 > instruction pointer                         = 0x8:0xf010def1
 > stack pointer                               = 0x10: 0xefbffd64
 > frame pointer                               = 0x10: 0xefbffd8c
 > code segment                                = base 0x0, limit 0xfffff, type 0x1b
 > processor eflags                            = interrupt enabled, resume, IOPL=0
 > int mask                                    = net tty bio
 > panic: general protection fault
 
 I've never seen this, and be assured, i also use mtools every now
 and then...
 
 Again, do a
 
 	nm /kernel | sort | more
 
 and extract the region around 0xf010def1.
 
 What makes me wonder is the GP fault.  This is something concerning
 the dreaded segment registers... maybe Bruce's got an idea offhand.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Sat Feb 8 23:19:00 MET 1997 
State-Changed-Why:  
The originator confirmed this to be a problem with his CD-ROM 
drive. 

>Unformatted:
