This may or may not be a bug, but I figured that sending out the messagewould do better good than not sending one out at all:

when I run the command:

# mount -t hfs /dev/scd0 /mnt/cdrom

The kernel gives an Oops that traces back to line buffer.c:2555 (kernelversion 2.4.23-pre1). I'd attach the Oops output, but I'm on a remotemachine now.

The BUG() macro is called because the block size requested to be read byHFS (512 bytes) is not the same as the hardware block size set by theSCSI drivers (2048 by default). grow_buffers() wants whatever called itto request a blocksize that is a multiple of get_hardsect_size().

I would have bothered myself to write a fix, since I firmly believe thata CD could have an HFS filesystem, but the kernel code has grown socomplex that writing the code to perform the reads correctly would bedifficult.

My idea was to change buffer.c:2555 to just modify the requested blocksize to fit the hardware block size, then return an offset into a bufferwhere that requested (sub)block is. For example, if you're requesting512 bytes but the hardsect size is 2048. Read a 2048 block, and offsetthe buffer to (block_no % 4) * 512. This may have worked, but it couldpossibly have been slow too.

By the way, the offending code is the hfs/super.c:hfs_read_super() thattraces to hfs/sysdep.c:hfs_buffer_get() which calls sb_bread() andfurther then to buffer.c:grow_buffers(). hfs_read_super() setsmdb->s_blocksize to 512. sb_bread will use the hardsect_size set by theSCSI driver (drivers/scsi/sr.c:sr_init()).

Alas, if this information helps out, let me know -- I'm not on anykernel mailing list. Further information about my system is attached.