[Bug 192238] New: rtld-elf should use powerof2(); nmaskwords must not be zero
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 Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: conrad.me...@isilon.com >From DT_GNU_HASH parsing: == /* Number of bitmask words is required to be power of 2 */ nmw_power2 = ((nmaskwords & (nmaskwords - 1)) == 0); obj->maskwords_bm_gnu = nmaskwords - 1; ... obj->valid_hash_gnu = nmw_power2 && obj->nbuckets_gnu > 0 && obj->buckets_gnu != NULL; == The nmw_power2 statement can be rewritten using the powerof2() macro from sys/param.h: nmw_power2 = powerof2(nmaskwords); And valid_hash_gnu should probably include '&& nmaskwords > 0' (see underflow in obj->maskwords_bm_gnu if nmaskwords is less than 1). I may eventually get around to attaching a patch, but this isn't a priority for us (just something that came up reviewing a similar change to the kernel linker, which will end up on bugzilla sometime soon). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192239] New: NOTE_TRUNCATE not supported
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: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ericsh...@eradman.com Created attachment 145120 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145120&action=edit a minimal program for printing VNODE events on BSD On OpenBSD /usr/include/sys/event.h defines a filer for watching responding file truncation: #define·NOTE_TRUNCATE 0x0080 /* vnode was truncated */ On FreeBSD this is not defined, and does not appear to be covered by any other filers $ echo "test" > file.txt # NOTE_WRITE $ : > file.txt # NOTE_TRUNCATE I'm filing this bug on behalf of the entr utility (http://entrproject.org) since this leaves an edge case where a file is altered without triggering an action. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after hotswapping
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/GENERIC amd64 # dmesg | grep mps mps0: port 0xe000-0xe0ff mem 0xfba4-0xfba4,0xfba0-0xfba3 irq 34 at device 0.0 on pci3 mps0: Firmware: 19.00.00.00, Driver: 16:00.00.00-fbsd mps0: IOCCapabilities: 5285c Unafected 9.2-RELEASE: # uname -a FreeBSD boromir.uznam.net.pl 9.2-RELEASE-p10 FreeBSD 9.2-RELEASE-p10 #0: Tue Jul 8 10:48:24 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # dmesg | grep mps mps0: port 0xe000-0xe0ff mem 0xfba4-0xfba4,0xfba0-0xfba3 irq 34 at device 0.0 on pci3 mps0: Firmware: 19.00.00.00, Driver: 14.00.00.01-fbsd mps0: IOCCapabilities: 5285c So only difference I see is that 14.00.00.01-fbsd is fine and 16:00.00.00-fbsd is broken. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192246] New: [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))
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 Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: yaneurab...@gmail.com I've seen "Medium not present - tray closed" types of messages frequently at boot post-9.x dealing with cd(4). These messages are valuable for debugging real errors dealing with ses(4), etc, but they're noisy with cd(4) when there isn't media present in the drive tray (for instance). This is a low-ish/medium-ish priority bug as improving this would "polish" kernel boot printouts. (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error Timecounter "TSC" frequency 1995237816 Hz quality 1000 (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 uhub1: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error 4 ports with 4 removable, self powered (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error WARNING: WITNESS option enabled, expect reduced performance. (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unretryable error (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error (cd0:ahcich1:0:0:0): SCSI status: Check Condition (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) (cd0:ahcich1:0:0:0): Raw sense 0-17: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00 00 00 (cd0:ahcich1:0:0:0): Error 6, Unr
[Bug 192247] New: [cam][cd] READ_CD_CAPACITY could be reaped from scsi_cd.h
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 Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: yaneurab...@gmail.com READ_CAPACITY and READ_CD_CAPACITY have the same value in cam(4). Not sure if this was intentional given the comment in scsi_cd.h, but the value in scsi_cd.h could probably be reaped because it wasn't used in the tree (apart from that header). $ egrep 'READ_.*CAPACITY' /usr/src/sys/cam/scsi/scsi_all.h /usr/src/sys/cam/scsi/scsi_cd.h /usr/src/sys/cam/scsi/scsi_all.h:#defineREAD_CAPACITY 0x25 /usr/src/sys/cam/scsi/scsi_cd.h:#define READ_CD_CAPACITY0x25/* slightly different from disk */ $ grep -r READ_CD_CAPACITY /usr/src/ /usr/src/sys/cam/scsi/scsi_cd.h:#define READ_CD_CAPACITY0x25/* slightly different from disk */ $ -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192248] New: [vt] panic in vtbuf_fill_locked from vt_upgrade with no vt(4) drivers attached
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 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ema...@freebsd.org ** I have no early vt(4) driver: VT: init without driver. ** My WIP vt(4) fb driver fails to attach: terasic_mtl0: Failed to attach fbd device ** Later vt_upgrade gets called and panics: panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 cpuid = 0 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x8c: lui at,0x0 db> bt Tracing pid 0 tid 10 td 0x80729c20 db_trace_thread+40 (?,?,?,?) ra 80117514 sp 987c5ca0 sz 32 80117388+18c (ff,?,,?) ra 801165f0 sp 987c5cc0 sz 64 80116168+488 (?,?,?,?) ra 801168bc sp 987c5d00 sz 224 db_command_loop+f4 (?,?,?,?) ra 8011a2c8 sp 987c5de0 sz 32 8011a120+1a8 (?,?,?,?) ra 802e3e10 sp 987c5e00 sz 832 kdb_trap+1f0 (?,?,?,?) ra 80515bb0 sp 987c6140 sz 64 trap+10d8 (?,?,?,?) ra 804ff34c sp 987c6180 sz 320 MipsKernGenException+168 (0,0,80582490,aa) ra 802e3944 sp 987c62c0 sz 448 kdb_enter+8c (?,?,?,?) ra 80293800 sp 987c6480 sz 32 80293550+2b0 (?,?,?,?) ra 80293930 sp 987c64a0 sz 32 kassert_panic+c8 (?,0,0,107b3ac) ra 80186fd4 sp 987c64c0 sz 128 vtbuf_fill_locked+54 (?,?,?,?) ra 80188ddc sp 987c6540 sz 64 80188dc8+14 (?,?,?,?) ra 802fc28c sp 987c6580 sz 32 terminal_set_winsize_blank+1bc (?,?,?,?) ra 802fc2e0 sp 987c65a0 sz 96 terminal_set_winsize+28 (?,?,?,?) ra 80189654 sp 987c6600 sz 32 vt_upgrade+194 (?,?,?,?) ra 802231dc sp 987c6620 sz 160 mi_startup+20c (?,?,?,?) ra 8010026c sp 987c66c0 sz 32 _start+dc (?,?,?,?) ra 0 sp 987c66e0 sz 0 pid 0 db> presumably vt_upgrade needs to detect the case that only the dummy driver exists, and do nothing -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192249] New: [PATCH] Load reloc modules (amd64, mips) faster by caching global syms
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 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: conrad.me...@isilon.com Created attachment 145126 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145126&action=edit (cd src/ && patch -p1 ; diff is against recent-ish CURRENT) The problem: At Isilon, efs.ko is a very large kernel module; we were seeing kldload take 12-13 seconds. Most of that time was spent repeatedly resolving the same global symbols for relocations. link_elf_obj would lookup the same globals many times; each time, it would lookup in the local module first, before missing and falling back to deps, where it would find 'kernel' and get a fast hit (hash table hit). Since ld(1) doesn't generate lookup hashes (SysV or GNU) for relocatable objects (kmods on AMD64), lookups in the local module involved walking the entire symtab and strcmp()ing. efs.ko has 32k symbols. This was very slow. Solution: Add a special ELF SHN_ value (in the SHN_LOOS to SHN_HIOS range) to represent cached SHN_UNDEF globals. Cache the results of global lookup during relocatable object load. Modify Dtrace to ignore these SHN_FBSD_CACHED symbols the same way it ignored SHN_UNDEF symbols before. I didn't find other users of SHN_UNDEF that might be negatively affected by this change. Testing done: Basic Dtrace testing suggests it isn't broken. Performance results: Before # for i in 1 2 3 ; do time kldload efs.ko ; kldunload efs.ko ; done kldload efs.ko 0.00s user 13.00s system 103% cpu 12.607 total kldload efs.ko 0.00s user 13.25s system 102% cpu 12.876 total kldload efs.ko 0.00s user 13.14s system 103% cpu 12.752 total kldload zfs.ko 0.00s user 1.77s system 102% cpu 1.729 total# Smaller, for comparison After kldload efs.ko 0.00s user 0.25s system 99% cpu 0.252 total kldload efs.ko 0.00s user 0.20s system 99% cpu 0.204 total kldload efs.ko 0.00s user 0.21s system 99% cpu 0.211 total kldload zfs.ko 0.00s user 0.04s system 96% cpu 0.040 total # For comparison Sponsored by:EMC / Isilon storage division -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))
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? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192252] New: Various ELF parsers and support code should be unified
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 Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: conrad.me...@isilon.com I count something like five different ELF implementations in base. sys/kern/link_elf.c and link_elf_obj.c have tons of shareable code; sys/boot has some degree of ELF parsing / interpretation; libexec/rtld-elf has yet another implementation; usr.sbin/kldxref/ef.c is another version. Almost all of these could benefit from fixes and implementations happening in one place (e.g. GNU hash support, which is present in rtld-elf but none of the others). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))
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 > sources. Am I looking wrong? Is it clean FreeBSD? Good question. Some of the extra debug output is coming a custom kernel (sorry... can't share the sources :/), so it might not be 100% valid on vanilla FreeBSD. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192246] [cam] scsi_sense_only_sbuf printfs are noisy at boot in certain scenarios (like dealing with cd(4))
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192246 yaneurab...@gmail.com changed: What|Removed |Added Status|Needs Triage|Issue Resolved Resolution|--- |Unable to Reproduce --- Comment #3 from yaneurab...@gmail.com --- I'll close this bug and see if I can repro this with a vanilla kernel. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192253] New: [INCOMPLETE] [PATCH] Add GNU hash support to kernel link_elf, kldxref
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 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: conrad.me...@isilon.com Created attachment 145127 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=145127&action=edit (patch -p1 in src/ ; applies against recent-ish CURRENT) This incomplete patch ports r234841 (GNU hash for rtld-elf) to the kernel linker and kldxref ELF implementations. To finish the work, someone will have to port support to the bootloader as well (OR, switch '--hash-style=gnu' to '--hash-style=both' and eat the additional hash table bloat). We abandoned this route because it doesn't help very much on AMD64 (relocatable ELF object kmodules do not get any hash table) and we got 99.9% of the gains we wanted with the patch in bug 192249. Also, it is obnoxious how many different ELF implementations exist and most of them lack GNU hash support (bug 192252). Still, maybe this is useful to someone or other (embedded?) architectures where kernel modules are proper shared objects. Sponsored by:EMC / Isilon storage division -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192257] New: modevent_nop always returns EBUSY on MOD_UNLOAD; blocks user from being able to unload modules with evhand = NULL
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
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: yaneurab...@gmail.com
The code in modevent_nop always returns EBUSY when one tries to unload a
module. This doesn't necessarily make sense because it effectively wires the
module into the kernel until it's rebooted, making it difficult for
developers/testers/users to swap out kernel modules as need be:
68 static int
69 modevent_nop(module_t mod, int what, void *arg)
70 {
71
72 switch(what) {
73 case MOD_LOAD:
74 return (0);
75 case MOD_UNLOAD:
76 return (EBUSY);
77 default:
78 return (EOPNOTSUPP);
79 }
80 }
It would make more sense if it returned 0 when MOD_LOAD/MOD_UNLOAD events are
passed through, like it used to before r132167, but this requires additional
discussion.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192231] Fixing typo in sys/sys/procdesc.h
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:192231 Submitted by:Ron Dahlgren MFC after:1 week Changes: head/sys/sys/procdesc.h -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192231] Fixing typo in sys/sys/procdesc.h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192231 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|ema...@freebsd.org Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192262] New: the -S flag of newfs do not take effective,sector size always set to 512
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 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: am...@amutu.com newfs -S 4k -U /dev/da1p2 /dev/da1p2: 544268.7MB (1114662280 sectors) block size 32768, fragment size 4096 using 870 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates newfs -N -U /dev/da1p2 /dev/da1p2: 544268.7MB (1114662280 sectors) block size 32768, fragment size 4096 using 870 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates while the sector size always 512 (544268.7MB / 1114662280 ).But My disk' phys sector size is 4k,I want to set the ufs sector to 4k. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192262] the -S flag of newfs do not take effective,sector size always set to 512
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192262
Xin LI changed:
What|Removed |Added
CC||delp...@freebsd.org
--- Comment #1 from Xin LI ---
This doesn't really matter. By default, the minimal allocation unit ('fragment
size') on FreeBSD UFS is 4K on modern systems (used to be 2K), which means it's
always 4K ready regardless the underlying disk hardware.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 192262] the -S flag of newfs do not take effective,sector size always set to 512
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 FreeBSD UFS is 4K on modern systems (used to be 2K),
> which means it's always 4K ready regardless the underlying disk hardware.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
