Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
It was a SCAM! Well, SCAM seems to be the problem. I don't know if it's a behavior particular to the new Linux driver, but the SCAM-assigned IDs got ignored to some extent. What seemed to be happening was that the HD (not a boot device, BTW) that was SCAMed to ID#15 ended up being ID#0 to the Linux driver. As I said before, the CDRW was on ID#0 so things got messy. The best I could do before disabling SCAM was seeing the HD at ID#0 and the SyJet at ID#4, which was the only non-SCAM device. Best I can figure, the driver can't handle SCAM and assumes that everything not explicitly assigned is at 0. That would explain why I could see the HD (fastest response to the controller) and the non-SCAM stuff, but everything else on 0 is hidden. So now I'm a few jumper caps poorer, and I've lost one of the drive mounting screws. Oh well. Thanks to everyone who helped. Since the consensus was that it had to be an address or termination problem, it convinced me to do some poking. -- -Matt The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |