Re: strange scsi/CAM related dmesg output

On Friday 18 June 2010 10:18:54 pm Scott Long wrote:
> 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.

Huh?  My point is that the buffer size is not line buffered, but the entire 
buffer is always output before printf() returns.  Thus, if you do:

printf("foo");
printf(" bar\n");

Then another CPU or thread can send output in between the "foo" and " bar\n".
What people want, aesthetically, is to have per-thread line-buffered output,
so each thread would accumulate chars up to a limit or '\n' across multiple 
calls to printf() and output all of that at once.

On the other hand, if something else should be serializing these printfs then 
they shouldn't interleave even w/o PRINTF_BUFR_SIZE, so I don't see how 
PRINTF_BUFR_SIZE would fix it.

-- 
John Baldwin