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? cheers. > > -- > John Baldwin > -- Alexander BestReceived on Fri Jun 18 2010 - 13:11:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC