From owner-freebsd-bugs Mon Feb 5 04:28:19 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA23769 for bugs-outgoing; Mon, 5 Feb 1996 04:28:19 -0800 (PST) Received: from obelix.cica.es (obelix.cica.es [150.214.1.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA23733 for ; Mon, 5 Feb 1996 04:28:06 -0800 (PST) Received: (from amora@localhost) by obelix.cica.es (8.7.1/8.7.1) id NAA11830; Mon, 5 Feb 1996 13:19:22 +0100 (GMT-1:00) Date: Mon, 5 Feb 1996 13:19:22 +0100 (GMT-1:00) From: "Jesus A. Mora Marin" Message-Id: <199602051219.NAA11830@obelix.cica.es> To: undisclosed-recipients:; Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Hi. Weekend came, so time to work on what I do like (no more code-grinding stupid apps in a brain-damaged 4GL five days a week, no more telling lusers that ttys use to work faster when plugged. Barfulous, but have to earn my life). I have compiled again my custom kernel with `config -g', backed up a version with the debug info (more than 6MB long!), set the dumpdev option, rebooted with the new stripped kernel and forced the crash. This time all worked right and I could savecore and run a `gdb -k' session on the crash dump. Here you are: (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /usr/crash/kernel.0 # My /var fs is only 10MB -enough for me- (kgdb) core-file /usr/crash/vmcore.0 IdlePTD 1a1000 current pcb at 195374 panic: page fault #0 boot (howto=256) at ../../i386/i386/machdep.c:892 892 dumppcb.pcb_ptd = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../i386/i386/machdep.c:892 #1 0xf0112aa3 in panic (fmt=0xf016b6fc "page fault") at ../../kern/subr_prf.c:124 #2 0xf016c1ee in trap_fatal (frame=0xf0189f18) at ../../i386/i386/trap.c:745 #3 0xf016bd60 in trap_pfault (frame=0xf0189f18, usermode=0) at ../../i386/i386/trap.c:667 #4 0xf016b9ff in trap (frame={tf_es = 16, tf_ds = -252706800, tf_edi = 0, tf_esi = -266780848, tf_ebp = -266821732, tf_isp = -266876354, tf_ebx = 85, tf_edx = 560, tf_ecx = 561, tf_eax = -236834816, tf_trapno = 12, tf_err = 2, tf_eip = -266876354, tf_cs = -267255800, tf_eflags = 66118, tf_esp = 144, tf_ss = -266876864}) at ../../i386/i386/trap.c:307 #5 0xf0164c9d in calltrap () #6 0xf017ca3e in matcd_blockread (state=144) at ../../i386/isa/matcd/matcd.c:2043 #7 0xf0107110 in softclock () at ../../kern/kern_clock.c:654 #8 0xf0165ff7 in doreti_swi () #9 0xf016b3ec in cpu_switch () (kgdb) up 4 #4 0xf016b9ff in trap (frame={tf_es = 16, tf_ds = -252706800, tf_edi = 0, tf_esi = -266780848, tf_ebp = -266821732, tf_isp = -266876354, tf_ebx = 85, tf_edx = 560, tf_ecx = 561, tf_eax = -236834816, tf_trapno = 12, tf_err = 2, tf_eip = -266876354, tf_cs = -267255800, tf_eflags = 66118, tf_esp = 144, tf_ss = -266876864}) at ../../i386/i386/trap.c:307 307 (void) trap_pfault(&frame, FALSE); (kgdb) frame frame->tf_ebp frame->tf_eip #0 0xf017ca3e in matcd_blockread (state=144) at ../../i386/isa/matcd/matcd.c:2043 2043 *addr++=inb(port+DATA); (kgdb) list # Modified by hand. Not compiled lines deleted. 2033 addr=bp->b_un.b_addr + mbx->skip; 2039 if (iftype==0) { /*<20>Creative host I/F*/ 2040 outb(port+PHASE,1); /*Enable data read*/ 2041 while((inb(port+STATUS) & 2042 (DTEN|STEN))==STEN) {/*<19>*/ 2043 *addr++=inb(port+DATA); ^^^^^^^ 2047 } 2048 outb(port+PHASE, 0); /* Disable read */ (kgdb) print addr $1 = 0xf1e23000
(kgdb) print bp $2 = (struct buf *) 0xf0f04858 (kgdb) print bp->b_un.b_addr $3 = 0xf1e22800 ..... (lot of pretty struct fields) (kgdb) print mbx->skip $4 = 0 (kgdb) quit For the sake of completion, some other vars inspected in the same session: mbx->nblk 1 mbx->partition 0 mbx->sz 2048 cd->partflags[mbx->partition] 1 iftype 0 i 85 blknum 0xf1e23000 ldrive 0 cdrive 0 port 560 (0x230) cmd { 0x00, 0xfc, 0x62, 0xf0, 0x00, 0xfc, 0x62, 0xf0, 0x00, 0xf6, 0x62, 0xf0 } phase 0 state 0 (it was 0x90 at the start of function) That is, the offending source line is exactly the one pointed out by J"org Wunsch in msg <199601301131.MAA13737@uriah.heep.sax.de>. Further, at the start of the read loop, `addr' pointed to 0xf1e22800 (bp->b_un.b_addr + mbx->skip), and at the time of panic it was pointing to an address 2048 bytes up, i.e. the loop was reading the 2049th byte of the block. The problem seems to be hardware/firmware related (mbx values denote that a 2048 byte block was to be read, I guess). For some reason, the drive wants to transfer more than the 2KB expected. > The only way that more than 2048 bytes could be read (assuming no drive > malfunction) is if the "c" partition was opened, which causes the drive > to read 2532 byte sectors. This is intentional. Partition "c" must > never be mounted. Er... I have NEVER tried to mount a "c" partition. I've read manpage for matcd and was warned against. > .... It is possible that the firmware he has in the system > has a bug and the drive returns more data than it should, which could cause > a GPF, but such an action would break the Windows driver that also reads > bytes until the drive says "All Done" as matcd does. In fact, there aren't problems with Windows, nor Linux. > I was planning to change the way this loop was done anyway to improve > speed (the 6x TEAC drive bogs badly here) and simply pull in the expected > number of bytes and deal with any excess later, but I really can't blame > the current implementation as the cause of this reported failure since it > won't fail here. According to this idea I have patched the read loop, keeping a count of the bytes read in a block and `breaking' out of the loop when it reaches the expected 2048 bytes, and simply ignoring the excess. I am not sure this is a convenient solution but it has proved to work great. Yes, the panic has gone, although I wouldn't bet that this crude approach cannot raise some unexpected and `creative' problems later :). For example, something must be done to deal with raw blocks. Frank, I think that, if you've implemented the driver this way, you'd have your reasons. So, any clue to deal with the nasty behaviour of my hardware? I tell you, now this simplistic patch works fine for accessing data in a mounted fs on CD-ROM -enough for me-, but... > Again, I do not have the precise drive firmware revision Jesus has. I have reviewed the text of my original report, and have seen I stated: Creative Lab, Matsushita/Panasonic CR-563-x 0.81. Oops! Sorry, this is the signature of the MS-DOS CD-ROM driver. More details about this: my CD-ROM drive is a Creative Lab CR-563-B, manufactured in January '95. I cannot extract more info from the messy bunch of numbers and codes in the labels on the drive. It is connected to the socket in a Creative Labs SoundBlaster AWE 32, model CT2760. The board has a signature '02 95' on it. Extract your own conclusions. (NB: -You CAN skip this comment- I know at least two CR-563 drives that died miserably because of a broken design in the heatsinking of the IC that drives the spindle motor. They simply stopped working without even some smoke to let you know they had joined their ancestors. I was told that some changes were introduced in the hardware of model CR563B, but nobody is sure whether this has been fixed -so you couldn't :) That's all. Comments, ideas, suggestions about this question will be highly appreciated. Thanks. Jesus