[haiku-bugs] Re: [Haiku] #10880: haiku_loader can hang for minutes when one or more BIOS reported drives are unreadable

  • From: "MasterM" <trac@xxxxxxxxxxxx>
  • Date: Thu, 29 May 2014 09:46:42 -0000

#10880: haiku_loader can hang for minutes when one or more BIOS reported drives 
are
unreadable
----------------------------------+----------------------------
   Reporter:  MasterM             |      Owner:  jessicah
       Type:  bug                 |     Status:  assigned
   Priority:  high                |  Milestone:  R1/alpha5
  Component:  System/Boot Loader  |    Version:  R1/Development
 Resolution:                      |   Keywords:
 Blocked By:                      |   Blocking:
Has a Patch:  1                   |   Platform:  x86
----------------------------------+----------------------------

Comment (by MasterM):

 Replying to [comment:5 pdziepak]:
 > 1. Why try to read 512 bytes? Wouldn't 1 byte be enough?
 BIOSDrive::ReadAt uses BIOS interrupt 13h for disk access. You can only
 read a multiple of sector size that way and since there are virtually no
 devices with sector size less than 512 bytes, there is really no
 performance difference when reading anything <=512 bytes.

 Since find_unique_check_sums() uses chunks of 512b anyway I figured it
 would be good heuristic to check if one could read at least chunk that big
 without any explicit read errors.
 > 2. Format string, `driveID` is `uint8` not `unsigned`.
 On most compilers driveID should be promoted to unsigned int
 automatically. Should I add explicit cast there?

 > 3. That's probably out of scope of this patch but if I understand
 correctly (basing on th description of this ticket) we should try some
 perfect hashing here (without any bound on number of attempts) that
 guarantees generation of collision-free hash table in O(n). I admit though
 that I haven't fully read and understood the code in question yet, so this
 suggestion may be wrong.
 Well there are really two seperate problems with that piece of code. One
 of them is indeed a simple sum used as a poor's man hashing algorithm (a
 good candidate for replacement would be crc32 for example) and the other
 one is that it tries to read random sectors from a drive in an attempt to
 uniquely identify it. So if two drives contain exactly the same data, then
 it will fail anyway after max tries. This scenario is of course highly
 unlikely but nevertheless possible.

 It is worth noting that this algorithm only runs if haiku_loader is unable
 to get drive identification data from BIOS (which happens quite often on
 real hardware but I haven't looked at that code so can't say why).

--
Ticket URL: <https://dev.haiku-os.org/ticket/10880#comment:7>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: