(resent to include other lists) On Wednesday 07 December 2005 23:58, Andrew de Quincey wrote: > Reposting to the -devel list since there was no response on -user. > > Hi, I'm using linux kernel 2.6.14 with an generation 1 ipod connected via > ieee1394/sbp2. > > I can mount/unmount it and use it fine. It even works with HAL now. > > The problem comes when I want to remove it. If I do: > > eject /dev/sdb > > The kernel panics with the following error: > Kernel panic - not syncing: PCI-DMA: high address but no IOMMU > > I'm using an nforce 4 motherboard (Asus A8N-SLI Deluxe). The ipod is > attached to the ieee1394 port on a creative labs Audigy2 sound card (uses > OHCI-1394). More info (I'm on an AMD64 in 64 bit mode BTW): eject sends a CDROMEJECT ioctl first of all. It is this IOCTL that kills my system. If I hack/tell it to just use a "SCSI eject", it works and actually makes my ipod show that tick thing showing it is safe to remove it. Tracing through the kernel for the CDROMEJECT shows: drivers/scsi/sd.c/sd_ioctl() -- calls scsi_cmd_ioctl() drivers/block/scsi_ioctl.c/scsi_cmd_ioctl() -- emulates the CDROMEJECT ioctl as a START_STOP unit SCSI packet command ... then that passes through the blockdev/scsi layers until: drivers/ieee1394/sbp2.c/sbp2scsi_queuecommand() -- this function actually works fine - it must be either in the callback handler when the command completes (?) or sometime afterwards. The last SCSI command received by sbp2 before the crash is: 1b 00 00 02 00 Which is definitely what scsi_cmd_ioctl() is setting up. CDROMEJECT works on other scsi devices - e.g. my USB storage pendrive appears as a SCSI drive, and can be "safely removed" by simply calling a CDROMEJECT ioctl. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html