On Jun 18, 2010, at 9:11 AM, Alexander Best <alexbes...@uni-
muenster.de> wrote:
On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin <j...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
