cvsup.uk.freebsd.org appears to not be serving
Hi list, hopefully this is the right one and not -questions cvsup.uk.freebsd.org appears to have not been serving these last few weeks. I get, variously, in my logs: Parsing supfile /etc/cvsupfile Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Rejected by server: Access limit exceeded; try again later Will retry at 03:08:08 Retrying Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing passive-mode data connection Cannot connect to data port: Connection refused Will retry at 03:18:04 Retrying Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing passive-mode data connection Cannot connect to data port: Connection refused Will retry at 03:37:33 Retrying ... on and on and on, continuously, 24/7. Because the update is called in a daily script by cron, potentially I get many instances of cvsup each time cron calls it and this happens - additionally the mailed output never arrives until the script successfully completes. So the first I knew of this was when I wasn't getting my mails for the daily run, but anyway... I'm now using cvsup4.uk.freebsd.org, which seems to work fine. Should cvsup.uk.freebsd.org be taken out of the list of cvsup servers? cheers -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cvsup.uk.freebsd.org appears to not be serving
On Mon, 04 May 2009, 09:26 +0100, John wrote: Hi list, hopefully this is the right one and not -questions Perhaps -hubs would have been a better choice? cvsup.uk.freebsd.org appears to have not been serving these last few weeks. I get, variously, in my logs: Parsing supfile /etc/cvsupfile Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Rejected by server: Access limit exceeded; try again later Will retry at 03:08:08 Retrying You are obviously connecting OK; it's just that the server is already as busy as it's minder is willing to let it be. Perhaps you'd be better off choosing something other than 03:00 as a starting point? Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing passive-mode data connection Cannot connect to data port: Connection refused Will retry at 03:18:04 Retrying Don't do that! Use multiplexed mode -P m (from the cvsup man page, All but multiplexed mode are deprecated); or use csup which does multiplexed mode by default. On Saturday morning I updated two servers in London from from RELENG_7_1 to RELENG_7_2 using cvsup.uk. I checked again just now and it's still happy. -- Running /usr/bin/csup -- Parsing supfile /usr/local/etc/cvsup/src-supfile Connecting to cvsup.uk.FreeBSD.org Connected to 131.111.8.41 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully -- John Marshall pgpJzO15l89Ha.pgp Description: PGP signature
Re: Help! regarding libpcap.
Hi Burce, At first, I'm sorry replay late. I've test build libpcap without ports and using same tar ball. The error message still output. SLT2# make gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:43: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here *** Error code 1 Stop in /usr/ports/distfiles/libpcap-1.0.0. SLT2# Thank you! -Leo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bluetooth troubleshooting
On Sat, 2 May 2009, Dominic Fandrey wrote: # hccontrol -n ubt0hci inquiry Inquiry complete. Status: No error [00] is pretty lame compared to what should appear according to the handbook: % hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] Depends what's in range. Your command indicates to me that there are no _discoverable_ BT modules in range. (Note the discoverable part :) BTW the '-n ubt0hci' is optional if you only have one BT controller. If it isn't discoverable you can do something like.. sdpcontrol -a pda browse (I entered pda into /etc/bluetooth/hosts). If it doesn't show anything (like my phone) you need to bruteforce search for services (I don't understand the rationale of that but that's the way it is), eg.. sh -c 'for i in \ CIP CTP DUN FAX FTRN GN HID HSET LAN NAP OPUSH SP; do \ sdpcontrol -a pda search $i; done' There's a command in Bluez which does this for you but the above would tell you a reasonable amount. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
RE: FreeBSD supported branches update
Hello, owner-freebsd-security-notificati...@freebsd.org wrote on : The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 7.0. The new list is below and at URL: http://security.freebsd.org/ . Please note that FreeBSD 7.0 was originally announced with an EoL date of February 28, 2009, but the EoL was delayed by two months in order to allow a 3 month window for systems to be upgraded to FreeBSD 7.1. I have severe problems with this, because NFS-Locking is not working on FreeBSD-7.1 and later with HP-UX clients. See several PRs which are talking about this. Same is true für FreeBSD-6.4. So all Releases with kernel-supported NFS-Locking have problems with HP-UX clients. FreeBSD-7.0 is the last release that is working and that is therefor still productive at our site. What do you recommend? with best regards Matthias Schündehütte SIEMENS AG, Industry Sector, DT LD S IT Tel. +49-30-386 29957 -- Plain text mail please HTML is considered as SPAM ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Leo wrote: Hi Burce, At first, I'm sorry replay late. I've test build libpcap without ports and using same tar ball. The error message still output. SLT2# make gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:43: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here *** Error code 1 Hi, I can't think what might be causing this for you... Do you have other pcap libraries installed on the system? Perhaps a define is incorrect. Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that should rule out changes in HEAD. Do you have BPF headers present on the system? Have you checked the output of config.log? Do you have a bpf device in your kernel? -- I think that might be it. The fix might be to specify --with-pcap=bpf in CONFIGURE_ARGS in the port. I just built the port on an i386 system tracking RELENG_7 sources, and couldn't reproduce this problem, although I have bpf in kernel there. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Bruce Simpson wrote: Leo wrote: Hi Burce, At first, I'm sorry replay late. I've test build libpcap without ports and using same tar ball. The error message still output. SLT2# make gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:43: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here *** Error code 1 Hi, I can't think what might be causing this for you... Do you have other pcap libraries installed on the system? Perhaps a define is incorrect. Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that should rule out changes in HEAD. Do you have BPF headers present on the system? Have you checked the output of config.log? Do you have a bpf device in your kernel? -- I think that might be it. The fix might be to specify --with-pcap=bpf in CONFIGURE_ARGS in the port. I just built the port on an i386 system tracking RELENG_7 sources, and couldn't reproduce this problem, although I have bpf in kernel there. thanks, BMS Hi Bruce, I don't have other pcap lib installed on this box. Previously installed a libpcap 0.9 on this box , But I've deleted this version. On my box, not enable BPF. Let me try if enable the feature. -Leo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bluetooth troubleshooting
Daniel O'Connor wrote: On Sat, 2 May 2009, Dominic Fandrey wrote: # hccontrol -n ubt0hci inquiry Inquiry complete. Status: No error [00] is pretty lame compared to what should appear according to the handbook: % hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] Depends what's in range. Your command indicates to me that there are no _discoverable_ BT modules in range. (Note the discoverable part :) Not all devices need be INQUIRE-able. Some may not have INQUIRE scan enabled. In that case you need to know the Bluetooth address of the device you're looking for so you can PAGE it. If you're expecting to see a mobile phone or other handheld device you might need to enable discoverability on the device itself. There are also other IAC codes used for INQUIRY, but generally these aren't used. cheers, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Leo wrote: I don't have other pcap lib installed on this box. Previously installed a libpcap 0.9 on this box , But I've deleted this version. On my box, not enable BPF. Let me try if enable the feature. That's probably what it is. Can you try the following: * give pcap configure --with-pcap=bpf WITHOUT having bpf in your kernel config. * try enabling bpf in kernel config and building the port as usual. Most likely libpcap's new configure script is detecting the lack of /dev/bpf* and assuming there is no packet capture support in the system. This needs to be fixed for cross compiling to be possible. If you could try at least the first fix then this is the answer. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 7.2-RELEASE Available
Just a quick note for those of you not subscribed to freebsd-annou...@. We finished up 7.2-RELEASE over the weekend. The announcement message is available here: http://www.freebsd.org/releases/7.2R/announce.html Thanks for all the help with testing during the release cycle. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Radeon 9250 DRM in 7.2-RELEASE
I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: ATI Radeon RV280 9250 on vgapci2 vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 13:41 -0400, Steve Polyack wrote: I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: ATI Radeon RV280 9250 on vgapci2 Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
Paul Schmehl wrote: Read /usr/portsUPDATING wrt xorg. There were major changes in the config file and peripheral detection between 7.1 and 7.2 You need to make sure that both dbus and hald are running. Remove the mouse and keyboard sections from your xorg.conf file. They are no longer needed. Make sure to remove any line that references RgbPath. This may help to get the mouse working (ignore the DontZap line): Section ServerFlags Option DontZap No Option AllowEmptyInput No EndSection This should get DRI working: Section DRI Group 0 Mode 0660 EndSection I tackled the above when I upgraded Xorg to 7.4 months ago, independently of any FreeBSD release updates. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
--On Monday, May 04, 2009 12:41:16 -0500 Steve Polyack kor...@comcast.net wrote: I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: ATI Radeon RV280 9250 on vgapci2 vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. Read /usr/portsUPDATING wrt xorg. There were major changes in the config file and peripheral detection between 7.1 and 7.2 You need to make sure that both dbus and hald are running. Remove the mouse and keyboard sections from your xorg.conf file. They are no longer needed. Make sure to remove any line that references RgbPath. This may help to get the mouse working (ignore the DontZap line): Section ServerFlags Option DontZap No Option AllowEmptyInput No EndSection This should get DRI working: Section DRI Group 0 Mode 0660 EndSection -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Thanks, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: Robert Noland wrote: Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Can you send me a pciconf -lvb robert. Thanks, ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: #0 sched_switch (td=0xc579b230, newtd=Variable newtd is not available.
On Saturday 02 May 2009 2:11:59 pm dikshie wrote: is this known bug? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8c000180 fault code = supervisor read, page not present instruction pointer = 0x20:0xc063d904 stack pointer = 0x28:0xe7704608 frame pointer = 0x28:0xe7704620 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2013 (firefox-bin) trap number = 12 panic: page fault cpuid = 0 Uptime: 5h1m34s Physical memory: 2038 MB Dumping 194 MB: 179 163 147 131 115 99 83 (CTRL-C to abort) 67 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 51 (CTRL-C to abort) 35 19 3 kgdb: kvm_read: invalid address (0x4c414e52) kgdb: kvm_read: invalid address (0x35b2e804) kgdb: kvm_read: invalid address (0x5502) kgdb: kvm_read: invalid address (0x6a02) Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 sched_switch (td=0xc579b230, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944cpuid = PCPU_GET(cpuid); (kgdb) Please get a backtrace using 'bt'. Also, 'l *0xc063d904' may also be useful. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Can you send me a pciconf -lvb robert. $ pciconf -lvb hos...@pci0:0:0:0:class=0x06 card=0x01ad1028 chip=0x27708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host Bridge/DRAM Controller' class = bridge subclass = HOST-PCI pc...@pci0:0:1:0:class=0x060400 card=0x8086 chip=0x27718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host to PCI Express Bridge' class = bridge subclass = PCI-PCI vgap...@pci0:0:2:0:class=0x038000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb0, size 524288, enabled bar [14] = type I/O Port, range 32, base 0xe898, size 8, enabled bar [18] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [1c] = type Memory, range 32, base 0xfeac, size 262144, enabled vgap...@pci0:0:2:1:class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb8, size 524288, enabled pc...@pci0:0:28:0:class=0x060400 card=0x chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pc...@pci0:0:28:1:class=0x060400 card=0x chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uh...@pci0:0:29:0:class=0x0c0300 card=0x01ad1028 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff80, size 32, enabled uh...@pci0:0:29:1:class=0x0c0300 card=0x01ad1028 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff60, size 32, enabled uh...@pci0:0:29:2:class=0x0c0300 card=0x01ad1028 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff40, size 32, enabled uh...@pci0:0:29:3:class=0x0c0300 card=0x01ad1028 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff20, size 32, enabled eh...@pci0:0:29:7:class=0x0c0320 card=0x01ad1028 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xffa80800, size 1024, enabled pc...@pci0:0:30:0:class=0x060401 card=0x chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI p...@pci0:0:30:2:class=0x040100 card=0x01ad1028 chip=0x27de8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub AC'97 Audio' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xec00, size 256, enabled bar [14] = type I/O Port, range 32, base 0xe8c0, size 64, enabled bar [18] = type Memory, range 32, base 0xfeabfa00, size 512, enabled bar [1c] = type Memory, range 32, base 0xfeabf900, size 256, enabled is...@pci0:0:31:0:class=0x060100 card=0x chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 15:56 -0400, Steve Polyack wrote: vgap...@pci0:0:2:0:class=0x038000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb0, size 524288, enabled bar [14] = type I/O Port, range 32, base 0xe898, size 8, enabled bar [18] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [1c] = type Memory, range 32, base 0xfeac, size 262144, enabled vgap...@pci0:0:2:1:class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb8, size 524288, enabled Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. -- Robert Noland rnol...@freebsd.org FreeBSD Index: radeon_cp.c === --- radeon_cp.c (revision 191793) +++ radeon_cp.c (working copy) @@ -1429,7 +1429,7 @@ dev_priv-gart_info.mapping.size = dev_priv-gart_info.table_size; - drm_core_ioremap_wc(dev_priv-gart_info.mapping, dev); + drm_core_ioremap(dev_priv-gart_info.mapping, dev); dev_priv-gart_info.addr = dev_priv-gart_info.mapping.handle; signature.asc Description: This is a digitally signed message part
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. Unfortunately, this didn't help. I should also clarify what I'm seeing, as it's not complete garbage as I thought. I have a dual monitor setup, side-by-side using xrandr. When I start X (xfce4) with drm available, the left monitor (primary) is a sold light shade of blue, except for a black corner which is maybe 10pix square. The right monitor displays my typical background image with another black box over part of it. If it shift back to the console and then back into X, I can see the outlines of my startup windows, but they contain garbage and the outlines are fuzzed with green and magenta garbage. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 16:36 -0400, Steve Polyack wrote: Robert Noland wrote: Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. Unfortunately, this didn't help. I should also clarify what I'm seeing, as it's not complete garbage as I thought. I have a dual monitor setup, side-by-side using xrandr. When I start X (xfce4) with drm available, the left monitor (primary) is a sold light shade of blue, except for a black corner which is maybe 10pix square. The right monitor displays my typical background image with another black box over part of it. If it shift back to the console and then back into X, I can see the outlines of my startup windows, but they contain garbage and the outlines are fuzzed with green and magenta garbage. ok, how about this one... If this doesn't do it, then we need to start digging... robert. -- Robert Noland rnol...@freebsd.org FreeBSD Index: ati_pcigart.c === --- ati_pcigart.c (revision 191793) +++ ati_pcigart.c (working copy) @@ -83,7 +83,7 @@ } flags = BUS_DMA_WAITOK | BUS_DMA_ZERO; - if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) +// if (gart_info-gart_reg_if == DRM_ATI_GART_IGP) flags |= BUS_DMA_NOCACHE; ret = bus_dmamem_alloc(dmah-tag, dmah-vaddr, flags, dmah-map); signature.asc Description: This is a digitally signed message part
RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
Ok, this is strange. I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as of today, using csup and building world. As part of that process I did (as I always do) 'mergemaster -iU' after the 'make installworld' step. A few files on my machines are modified by me, and thus should nevber be upgraded: /etc/dhclient.conf /etc/motd (mergemeaster will usually ask about this - this time it did not, it claimed it wasn't user modified, huh?) /etc/profile /root/.profile /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) /etc/group (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) It can be more files, I haven't found out yet. Has anyone else seen this? I am upgrading my next machine, this time I'll have backups and keep better notes. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ext2fs inode size fix never MFC'd
I just noticed that the changes to the ext2 code to support inode sizes other than 128 was never MFC'd: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/fs/ext2fs/ext2_linux_ialloc.c?r1=1.25.8.1;sortby=date#diff I submitted a patch to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=124621cat= Which was partially adopted (or at least the same idea was used) and committed to HEAD back in January, but the MFC after 2 weeks to RELENG_7 never happened, unfortunately. I was hoping this would make it into 7.1, and I seem to have noticed this too late for 7.2-RELEASE but can someone get this merged into RELENG_7? Regards, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
Torfinn Ingolfsen wrote: Ok, this is strange. I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as of today, using csup and building world. As part of that process I did (as I always do) 'mergemaster -iU' after the 'make installworld' step. A few files on my machines are modified by me, and thus should nevber be upgraded: /etc/dhclient.conf /etc/motd (mergemeaster will usually ask about this - this time it did not, it claimed it wasn't user modified, huh?) /etc/profile /root/.profile /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) /etc/group (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) It can be more files, I haven't found out yet. Has anyone else seen this? I am upgrading my next machine, this time I'll have backups and keep better notes. I always use -iU too. I've lost motd, passwd, group and master.passwd During mergemaster -p I was asked to merge changes to some of these, and still they were replaced with the newer versions. I don't know what went wrong but have restored them from backup. (I always tar /etc before a source upgrade). Upgrading another system using freebsd-update did not cause any problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
On 4/5/09 21:50, Torfinn Ingolfsen wrote: Ok, this is strange. I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as of today, using csup and building world. As part of that process I did (as I always do) 'mergemaster -iU' after the 'make installworld' step. A few files on my machines are modified by me, and thus should nevber be upgraded: /etc/dhclient.conf /etc/motd (mergemeaster will usually ask about this - this time it did not, it claimed it wasn't user modified, huh?) /etc/profile /root/.profile /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) /etc/group (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) It can be more files, I haven't found out yet. Has anyone else seen this? I am upgrading my next machine, this time I'll have backups and keep better notes. Not that its a cure but are master.passwd and group backups in /var/backups any help to you in this case? Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
Robert Noland wrote: ok, how about this one... If this doesn't do it, then we need to start digging... robert. No change when using this patch either. I've also updated to the latest BIOS and have ensured that the onboard Intel adapter is as disabled as it can get. I can provide you some photos of the screen behavior if you think it may help. Thanks again so far! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Radeon 9250 DRM in 7.2-RELEASE
On Mon, 2009-05-04 at 17:41 -0400, Steve Polyack wrote: Robert Noland wrote: ok, how about this one... If this doesn't do it, then we need to start digging... robert. No change when using this patch either. I've also updated to the latest BIOS and have ensured that the onboard Intel adapter is as disabled as it can get. I can provide you some photos of the screen behavior if you think it may help. Thanks again so far! Ok, so to start with, we need an xorg log and conf. If you kldload radeon.ko before starting X then you can set hw.dri.0.debug=1 which will dump a bunch of drm debugging into /var/log/messages. That would be useful. Also having a look at memcontrol list might be a good idea. robert. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
On Mon, 04 May 2009 22:26:52 +0100 Vincent Hoffman vi...@unsane.co.uk wrote: Not that its a cure but are master.passwd and group backups in /var/backups any help to you in this case? Ah - great tip - thanks! (In case of the first server, the changes to group and passwd files were few, so I just re-did the changes from memory. The only part I had to look up was user and group mysql. So restoring from /var/backups would have been quicker.) -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Help! regarding libpcap.
Bruce Simpson wrote: Leo wrote: I don't have other pcap lib installed on this box. Previously installed a libpcap 0.9 on this box , But I've deleted this version. On my box, not enable BPF. Let me try if enable the feature. That's probably what it is. Can you try the following: * give pcap configure --with-pcap=bpf WITHOUT having bpf in your kernel config. * try enabling bpf in kernel config and building the port as usual. Most likely libpcap's new configure script is detecting the lack of /dev/bpf* and assuming there is no packet capture support in the system. This needs to be fixed for cross compiling to be possible. If you could try at least the first fix then this is the answer. thanks, BMS Hi Bruce, I've tried 2 method on my box. that you previously mentioned. Both of these 2 method can build successfully! Thank your for your help!! Best Regards! -Leo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lock up in 6.2 (procs massively stuck in Giant)
2009/5/1 John Baldwin j...@freebsd.org:
On Thursday 30 April 2009 2:36:34 am pluknet wrote:
Hi folks.
Today I got a new locking issue.
This is the first time I got it, and it's merely reproduced.
The box has lost both remote connection and local access.
No SIGINFO output on the local console even.
Jumping in ddb shows the next:
1) first, this is a 8-way web server. No processes on runqueue except one
httpd
(i.e. ps shows R in its state):
You need to find who owns Giant and what that thread is doing. You can try
using 'show lock Giant' as well as 'show lockchain 11568'.
Hi, John!
Just reproduced now on another box.
Hmm.. stack of the process owing Giant looks garbled.
db show lock Giant
class: sleep mutex
name: Giant
flags: {DEF, RECURSE}
state: {OWNED, CONTESTED}
owner: 0xd0d79320 (tid 102754, pid 34594, httpd)
db show lockchain 34594
thread 102754 (pid 34594, httpd) running on CPU 7
db show lockchain 102754
thread 102754 (pid 34594, httpd) running on CPU 7
db bt 102754
Tracing pid 34594 tid 102754 td 0xd0d79320
sched_switch(2,2,1,f1a3fb3c,c08a55d9,...) at sched_switch+0x143
MAXCPU(e5895590,62e85356,e8000110,a3d5,ffb988e8,...) at 0xf7
*** error reading from address f8658d94 ***
What can I do else?
db show allpcpu
Current CPU: 1
cpuid= 0
curthread= 0xcd963960: pid 95678 httpd
curpcb = 0xf0593d90
fpcurthread = none
idlethread = 0xc7cfeaf0: pid 17 idle: cpu0
APIC ID = 0
currentldt = 0x50
cpuid= 1
curthread= 0xc7dfaaf0: pid 40 swi0: sio
curpcb = 0xe82ebd90
fpcurthread = none
idlethread = 0xc7cfe000: pid 16 idle: cpu1
APIC ID = 1
currentldt = 0x50
cpuid= 2
curthread= 0xca8aa640: pid 31167 httpd
curpcb = 0xf1279d90
fpcurthread = none
idlethread = 0xc7cfde10: pid 15 idle: cpu2
APIC ID = 2
currentldt = 0x50
cpuid= 3
curthread= 0xc8b62e10: pid 17221 httpd
curpcb = 0xee951d90
fpcurthread = none
idlethread = 0xc7cfdc80: pid 14 idle: cpu3
APIC ID = 3
currentldt = 0x50
cpuid= 4
curthread= 0xca1f2c80: pid 39078 httpd
curpcb = 0xeec17d90
fpcurthread = none
idlethread = 0xc7cfdaf0: pid 13 idle: cpu4
APIC ID = 4
currentldt = 0x50
cpuid= 5
curthread= 0xcd423af0: pid 74960 httpd
curpcb = 0xf03f2d90
fpcurthread = none
idlethread = 0xc7cfd960: pid 12 idle: cpu5
APIC ID = 5
currentldt = 0x50
cpuid= 6
curthread= 0xcaa89c80: pid 23426 httpd
curpcb = 0xef1aed90
fpcurthread = none
idlethread = 0xc7cfd7d0: pid 11 idle: cpu6
APIC ID = 6
currentldt = 0x50
cpuid= 7
curthread= 0xd0d79320: pid 34594 httpd
curpcb = 0xf1a3fd90
fpcurthread = none
idlethread = 0xc7cfd640: pid 10 idle: cpu7
APIC ID = 7
currentldt = 0x50
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Xorg hangs with drmwtq in 7.2-RELEASE
This topic has been recently discussed twice before in the past month and a half, but without resolution. It now reappears on my system as I upgrade to 7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I am desperately hoping for a resolution. To reiterate the problem: Xorg will occassionally hang. This only happens when compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports updated to this morning. About a third of the time the kernel locks up, and I cannot ssh into the system. The other half of the time I can ssh into the system. There I notice that Xorg has the state of drmwtq, with perhaps some other GUI processes in the same state. The video card is a Radeon X1550. I have tried with and without AGPMode set, and both XAA and EXA render modes. No change. You can look at my xorg.conf and Xorg log at: http://www.usermode.org/misc/xorg.conf http://www.usermode.org/misc/Xorg.0.log.old p.s. Posting to freebsd-stable, as this problem has been previously discussed here. If this is no longer the appropriate list, please let me know. Thank you, -- David Johnson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
