In message <199905221811.maa09...@pluto.plutotech.com>, "Justin T. Gibbs" write
s:
>>>CAM has finished probing at this point, but it holds off on announcing
>>>devices until it has all necessary info. The drives may need to
>>>be spun up, etc. I believe the printf happens before the device has
>>
>>CAM has finished probing at this point, but it holds off on announcing
>>devices until it has all necessary info. The drives may need to
>>be spun up, etc. I believe the printf happens before the device has
>>been opened and CAM blocks in the open until the device is really
>>ready for service.
In message <199905221736.laa08...@pluto.plutotech.com>, "Justin T. Gibbs" write
s:
>>Am I missing something here ? We shouldn't set the root device until
>>CAM is done probing, right ?
>
>CAM has finished probing at this point, but it holds off on announcing
>devices until it has all necessary in
>In message <199905192231.qaa09...@narnia.plutotech.com>, "Justin T. Gibbs" wri
>t
>es:
>>In article <199905191637.jaa03...@dingo.cdrom.com> you wrote:
>>> I'm not sure why it happens like this; try putting a DELAY() just
>>> before we actually set the root device and see if you can put it off.
>>
In message <199905192231.qaa09...@narnia.plutotech.com>, "Justin T. Gibbs" writ
es:
>In article <199905191637.jaa03...@dingo.cdrom.com> you wrote:
>> I'm not sure why it happens like this; try putting a DELAY() just
>> before we actually set the root device and see if you can put it off.
>
>Why no
>Perhaps I should use the log facility instead of printf in the announce
>code?
This would just duplicate boot-time output, since log() echoes everything
using printf() if the log device is not open.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in
In article <199905210435.oaa11...@godzilla.zeta.org.au> you wrote:
>>> I'm not sure why it happens like this; try putting a DELAY() just
>>> before we actually set the root device and see if you can put it off.
>>
>>Why not just spl() protect that printf call so that its output is
>>dumped contigu
>> I'm not sure why it happens like this; try putting a DELAY() just
>> before we actually set the root device and see if you can put it off.
>
>Why not just spl() protect that printf call so that its output is
>dumped contiguously into the console buffer?
This would just move the race. It is pr
In article <199905191637.jaa03...@dingo.cdrom.com> you wrote:
> I'm not sure why it happens like this; try putting a DELAY() just
> before we actually set the root device and see if you can put it off.
Why not just spl() protect that printf call so that its output is
dumped contiguously into the
> No offense, but can we use something like "assigning" in place of the
> rather loaded word "hanging?" I can just see the user bug reports now;
> "My root device is hanging! It says so every time I boot! HELP!" :)
Actually, it says "changing", but the 'c' gets printed and then all of
the inter
Heh. Well, then you would have people asking you what "ssigning" root
devices means :)
The message seems to get garbled when the CAM probes (being done in the
background) emit their messages. The "c" in my "changing" creates a new
device called cda4 in my log file:
Waiting 5 seconds for SCSI d
> No offense, but can we use something like "assigning" in place of the
> rather loaded word "hanging?" I can just see the user bug reports now;
> "My root device is hanging! It says so every time I boot! HELP!" :)
Or better still, revert to printing the SCSI probe results on a line break,
rathe
No offense, but can we use something like "assigning" in place of the
rather loaded word "hanging?" I can just see the user bug reports now;
"My root device is hanging! It says so every time I boot! HELP!" :)
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd
13 matches
Mail list logo
