[Bug 192238] New: rtld-elf should use powerof2(); nmaskwords must not be zero

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192238 Bug ID: 192238 Summary: rtld-elf should use powerof2(); nmaskwords must not be zero Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any

[Bug 192239] New: NOTE_TRUNCATE not supported

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192239 Bug ID: 192239 Summary: NOTE_TRUNCATE not supported Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity:

[Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after hotswapping

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348 --- Comment #3 from MichaƂ Margula --- Unfortunately same issue is in FreeBSD 9.3-RELEASE: # uname -a FreeBSD 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r260512: Thu Jul 10 23:44:39 UTC 2004 r...@snap.freebsd.org:/usr/obj/usr/srcv/sys/GENERI

[Bug 192246] New: [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192246 Bug ID: 192246 Summary: [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4)) Product: Base System Version: 11.0-CURRENT

[Bug 192247] New: [cam][cd] READ_CD_CAPACITY could be reaped from scsi_cd.h

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192247 Bug ID: 192247 Summary: [cam][cd] READ_CD_CAPACITY could be reaped from scsi_cd.h Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any

[Bug 192248] New: [vt] panic in vtbuf_fill_locked from vt_upgrade with no vt(4) drivers attached

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192248 Bug ID: 192248 Summary: [vt] panic in vtbuf_fill_locked from vt_upgrade with no vt(4) drivers attached Product: Base System Version: 11.0-CURRENT Hardware: Any

[Bug 192249] New: [PATCH] Load reloc modules (amd64, mips) faster by caching global syms

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192249 Bug ID: 192249 Summary: [PATCH] Load reloc modules (amd64, mips) faster by caching global syms Product: Base System Version: 11.0-CURRENT Hardware: Any

[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192246 --- Comment #1 from Alexander Motin --- That looks quite odd to me. I don't remember I've seen such messages when tested it last time. And the message "Raw sense" I can't even find in sources. Am I looking wrong? Is it clean FreeBSD? -- Y

[Bug 192252] New: Various ELF parsers and support code should be unified

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192252 Bug ID: 192252 Summary: Various ELF parsers and support code should be unified Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs

[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192246 --- Comment #2 from yaneurab...@gmail.com --- (In reply to Alexander Motin from comment #1) > That looks quite odd to me. I don't remember I've seen such messages when > tested it last time. And the message "Raw sense" I can't even find in >

[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192246 yaneurab...@gmail.com changed: What|Removed |Added Status|Needs Triage|Issue Resolved Reso

[Bug 192253] New: [INCOMPLETE] [PATCH] Add GNU hash support to kernel link_elf, kldxref

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192253 Bug ID: 192253 Summary: [INCOMPLETE] [PATCH] Add GNU hash support to kernel link_elf, kldxref Product: Base System Version: 11.0-CURRENT Hardware: Any

[Bug 192257] New: modevent_nop always returns EBUSY on MOD_UNLOAD; blocks user from being able to unload modules with evhand = NULL

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192257 Bug ID: 192257 Summary: modevent_nop always returns EBUSY on MOD_UNLOAD; blocks user from being able to unload modules with evhand = NULL Product: Base System

[Bug 192231] Fixing typo in sys/sys/procdesc.h

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192231 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Wed Jul 30 00:28:30 UTC 2014 New revision: 269282 URL: http://svnweb.freebsd.org/changeset/base/269282 Log: Correct typo in comment PR:

[Bug 192231] Fixing typo in sys/sys/procdesc.h

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192231 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Assignee|f

[Bug 192262] New: the -S flag of newfs do not take effective,sector size always set to 512

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192262 Bug ID: 192262 Summary: the -S flag of newfs do not take effective,sector size always set to 512 Product: Base System Version: 10.0-RELEASE Hardware: amd64

[Bug 192262] the -S flag of newfs do not take effective,sector size always set to 512

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192262 Xin LI changed: What|Removed |Added CC||delp...@freebsd.org --- Comment #1 from X

[Bug 192262] the -S flag of newfs do not take effective,sector size always set to 512

2014-07-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192262 --- Comment #2 from Jov --- I see.Thank you Xin. May be this message should be added to the newfs man page? (In reply to Xin LI from comment #1) > This doesn't really matter. By default, the minimal allocation unit > ('fragment size') on