kern/172386: Request: syscons(4) support for mouse scroll wheel (a la xterm)
>Number: 172386 >Category: kern >Synopsis: Request: syscons(4) support for mouse scroll wheel (a la xterm) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Oct 06 09:50:03 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Ronald F. Guilmette >Release:FreeBSD 8.3-RELEASE amd64 >Organization: entr0py >Environment: System: FreeBSD 8.3-RELEASE amd64 >Description: The man page for syscons(4) makes clear that the console driver already has the capability to ``scroll'' the text of the currently selected virtual console forward and backwards. It does this via a combination of the ScrollLock key and then the PageUp/PageDown or Up/Down arrow keys. It would be Nice if the console driver could also be induced to perform line-by-line up/down scrolling via the scroll wheel on a wheeled mouse, as in an xterm window under X. >How-To-Repeat: N/A >Fix: Sorry, I do not have patches to propose at this time. I have always depended on the kindness of strangers. >Release-Note: >Audit-Trail: >Unformatted: ___ 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"
misc/172390: __res_state_ext missing from system headers
>Number: 172390
>Category: misc
>Synopsis: __res_state_ext missing from system headers
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Oct 06 11:10:13 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Antonio Querubin
>Release:9.0
>Organization:
>Environment:
FreeBSD vm2 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
>Description:
Programs that use the resolver library but query IPv6 resolvers directly
require access to the IPv6 extensions in resolv.h. However, the definition for
struct __res_state_ext is missing from the standard system header files.
>How-To-Repeat:
The following will fail to compile:
#include
#include
#include
#include
int main(void) {
struct __res_state myres;
struct __res_state_ext *myres6;
struct sockaddr_in6 *mysockaddr6;
res_ninit(&myres);
myres6 = myres._u._ext.ext;
mysockaddr6 = &(myres6->nsaddrs[0].sin6);
}
>Fix:
Include a definition for struct __res_state_ext in resolv.h
struct __res_state_ext {
union res_sockaddr_union nsaddrs[MAXNS];
struct sort_list {
int af;
union {
struct in_addr ina;
struct in6_addr in6a;
} addr, mask;
} sort_list[MAXRESOLVSORT];
char nsuffix[64];
char nsuffix2[64];
};
>Release-Note:
>Audit-Trail:
>Unformatted:
___
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"
Re: kern/171754: Re: ARP ISSUE
Synopsis: Re: ARP ISSUE State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sat Oct 6 19:00:24 UTC 2012 State-Changed-Why: Misfiled followup to kern/171728; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 19:00:24 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=171754 ___ 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"
Re: kern/171769: Re: ARP ISSUE
Synopsis: Re: ARP ISSUE State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sat Oct 6 19:00:24 UTC 2012 State-Changed-Why: Misfiled followup to kern/171728; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 19:00:24 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=171769 ___ 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"
Re: kern/171771: Re: ARP ISSUE
Synopsis: Re: ARP ISSUE State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sat Oct 6 19:00:24 UTC 2012 State-Changed-Why: Misfiled followup to kern/171728; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 19:00:24 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=171771 ___ 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"
Re: misc/172119: Re: misc/171078: X and XFCE (xfsettingsd) errors on shutdown/logout
Old Synopsis: Re: Fwd: misc/171078: X and XFCE (xfsettingsd) errors on New Synopsis: Re: misc/171078: X and XFCE (xfsettingsd) errors on shutdown/logout State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sat Oct 6 19:31:48 UTC 2012 State-Changed-Why: Misfiled followup to misc/171078; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 19:31:48 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=172119 ___ 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"
Re: kern/172386: [syscons] [request] syscons(4) support for mouse scroll wheel (a la xterm)
Old Synopsis: Request: syscons(4) support for mouse scroll wheel (a la xterm) New Synopsis: [syscons] [request] syscons(4) support for mouse scroll wheel (a la xterm) State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Sat Oct 6 19:39:12 UTC 2012 State-Changed-Why: mark suspended awaiting patches. http://www.freebsd.org/cgi/query-pr.cgi?pr=172386 ___ 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"
misc/172413: Boot "loader" should accept additional parameters
>Number: 172413
>Category: misc
>Synopsis: Boot "loader" should accept additional parameters
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Oct 06 21:50:02 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Zbigniew
>Release:9.0
>Organization:
>Environment:
FreeBSD Trurl 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Oct 3 17:39:02 CEST 2012
root@Trurl:/usr/src/sys/i386/compile/GENERIC i386
>Description:
Installed recently FreeBSD 9.0 - and I've got a problem: while booting,
"loader" somehow gets incorrect currdevice value, stopping boot process. It
does get "disk1s6a", but it should be "disk1s7a" ("lsdev" reports such number).
I can boot system, when I set currdev "manually", then type "boot". Of course,
loader won't read its config files, when not having access to root directory.
Having multiple OS-es on HDD, I'm using GRUB for booting. My FreeBSD section
looks like:
root (hd0,5,a)
kernel /boot/loader
No, I can't change "root partition" - the solution would be to allow to pass
the boot parameters to loader, like this:
kernel /boot/loader currdev=disk1s7a
I mean: each variable, that can be later examined by "show", should be
possible to be changed in such GRUBs command-line, by passing sequence of such
parameters, separated by spaces. Such ability is present since years in Linux -
no problem there with passing boot parameters - why not in FreeBSD?
BTW: I would to mention here, that at least two essential utilities - I mean
boot0cfg and dumpon - (but maybe more of them) have "artifically" imposed a
limit to handle at most fourth partition. It's an obvious nonsense, since I've
got by now FreeBSD installed - and working - on "logical partition" 6 created
inside "physical partition" 4. Why the most essential tools are ignoring the
fact, that nowadays we're able to have - say - 20 partitions, not just four?
The man page for dumpon is signed "12 may 1995", which suggests to me, that
this utility has been left untouched since that time. Maybe 17 years ago
keeping the limit "four partitions" was reasonable, but today HDDs of terabyte
capacity aren't anything extraordinary. Time, and the work conditions, have
changed - therefore such changes should be reflected in such basic tools,
needed for proper disk partitioning and setting the boot process.
I would to add, that on the very same partition I had a few days ago NetBSD
installation, which had no problem with the partition number whatsoever. I've
replaced Net- with FreeBSD, and since the very start such strange problems "we
don't like your partitions schema". Almost twenty years later it's still not
possible to install FreeBSD onto chosen partition the straight way, and then to
run the system without additional "adventures". Being very essential thing,
this really needs a fix!
>How-To-Repeat:
Just by booting FreeBSD from some "unusul" partition (the one with "high"
number)
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
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"
9.1-RCs issues
1) moused stops functioning on 9.1-RC2. Neither PS2 nor USB mouse can work. 9.1-RC1 has no such problem. 2) All i386 / amd64 of 9.1-RC1/RC2 have USB read failure -- see dmesg output at end of this email. ada0 is internal SATA drive for system disk -- s# partitions: /, /tmp, /var, /usr s1 -- 6.4-Release s2 -- 8.3-Release s3 -- 9.1-RC2 amd64 s4 -- 9.1-RC2 i386 -- This slice also contains /home da0 is external USB2 drive (300GB) plugged in USB2 port -- mounted on /mnt operations failed by 9.1-RCs -- test directory has 2GB content (failure is not related to data size; a 4.7GB dir at the begining of the USB dirve can be copied forth/back from SATA without problems). cp -pr /mnt/test/* /home cd /mnt; tar -cf - test | (cd /home; tar -xf -) FreeBSD 6.4-R and 8.3-R have no problem at all on any direction of disk I/O. 9.1-RC# read from SATA and write to USB seems OK -- may need a bigger SATA drive to do more intensive check. All 9.1-RC* completely failed for operating "cp -pr" from USB to SATA -- see dmesg output below. tarring the same test directory from USB to SATA will succeed with many da0:umass-sim0 errors, but have much less errors than "cp -pr". Have not checked the content being copied. -Jin Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RC2 #0 r241133: Tue Oct 2 17:11:45 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 CPU: AMD A4-3400 APU with Radeon(tm) HD Graphics (2699.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x300f10 Family = 12 Model = 1 Stepping = 0 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 3398332416 (3240 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20110527/tbfadt-586) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110527/psargs-392) ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110527/nsinit-380) acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xd000-0xdfff,0xfeb0-0xfeb3 irq 18 at device 1.0 on pci0 hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 xhci0: mem 0xfeb4a000-0xfeb4bfff irq 18 at device 16.0 on pci0 xhci0: 32 byte context size. usbus0 on xhci0 xhci1: mem 0xfeb48000-0xfeb49fff irq 17 at device 16.1 on pci0 xhci1: 32 byte context size. usbus1 on xhci1 atapci0: port 0xf190-0xf197,0xf180-0xf183,0xf170-0xf177,0xf160-0xf163,0xf150-0xf15f mem 0xfeb51000-0xfeb517ff irq 19 at device 17.0 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ohci0: mem 0xfeb5-0xfeb50fff irq 18 at device 18.0 on pci0 usbus2 on ohci0 ehci0: mem 0xfeb4f000-0xfeb4f0ff irq 17 at device 18.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ohci1: mem 0xfeb4e000-0xfeb4efff irq 18 at device 19.0 on pci0 usbus4 on ohci1 ehci1: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf100-0xf10f at device 20.1 on pci0 ata0: at channel 0 on atapci1 ata1: at channel 1 on atapci1 hdac1: mem 0xfeb4-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib1: at device 20.4 on pci0 pci1: on pcib1 ohci2: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 20.5 on pci0 usbus6 on ohci2 pcib2: at device 21.0 on pci0 pci2: on pcib2 pcib3: at device 21.1 on pci0 pci3: on pcib3 alc0: port 0xe000-0xe07f mem 0xfea0-0xfea3 irq 17 at device 0.0 on pci3 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on m
