Portable Mono Scooter SegWay
ImporterDeals Air Wheel Bike: http://rdir.importerdeals.com.au/d/d.html?qb5000jris00dlyi000ku7d05 VIOLET Jewellery Set: http://rdir.importerdeals.com.au/d/d.html?qb3i00jris00dlyi000kqw6i5 240 Watt Solar Folding - $290: http://rdir.importerdeals.com.au/d/d.html?qb3q00jris00dlyi000k5mgy5 Safe Wash - $299: http://rdir.importerdeals.com.au/d/d.html?qb3y00jris00dlyi000kwb6q5 un-subscribe: http://rdir.importerdeals.com.au/d/d.html?qb4000jris00klyi000k2egy5 ___ 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 198344] [virtio] virtio-balloon does not work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198344 Bug ID: 198344 Summary: [virtio] virtio-balloon does not work Product: Base System Version: 10.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jan.he...@taujhe.de I am running FreeBSD in a Linux/KVM environment with the -balloon virtio flag passed to qemu. The virtio-balloon kernel module gets loaded: jan@vm03 ~ $ kldstat -v | grep virtio 460 virtio_pci/virtio_scsi 459 virtio_pci/virtio_balloon 458 virtio_pci/virtio_blk 457 virtio_pci/vtnet 456 pci/virtio_pci 455 virtio But there is no ballooning at all. The VM allocates all the memory up to the specified maximum from the host, no matter how much memory is actually in use inside FreeBSD. Expected result would be that the VM only allocates as much memory from the host as it actually uses right now. This works with Linux guests, but not FreeBSD ones. For reference the complete qemu command line: qemu-system-x86_64 -enable-kvm \ -cpu host \ -smp cores=4,threads=2 \-drive file=/var/kvm/disks/vm03.img,if=virtio \-net tap,ifname=tap_br1_3,script=no,downscript=no -net nic,model=virtio,macaddr=0e:77:77:0e:0e:03 \ -m 4G \ -balloon virtio \ -vga std \ -display vnc=:3 \ -monitor stdio \ -name "VM 03" \ -usbdevice tablet \ -k de -- 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 197286] Panic in IPv6 stack - 0xc0d0b1fc is in ip6_input (/usr/src/sys/netinet6/ip6_input.c:702)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197286 --- Comment #5 from Tim Bishop --- (In reply to Andrey V. Elsukov from comment #4) Sorry, I can't at the moment since the machine is now running HEAD, so I'd have to do a complete rebuild including packages. If I do get a chance I'll report back though. -- 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 198347] [patch] continuous batch mode for gstat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198347 Bug ID: 198347 Summary: [patch] continuous batch mode for gstat Product: Base System Version: 10.1-STABLE Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: r...@bytecamp.net Keywords: patch Created attachment 153890 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153890&action=edit Add option -B to gstat This simple patch adds the option -B to gstat, which does like -b but without exiting after the first measurement. -- 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 197766] [patch] GEOM_MAP does not build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197766 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|a...@freebsd.org -- 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 198356] Possible infinite sleep in mmc_wait_for_req()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198356
Bug ID: 198356
Summary: Possible infinite sleep in mmc_wait_for_req()
Product: Base System
Version: 10.1-STABLE
Hardware: arm
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: sout...@gmail.com
This is the current code of sys/dev/mmc/mmc.c.
372 static void
373 mmc_wakeup(struct mmc_request *req)
374 {
375 struct mmc_softc *sc;
376
377 sc = (struct mmc_softc *)req->done_data;
378 MMC_LOCK(sc);
379 req->flags |= MMC_REQ_DONE;
380 MMC_UNLOCK(sc);
381 wakeup(req);
382 }
383
384 static int
385 mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req)
386 {
387
388 req->done = mmc_wakeup;
389 req->done_data = sc;
390 if (mmc_debug > 1) {
391 device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags
%#x",
392 req->cmd->opcode, req->cmd->arg, req->cmd->flags);
393 if (req->cmd->data) {
394 printf(" data %d\n", (int)req->cmd->data->len);
395 } else
396 printf("\n");
397 }
398 MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req);
399 MMC_LOCK(sc);
400 while ((req->flags & MMC_REQ_DONE) == 0)
401 msleep(req, &sc->sc_mtx, 0, "mmcreq", 0);
402 MMC_UNLOCK(sc);
403 if (mmc_debug > 2 || (mmc_debug > 0 && req->cmd->error !=
MMC_ERR_NONE))
404 device_printf(sc->dev, "CMD%d RESULT: %d\n",
405 req->cmd->opcode, req->cmd->error);
406 return (0);
407 }
As I understand :
When the MMC stack sends a command, it goes into mmc_wait_for_req(), that
defines callback mmc_wakeup(). This callback should sets MMC_REQ_DONE flag and
wakeup sleeped thread when request is completed. Request is sent to driver at
line 398, then it locks the mutex, test flag and goes to sleep.
But, in my case, I got an interrupt after flag test (line 400) and before "req"
has been added to the sleepqueue. It results that mmc_wakeup() is called, it
sets flag and try to wakeup, but didn't find "req" in the sleepqueue. In theory
this behaviour is protected by MMC_LOCK, but the two calls (mmc task and
interrupt) has the same thread id, so anyone is being suspended.
To fix this, I suggest setting a timeout in msleep() instead of 0.
I marked it for version 10.1-STABLE, but 11.0-CURRENT has the same code.
--
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 198336] :-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for device
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198336 --- Comment #1 from papow...@astart.com --- I forgot to indicate that I have: /boot/loader.conf: atapicam_load="YES" But when I do kldstat it does not show up in the installed modules list. -- 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"
LAGG + VLAN + CARP Not supported?
root@nfs1:/home/rmasse # uname -a FreeBSD nfs1 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@nfs1:/home/rmasse # ifconfig bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:21:9b:a6:b0:4d nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active bce1: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:21:9b:a6:b0:4d nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active bce2: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:21:9b:a6:b0:4d nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active bce3: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:21:9b:a6:b0:4d nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=63 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 nd6 options=21 lagg0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:21:9b:a6:b0:4d nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: bce3 flags=1c laggport: bce2 flags=1c laggport: bce1 flags=1c laggport: bce0 flags=1c root@nfs1:/home/rmasse # ifconfig lagg0.2 create root@nfs1:/home/rmasse # ifconfig lagg0.2 inet 10.254.0.3/24 vhid 1 pass test ifconfig: SIOCGVH: Protocol not supported I've tried every combination imaginable with the same result. The mailing lists suggest that this should have been patched in v9? Any ideas? ___ 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 197286] Panic in IPv6 stack - 0xc0d0b1fc is in ip6_input (/usr/src/sys/netinet6/ip6_input.c:702)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197286 Andrey V. Elsukov changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|a...@freebsd.org -- 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 195407] relayd crashes kernel after update to 10.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195407 jja...@gmail.com changed: What|Removed |Added CC||m...@freebsd.org --- Comment #2 from jja...@gmail.com --- I can confirm the original posters opinion: "My guess was that some data structure has changed between 10.0 and 10.1 kernels. So a recompile of relayd should fix that. It did. I compiled it from the ports and it worked." a) A fresh installation of FreeBSD-10.1, updated to p6, and pkg install relayd will crash relayd. restarting relayd will cause a kernel panic. b) A fresh installation of FreeBSD-10.1, updated to p6, with relayd compiled from ports does NOT experience either issue. -- 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"
[Prophecy] March 6, 2015 The Romerican Empire - Part I
Christian Media Communique THE RISE AND FALL OF THE ROMERICAN EMPIRE For over two decades, the Christian Media ministry has sought to propagate the supernaturally revealed truth that America is the fourth kingdom described in Daniel 7: “The fourth beast shall be the fourth kingdom upon earth, which shall be diverse from all kingdoms, and shall devour the whole earth, and shall tread it down, and break it in pieces” (Daniel 7:23). Utilizing the consistent pattern of prophetic parallels, long ago the LORD revealed the four kingdoms counting down to the arrival of JESUS CHRIST, which were allegorized in Nebuchadnezzar’s dream of the great statue composed of a golden head, silver arms, brass belly, and iron legs, were not the same kingdoms as those described as the lion, bear, leopard, and diverse fourth beast. Unfortunately, there are heavily vested interests which put forth the idea the head of gold – the first of four kingdoms in Daniel 2, which is clearly identified as Babylon in the text (Daniel 2:38) – is the same as the lion kingdom in Daniel 7, the first of four kingdoms in Daniel 7, which is not identified in the text: “Behold, the four winds of the heaven strove upon the great sea. And four great beasts came up from the sea, diverse one from another. The first was like a lion, and had eagle’s wings: I beheld till the wings thereof were plucked, and it was lifted up from the earth…” (Daniel 7:2-4). Whenever a believer examines these illustrative sequences featuring the two quartets of kingdoms in Daniel 2 (the four part statue dream), and Daniel 7 (the four part beast vision), they universally focus on the components themselves (the gold, silver, brass, and iron – as well as the lion, bear, leopard), and breeze past the setting. Thus, most miss the fact that the first set of four kingdoms – symbolically pictured as the statue -- is plainly constructed on the earth, whereas the beast kingdoms “came up from the sea” (Daniel 7:2). Further, almost everyone fails to see the significance of how it is “the four winds of heaven” which stir up the sea – the setting of the beast kingdoms. Revealingly, the book of Daniel is set in the Babylonian era, the same kingdom in power during the writings of the prophet Ezekiel, whose book was divinely engineered to immediately precede Daniel’s epic work. In the second half of Ezekiel’s prophecy, towards the end of a lengthy narrative describing how the LORD will save the “lost sheep” of the house of Israel (Ezekiel 34:11) by making an “everlasting covenant” with them, through the prophet, God tells Israel that this life will be associated with “the four winds” – precisely the same metaphor used by Daniel. These “four winds” occur at the conclusion of the hugely important prophecy of the “dry bones,” which are clustered together in a deep valley, and the text clearly states these ancient bones represent the whole house of Israel. In this epic prophecy, we learn the LORD promises to re-gather the dry bones, which were scattered during the Babylonian exile, and to subsequently breathe life into them, under the leadership of a messianic figure associated with the house of David: “These bones are the whole house of Israel: behold, they say, Our bones are dried, and our hope is lost…Therefore prophesy and say unto them, Thus saith the Lord God: Behold, O my people, I will open your graves, and cause you to come up out of your graves…Then [the LORD] said unto me, Prophesy unto the wind, prophesy, son of man, and say to the wind, Thus saith the Lord God; Come from the four winds, O breath, and breathe upon these slain, that they may live” (Ezekiel 37:11, 12, 9). Having proven a thousand times over the Word of God is divinely inspired, and subtle shades of detail are embedded throughout, we recognize the Hebrew word for wind is also rendered Spirit – plainly indicating the Spirit of the LORD is that which raised Israel from their collective “graves” – an epic event which occurs when people are born again to new life in the Spirit of the LORD. In fact, the allusion to the spiritually “dead,” who received not Jesus Christ, was applied to the Pharisees, as the LORD described them as graves: “Woe unto you, scribes and Pharisees, hypocrites! For ye are as graves which appear not, and the men that walk over them are not aware of them” (Luke 11:44). Conversely, those who received Jesus have been given new life, as believers were ransomed from the grave: “Therefore we are buried with him by baptism unto death: that like as Christ was raised up from the dead by the glory of the Father, even so we also should walk in newness of life” (Romans 6:4). Further, in recognizing that God promised in the Old Testament prophet Ezekiel’s writing to bring the “four winds of heaven,” and breathe new life into Israel, The Apostle Paul conclusively stated this occurred in his time: “Has God ca
[Bug 198208] FreeBSD 10.1 multiple kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198208 --- Comment #1 from Dan --- I put the GENERIC kernel back, and it paniced in about an hour. FreeBSD name.replaced 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 processor eflags= panic: page fault cpuid = 18 KDB: stack backtrace: #0 0x80963000 at kdb_backtrace+0x60 #1 0x80928125 at panic+0x155 #2 0x80d24f0f at trap_fatal+0x38f #3 0x80d25228 at trap_pfault+0x308 #4 0x80d2488a at trap+0x47a #5 0x80d0a772 at calltrap+0x8 #6 0x809c12fe at vfs_ref+0x3e #7 0x809b8d91 at vop_stdgetwritemount+0x21 #8 0x80e43f07 at VOP_GETWRITEMOUNT_APV+0xa7 #9 0x809d67db at vn_start_write+0x3b #10 0x809d9550 at vn_write+0xb0 #11 0x809d9932 at vn_io_fault_doio+0x22 #12 0x809d750c at vn_io_fault1+0x7c #13 0x809d5a0b at vn_io_fault+0x18b #14 0x8097a437 at dofilewrite+0x87 #15 0x8097a168 at kern_writev+0x68 #16 0x8097a0f3 at sys_write+0x63 #17 0x80d25841 at amd64_syscall+0x351 Uptime: 1h18m16s Dumping 796 out of 16347 MB:..3%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/ipl.ko.symbols...done. Loaded symbols for /boot/kernel/ipl.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/ipfw.ko.symbols...done. Loaded symbols for /boot/kernel/ipfw.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0x80927da2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0x80928164 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0x80d24f0f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:865 #4 0x80d25228 in trap_pfault (frame=0xfe04695c1560, usermode=) at /usr/src/sys/amd64/amd64/trap.c:676 #5 0x80d2488a in trap (frame=0xfe04695c1560) at /usr/src/sys/amd64/amd64/trap.c:440 #6 0x80d0a772 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x809149e1 in __mtx_lock_sleep (c=0xf80012c2c348, tid=18446735277931354400, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:433 #8 0x809c12fe in vfs_ref (mp=0xf80012c2c330) at /usr/src/sys/kern/vfs_mount.c:433 #9 0x809b8d91 in vop_stdgetwritemount (ap=0xfe04695c1728) at /usr/src/sys/kern/vfs_default.c:591 #10 0x80e43f07 in VOP_GETWRITEMOUNT_APV (vop=, a=) at vnode_if.c:2341 #11 0x809d67db in vn_start_write (vp=0xf802bb5af1d8, mpp=0xfe04695c1788, flags=257) at vnode_if.h:963 #12 0x809d9550 in vn_write (fp=0xf801b3fe4230, uio=0xfe04695c1ab0, active_cred=0xf800128ce700, flags=0, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:854 #13 0x809d9932 in vn_io_fault_doio (args=, uio=0xf80012c3d920, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:986 #14 0x809d750c in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1042 #15 0x809d5a0b in vn_io_fault (fp=0xf801b3fe4230, uio=0xfe04695c1ab0, active_cred=, flags=0, td=0xf80012c3d920) at /usr/src/sys/kern/vfs_vnops.c:1147 #16 0x8097a437 in dofilewrite (td=0xf80012c3d920, fd=31, fp=0xf801b3fe4230, auio=0xfe04695c1ab0, offset=, flags=0) at file.h:304 #17 0x8097a168 in kern_writev (td=0xf80012c3d920, fd=31, auio=0xfe04695c1ab0) at /usr/src/sys/kern/sys_generic.c:467 #18 0x8097a0f3 in sys_write (td=, uap=) at /usr/src/sys/kern/sys_generic.c:382 #19 0x80d25841 in amd64_syscall (td=0xf80012c3d920, traced=0) at subr_syscall.c:134 #20 0x80d0aa5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #21 0x000800fa3bda in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal -- 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"
LED Cree Light Bar
[1]campsalesau [led4.jpg] 4x3W LED Light Bar generator Only $19.00 Was $199.00 Buy Now LED light bars use 3w USA Chip leds, hard wired with 1 Meter of 6mm 2 core wire, strong alloy diecast body with lens made from strong polycarbonate... [2][read more] [3]www.campsalesaustralia.com | Australia This email was sent by CampSalesAU, Sydney NSW Australia to freebsd-bugs@freebsd.org [4]Unsubscribe References Visible links 1. http://www.vision6.com.au/ch/44773/f6mpq/1895903/7467atf5z.html 2. http://www.vision6.com.au/ch/44773/f6mpq/1895904/7467a94xg-1.html 3. http://www.vision6.com.au/ch/44773/f6mpq/1895903/7467atf5z-1.html 4. http://www.vision6.com.au/forms/u/3b72228/44773/12332576.html Hidden links: 6. http://www.vision6.com.au/ch/44773/f6mpq/1895904/7467a94xg.html ___ 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 198377] libc: Invalid size check in load_msgcat()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198377
Bug ID: 198377
Summary: libc: Invalid size check in load_msgcat()
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: misc
Assignee: freebsd-bugs@FreeBSD.org
Reporter: p...@freebsd.org
Created attachment 153941
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153941&action=edit
Fix
According to coverity 1193663, the following check always yields a false
result:
405if (st.st_size > SIZE_T_MAX) {
406_close(fd);
407SAVEFAIL(name, lang, EFBIG);
408NLRETERR(EFBIG);
409}
_
result_independent_of_operands: st.st_size > 18446744073709551615ULL is always
false regardless of the values of its operands. This occurs as the logical
operand of if.
We can workaround this by excluding also SIZE_T_MAX but we should also exclude
negative values since that would indicate an overflow.
--
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 198377] libc: Invalid size check in load_msgcat()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198377 Pedro F. Giffuni changed: What|Removed |Added CC||ga...@freebsd.org --- Comment #1 from Pedro F. Giffuni --- Add Gabor since he is the author of the code. -- 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 198377] libc: Invalid size check in load_msgcat()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198377 --- Comment #2 from Pedro F. Giffuni --- Forgot to mention the code in question is in lib/libc/nls/msgcat.c -- 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 198380] Can't install using MBR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198380 Bug ID: 198380 Summary: Can't install using MBR Product: Base System Version: 10.1-RELEASE Hardware: i386 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: blake1...@gmail.com I am trying to install FreeBSD 10.1 Release on a 10 year old 32 bit machine with 400GB disk and 3+ GB memory. It ran Linux for years without a problem. I installed using the GUI install program. I accepted all of the defaults. Everything installed fine but then the system wouldn't boot. I presume that is because I should use MBR instead of GPT. Here is where all the problems start. When you change to MBR you have to manually configure the partitions (slices). Fine. I create the BSD MBR just fine. I created: ada0 MBR Then I created: ada0s1 BSD but when I go into ada0s1, it will only accept freebsd-ufs. I can't create freebsd-boot or freebsd-swap. It keeps telling me "invalid argument". I have spent hours trying to boot a basic machine with no luck. Sure appreciate some help. Blake McBride -- 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"
