Comment 11 for bug 287751

Some relevant information from my syslog:

#kernel loads 'sd' driver and detects (correctly) one of the four 500GB drives of which my 2TB RAID:0 consists.
Oct 7 19:20:43 quequotion kernel: [ 7.109183] sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
[...]
#kernel remarks that the partitions specified by the first disk are much larger than the first disk, which I figure for true, assuming it means the raid partitions (approximately 1.9tb root and 1gb swap, both across 4 disks).
Oct 7 19:20:43 quequotion kernel: [ 7.132039] sda: p1 exceeds device capacity
Oct 7 19:20:43 quequotion kernel: [ 7.132059] sda: p2 exceeds device capacity
[...]
#Nonetheless boot continues (I hate to think the linux kernel is capable of being more confused by it's operation than I am but you have to admire how it picks up and carries on even over several misgivings, objections and outright nonsense.) and the rest of the four drives are loaded with this message at the end of each one (?=b, c, and d)-
Oct 7 19:20:43 quequotion kernel: [ 7.158356] sd?: unknown partition table
[...]
#Some time later, amidst the loading of several other unrelated drivers-
Oct 7 04:10:28 quequotion kernel: [ 7.512474] attempt to access beyond end of device
Oct 7 04:10:28 quequotion kernel: [ 7.512478] sda: rw=0, want=3904983616, limit=976773168

Sometime I'll have to clear the syslog and reboot and see what range it's failing to get. The limit is set to the correct physical size of the physical drive, but the target must be somewhere within the logical size of the RAID.

Further questions:
1. Why is the kernel attempting to directly access any data on /dev/sda other than the partition table? Once it's loaded, all other data should be loaded from /dev/mappper/nvida_somerandomalphanumerics1... I think....

2. Does this look like a problem with the 'sd' driver, the 'dmraid' driver, or the kernel itself?

Another issue:

This came up in syslog as well:
Oct 7 04:10:28 quequotion kernel: [ 7.097556] Driver 'sd' needs updating - please use bus_type methods

I'm looking into that now, but I'll consider it related until proven otherwise (there can be no justice for computers).