Date: Fri, 18 Jun 2010 17:11:16 +0200 From: Alexander Best <alexbestms@uni-muenster.de> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Jille Timmermans <jille@quis.cx> Subject: Re: strange scsi/CAM related dmesg output Message-ID: <AANLkTimpYGRKKF-c8YfjaQD38px3F38ktC8gwfun98od@mail.gmail.com> In-Reply-To: <201006070957.07376.jhb@freebsd.org> References: <AANLkTinPhcc8Z_BdvoEQUv-ZXlHAYOTQJwlUQDVO8iJ9@mail.gmail.com> <6BEF4925-A058-4EFA-B005-30A01B3132FC@samsco.org> <4C0A9D57.8000900@quis.cx> <201006070957.07376.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin <jhb@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 =A0 =A0 =A0 =A0 SC_HISTORY_SIZE=3D1000 >> >> options =A0 =A0 =A0 =A0 MSGBUF_SIZE=3D65536 >> >> options =A0 =A0 =A0 =A0 PRINTF_BUFR_SIZE=3D128 >> >> >> >> 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, i= t 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 > --=20 Alexander Best
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimpYGRKKF-c8YfjaQD38px3F38ktC8gwfun98od>