On Tuesday 09 June 2009 19:12:18 bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13399 > > > > > > --- Comment #18 from Hans de Bruin <bruinjm@xxxxxxxxx> 2009-06-09 17:12:18 --- > Created an attachment (id=21831) > --> (http://bugzilla.kernel.org/attachment.cgi?id=21831) > debug1 dmesg Hans, thanks for the debug data! ide-cd: ide_cd_queue_pc: cmd[0]: 0x51, write: 0x0, timeout: 1750, cmd_flags: 0x8000 ide-cd: ide_cd_do_request: cmd: 0x51, block: 18446744073709551615 ide_cd_do_request: dev hda: type=a, flags=108a640 sector 18446744073709551615, nr/cnr 0/0 bio (null), biotail (null), buffer (null), data ffff88011b849ba0, len 2 ide-cd: cdrom_do_block_pc: rq->cmd[0]: 0x51, rq->cmd_type: 0xa ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x58, thislen: 2 ide-cd: ide_cd_check_ireason: ireason: 0x2, rw: 0x0 ide-cd: cdrom_newpc_intr: data transfer, rq->cmd_type: 0xa, ireason: 0x2 ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x50, thislen: 0 ide-cd: ide_cd_request_sense_fixup: rq->cmd[0]: 0x51 #3 ide-cd: ide_cd_queue_pc: cmd[0]: 0x51, write: 0x0, timeout: 1750, cmd_flags: 0x8000 ide-cd: ide_cd_do_request: cmd: 0x51, block: 18446744073709551615 ide_cd_do_request: dev hda: type=a, flags=108a640 sector 18446744073709551615, nr/cnr 0/0 bio (null), biotail (null), buffer (null), data ffff88011b849ba0, len 32 ide-cd: cdrom_do_block_pc: rq->cmd[0]: 0x51, rq->cmd_type: 0xa ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x58, thislen: 30 ide-cd: ide_cd_check_ireason: ireason: 0x2, rw: 0x0 ide-cd: cdrom_newpc_intr: data transfer, rq->cmd_type: 0xa, ireason: 0x2 ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x50, thislen: 2 ide-cd: ide_cd_request_sense_fixup: rq->cmd[0]: 0x51 #3 BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 The above command sequence corresponds to requests generated by drivers/cdrom/cdrom.c::cdrom_get_disc_info() /* set up command and get the disc info */ init_cdrom_command(&cgc, di, sizeof(*di), CGC_DATA_READ); cgc.cmd[0] = GPCMD_READ_DISC_INFO; cgc.cmd[8] = cgc.buflen = 2; cgc.quiet = 1; if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; /* not all drives have the same disc_info length, so requeue * packet with the length the drive tells us it can supply */ buflen = be16_to_cpu(di->disc_information_length) + sizeof(di->disc_information_length); if (buflen > sizeof(disc_information)) buflen = sizeof(disc_information); cgc.cmd[8] = cgc.buflen = buflen; if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; and we are hitting BUG because of the limitation of block layer, only rq->bio requests can be partially completed: int __blk_end_request(struct request *rq, int error, unsigned int nr_bytes) { if (rq->bio && __end_that_request_first(rq, error, nr_bytes)) return 1; add_disk_randomness(rq->rq_disk); end_that_request_last(rq, error); return 0; } so on error we complete the request fully instead of partially and later we try to complete the already freed request. Borislav, there are actually two issues here to investigate: * seems like we need to check for rq->bio before calling ide_cd_error_cmd() to make the regression go away (IOW we shouldn't don't do partial "good" completions for !rq->bio requests) * potentially revise our strategy of handling GPCMD_READ_DISC_INFO packet command returning less data than requested (in this particular case we ask for 32 bytes, device gives us only 30 bytes but returns good status) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
