Date: Sat, 28 Nov 2015 14:57:08 +0000 (UTC) From: mlel...@serpens.de (Michael van Elst) Message-ID: <n3cfc4$2pm$1...@serpens.de>
| I've just committed a few fixes for disks with non-512byte sectors | to HEAD. | | cgd now works on my drive with 1k sectors. Thanks, works for me too (I didn't have all the changes you made to cgd.c and certainly not all of the ones to the other files, though I had been looking in that region). It works for my 4K sector drive now too ... at least, provided that it is configured as cgd0 When it is cgd1, I get a panic ... that I think is from the same underlying cause as PR 41704 (from July 2009...) This is (it appears) caused by this line in cgdioctl() ... dk_getdisklabel(dksc, 0 /* XXX ? (cause of PR 41704) */); The 0 ((dev_t)0) and XXX have been there since cgd.c 1.1, so this is nothing new! Whether it is because of the secsize changes, or whether it would always have caused a panic (I config'd cgd1 without bothering with cgd0 .. my convention is that cgd0 is always a (fairly small) filesystem that contains stuff like my ssh private keys ... I didn't have that on the test system I was using, no point .. but I still did cgdconfig cgd1 ... just from habit.) When I switched to use cgd0 it worked. The panic traceback was ... vpanic() at vpanic+0x140 snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x19 disk_read_sectors() at disk_read_sectors+0x47 read_sector() at read_sector+0x1d scan_mbr() at scan_mbr+0x32 readdisklabel() at readdisklabel+0x150 dk_getdisklabel() at dk_getdisklabel+0xbf cgdioctl() at cgdioctl+0x76c cdev_ioctl() at cdev_ioctl+0x90 VOP_IOCTL() at VOP_IOCTL+0x3b vn_ioctl() at vn_ioctl+0xa6 sys_ioctl() at sys_ioctl+0x17e syscall() at syscall+0x9c --- syscall (number 54) --- which is about as blatant a clue that you can get that this is the problem. (That is not the panic I was seeing in my earlier testing, but I might have been using cgd0 to test earlier, that was a couple of months ago now, and I don't remember...) So, I think it is finally time to figure out how to fix PR 41704 once and for all - I doubt it is worth worrying about why I got a panic, and the PR reports just getting EINVAL, and often, even for cgd1... things seem to work fine (normally with cgd0 config'd before cgd1 of course.) But since this has been there, complete with its XXX, since 2002 when cgd was committed, it obviously isn't going to be easy to fix. Somehow, we need to get the dev_t for the device passed down, or stored somewhere. Currently that info seems to be missing. Anyone have any suggestions? kre