Re: strange scsi/CAM related dmesg output

On Jun 18, 2010, at 9:11 AM, Alexander Best <alexbestms_at_uni- 
muenster.de> wrote:

> On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin <jhb_at_freebsd.org> wrote:
>> On Saturday 05 June 2010 2:54:15 pm Jille Timmermans wrote:
>>> Scott Long schreef:
>>>> On Jun 4, 2010, at 4:35 PM, Alexander Best wrote:
>>>>
>>>>> hi there. running HEAD, amd64 and r208806 i get this dmesg output
>>>>> which doesn't look right:
>>>>>
>>>>> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0
>>>>> ada0: <SAMSUNG SP2504C VT100-50> ATA-7 SATA 2.x device
>>>>> ada0: 300.000MB/s transferscd0 at ata2 bus 0 scbus2 target 0 lun 0
>>>>> cd0: <HL-DT-ST DVDRAM GSA-H10N JL12> Removable CD-ROM SCSI-0  
>>>>> device
>>>>> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
>>>>> cd0: cd present [1944656 x 2048 byte records]
>>>>> (SATA 2.x, UDMA6, PIO 8192bytes)
>>>>> ada0: Command Queueing enabled
>>>>> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C)
>>>>>
>>>>>
>>>>> my kernel contains:
>>>>>
>>>>> options         SC_HISTORY_SIZE=1000
>>>>> options         MSGBUF_SIZE=65536
>>>>> options         PRINTF_BUFR_SIZE=128
>>>>>
>>>>> might this be caused by one of these lines?
>>>>>
>>>>> cheers.
>>>>>
>>>>
>>>> Can you be more specific about what you think is not right?
>>>>
>>>> Scott
>>> I assume he means that 'cd0 at ata2 ...' is on the same line as the
>>> third ada0 line. After all the cd0-lines, the ada0 line continues.
>>> That shouldn't happen with PRINTF_BUFR_SIZE set, should it?
>>
>> It can happen because the print buffer size thing is not line- 
>> buffered, it is
>> printf-invocation buffered.
>
> hmmm...can this somehow be fixed? i'm not sure this is specific to
> scsi/cam. the other day i bootd my system and almost all of the dmesg
> output was displayed incorrectly. would increasing PRINTF_BUFR_SIZE
> from 128 to lets say 512 or 1024 solve the issue


Johns response is off base.  I explained the issue prior to him,  
please review that.

Scott

>>