Re: svn repository uuid mismatch from mirror
On Mon, 17 Aug 2015, Jia-Shiun Li wrote: I wanted to svn up my /usr/src and it reported repository uuid mismatch. After digging it seems to be related to svn mirrors. Is UUID supposed to be different among mirrors? If not, could anything detect it and contact mirror admins? Since it is now all hidden behind geo dns. Apologies for this, this is now fixed. Gavin # svn up Updating '.': svn: E170009: Repository UUID '50bf32de-df07-e311-8ff9-0026557e8dec' doesn't match expected UUID 'ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f' # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 286782 Node Kind: directory Schedule: normal Last Changed Author: pfg Last Changed Rev: 286782 Last Changed Date: 2015-08-14 22:58:04 +0800 (Fri, 14 Aug 2015) # svn info https://svn.freebsd.org/base Path: base URL: https://svn.freebsd.org/base Relative URL: ^/ Repository Root: https://svn.freebsd.org/base Repository UUID: 50bf32de-df07-e311-8ff9-0026557e8dec Revision: 286835 Node Kind: directory Last Changed Author: adrian Last Changed Rev: 286835 Last Changed Date: 2015-08-17 10:04:11 +0800 (Mon, 17 Aug 2015) # host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.FreeBSD.org has address 140.113.168.170 svnmir.geo.FreeBSD.org has IPv6 address 2001:f18:113:fb5d::e6a:0 svnmir.geo.FreeBSD.org mail is handled by 0 . # svn info https://213.138.116.72/base Error validating server certificate for 'https://213.138.116.72:443': - The certificate hostname does not match. Certificate information: - Hostname: svn.freebsd.org - Valid: from Jun 22 00:00:00 2015 GMT until Jun 22 23:59:59 2016 GMT - Issuer: Gandi, Paris, Paris, FR - Fingerprint: E9:37:73:80:B5:32:1B:93:92:94:98:17:59:F0:FA:A2:5F:1E:DE:B9 (R)eject, accept (t)emporarily or accept (p)ermanently? t Path: base URL: https://213.138.116.72/base Relative URL: ^/ Repository Root: https://213.138.116.72/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 286835 Node Kind: directory Last Changed Author: adrian Last Changed Rev: 286835 Last Changed Date: 2015-08-17 10:04:11 +0800 (Mon, 17 Aug 2015) # -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head up!] WiFi drivers changes
On Thu, 6 Aug 2015, Gleb Smirnoff wrote: As part of the opaque ifnet project [1], all 802.11 (WiFi) drivers undergo change of not being an interface anymore. Historically in FreeBSD 802.11 stack, 802.11 devices called if_attach() and created an interface. Later this was generalized and real functioning interface is created by net80211 stack. However, remnant of parent interface remained. If you are running Intel Centrino wireless, then you got iwn0 interface and wlan0 interface. However, the former doesn't do anything. You can't assign addresses to it or modify any of it parameters. Or you can modify them, but that affects nothing. You could, however, change the Ethernet address of the underlying interface before creating the wlanX interfaces, which woud then be used by the child interfaces. This has traditionally been the only way you could change the Ethernet interface of a wifi device - changing it after creating the wlanX interface does not work. How will this be done in the new world? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Difference between pkg 1.5.2 and 1.5.4
On Thu, 18 Jun 2015, Eggert, Lars wrote: Hi, I'm netbooting with a read-only rootfs. Up until version 1.5.2 of pkg, that sometimes caused some errors when installing various packages, but the install continued even if some files couldn't be written. That seems to have changed with 1.5.4. Specifically, upgrading ca_root_nss from 3.19 to 3.19.1_1 now aborts in archive_read_extract () as shown below. This regression makes it difficult to run read-only; any chance this abort can be turned into a warning instead? pkg is maintained externally to FreeBSD, opening a bug report at https://github.com/freebsd/pkg/issues is the best way to get things like this fixed. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HP 2B19WM PCI-E SD Reader
On Mon, 2 Feb 2015, R0B_ROD wrote: Thank you for the time you took to help. According to: http://lists.freebsd.org/pipermail/ \ \ freebsd-current/2013-July/042788.html \ freebsd-questions/2014-August/259843.html Is the Realtek RTS5229 PCI-E SD Card Reader supported yet??? Unfortunately, we don't have a driver for this card reader yet. It is worth checking to make sure that you do indeed have this drvice though. Can you give the output of both pciconf -lv and usbconfig list please? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WiFi 802.11/ac PCIe supported adaptor
On Sun, 28 Sep 2014, O. Hartmann wrote: Am Sat, 27 Sep 2014 23:44:19 -0700 Kevin Oberman rkober...@gmail.com schrieb: On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 09/27/14 23:06, O. Hartmann wrote: Am Sun, 28 Sep 2014 00:22:09 +0200 Lars Engels lars.eng...@0x20.net schrieb: FreeBSD doensn't support 802.11ac, yet. I'm bitter aware of that. This OS doesn't support the chipsets, even if they provide also 11a/g/n. As Lars says, we don't yet support anything 11ac, either hardware/driver wise, or in the 802.11 stack. I am aware of people working on support for the 7260, though I suspect a working driver will be some time away. It will also only support a/b/g and maybe n to begin with - we are quite a way from having 11ac support in the stack. We have at our department now a bunch of Lenovo hardware, with Intels 7260 chipset. The laptops are now runninmg Ubuntu 14.0X something which obviously supports the WiFi chip. I'm the last man standing with FreeBSD on my private Lenovo :-( This is a serious problem. I'm about ready to install Linux on my laptop as well just to get a usable system. Some kind of funding directed to a willing developer would be hugely valuable for the usability of the operating system on recent hardware. This is probably more important even than Haswell graphics since without a driver, Haswell is merely slow, whereas networking is completely broken. Unfortunately, funding is just half the problem - we also need to find a developer capable of doing the work. The Intel 3160 and 7260 will likely require a whole new driver - almost no code can be shared between it and the iwn(4) driver. Please understand though that getting a driver for the Intel 11ac devices is seen as a big priority. Some notes from my side. I have personally a i3-3220 IvyBridge based server with iGPU HD2500, which doesn't work properly on CURRENT and gets messed up with EFI and vt(). The screen is dark after loading i915kms and the reason having a highres console is at hand. This is two year old hardware! This server is now getting a new XEON CPU (same board, but with a professional Can you point me to a thread or PR about this? Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( I was always told (or even thaught!) that FreeBSD hasn't the fundings or the manpower to solve problems like KMS, driver and so on. I guess several Linux distributions face a similar problem, but somehow the manufactureres emmit drivers or support. I was aware of that guy that was payed by Intel to develop OpenSource NIC drivers, wasn't his name Vogel? What happened to him? If FreeBSD is pushed more and more in the background, then Jack Vogel still supports wired Intel NIC drivers for us, and other Intel staff support other hardware such as their new storage controllers. it is also due to a bad politics. nVidia, for instance, offers a BLOB for their GPUs. Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts regarding opensource drivers is a pity. nVidia just informed Nouveau (so the headline at Phoronix, if I'm not wrong), that they now make some new restrictions about their harware. Well, FreeBSD hasn't this problem, we do not haven even xf86-video-nouveau in the ports due to the lack of functionality in the kernel. The fact is: under these circumstances, FreeBSD is UNUSABLE on some sort of recent hardware and even opensource drivers are not an option anymore. I'm not hugely knowledgeable on the state of drivers, but: - We have new drivers for the Radeon stuff, in head and 10.1. - nVidia provide FreeBSD drivers for FreeBSD. I understand that part of the reason we don't have OpenCL support is because they don't know there is a demand for it. - I have no idea what functionality we lack for Nouveau, is that documented anywhere? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Install 10.0-RC3 on MacBookPro Late 2013
On Tue, 7 Jan 2014, Lundberg, Johannes wrote:
I have also experienced random hangs. However, I'm not sure if they are
really hangs or just the USB driver stopped working. Since mouse pad,
keyboard everything is run through USB I couldn't tell really what happened.
It seems that the frequency of these hangs depends on the speed of the
CPU. With powerd -a max -b max the machine can last hours without
hanging, with the CPU throttled down the machine can hang within seconds.
The MBA at least defaults to a CPU speed midway between minimum and
maximum.
Did you have any problems with the identifier of the ssd? When I first
tried FreeBSD on MBA2013 it couldn't identify the ssd because there was
some weird characters in the ssd's identifier. Gavin helped me create a
patch that solved the problem temporary (by hard coding a different ident)
but I'm not sure if a permanent fix has been merged.
Yes, mav@ committed the real fix for this in r258683.
Thanks,
Gavin
--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.
On Tue, Jan 7, 2014 at 12:05 PM, Huang Wen Hui huang...@gmail.com wrote:
USB problem fixed by revert to r245731,
set hint.ahci.0.msi=0 seem to fixed timeout problem of AHCI.
Random hang I think still exist, will check later...
Cheers,
Huang Wen Hui
2014/1/7 Lundberg, Johannes johan...@brilliantservice.co.jp
Hi Huang
Good job!! By works, which parts do you mean has been fixed?
1. USB problem
or
2. AHCI timeout problem
or
3. Random hang
Best regards!
--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.
On Tue, Jan 7, 2014 at 11:30 AM, Huang Wen Hui huang...@gmail.comwrote:
Hans,
This wild guess do NOT works.
I binary sect xhci.c in SVN, found that *r245732
*http://svnweb.freebsd.org/base?view=revisionrevision=245732*
introduce the bug.*
http://svnweb.freebsd.org/base?view=revisionrevision=245732
revert to r345731 fixed this USB problem in 9.2R
I also copy xhci_interrupt(struct xhci_softc *sc) from 9.1R to CURRENT,
CURRENT also works!
Cheers,
Huang Wen Hui.
2014/1/7 Hans Petter Selasky h...@bitfrost.no
On 01/06/14 16:28, Hans Petter Selasky wrote:
On 01/06/14 15:17, Adrian Chadd wrote:
Right, but it used to work. That's the confusing bit. How'd you make
it not work? :)
Binary sect the sys/dev/usb/controller/xhci.c revision history? There
has been several bug reports for the Lynx point, and others XHCI
chipsets are working just fine.
A wild guess:
Copy the USB-code from -current.
Add #if 0 as shown sys/dev/usb/controller/xhci_pci.c
static int
xhci_pci_port_route(device_t self, uint32_t set, uint32_t clear)
{
#if 0
uint32_t temp;
temp = pci_read_config(self, PCI_XHCI_INTEL_USB3_PSSEN, 4) |
pci_read_config(self, PCI_XHCI_INTEL_XUSB2PR, 4);
temp |= set;
temp = ~clear;
pci_write_config(self, PCI_XHCI_INTEL_USB3_PSSEN, temp, 4);
pci_write_config(self, PCI_XHCI_INTEL_XUSB2PR, temp, 4);
device_printf(self, Port routing mask set to 0x%08x\n, temp);
#endif
return (0);
}
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
Re: Panic/Freeze with IPSEC on r254532
On Tue, 20 Aug 2013, Vincent Hoffman wrote: I thought I'd have a play with ipsec since its been a while since I last set it up, and was setting up a transport mode connection between my poudiere/repo server (the -curent server) and another box (8.2-RELEASE) 3 pings later the -CURRENT box froze, its zfs on root so no kernel dump I'm afraid, it does have an ipmi so I repeated with a serial over lan connection to test but got nothing it just froze. Any suggestions? The only unusual thing about this machine is that i am running a bhyve vm on it. not sure how relevant that is. FWIW, I posted on what is likely to be the same issue yesterday on freebsd-net@ - http://docs.FreeBSD.org/cgi/mid.cgi?1378750330.11656.44.camel Can you test the workaround I'm currently using? Basically, just ifconfig enc0 create before using the tunnel should be sufficient. Gavin Log output 1st occurance Aug 20 13:24:51 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 13:24:51 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xf80020fe2f60) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 13:24:51 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xf800587afda8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 13:24:51 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 13:24:51 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238af91e0 Aug 20 13:24:51 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238af9290 Aug 20 13:24:51 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfe0238af9350 Aug 20 13:24:51 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfe0238af9400 Aug 20 13:24:51 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: --- trap 0xc, rip = 0x80aa6a53, rsp = 0xfe0238af96e0, rbp = 0xfe0238af9770 --- Aug 20 13:24:51 bsdpkgbuild kernel: ipsec4_process_packet() at ipsec4_process_packet+0x73/frame 0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: ip_ipsec_output() at ip_ipsec_output+0x197/frame 0xfe0238af97b0 Aug 20 13:24:51 bsdpkgbuild kernel: ip_output() at ip_output+0x8a3/frame 0xfe0238af98a0 Aug 20 13:24:51 bsdpkgbuild kernel: rip_output() at rip_output+0x2fa/frame 0xfe0238af98f0 Aug 20 13:24:51 bsdpkgbuild kernel: sosend_generic() at sosend_generic+0x3dc/frame 0xfe0238af99a0 Aug 20 13:24:51 bsdpkgbuild kernel: kern_sendit() at kern_sendit+0x1e4/frame 0xfe0238af9a40 Aug 20 13:24:51 bsdpkgbuild kernel: sendit() at sendit+0xf8/frame 0xfe0238af9a90 Aug 20 13:24:51 bsdpkgbuild kernel: sys_sendto() at sys_sendto+0x4d/frame 0xfe0238af9ae0 Aug 20 13:24:51 bsdpkgbuild kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800d5ccea, rsp = 0x7ffed578, rbp = 0x7ffed5b0 --- Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Fatal trap 12: page fault while in kernel mode Aug 20 13:24:51 bsdpkgbuild kernel: cpuid = 5; apic id = 02 Aug 20 13:24:51 bsdpkgbuild kernel: fault virtual address = 0xd0 Aug 20 13:24:51 bsdpkgbuild kernel: fault code = supervisor write data, page not present Aug 20 13:24:51 bsdpkgbuild kernel: instruction pointer = 0x20:0x80aa6a53 Aug 20 13:24:51 bsdpkgbuild kernel: stack pointer = 0x28:0xfe0238af96e0 Aug 20 13:24:51 bsdpkgbuild kernel: frame pointer = 0x28:0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: code segment= base 0x0, limit 0xf, type 0x1b Aug 20 13:24:51 bsdpkgbuild kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Aug 20 13:24:51 bsdpkgbuild kernel: processor eflags= interrupt enabled, === repeated occurrence Aug 20 14:16:21 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 14:16:21 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xf8001a9820e0) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 14:16:21 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xf801db519da8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 14:16:21 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 14:16:21 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238b081e0 Aug 20 14:16:21 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238b08290 Aug 20 14:16:21 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfe0238b08350 Aug 20 14:16:21 bsdpkgbuild kernel: trap_pfault() at
Re: make[6]: stopped in /usr/src/lib/bind/dns
On Mon, 12 Aug 2013, AN wrote: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #78 r253966: Mon Aug 5 14:42:05 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 254252 Node Kind: directory Schedule: normal Last Changed Author: ed Last Changed Rev: 254252 Last Changed Date: 2013-08-12 13:17:45 -0500 (Mon, 12 Aug 2013) [...] /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:11: warning: null character ignored [-Wnull-character] isc_time_ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:12: warning: null character ignored [-Wnull-character] isc_time_U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:13: warning: null character ignored [-Wnull-character] isc_time_U+U+ ^ [...] /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:23: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+U+U+U+U+U+ ^ OK, this doesn't look good. Somehow, that file appears to contain a load of \0 characters. Looking into where exactly in the file this appears (lines 14678-14688): set_resigntime(zone); UNLOCK_ZONE(zone); } isc_time_settoepoch(zone-refreshkeytime); /* * If we're doing key maintenance, set the key refresh timer to * the next scheduled key event or to one hour in the future, * whichever is sooner. */ The null characters start exactly at 0x6 into the file, a page boundary: 005ffd0 6e 74 69 6d 65 28 7a 6f 6e 65 29 3b 0a 09 09 55 |ntime(zone);...U| 005ffe0 4e 4c 4f 43 4b 5f 5a 4f 4e 45 28 7a 6f 6e 65 29 |NLOCK_ZONE(zone)| 005fff0 3b 0a 09 7d 0a 0a 09 69 73 63 5f 74 69 6d 65 5f |;..}...isc_time_| 006 73 65 74 74 6f 65 70 6f 63 68 28 26 7a 6f 6e 65 |settoepoch(zone| 0060010 2d 3e 72 65 66 72 65 73 68 6b 65 79 74 69 6d 65 |-refreshkeytime| 0060020 29 3b 0a 0a 09 2f 2a 0a 09 20 2a 20 49 66 20 77 |);.../*.. * If w| So, at least one whole page has been replaced by a page of zeros. This feels like it could actually be a VM issue, though it could also be storage. What drives are you using on this system (AHCI? SSD?), and are you using anything like e.g. geom_mirror? A full dmesg may be useful. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: vm_page_alloc: pindex already allocated
On Tue, 25 Jun 2013, Gavin Atkinson wrote: I've just managed to panic an amd64 host, running HEAD r252161 from June 24th. Filesystem is fully ZFS, no UFS or NFS is involved. The panic is fully reproducible, and is also reproduceable with r251861, so has not been introduced in the last week. Within the jail, I ran tail -f /var/log/httpd-access.log. The machine immediately paniced: For the archives, this was fixed with r252337. Gavin panic: vm_page_alloc: pindex already allocated cpuid = 3 KDB: enter: panic [ thread pid 29345 tid 100408 ] Stopped at kdb_enter+0x3b: movq$0,0xabcab2(%rip) db bt Tracing pid 29345 tid 100408 td 0xfe00cd564000 kdb_enter() at kdb_enter+0x3b/frame 0xff895d48e340 vpanic() at vpanic+0xe1/frame 0xff895d48e380 kassert_panic() at kassert_panic+0xd3/frame 0xff895d48e470 vm_page_alloc() at vm_page_alloc+0x4ce/frame 0xff895d48e4b0 zfs_freebsd_write() at zfs_freebsd_write+0x89c/frame 0xff895d48e6c0 VOP_WRITE_APV() at VOP_WRITE_APV+0x113/frame 0xff895d48e7d0 vn_write() at vn_write+0x281/frame 0xff895d48e860 vn_io_fault() at vn_io_fault+0x94/frame 0xff895d48e9f0 dofilewrite() at dofilewrite+0x85/frame 0xff895d48ea40 kern_writev() at kern_writev+0x6c/frame 0xff895d48ea80 sys_write() at sys_write+0x64/frame 0xff895d48ead0 amd64_syscall() at amd64_syscall+0x389/frame 0xff895d48ebf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff895d48ebf0 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x8020cd7aa, rsp = 0x7fffd798, rbp = 0x13 --- Reproducing the panic is easy. While the machine is being accessed (and so Apache is busy writing lots to /var/log/httpd-access.log), running the following as root will panic the machine, usually within 10 seconds: #!/bin/sh while [ 1 ] do tail /var/log/httpd-access.log /dev/null done I have core files available. I've also put a dump of the implicated mpred and object structures at https://svnmir.bme.freebsd.org/core.1.gdb.txt (gdb output) https://svnmir.bme.freebsd.org/core.txt.1 (dumpinfo) Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: vm_page_alloc: pindex already allocated
Hi, I've just managed to panic an amd64 host, running HEAD r252161 from June 24th. Filesystem is fully ZFS, no UFS or NFS is involved. The panic is fully reproducible, and is also reproduceable with r251861, so has not been introduced in the last week. The host machine runs several jails. Inside one of them Apache is used to serve a SVN repository though mod_svn. At the time of the panic, two machines were checking out the same (FreeBSD ports) tree over IPv4 https. Apache will have been writing significant amounts of data to to /var/log/httpd-access.log at the time. Within the jail, I ran tail -f /var/log/httpd-access.log. The machine immediately paniced: panic: vm_page_alloc: pindex already allocated cpuid = 3 KDB: enter: panic [ thread pid 29345 tid 100408 ] Stopped at kdb_enter+0x3b: movq$0,0xabcab2(%rip) db bt Tracing pid 29345 tid 100408 td 0xfe00cd564000 kdb_enter() at kdb_enter+0x3b/frame 0xff895d48e340 vpanic() at vpanic+0xe1/frame 0xff895d48e380 kassert_panic() at kassert_panic+0xd3/frame 0xff895d48e470 vm_page_alloc() at vm_page_alloc+0x4ce/frame 0xff895d48e4b0 zfs_freebsd_write() at zfs_freebsd_write+0x89c/frame 0xff895d48e6c0 VOP_WRITE_APV() at VOP_WRITE_APV+0x113/frame 0xff895d48e7d0 vn_write() at vn_write+0x281/frame 0xff895d48e860 vn_io_fault() at vn_io_fault+0x94/frame 0xff895d48e9f0 dofilewrite() at dofilewrite+0x85/frame 0xff895d48ea40 kern_writev() at kern_writev+0x6c/frame 0xff895d48ea80 sys_write() at sys_write+0x64/frame 0xff895d48ead0 amd64_syscall() at amd64_syscall+0x389/frame 0xff895d48ebf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff895d48ebf0 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x8020cd7aa, rsp = 0x7fffd798, rbp = 0x13 --- Reproducing the panic is easy. While the machine is being accessed (and so Apache is busy writing lots to /var/log/httpd-access.log), running the following as root will panic the machine, usually within 10 seconds: #!/bin/sh while [ 1 ] do tail /var/log/httpd-access.log /dev/null done I have core files available. I've also put a dump of the implicated mpred and object structures at https://svnmir.bme.freebsd.org/core.1.gdb.txt (gdb output) https://svnmir.bme.freebsd.org/core.txt.1 (dumpinfo) Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Google Summer of Code 2013
Hi all, A reminder: The deadline for applications is 19:00 UTC Friday May 3rd (tomorrow). FreeBSD is pleased to announce that once again we have been selected to participate in the Google Summer of Code program. This gives University students the opportunity to earn a $5000 USD stipend in exchange for working on Open Source software over their Summer break. Students have around 12 weeks to work on their project, and will be mentored by existing FreeBSD committers. Participating organisations will earn $500 USD per student mentored. Over the past eight years we have hosted over 150 successful projects, and look forward to continuing this trend. FreeBSD's organisation page may be found at http://www.google-melange.com/gsoc/org/google/gsoc2013/freebsd and a list of possible project ideas may be found at https://wiki.freebsd.org/IdeasPage . Please note that projects do not have to come from the ideas list, and indeed students are encouraged to produce their own project ideas - the majority of past projects have been thought up by the particpants themselves. We are encouraging discussion of projects on the freebsd-hackers mailing list and the #freebsd-soc IRC channel on EFNet. Students are also encouraged to visit http://www.google-melange.com/ to view more details of the program, including eligibility requirements, and a list of other participating organisations. If you have administrative questions you can contact the FreeBSD GSoC administration team at soc-adm...@freebsd.org. Thanks, Gavin signature.asc Description: This is a digitally signed message part
FreeBSD is participating in Google Summer of Code
Hi all, FreeBSD is pleased to announce that once again we have been selected to participate in the Google Summer of Code program. This gives University students the opportunity to earn a $5000 USD stipend in exchange for working on Open Source software over their Summer break. Students have around 12 weeks to work on their project, and will be mentored by existing FreeBSD committers. Participating organisations will earn $500 USD per student mentored. FreeBSD's organisation page may be found at http://www.google-melange.com/gsoc/org/google/gsoc2013/freebsd and a list of possible project ideas may be found at https://wiki.freebsd.org/IdeasPage . Please note that projects do not have to come from the ideas list, and indeed students are encouraged to produce their own project ideas - the majority of past projects have been thought up by the particpants themselves. Students are also encouraged to visit http://www.google-melange.com/ to view more details of the program, including eligibility requirements, and a list of other participating organisations. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lsof vs. clang
On Tue, 6 Nov 2012, Niclas Zeising wrote:
On 11/06/12 14:42, Larry Rosenman wrote:
It appears that we've (mostly) cleaned up the clang/system interface
such that sysutils/lsof works with cc as clang.
Can someone tell me what we need to do to shut these up?
# LSOFCC=cc CC=cc make LSOFCC=cc CC=cc
=== lsof-4.87.a,7 depends on file: /usr/local/sbin/pkg - found
=== Extracting for lsof-4.87.a,7
= SHA256 Checksum OK for lsof_4.87A.freebsd.tar.bz2.
=== Patching for lsof-4.87.a,7
=== Configuring for lsof-4.87.a,7
Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
./lockf_owner.h creation succeeded.
rm -f ddev.c dfile.c dlsof.h dmnt.c dnode*.c dproc.c dproto.h dsock.c
dstore.c dzfs.h kernelbase.h machine.h machine.h.old new_machine.h
__lseek.s Makefile Makefile.zfs ./tests/config.cflags
rm -f ./tests/config.cc ./tests/config.xobj ./tests/config.ldflags
Testing C library for localtime() and strftime(), using cc ... present
ln -s dialects/freebsd/dlsof.h dlsof.h
ln -s dialects/freebsd/dmnt.c dmnt.c
ln -s dialects/freebsd/dnode.c dnode.c
ln -s dialects/freebsd/dnode1.c dnode1.c
ln -s dialects/freebsd/dnode2.c dnode2.c
ln -s dialects/freebsd/dproc.c dproc.c
ln -s dialects/freebsd/dproto.h dproto.h
ln -s dialects/freebsd/dsock.c dsock.c
ln -s dialects/freebsd/dstore.c dstore.c
ln -s dialects/freebsd/dzfs.h dzfs.h
ln -s dialects/freebsd/machine.h machine.h
Makefile and lib/Makefile created.
Makefile.zfs created.
./tests/config.cc created
./tests/config.cflags created
./tests/config.ldflags created
./tests/config.xobj created
=== Building for lsof-4.87.a,7
(cd lib; make DEBUG=-O2 CFGF=-pipe -fno-omit-frame-pointer
-fno-strict-aliasing -fno-omit-frame-pointer -DHASEFFNLINK=i_effnlink
-DHASF_VNODE -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2
-DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H
-DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB
-DNEEDS_BOOLEAN_T -DFREEBSDV=1 -DHASFDESCFS=2 -DHASPSEUDOFS
-DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME
-DLSOF_VSTR=\10.0-CURRENT\)
cc -pipe -fno-omit-frame-pointer -fno-strict-aliasing
-fno-omit-frame-pointer -DHASEFFNLINK=i_effnlink -DHASF_VNODE
-DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T
-DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHAS_ZFS -DHAS_V_LOCKF
-DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T
-DFREEBSDV=1 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6
-DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR=10.0-CURRENT -I/usr/src/sys -O2
-c ckkv.c
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:190:
In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
/usr/src/sys/sys/buf.h:392:2: warning: implicit declaration of function
'KASSERT' is invalid in C99 [-Wimplicit-function-declaration]
KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp));
^
As this hints on, KASSERT is undeclared. You should either declare KASSERT
manually or include the proper header file.
With that said, KASSERT look very much like kernel code, and should probably
not be used in userland utilities at all, but I am no expert on this.
Yes, probalby either #include sys/systm.h, or it may be easier to roll
your own #define inside lsof.h:
#define KASSERT(exp,msg) do {} while (0)
Given this is userland code, you probably don't want the true KASSERT code
anyway.
Gavin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cron seems not working for me
On Wed, 31 Oct 2012, Alexander Yerenkow wrote: Hello there! I'm probably stuck into something on two my VM FreeBSD's. FreeBSD 10.0-CURRENT #0 r241608: Tue Oct 16 16:32:03 EEST 2012 Cron was broken in odd ways between r241576 and r241672. Update your system and try again. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geom mirror now rebuilding on every reboot?
On Mon, 2012-08-06 at 08:34 -0700, Maksim Yevmenkin wrote: Michael, Something in -current and recently MFC'd to -stable is causing all of my gmirror drives to rebuild on reboot :-( Being remote and these being production machines, I suspect SVN r237929 and r237930 in -current and SVN r238500 to -stable but haven't yet been able to prove it. Is anyone else seeing this? yes, i've seem something similar only much, much worse. one of our production systems completely kept loosing its gmirror volumes on every reboot. it looked like gmirror metadata were completely corrupted. rebuilding mirrors and reverting back to previous kernel seemed to work. someone else is tracking it down. Have they managed to track this down to a commit or range of commits yet? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r234000: i386 freeze when HT enabled
On Mon, 9 Apr 2012, Alex Keda wrote: FreeBSD bsd-test.moskb.local 9.9-CURRENT FreeBSD 10.0-CURRENT #0 r234000: Sun Apr 8 03:02:51 MSK 2012 root@bsd-test.moskb.local:/usr/obj/usr/src/sys/GENERIC i386 Proliant 320 G4 freeze with Hyper-Threading enabled with last Line some about CPU1 AP Launched with disabled - boot OK Can you try reverting r233961 and seeing if this fixes boot for you? Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Enhancing the user experience with tcsh
On Thu, 2012-02-09 at 19:52 -0500, Eitan Adler wrote: In conf/160689 (http://www.freebsd.org/cgi/query-pr.cgi?pr=160689) there has been some discussion about changing the default cshrc file. I'd like to commit something like the following based on Chris's patch at the end of the thread. This post is an attempt to open the change to wider discussion. commit dbe6cb730686dd53af7d06cc9b69b60e6e55549c diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc --- a/etc/root/dot.cshrc +++ b/etc/root/dot.cshrc @@ -7,9 +7,10 @@ alias h history 25 alias j jobs -l -alias la ls -a +alias la ls -aF alias lf ls -FA -alias ll ls -lA +alias ll ls -lAF +alias ls ls -F Please, no. # A righteous umask umask 22 @@ -17,19 +18,24 @@ umask 22 set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin $HOME/bin) setenv EDITOR vi -setenv PAGER more +setenv PAGER less setenv BLOCKSIZE K Probably sensible. if ($?prompt) then # An interactive shell -- set some stuff up set prompt = `/bin/hostname -s`# set filec - set history = 100 - set savehist = 100 + set history = 1 + set savehist = 1 + set autolist I think it'd be better for this to be set autolist=ambiguous - it changes an accidental keypress into a deliberate choice, and matches Linux a bit better. + # Use history to aid expansion + set autoexpand set mail = (/var/mail/$USER) if ( $?tcsh ) then bindkey ^W backward-delete-word bindkey -k up history-search-backward bindkey -k down history-search-forward endif + set prompt = [%n@%m]%c04%# + set promptchars = %# endif I always override the prompt anyway. My personal favourite is set prompt=%B%n@`hostname -s`%b:%/ %h% but I see no real problem with the suggested prompt (although set prompt = %n@%m:%c04%# would at least save one character. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Enhancing the user experience with tcsh
On Fri, 2012-02-10 at 11:25 -0500, Eitan Adler wrote: Picking a random email to reply to. My goal with this email is to reduce the amount of controversial changes. I applaud this. I've often considered doing the same but avoided it because it was easier than fighting the bikeshed :) commit 3ea4ea3a59d14cb060244618dd89d7dd0170bee1 diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc --- a/etc/root/dot.cshrc +++ b/etc/root/dot.cshrc @@ -7,9 +7,10 @@ alias hhistory 25 alias jjobs -l -alias la ls -a +alias la ls -aF alias lf ls -FA -alias ll ls -lA +alias ll ls -lAF +alias ls ls -F Two people didn't like these changes but didn't explain why. This is incredibly helpful, especially for a new user. If you dislike the alias change please explain what bothers you about it? I don't use the first two aliases, so I don't care about them at all. I do however disagree strongly with changing the default options on such a widely used command. This change is disruptive, and it can affect use of ls(1) in scripts. For example, it even sticks the extra characters in the output of ls -1 (the number 1), which is specifically designed to be used when piping the output elsewhere. Please do not break this. It is also distracting - If I want to see what type of file a particular entry is, why not just run ls -l? It's like the tendency some Linux distributions have of alias mv mv -i, although that can at least be overridden on the command line with -f. The ls -F change cannot be overridden without unaliasing. if ($?prompt) then # An interactive shell -- set some stuff up - set prompt = `/bin/hostname -s`# + set prompt = [%n@%m]%c04%# + set promptchars = %# Many people had alternative suggestions for the prompt. Can you please clarify why you believe your prompt should be the _default_ one? I can't comment as I didn't say my suggestion should be default - but for me the above isn't a bad choice. I would however prefer: set prompt = %n@%m:%c04 %# and not set prompt = [%n@%m]%c04%# as that then gives you user@host:path in exactly the same format as you need to use with scp, etc. I use the $HOME/bin on my machines but I am not so sure to make this a general thing. Many people expect it, and given that it is the last item in the path it won't affect all that much. It's been in there forever. I think this should stay, it would just be too disruptive otherwise. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removal of sysinstall from HEAD and lack of a post-install configuration tool
On Tue, 27 Dec 2011, Ron McDowell wrote: As a related question, is there a good primer somewhere about how to use SVN? I'm using csup at present. - Install the subversion port - Downlaod the source. To get HEAD code: svn co svn://svn.freebsd.org/base/head/ or to get 9-stable code: svn co svn://svn.freebsd.org/base/stable/9 (If you want to check it out into a different directory, append the dir name, for example: svn co svn://svn.freebsd.org/base/head/ src) - Make your changes :) - To get a diff of your changes, you can just use svn diff Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 3 show-stopper issues with 9-BETA3
On Wed, 5 Oct 2011, Ian FREISLICH wrote: In no particular order: It's a shame that nobody has yet picked up on this, it is a very useful list of bugs in 9.0. Is there any chance you could log these three issues as three separate PRs so that they don't get lost? Please tag them with [regression] in the subject if they are indeed regressions from a previous version (they sound like they are) so that they hopefully get onto the release engineering radar. 1. bce(4) transmit and recieve ring buffer overruns On a moderately busy router with a full BGP table and aggregate throughput of between 200mbps and 800mbps, I get these buffer overruns at an average rate of 28 per second on the busiest interface. [firewall1.jnb1] ~ # sysctl dev.bce |grep com_no_buffers dev.bce.0.com_no_buffers: 101 dev.bce.1.com_no_buffers: 0 dev.bce.2.com_no_buffers: 32547 dev.bce.3.com_no_buffers: 444 I've tried increasing the TX_PAGES and RX_PAGES in sys/dev/bce/if_bcereg.h as I've done in the past (to 64) which is what resolved this problem on 8.2-STABLE to no avail. It appears that there is a hard limit of 8 according to bce_set_tunables() in if_bce.c. But no values to hw.bce.tx_pages and hw.bce.rx_pages makes the slightest difference. 2. carp(4) on my backup router randomly takes over MASTER on the standby host, but when ifconfig claims the carp interface is master tcpdump shows that it's not broadcasting its advertisement. The actual master still broadcasts and no setting of advskew or advbase changes the 9-BETA host's idea of who is actually master. I have to reboot the host to reset the carp interfaces. destroying and re-creating them just brings them up as backup for about a second and then they regress to master. Is ipv6 involved in this? Do you have a couple of sample config files that I can drop onto two machines and recreate the issue, by any chance? 3. PF doesn't expire state. The state table on my older host (pre OpenBSD-4.5) has the following stats: Status: Enabled for 0 days 00:37:17 Debug: Urgent State Table Total Rate current entries 169546 searches9438745142193.8/s inserts 4012389 1793.6/s removals 3842843 1717.9/s The 9-BETA3 host's current entries exactly match the number of inserts until it hits the hard limit of 1.5M entries and can add no more. It takes about 10 minutes to fill up and then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9-Beta3 on X300 problems.
On Mon, 2011-09-26 at 21:40 +0200, crsnet.pl wrote: Hello. I upgrade my FreeBSD 8.2-Release to FreeBSD 9-Beta and pkg_delete -f -a and add new (that same) pkgs with pkg_add. And system, xorgs, wine, opera, java, flash works ok, but... I find two things that dont works ;/ 1. Suspend. On FreeBSD 8.2 when i make ifconfig wlan0 down, and use zzz from X.org all works. Suspend/resume. Now when i make this same, system go to console and suspend. When i try to resume. System show console, but when i try to press ALT+F9 i get long beeep and system hang ;/ I found on Google that i can try, to make uhci as a module, and first unload it, and then suspend system. But when i try to kldload uhci system go to dbg and hangs ;/ I'm not sure why the machine panics when you unload uhci - if you can get any more information about the panic then please open a PR. As for the issue with suspend/resume hanging, can you please try the patch at http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 and see if that makes suspend/resume work? That patch is a hack rather than the correct solution, but it would be useful if you can test it and see if that makes any difference. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Choosing between DELAY(useconds) and pause()
On Mon, 2011-09-26 at 09:30 -0400, John Baldwin wrote: On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: It appears that the pause() function cannot be used in driver functions which are invoked early in the boot process. Is there is a kernel api which a device driver can use to determine whether to use pause() or DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. Note that this still shouldn't be done in your suspend/resume paths, as cold isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this has changed in HEAD though with the eventtimers stuff. I do think it is best however, to use DELAY() in the suspend/resume path always regardless. I don't think head is any different from stable/8 in this respect - the same hack patch that fixes suspend/resume for me on head also fixes it on stable/8 (the patch basically fakes cold during USB suspend/resume). See my email to -usb a few months ago: http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 I'd really like some guidance as to the correct solution to this, I have four separate laptops which fail out of the box on 8 and 9, but suspend/resume perfectly with this hack. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Solved] FreeBSD 9-Beta3 on X300 2 problems
On Tue, 2011-09-27 at 19:53 +0800, Adrian Chadd wrote: Hans, Why haven't those patches been committed? This patch is an absolute hack, and shouldn't be committed as it is. I would, however, appreciate some help in determining the correct solution. The solution may well involve not suspending/resuming hpet(4) or the other timers on the normal DEVICE_SUSPEND()/DEVICE_RESUME() path but instead doing them as the last thing to be suspended, or it may instead involve reworking the USB code (and potentially other code) to not need to sleep during suspend/resume. I don't know the right solution, but would really like to work with somebody who does. Please also see the thread Choosing between DELAY(useconds) and pause() on -current. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Choosing between DELAY(useconds) and pause()
On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: It appears that the pause() function cannot be used in driver functions which are invoked early in the boot process. Is there is a kernel api which a device driver can use to determine whether to use pause() or DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. Note that this still shouldn't be done in your suspend/resume paths, as cold isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 bata2 keymap
On Sat, 2011-09-17 at 12:24 -0400, Fbsd8 wrote: Changing the cancel button in the kbdmap command to skip, does not address the problem, which is the lack of knowledge of the standard bsdinstall user. I've been using Freebsd since 4.0 and never used the kbdmap command or for that matter even knew it existed. Interesting. Sysinstall has asked for country information and then asked you to choose a keymap (using kbdmap) if you selected a non-default country as the first two questions (i.e. before you get the sysinstall menu) since 6.1. Would that be a good solution still? Some of the other points brought up later about wanting to switch between two different keymaps seem sensible too, though I don't initially see how that would be possible. Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup servers broken?
On Sat, 2 Jul 2011, Ian FREISLICH wrote: Matt wrote: On 07/01/11 09:34, Ian FREISLICH wrote: It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Try csup instead of cvsup...I've found it works better. Any possibility of network issues? csup gets into an infinite loop near the end of the ports tree and starts growing in memory consumption. I killed it after it grew to about 500M resident. The following is a ktrace snippet after it stalls: 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) The first part of csup's stack trace. It appears to be corrupted with several null frames, and is very, very deep. (gdb) bt #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 #2 0x2832b7ea in isatty () from /lib/libc.so.7 #3 0x08051832 in fnmatch () #4 0x08051906 in fnmatch () #5 0x08052135 in fnmatch () #6 0x08059c19 in fnmatch () #7 0x08059a76 in fnmatch () #8 0x0804c1ff in ?? () #9 0x28c11380 in ?? () #10 0x2845f402 in ?? () [mini] /usr/home/ianf # procstat -f 75390 PID COMM FD T V FLAGSREF OFFSET PRO NAME 75390 csup text v r r--- - - - /usr/bin/csup 75390 csup ctty v c rw-- - - - /dev/pts/1 75390 csup cwd v d r--- - - - /usr/src 75390 csup root v d r--- - - - / 75390 csup0 v c rw-- 14 10464115 - /dev/pts/1 75390 csup1 v c rw-- 14 10464115 - /dev/pts/1 75390 csup2 v c rw-- 14 10464115 - /dev/pts/1 75390 csup3 s - rw-- 2 0 TCP 10.0.2.67:19238 128.205.32.24:5999 75390 csup4 v r r--- 1 0 - /usr/home/ncvs/ports/x11/wbar/Makefile,v 75390 csup5 v r r--- 11023 - /var/db/sup/ports-all/checkouts 75390 csup6 v r r--- 1 24492073 - /var/db/sup/ports-all/checkouts 75390 csup7 v r -w-- 1 24491389 - /var/db/sup/ports-all/#cvs.csup-75390.0 filedescriptor 4's directory listing: [mini] /usr/home/ncvs/ports/x11/wbar # ls -la total 24 drwxr-xr-x3 root wheel512 Jul 1 07:21 . drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. -r--r--r--1 root wheel 0 Feb 8 22:51 Makefile,v -r--r--r--1 root wheel 0 Mar 19 14:38 distinfo,v drwxr-xr-x2 root wheel512 Jul 1 07:21 files -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-descr,v -r--r--r--1 root wheel 0 Feb 8 22:51 pkg-plist,v After removing the zero sized files, csup continued until it hit x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was also zero sized. Having deleted all the zero files, both cvsup and csup complete their run. I don't think you'll get much interest in fixing cvsup, but if you can recreate this at will with csup and haven't had a response in a few days, could you please submit a PR? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: current status of digi driver
On Thu, 23 Jun 2011, David Boyd wrote: While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? [snip] I have time and hardware to test with and can help as needed. Patches have been submitted in the last week to update the digi(4) driver to work with the new TTY layer. If you are able to spend some time testing them on 9-CURRENT, there is a possibility that there may still be time to get them into the tree before 9.0-RELEASE. The patches can be found in kern/158086. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: graid hit the tree
On Thu, 2011-03-24 at 23:48 +0200, Alexander Motin wrote: Hi. I've just committed the new GEOM-based software RAID driver (graid) into the HEAD [1]. Brave testers are welcome. :) 1. http://svn.freebsd.org/viewvc/base?view=revisionrevision=219974 One question. I'm very happy with the performance of the ahci subsystem, it is measurably faster against the old ATA subsystem on modern hardware. I also really appreciate the compatibility shims to aid migration from the adX style numbering to adaX. On every system I've migrated so far, this mapping has worked flawlessly. Is there any chance that mapping from /dev/arX - /dev/raid/r0 etc could also be done? One thing that I have found is that it can be hard to determine from the dmesg exactly where raid partitions will appear. It would be wonderful if devices similar to the adX devices could be made, for any graid devices found. Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mount root from zfs fails under current with error 6
On Tue, 2011-05-31 at 19:38 +0200, Michael Reifenberger wrote: Hi, On Tue, 31 May 2011, Michael Reifenberger wrote: ... (fs)(root) gpart show ada0 =34 5860533101 ada0 GPT (2.7T) 34 990 1 freebsd-boot (495k) 1024 2098176 2 freebsd-swap (1.0G) 2099200 5858433928 3 freebsd-zfs (2.7T) 5860533128 7- free - (3.5k) ... maybe I found something: After setting vfs.zfs.debug=1 I got two new verbose bootlogs: http://people.freebsd.org/~mr/boot_fail2.txt http://people.freebsd.org/~mr/boot_success2.txt As you can see, in the failing case ZFS tries to attach to ada[0123] whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the correct devices) Can you try setting kern.geom.part.check_integrity=0 ? Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant and ssid
On Tue, 2010-10-19 at 00:55 +0800, Buganini wrote: It seems that wpa_supplicant iterate through all scanned ssids and try to associate with each, and that cause two problem for me. 1) in my school, there are many AP, and connection is not stable, when disconnect, it take many time to try and fail to associate with those ssids until the one I want. This appears to be the same as the bug reported in PR bin/98220. wpa_supplicant is contributed code, so I think the correct answer is to report this upstream. As far as I could tell when I last checked, this hasn't yet been fixed upstream. Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Please join us for Bugathon #7, this weekend (6th-9th August)
(bcc'd to freebsd-stable@, please reply to freebsd-current@) Hi all, Apologies for the late notice, but the bug team will be holding a bugathon this weekend. We'll be starting on Friday 6th, and continuing through Monday 9th, and the aim is to put a real effort into getting patches from PRs into a committable state, and get them committed. Some PRs will be invalid because either the bug no longer exists or was fixed without the PR being closed, identifying these is also of great benefit. The basic plan is to get as many volunteers and committers into the same place (#freebsd-bugbusters on EFnet), and work through some PRs. For this particular bugathon, we're planning on focusing on the ~1600 PRs which contain patches. Committers can help by being in the channel and available to review patches and commit them, but these events benefit especially from volunteers who are not committers: the more people who are able to look at PRs, evalaute the patches, and assess whether the patches are correct and/or the best solution to the problem, the better. If you've never been more than a user of FreeBSD then this is a great way to start to get involved - many of the bugs in the database are relatively simple to fix, and are just waiting for somebody with enough time to sit down and actually take a close look at the bugs. If you're able to evaluate patches and actually justify why the patch included is the correct solution then that is a huge help, too! So, please join us in #freebsd-bugbusters if you are free at any point over the weekend. I'll be in the channel pretty much all the time during the day (GMT) Friday - Monday, and other bugbusters/bugmeisters will be around over those four days too. Everybody is welcome to join us, the more eyes the better. We should hhopefully ave quite a few committers in the channel too, so there should be plenty of expertise available to review and commit the patches that are in a committable state. There are several wiki pages available for people who are interested in joining in, especially: http://wiki.freebsd.org/Bugathons/2010August http://wiki.freebsd.org/Bugathons/PRsWithPatches http://wiki.freebsd.org/BugBusting/Resources Many thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Tue, 27 Jul 2010, Anton Shterenlikht wrote: On Tue, Jul 27, 2010 at 05:53:25PM +0100, Gavin Atkinson wrote: On Tue, 2010-07-27 at 15:47 +0100, Anton Shterenlikht wrote: db bt Tracing pid 0 tid 10 td 0x80b40de0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b uma_dbg_free() at uma_zfree_arg+0x62 free() at free+0xcd device_set_driver() at device_set_driver+0x7c device_attach() at device_attach+0x1a3 Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) yes, thanks, the panic has gone away. I've committed this patch, and will MFC in one week. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: firefox is stuck in getbuf()
On Wed, 21 Jul 2010, Gavin Atkinson wrote: On Tue, 2010-07-20 at 16:29 +0300, Kostik Belousov wrote: On Tue, Jul 20, 2010 at 10:58:00AM +0800, David Xu wrote: With newest -HEAD code, firefox is stuck in getbuf(). top last pid: 1814; load averages: 0.00, 0.05, 0.07 up 0+00:37:11 10:54:01 135 processes: 1 running, 134 sleeping CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free Swap: 2020M Total, 2020M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1427 davidxu 1 450 114M 101M select 0 1:24 0.29% Xorg 1588 davidxu 10 440 279M 145M getbuf 0 2:15 0.00% firefox-bin procstat -k 1588 PIDTID COMM TDNAME KSTACK 1588 100200 firefox-bin initial thread mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100207 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscallenter syscall Xint0x80_syscall 1588 100208 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100209 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100210 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100216 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100220 firefox-bin -mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100238 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100239 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100240 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. I can relatively easily recreate this, see my thread on -current on the 17th July (Filesystem wedge, SUJ-related?), which (and the followup emails) contain additional info. I'm currently trying to find the commit responsible for introducing this, and have established that a OK, sorry for the delay. I have the information requested. Please see http://people.freebsd.org/~gavin/rho-fs-hang.txt I've started to try and narrow down where exactly the hangs started: r208700 - June 1st - seems to work fime r209425 - June 22st - hangs occur If you need any more info, let me know. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Mon, 2010-07-26 at 14:24 +0100, Anton Shterenlikht wrote: On amd64 r210496 I get this panic when booting a kernel with snd_hda(4). I haven't used this driver before, so can't say if this is a regression. (copied by hand) hdac0: ATI SB600 High Definition Audion Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (0) device_attach: hdac0 attach returned 6 Slab at 0xff000261eb18, freei 3 = 0 panic: Duplicate free of item 0xff0002661c00 from zone 0xff00b7f9a500(1024) cpuid = 0 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3d: movq $0,0x74f360(%rip) dbbt (very long output.. ending in) Can you give us this output please? At least the panic() line and the next six or so lines? Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Tue, 2010-07-27 at 12:58 +0100, Anton Shterenlikht wrote: On Tue, Jul 27, 2010 at 11:23:24AM +0100, Gavin Atkinson wrote: On Mon, 2010-07-26 at 14:24 +0100, Anton Shterenlikht wrote: On amd64 r210496 I get this panic when booting a kernel with snd_hda(4). I haven't used this driver before, so can't say if this is a regression. (copied by hand) hdac0: ATI SB600 High Definition Audion Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (0) device_attach: hdac0 attach returned 6 Slab at 0xff000261eb18, freei 3 = 0 panic: Duplicate free of item 0xff0002661c00 from zone 0xff00b7f9a500(1024) cpuid = 0 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3d: movq $0,0x74f360(%rip) dbbt (very long output.. ending in) Can you give us this output please? At least the panic() line and the next six or so lines? ok, will do. I wish the modern laptops had a serial link.. Indeed. I keep buying Toshibas, who still have a range with serial ports. Having said that, have you tried to use the dcons stuff over firewire? That usually works pretty well in my experience. http://wiki.freebsd.org/DebugWithDcons Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Tue, 2010-07-27 at 15:47 +0100, Anton Shterenlikht wrote: On Tue, Jul 27, 2010 at 02:52:17PM +0100, Gavin Atkinson wrote: On Tue, 2010-07-27 at 12:58 +0100, Anton Shterenlikht wrote: On Tue, Jul 27, 2010 at 11:23:24AM +0100, Gavin Atkinson wrote: On Mon, 2010-07-26 at 14:24 +0100, Anton Shterenlikht wrote: hdac0: ATI SB600 High Definition Audion Controller irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (0) device_attach: hdac0 attach returned 6 Slab at 0xff000261eb18, freei 3 = 0 panic: Duplicate free of item 0xff0002661c00 from zone 0xff00b7f9a500(1024) Can you give us this output please? At least the panic() line and the next six or so lines? here it is: db bt Tracing pid 0 tid 10 td 0x80b40de0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b uma_dbg_free() at uma_zfree_arg+0x62 free() at free+0xcd device_set_driver() at device_set_driver+0x7c device_attach() at device_attach+0x1a3 Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) Gavin -- Gavin Atkinson FreeBSD committer and bugmeister ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: firefox is stuck in getbuf()
On Tue, 2010-07-20 at 16:29 +0300, Kostik Belousov wrote: On Tue, Jul 20, 2010 at 10:58:00AM +0800, David Xu wrote: With newest -HEAD code, firefox is stuck in getbuf(). top last pid: 1814; load averages: 0.00, 0.05, 0.07 up 0+00:37:11 10:54:01 135 processes: 1 running, 134 sleeping CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free Swap: 2020M Total, 2020M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1427 davidxu 1 450 114M 101M select 0 1:24 0.29% Xorg 1588 davidxu 10 440 279M 145M getbuf 0 2:15 0.00% firefox-bin procstat -k 1588 PIDTID COMM TDNAME KSTACK 1588 100200 firefox-bin initial thread mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100207 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscallenter syscall Xint0x80_syscall 1588 100208 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100209 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100210 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100216 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100220 firefox-bin -mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100238 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100239 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100240 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. I can relatively easily recreate this, see my thread on -current on the 17th July (Filesystem wedge, SUJ-related?), which (and the followup emails) contain additional info. I'm currently trying to find the commit responsible for introducing this, and have established that a kernel from the 1st June does not seem to exhibit the same issue. Tonight, I'll revert to a current -current and try to get the info you need. Thanks, Gavin -- Gavin Atkinson FreeBSD committer and bugmeister ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Filesystem wedge, SUJ-related?
On Sat, 17 Jul 2010, Gavin Atkinson wrote: Semi-regularly (every two-three days) I'm seeing what appears to be some sort of filesystem wedge. I usually see it initially with web browsers, but it's possible that's only because it's what produces most disk activity on this machine. I've seen it with both Opera and Firefox. What happens is that the process will just wedge. A procstat -kk on it shows the following stack backtrace: 9012 100243 firefox-bin initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 A bit more detail: it does look like whatever is supposed to periodically flush the journal just stops doing it's job. Presumably this is also the root cause of the softdep: Out of journal space! messages I have been seeing in the past, which I had assumed may have been fixed by r209717. (I'm running r209723 at the moment) While processes are starting to hang, sh ffs from ddb shows: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 17345 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 55 su_req 0 Leaving it another couple of hours, I then see: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 36 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 31899 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 95 su_req 0 so, su_deps is increasing significantly. During reboot, vnlru failed to stop within 60 seconds, and gave up on syncing 125 vnodes and 140 buffers (no idea if these are related). On reboot, SU+J fsck shows for /usr: ** SU+J Recovering /dev/ad4s1f ** Reading 33554432 byte journal from inode 150. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 405991 journal records in 18194944 bytes for 71.40% utilization ** Freed 3872 inodes (0 dirs) 48157 blocks, and 8744 frags. So it seems clear that somehow the journal is filling up, and never being written. Any other suggestions as to where I should go from here? Thanks, Gaivn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Filesystem wedge, SUJ-related?
Hi guys, Semi-regularly (every two-three days) I'm seeing what appears to be some sort of filesystem wedge. I usually see it initially with web browsers, but it's possible that's only because it's what produces most disk activity on this machine. I've seen it with both Opera and Firefox. What happens is that the process will just wedge. A procstat -kk on it shows the following stack backtrace: 9012 100243 firefox-bin initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 8954 100231 operainitial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 Reading from the disk is fine, indeed writing to the disk seems to work fine for other applications, even once a browser has wedged. I've included the output of sysctl -a | grep debug.softdep later in the email, in case it gives any clues. This was taken while the system was idle, about an hour after both Firefox and Opera had wedged. As I say, this happens every few days, so please let me know what further information can be useful to diagnose this. I can get info from the debugger too - but as I don't have much experience diagnosing FS issues somebody needs to tell me which info to obtain other than the standard (alltrace, ps, etc). Thanks, Gavin debug.softdep.jwait_newblk: 3 debug.softdep.jwait_inode: 44 debug.softdep.jwait_freeblks: 115 debug.softdep.jwait_filepage: 181 debug.softdep.journal_wait: 15488 debug.softdep.journal_min: 0 debug.softdep.journal_low: 0 debug.softdep.jnewblk_rollback: 27953 debug.softdep.jaddref_rollback: 1811 debug.softdep.dir_entry: 23248 debug.softdep.direct_blk_ptrs: 5975 debug.softdep.inode_bitmap: 8631 debug.softdep.indir_blk_ptrs: 7670 debug.softdep.sync_limit_hit: 0 debug.softdep.ino_limit_hit: 0 debug.softdep.blk_limit_hit: 0 debug.softdep.ino_limit_push: 0 debug.softdep.blk_limit_push: 0 debug.softdep.worklist_push: 0 debug.softdep.maxindirdeps: 50 debug.softdep.tickdelay: 2 debug.softdep.max_softdeps: 40 debug.softdep.current.jtrunc: 0 debug.softdep.current.sbdep: 0 debug.softdep.current.jsegdep: 5218 debug.softdep.current.jseg: 3921 debug.softdep.current.jfreefrag: 0 debug.softdep.current.jfreeblk: 0 debug.softdep.current.jnewblk: 0 debug.softdep.current.jmvref: 0 debug.softdep.current.jremref: 0 debug.softdep.current.jaddref: 11 debug.softdep.current.freedep: 18 debug.softdep.current.freework: 4666 debug.softdep.current.newdirblk: 0 debug.softdep.current.dirrem: 122 debug.softdep.current.mkdir: 0 debug.softdep.current.diradd: 132 debug.softdep.current.freefile: 2 debug.softdep.current.freeblks: 4198 debug.softdep.current.freefrag: 0 debug.softdep.current.allocindir: 0 debug.softdep.current.indirdep: 4 debug.softdep.current.allocdirect: 0 debug.softdep.current.newblk: 255 debug.softdep.current.bmsafemap: 3 debug.softdep.current.inodedep: 284 debug.softdep.current.pagedep: 119 debug.softdep.total.jtrunc: 114 debug.softdep.total.sbdep: 6109 debug.softdep.total.jsegdep: 489669 debug.softdep.total.jseg: 23468 debug.softdep.total.jfreefrag: 67993 debug.softdep.total.jfreeblk: 53638 debug.softdep.total.jnewblk: 180654 debug.softdep.total.jmvref: 160 debug.softdep.total.jremref: 95199 debug.softdep.total.jaddref: 92071 debug.softdep.total.freedep: 1044 debug.softdep.total.freework: 57287 debug.softdep.total.newdirblk: 267 debug.softdep.total.dirrem: 95173 debug.softdep.total.mkdir: 490 debug.softdep.total.diradd: 91573 debug.softdep.total.freefile: 67115 debug.softdep.total.freeblks: 38486 debug.softdep.total.freefrag: 67993 debug.softdep.total.allocindir: 0 debug.softdep.total.indirdep: 3798 debug.softdep.total.allocdirect: 0 debug.softdep.total.newblk: 180654 debug.softdep.total.bmsafemap: 11319 debug.softdep.total.inodedep: 197151 debug.softdep.total.pagedep: 89352 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Coming back to the btxld: No such file or directory installworld
On Sun, 2010-06-27 at 13:14 -0700, Garrett Cooper wrote: Hi Ruslan, I've run into this particular error twice now in the past couple of weeks when building with -j24 on a memory disk and I was wondering if there was an missing dependency / race somewhere or something (perhaps make obj?): === sys/boot/i386/boot2 (install) # ... btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: No such file or directory *** Error code 1 Stop in /scratch/freebsd/current/sys/boot/i386/boot2. *** Error code 1 I've seen this in the last couple of weeks as well. I build with -j3, and the buildworld seemed to go fine. During the installworld (after installkernel and reboot) I saw the same as you see. Running the make in the respective subdirectories, then rerunning installworld works. Example: btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/zfsboot/../btx/btx/btx -l zfsboot.ldr -o zfsboot.ld -P 1 zfsboot.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=602c text=0 data=0 bss=0 entry=0 output: fmt=bin size=66bc text=0 data=66bc org=0 entry=0 6468 bytes available dd if=zfsboot.ld of=zfsboot2 obs=32768 conv=osync 51+1 records in 1+0 records out 32768 bytes transferred in 0.62 secs (528611360 bytes/sec) cat zfsboot1 zfsboot2 zfsboot ... and I fixed it in the same way. I'm assuming there's some dependency not listed in a makefile or something, but without the log from buildworld it's hard to find. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sparse journal?
On Fri, 4 Jun 2010, John Baldwin wrote: I crashed a testbox running FreeBSD/i386 today which had SUJ enabled on its /var partition. It encountered the following error when trying to fsck -p during boot: ** SU+J Recovering /dev/ada0s1d ** Reading 16572416 byte journal from inode 4. fsck_ufs: Sparse journal inode 4. It then failed with an unexpected soft update inconsistency. du claims that /var/.sujournal takes up 16192 KB. This matches up assuming 8k blocks and 1 indirect block (I used fsdb -r and dumped the block list for inode 4 and it does have one indirect block). Any ideas? This should be fixed in r208241. Try disabling and re-enabling journalling on that partition with tunefs(8) built after that revision. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switchover to CAM ATA?
On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. Losing ataraid would be bad. I suspect there are a lot of installs using it - especially as there is no way to create any other mirror from sysinstall. However, I'm not actually sure that the functionality it provides is easy to push down into GEOM. ataraid depends on knowing a lot about the underlying hardware, in order to know which format of metadata to use. i.e. it needs to know that the disks are attached to (say) a Highpoint controller. This is especially important when creating new ATA RAID devices, although there is so little identifying metadata on the disks themselves that in some cases it doesn't look like it is possible to identify or even confirm the existence of metadata without knowing the PCI ID of the controller to which the disks are attached. I'm not sure I can see a way to do this from within GEOM. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown -p now reboots server instead off power down
On Thu, 2010-02-18 at 14:15 +0100, Johan Hendriks wrote: Hello all. I have a proliant ML110 server, with the latest FreeBSD 9.0 current. (cvsuped today) When i do a shutdown - p now on the system, it reboots instead of the power down it used to do. Which version was the last that successfully powered down? Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: time doesn't work?
On Fri, 12 Feb 2010, Xin LI wrote: Hi, Can anyone shed me some light? Can this be somehow related to some weird userland setting (sysctl, loader, etc?) I just realized that for some reason time doesn't work (both builtin, csh and /usr/bin/time). I'm running a unmodified fresh -CURRENT kernel and userland: FreeBSD pcbsd-5265 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r203800: Fri Feb 12 10:37:24 PST 2010 delp...@pcbsd-5265:/usr/obj/usr/src/sys/GENERIC amd64 === (See the '0.00u' stuff) and ignore the errors there. [delp...@pcbsd-5265]/mnt(112)% time gzip randomfile load: 0.85 cmd: gzip 8447 [running] 34.29r 0.00u 34.10s 98% 1476k /mnt: write failed, filesystem is full gzip: write: No space left on device gzip: output file: randomfile.gz wrong size (1673592832 != -1), deleting gzip: leaving original randomfile 0.000u 85.063s 1:25.10 99.9% 0+0k 12440+12839io 7pf+0w Does reverting r202387, 202441 and 202534 make any difference? Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysinstall spec_getpages panic (with VM overtones)
On Sun, 24 Aug 2003, Robert Watson wrote: Alan Cox just made a commit a couple of days ago that seems to resolve the problem for us. Here's the commit message so you can give it a try. [...] 1.208 +5 -2 src/sys/fs/specfs/spec_vnops.c I can confirm this fixes things for me too. Thanks all for the help, and sorry for the false alarm after the commit. Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall spec_getpages panic (with VM overtones)
On Wed, 20 Aug 2003, Robert Watson wrote:
On Wed, 20 Aug 2003, Gavin Atkinson wrote:
_mtx_lock_flags(0,0,c0529513,300,) at _mtx_lock_flags+0x43
spec_getpages(cce33b3c,54,0,cce33b2c,0) at spec_getpages+0x26c
ffs_getpages(cce33b80,0,c05459de,274,c05c63e0) at ffs_getpages+0x5f6
vnode_pager_getpages(c0bebafc,cce33c70,1,0,cce33c20) at
vnode_pager_getpages+0x73 vm_fault(c1259900,819b000,1,0,c12534c0) at
vm_fault+0x8e2 trap_pfault(cce33d48,1,819b004,200,819b004) at
trap_pfault+0x109 trap(2f,2f,2f,82e533c,0) at trap+0x1fc calltrap() at
calltrap+0x5
*c0529513 = /usr/src/sys/fs/specfs/spec_vnops.c, line 0x300 is line 768:
766 gotreqpage = 0;
767 VM_OBJECT_LOCK(vp-v_object);
768 vm_page_lock_queues();
769 for (i = 0, toff = 0; i pcount; i++, toff = nextoff) {
Is it ap-a_vp that's NULL, or vp-v_object that's NULL? vp is
dereferenced several times before that in the code, so if vp is really
NULL at line 767, we're probably talking about memory corruption. But if
vp-v_object is NULL, then it could be we're not creating a VM object
along some code path.
Although this panic is 100% reproducible during the initial install
through sysinstall, I have tried hard but can not reproduce this once the
system is installed and running multiuser, even by performing the same
actions within sysinstall. I have I have also tried without success to get
a crash dump of the panic, however after a fair bit of head scratching it
looks from a grep of the source code like the dumpdev loader variable
documented in loader(8) is not yet implemented... and as far as I can tell
there is no other way I can get the installer off CD to generate a dump.
I'm trying to make a release with extra debugging info, but won't be able
to test this until at least Wednesday or Thursday. What extra debugging
info would be useful? Who would be the best person to discuss this with?
From what kuriyama said, it appears that it is indeed vp-v_object that is
null, so I have added the following to specfs_vnops.c just before the lock
that fails:
if (vp-v_object == NULL)
panic(vp-v_object is null in %s, rdev=%s, __func__, devtoname(vp-v_rdev));
Hopefully that will help diagnose the cause a little further, but I'm
really working blind here - this is not an area of the kernel I understand
at all. If there is any other debugging info I can provide that may be
useful, I'm happy to have a go. Kuriyama, if you have any spare time
before I am able to do it, maybe you could add the above code and find out
what message it panics with?
Gavin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall spec_getpages panic
On Mon, 25 Aug 2003, Jun Kuriyama wrote: At Wed, 20 Aug 2003 17:01:30 + (UTC), Gavin Atkinson wrote: On the 8th August [EMAIL PROTECTED] mentioned he was getting a panic with FreeBSD inside VMware where _mtx_lock is being called with a NULL mutex from spec_getpages. This seems to be fixed by [EMAIL PROTECTED] I can install it on my VMware after this commit. alc 2003/08/22 10:50:32 PDT ... 1.208 +5 -2 src/sys/fs/specfs/spec_vnops.c Hmm, I totally missed this commit - I shall test a new snapshot as soon as I get a chance. Thanks, Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sysinstall spec_getpages panic
Hi,
On the 8th August [EMAIL PROTECTED] mentioned he was getting a panic
with FreeBSD inside VMware where _mtx_lock is being called with a NULL
mutex from spec_getpages. I'm also seeing this, 100% reproducible, on real
hardware. (see message ID [EMAIL PROTECTED] for the
original posters email and jhb's reply) For me, Sysinstall panics during
the extraction of the base package:
(note that I do not get to see a register dump)
kernel: type 12 trap, code=0
_mtx_lock_flags(0,0,c0529513,300,) at _mtx_lock_flags+0x43
spec_getpages(cce33b3c,54,0,cce33b2c,0) at spec_getpages+0x26c
ffs_getpages(cce33b80,0,c05459de,274,c05c63e0) at ffs_getpages+0x5f6
vnode_pager_getpages(c0bebafc,cce33c70,1,0,cce33c20) at vnode_pager_getpages+0x73
vm_fault(c1259900,819b000,1,0,c12534c0) at vm_fault+0x8e2
trap_pfault(cce33d48,1,819b004,200,819b004) at trap_pfault+0x109
trap(2f,2f,2f,82e533c,0) at trap+0x1fc
calltrap() at calltrap+0x5
I first noticed this with the 20030811 JPSNAP, but have tried with the 9th
July 2003 JPSNAP, and yesterdays snapshot, and see the same result on
both. I see the same panic whether installing over the net or from CD.
With 64 meg of ram, it panics half way through the read the chunks that
make up the base package, upping the ram to 256 allows it to read all of
the chunks before panicing.
*c0529513 = /usr/src/sys/fs/specfs/spec_vnops.c, line 0x300 is line 768:
766 gotreqpage = 0;
767 VM_OBJECT_LOCK(vp-v_object);
768 vm_page_lock_queues();
769 for (i = 0, toff = 0; i pcount; i++, toff = nextoff) {
so ap-a_vp is null. I'#m afraid that's the limit of my ddb ability.
Any suggestions as to where I should go from here? I don't really have the
facility at the moment to make release to test patches but will try to if
necessary.
Gavin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
On Fri, 8 Aug 2003, Soeren Schmidt wrote: ftp://ftp.deepcore.dk/pub/ATAng Before these rather radical changes to the ATA driver hits the tree, here is the opportunity to test them out, give usefull feedback and for the depending subsytems to adjust to the new ways of things (burncd atapicam are good examples). Hi, I'm using ATAng-20030809-1.tgz on top-of-tree current on hardware detected with the old ATA code as: atapci0: Intel ICH5 UDMA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: Intel ICH5 SATA150 controller port 0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 irq 10 at device 31.2 on pci0 ata2: at 0xec00 on atapci1 ata3: at 0xe400 on atapci1 ata1-master: timeout waiting for interrupt ata1-master: ATAPI identify failed ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 (ata1-master is a CD-ROM drive, and freebsd has been unable to detect it since I installed FreeBSD onto this machine about two weeks ago). With the new ATA code, the boot now hangs. I now get on a verbose bootup: ata1-master: FAILURE - ATAPI_IDENTIFY timeout ata1: resetting devices .. ata1: pre reset mask=03 ostat0=58 ostat2=00 ata1-master: ATAPI 14 EB ata1-slave: ATAPI 7F 7F ata1: after reset mask=03 stat0=10 stat1=00 ata1: devices=04 ata1-master: FAILURE - ATAPI_IDENTIFY status=1ERROR error=0 hang here db tr 0 mi_switch(...) msleep(...) ata_queue_request(...) ata_getparam(...) ata_identify_devices(...) ata_boot_attach(...) Unplugging the CD-ROM drive allows the machine to boot normally. Once booted, I keep seeing these messages relating to the S-ATA controller (which has no devices plugged into it): ata2: spurious interrupt - status=0x7f error=0xff reason=0xff ata3: spurious interrupt - status=0x7f error=0xff reason=0xff These are also new with the new ATA code. Hope that all helps, I can test any patches necessary. Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
On Wed, 13 Aug 2003, Soeren Schmidt wrote: It seems Gavin Atkinson wrote: With the new ATA code, the boot now hangs. I now get on a verbose bootup: ata1-master: FAILURE - ATAPI_IDENTIFY status=1ERROR error=0 Okies, what if you make that CDROM a slave ? That seems to work fine: ata1: spurious interrupt - status=0x7f error=0x7f reason=0x7f ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 acd0: CDROM SAMSUNG CD-ROM SC-152A at ata1-slave PIO4 Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
On Wed, 13 Aug 2003, Soeren Schmidt wrote: It seems Gavin Atkinson wrote: ata1: spurious interrupt - status=0x7f error=0x7f reason=0x7f ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 acd0: CDROM SAMSUNG CD-ROM SC-152A at ata1-slave PIO4 OK, your CDROM doesn't like to be a sole master it appears... I hate it when people respond with this, but I'm going to join them and say It works under Windows... Also, under the new code, this problem prevents the booting of the machine, but under the old code the machine carries on booting after giving up on the drive. Is it possible for this failure mode to not prevent the booting of the machine at least? Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
device puc on non-i386 or with parallel devices
Hi all, I'm currently working on updating the hardware release notes to reflect reality. the puc device is currently only in the i386 section of the release notes, however I am under the impression people are successfully using it with other platforms. Can anyone confirm this? Also, is anyone successfully using it to provide parallel port access? As far as I can tell, the device supports parallel ports, all the comments in the code suggests it does, however I can't find any mention of people using it for parallel ports and commit messages suggest it may be limited to serial ports only at the moment. Thanks! Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device puc on non-i386 or with parallel devices
On Sat, 5 Apr 2003, Gavin Atkinson wrote: Also, is anyone successfully using it to provide parallel port access? As far as I can tell, the device supports parallel ports, all the comments in the code suggests it does, however I can't find any mention of people using it for parallel ports and commit messages suggest it may be limited to serial ports only at the moment. Sorry for wasting bandwidth - I meant to delete this before sending. I can see from the source that the puc driver does not support parallel ports. Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another of my mailservers is being blocked by freebsd.org
On Thu, 23 Jan 2003, Hunter Peress wrote: Hi, I've been having to use this yahoo account because my normal email server *seems* to be blocked by freebsd.org: - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 450 txsmtp01.texas.rr.com: Helo command rejected: Host not found) The message tells you the answer - Host not found. wumpus# nslookup txsmtp01.texas.rr.com Server: xxx.yyy.co.uk Address: www.xxx.yyy.zzz *** xxx.yyy.co.uk can't find txsmtp01.texas.rr.com: Non-existent host/domain You need to get your reverse DNS sorted out. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bad ACPL asl's on motherboards
On Thu, 16 Jan 2003, David O'Brien wrote: I'm convinced that if we are going to keep insisting that ACPI is enabled by default, we need to gather the various fixed AML's and commit them to the tree. I can't decide if they should be ports, or in /usr/src. What are the copyright issues surrounding this? Presumably the original amls are copyright the bios manufacturer? Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic during ata_resume (sound)
Another panic. Kernel from 19th Dec. Laptop suspended itself (for no reason), and upon resume got this: (again, laptop could not manage to do the dump, so this is hand transcribed) wakeup from sleeping state (slept 00:02:53) ata0: resetting devices .. done ata1: resetting devices .. done Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fb093 stack pointer = 0x10:0xc874db48 frame pointer = 0x10:0xc874db68 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 = 13 (swi6: tty:sio clock) Stopped at _mtx_lock_flags + 0x43 cmpl $0xc03d16a0, 0(ebx) _mtx_lock_flags() at _mtx_lock_flags+0x43 mixer_reinit() at ds_ps_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() apm_resume() apm_processevent() apm_do_suspend() apm_timeout() softclock() ithread_loop() fork_exit() fork_trampoline() _mtx_lock_flags+0x43 corresponds to the compare of the line KASSERT(m-mtx_object.lo_class == lock_class_mtx_sleep, in kern_mutex.c. It looks like m == NULL. I can't get any more information sadly, again the machine hung while trying to reset ther ATA channel for the dump. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during ata_resume (sound)
On Wed, 1 Jan 2003, cameron grant wrote: _mtx_lock_flags() at _mtx_lock_flags+0x43 mixer_reinit() ds_ps_resume() bus_generic_resume() [snip] it would be helpful to have more information- dmesg, pcm static/preloaded kld/postboot kld, and if postboot, what else was the machine doing immediately prior to and during kldloading. also, had you used the mixer at all? Sorry - i meant to include more information (and indeed fix the subject line) but managed to forget in the post new-year haze. Dmesg is attached. The kernel has no sound support, sound modules are the only modules loaded from /boot/loader.conf: snd_pcm_load=YES snd_ds1_load=YES Sound and the mixer had not been used at all since the reboot, and nothing will have had the devices open during the suspend. The machine was not doing anything special, it runs apache, postgresql and sshd (all dormant), there was an ssh session active, and dnetc. X was not loaded. Uptime was probably less than 20 minutes. Nothing has changed with the laptop config recently, and it has successfully suspended/resumes hundreds of times before. Gavin FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Dec 18 23:32:24 GMT 2002) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x2bbb50 data=0x345d8+0x6528c syms=[0x4+0x397c0+0x4+0x45b23] /boot/kernel/snd_pcm.ko text=0x13708 data=0x2278+0x10a4 syms=[0x4+0x2950+0x4+0x2cd7] /boot/kernel/snd_ds1.ko text=0x408c data=0x647c syms=[0x4+0xa60+0x4+0xa0a] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2002 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 5.0-RC #10: Thu Dec 19 17:54:37 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON Preloaded elf kernel /boot/kernel/kernel at 0xc0502000. Preloaded userconfig_script /boot/kernel.conf at 0xc05020a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc05020f8. Preloaded elf module /boot/kernel/snd_ds1.ko at 0xc05021a4. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (547.31-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134086656 (127 MB) avail memory = 124833792 (119 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc0455ba2 (122) VESA: S3 Incorporated. M7 BIOS npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 9 entries at 0xc00f0190 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe000-0xe7ff at d evice 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 5.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfff0-0x at device 5.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xff80-0xff9f irq 11 at de vice 5.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 5.3 (no driver attached) pci0: simple comms at device 7.0 (no driver attached) pci0: unknown at device 9.0 (no driver attached) cbb0: ToPIC95B PCI-CardBus Bridge irq 11 at device 11.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: ToPIC95B PCI-CardBus Bridge irq 11 at device 11.1 on pci0 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcm0: Yamaha DS-1E (YMF744) port 0xfefc-0xfeff,0xff00-0xff3f mem 0xefff8000-0x efff irq 11 at device 12.0 on pci0 orm0: Option ROM at iomem 0xc-0xcbfff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f 0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300
5.0 devfs_lookupx panic w/dec 19 kernel
Hi, I don't think this will be of any use - i could not get a dump - but my system just panicked. background fsck was in progress. Here is the panic and backtrace: Dec 31 20:50:59 epsilon kernel: Fatal trap 12: page fault while in kernel mode Dec 31 20:50:59 epsilon kernel: fault virtual address = 0xe6d89 Dec 31 20:50:59 epsilon kernel: fault code = supervisor read, page not present Dec 31 20:50:59 epsilon kernel: instruction pointer = 0x8:0xc01bd059 Dec 31 20:50:59 epsilon kernel: stack pointer = 0x10:0xd12c27f8 Dec 31 20:50:59 epsilon kernel: frame pointer = 0x10:0xd12c28b0 Dec 31 20:50:59 epsilon kernel: code segment= base 0x0, limit 0xf, type 0x1b Dec 31 20:50:59 epsilon kernel: = DPL 0, pres 1, def32 1, gran 1 Dec 31 20:50:59 epsilon kernel: processor eflags= interrupt enabled, resume, IOPL = 0 Dec 31 20:50:59 epsilon kernel: current process = 560 (dnetc) Dec 31 20:50:59 epsilon kernel: panic: from debugger devfs_lookupx() devfs_lookup() lookup() namei() vn_open_cred() vn_open() kern_open() open() I could not get a dump - the machine hung after printing Dumping 127MB. Other than background fsck, there was only a single console login, a copy of screen, and a single outbound SSH. No X or anything else running. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 devfs_lookupx panic w/dec 19 kernel
On Tue, 31 Dec 2002, Gavin Atkinson wrote: Other than background fsck, there was only a single console login, a copy of screen, and a single outbound SSH. No X or anything else running. I only sent the email 5 minutes ago, and already two people have corrected me :) The distributed.net client was also running that the time, and a couple of background processes (apache, cvsupd and postgres) were loaded, but will have been dormant. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC2 install story
Hi all, I've just tested an install of 5.0-RC2 using the boot floppies FTP install method (from ftp3.uk.freebsd.org). The machine is a 1.8GHz P4 with an Intel 850MV2 motherboard. Overall the installation was successful, however: First time I booted the install disks, the machine hung on a sysinstall requester, Loading module if_awi.ko failed. Baystack 660 and others. Not even caps lock or scroll lock worked. I rebooted, checked the bios was setup correctly, never changed anything, and tried again. it worked. The drive was originally formatted NTFS, i deleted the whole partition and created a freebsd partition on the first half of the drive. I used the Auto option for the slices, and then manually split /usr into /usr and /usr/home. I performed a custom install, installing everything except kerberos and pre-4 compat. The install went well, however at the end of the install, every option I selected on the menu gave Couldn't stat dir /tmp. Bad file descriptor. Rebooted to find the same problem. I had to unmount it, newfs it, remount it and chmod it before it worked. I tried installing Gnome2, but the install couldn't find libgtkhtml-2.0.3 on the ftp mirror I was using. I grabbed it off the primary successfully. Similarly with the option to read online docs, lincs-0.98,1 could not be found on ftp3.uk.freebsd.org but was on ftp.freebsd.org. FreeBSD happily detected all my hardware, and seemed happy with everything. Xfree86 auto-config detected everything and worked fine. Worryingly, the game same-gnome died with a floating-point exception, which I haven't seen since all the FP problems last time. I won't be able to investigate this further until the new year. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic: memory modified after free
Hi,
Running 5.0-RC as of yesterday on i386. background fsck was in progress,
but other than that system was idle. Logged in as root on the console, had
cd'd to a ports directory. (note that it panics almost instantly when
using the console, but lasts upto 10 minutes when in use over ssh)
Running make deinstall triggered this panic:
Memory modified after free 0xc1891c00(1020)
panic: Most recently used by none
#10 0xc0204cfb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc032c7dd in mtrash_ctor (mem=0xc1891c00, size=0, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:138
#12 0xc032b1e7 in uma_zalloc_arg (zone=0xc0b653c0, udata=0x0, flags=0)
at /usr/src/sys/vm/uma_core.c:1358
#13 0xc01f95ad in malloc (size=6, type=0xc03cfb00, flags=0)
at /usr/src/sys/kern/kern_malloc.c:182
#14 0xc01df80c in exec_elf32_imgact (imgp=0xd0e18b88) at imgact_elf.c:804
#15 0xc01ec952 in kern_execve (td=0xc1924620, fname=---Can't read userspace from dump,
or kernel process---)
at /usr/src/sys/kern/kern_exec.c:313
#16 0xc01ed430 in execve (td=0x0, uap=0x0) at /usr/src/sys/kern/kern_exec.c:698
#17 0xc035f90e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135232232, tf_esi =
135232268, tf_ebp = -1077937688, tf_isp = -790524556, tf_ebx = 0, tf_edx =
135232268, tf_ecx = 135232303, tf_eax = 59, tf_trapno = 12, tf_err = 2,
tf_eip = 134723319, tf_cs = 31, tf_eflags = 642, tf_esp = -1077937716,
tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#18 0xc034faad in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
The machine seems perfectly stable in single user mode. It also seems
pretty stable at the moment with linux emulation, usbd, sendmail, ipv6,
nfs server and moused enables commented out of rc.conf. I will try to add
one at a time tonight to determine which is at fault.
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Panic: memory modified after free
On Thu, 19 Dec 2002, Gavin Atkinson wrote: Running 5.0-RC as of yesterday on i386. background fsck was in progress, but other than that system was idle. Logged in as root on the console, had cd'd to a ports directory. (note that it panics almost instantly when using the console, but lasts upto 10 minutes when in use over ssh) Running make deinstall triggered this panic: Memory modified after free 0xc1891c00(1020) panic: Most recently used by none [snip backtrace] The machine seems perfectly stable in single user mode. It also seems pretty stable at the moment with linux emulation, usbd, sendmail, ipv6, nfs server and moused enables commented out of rc.conf. I will try to add one at a time tonight to determine which is at fault. Update: I re-cvsupped (to 19 Dec 14:00 GMT) , and recompiled world and kernel. I can no longer cause the panic. I then (out of interest) dropped back to the old kernel that was panicing (18 Dec 12:00 GMT), but run with the new world, and could not recreate the panic. I therefore believe that one of the userland binaries that I replaced was tickling the bug, and now I have replaced that binary, the problem no longer occurs. So, unless anyone can think of a better reason for this, I suspect there is a kernel use-after-free bug laying dormant. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su(1) problem on -current
On Sun, 15 Dec 2002, David Malone wrote: On Sun, Dec 15, 2002 at 08:00:55PM +, Gavin Atkinson wrote: Confirmed. in su.c it seems that pam_authenticate is returning PAM_AUTH_ERR, when it presumably should not be doing so. Try getting rid of the auth_as_self in /etc/pam.d/su for the pam_wheel module. This fixes it. Although I don't understand why this wasn't needed until recently. Is there any reason to have the default pam su config contain auth_as_self? It just seems to introduce yet another (and quite annoying) incompatibility between 4.x and 5.x without achieving anything obvious. Maybe we could get auth_as_self removed from pam_wheel in /etc/pam.d/su? Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bpf lock order reversal
Just had this lock order reversal on a late-november kernel. Haven't seen it mentioned before. Dec 16 19:07:15 epsilon kernel: rl0: promiscuous mode enabled Dec 16 19:07:15 epsilon kernel: lock order reversal Dec 16 19:07:15 epsilon kernel: 1st 0xc0429cc0 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:375 Dec 16 19:07:15 epsilon kernel: 2nd 0xc296b9c4 rl0 (network driver) @ /usr/src/sys/pci/if_rl.c:1753 Dec 16 19:07:15 epsilon kernel: rl0: promiscuous mode disabled Is there any way I can set my machine to drop to debugger on any lock order reversal _other_ than sound-related LOR's? I realise these reversals are not as useful without a traceback, but as I use thismachine for playing audio Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su(1) problem on -current
On Sun, 15 Dec 2002, Craig Boston wrote: On a laptop running current, I have a problem using the su program multiple times (nested). (log in as auser) $ id uid=1002(auser) gid=1002(auser) groups=1002(auser) $ su - buser Password: $ id uid=1001(buser) gid=1001(buser) groups=1001(buser), 0(wheel) $ su - su: Sorry $ So, even though I'm in the wheel group after the first su, it won't let me su to root (doesn't even prompt for password). It seems to make no difference whether I use the -l option to su or not. Is this PAM related? Confirmed. in su.c it seems that pam_authenticate is returning PAM_AUTH_ERR, when it presumably should not be doing so. that's about all I can figure out, PAM is not an area I'm familiar with. 4.x does not have this problem. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: Anyone objects to this patch? Yes - this is the only place to put modules which are not built as part of the kernel, for example /usr/ports/comms/ltmdm. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: On Fri, 15 Nov 2002, Ruslan Ermilov wrote: Anyone objects to this patch? Yes - this is the only place to put modules which are not built as part of the kernel, for example /usr/ports/comms/ltmdm. This port puts it under /usr/local/share/ltmdm/ltmdm.ko. OK, it may have been a bad example, but I prefer having my kernel modules loaded via the standard loader.conf method rather than using kldload for modules which I always want to exist. /boot/modules has been documented as being in the search path for modules for ages now, it seems unnecessary to change this. I think that we do need somewhere on the root partition where modules can be kept, without them being lost on the next upgrade. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock order reversal
Just got this from a 17th October kernel, it does not look like it's been reported before. lock order reversal 1st 0xc21f5250 vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:945 2nd 0xc0409e80 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/vm/vm_kern.c:424 Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VESA 800x600 console not working
On Fri, 26 Jul 2002, David Xu wrote: Yes, this is a known problem. I have a patch for this, you may download it from here: http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz Is there any chance of geting these committed? With them, my laptop is happy to give a 100x37 screen on VESA_800x600. Gavin - Original Message - From: Rob [EMAIL PROTECTED] To: Current [EMAIL PROTECTED] Sent: Saturday, July 27, 2002 6:46 AM Having a laptop here, I wanted to get the same 800x600 console that I have in -stable. I built my kernel with OPTIONS VESA and OPTIONS SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080 in the device.hints file for SC. That gave me a blank screen upon startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol command vidcontrol -g 100x37 VESA_800x600. That gave me a blank screen at the end of the bootup. Is this functionality broken in -current, or am I doing something wrong? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI no longer disabled when APM enabled?
On Thu, 29 Aug 2002, Gavin Atkinson wrote:
Since the recent ACPI import (i believe), it seems that ACPI is no longer
disabled when APM is enabled. I do not explicitely disable API anywhere.
In the past, I have seen upon bootup a message apm: Other PM system
enabled. and the kernel would carry on booting as if ACPI had not been
loaded.
As a follow-up to this... adding the hint hint.acpi.0.disable=1 fixes
the suspend problems, but produces the following error messages on
boot-up:
unknown: PNP0303 can't assign resources (port)
unknown: PNP0f13 can't assign resources (irq)
unknown: PNP0700 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0401 can't assign resources (port)
These only exist with the acpi hint above. Removing the hint and
reverting to a previous kernel (where ACPI is disabled because APM is
enabled) shows them with the hint in place too, but obviously acpi is not
enabled then. I have confirmed that this is new with the latest acpi
import.
The recent heads-up about hw.acpi.0.disable=1 has not fixed the problem
I am seeing.
Those ISA PNP IDs correspond to,
/usr/src/sys/isa/atkbdc_isa.c: { 0x0303d041, Keyboard controller (i8042) },/*
PNP0303 */
/usr/src/sys/boot/common/pnpdata:ident=PNP0700 module=fd # PC standard
floppy disk controller
/usr/src/sys/boot/common/pnpdata:ident=PNP0501 module=sio#
16550A-compatible COM port
/usr/src/sys/boot/common/pnpdata:ident=PNP0401 module=lpt# ECP printer port
/usr/src/sys/isa/psm.c: { 0x130fd041, PS/2 mouse port }, /* PNP0F13 */
These devices seem to work fine however.
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ACPI no longer disabled when APM enabled?
Hi, Since the recent ACPI import (i believe), it seems that ACPI is no longer disabled when APM is enabled. I do not explicitely disable API anywhere, I have the following configuration: device.hints: hint.apm.0.at=nexus hint.apm.0.flags=0x20 kernel config file: device apm device pmtimer In the past, I have seen upon bootup a message apm: Other PM system enabled. and the kernel would carry on booting as if ACPI had not been loaded. Now I see the following: FreeBSD 5.0-CURRENT #15: Thu Aug 29 16:54:05 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON Preloaded elf module /boot/kernel/acpi.ko at 0xc05742fc. ... apm: Other PM system enabled. acpi0: TOSHIB 750 on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib1: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 ... acpi_lid0: Control Method Lid Switch on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 etc. Although apm -z still seems to work as expected, closing the lid causes havoc with my IDE controller (i guess it's no real suprise given APM and ACPI are fighting over what to do). I can do a binary search of commits if required, but am pretty certain this is new within the last three days. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
100% reproducable hang: serial related
Hi, [bde cc'd - it seems to be sio related] I have an i386 toshiba laptop, running FreeBSD 5.0-CURRENT #4: Sat Aug 10 13:27:55 BST 2002. I can get a 100% reproducible hang by doing the following: - Connect a serial cable between my laptop and a PC - run tip -9600 com1 (where com1 in /etc/remote is the default: com1:dv=/dev/cuaa0:br#9600:pa=none:) - power down the PC. My laptop hangs solid, and DDB cannot be entered from the keyboard. Note that if I close tip before powering down the PC, i don't get a hang. I am not using ACPI. Interestingly, if I type something and then power up the PC again, that character will echo on the screen before locking up again. By power-cycling the PC frequently, i could actually carry on using my laptop. Power cycling the PC (either on-off or off-on) seems to unlock the laptop for a fraction of a second. I can also hold ctrl-alt-escape on my laptop, and power up or down the PC, which will drop my laptop into DDB. From that point on, ddb works fine, continuing back to userspace works fine, and my laptop is no longer hung. Note however that often, from this point on until I quit tip, all characters I send seem to be sent as uppercase. Is it possible that the serial driver is getting confused, and the entry into DDB is causing the hardware and/or some lock to be reset? Can I get any other information to help diagnose this problem? while in DDB during the hang, a show locks gives: exclusive sleep mutex Giant r=0 (0xc0389d60) locked @ /usr/src/sys/kern/kern_intr.c:535 though I guess this is due to the keyboard event interrupt. As this is 100% reproducible, i am able to test anything people want testing. Thanks, Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ftpd problem: Input/output error
Hi, For a few months now I have been seeing the following problems with the ftpd in current. When transferring a large file, ftpd seems to consistantly fail after almost all of the file hass been transferred. The example transcript below shows all but 4096 bytes of a file being transferred before stopping. This also happens across networks, with 4-stable ftp clients - i am confident that it is the ftp server in current. gavin@epsilon:/home/gavin grep ^ftp /etc/inetd.conf ftp stream tcp nowait root/usr/libexec/ftpd ftpd -ll gavin@epsilon:/home/gavin ls -l foo -rw--- 1 gavin users 31969280 Aug 4 18:19 foo gavin@epsilon:/home/gavin ftp localhost Trying ::1... ftp: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. 220 epsilon.ury.york.ac.uk FTP server (Version 6.00LS) ready. Name (localhost:gavin): 331 Password required for gavin. Password: 230 User gavin logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp lcd test Local directory now /usr/home/gavin/test ftp get foo local: foo remote: foo 229 Entering Extended Passive Mode (|||49152|) 150 Opening BINARY mode data connection for 'foo' (31969280 bytes). 99% | | 31216 KB3.25 MB/s00:09 426 Data connection: Input/output error. 31965184 bytes received in 00:09 (3.25 MB/s) ftp gavin@epsilon:/home/gavin ls -l test/foo -rw-r--r-- 1 gavin users 31965184 Aug 4 18:19 test/foo epsilon# tail -3 /var/log/ftp.log Aug 10 14:28:28 epsilon ftpd[345]: connection from localhost (127.0.0.1) Aug 10 14:29:03 epsilon ftpd[345]: FTP LOGIN FROM localhost as gavin Aug 10 14:29:36 epsilon ftpd[345]: get /usr/home/gavin/foo = 31965184 bytes As can be seen, the file is 31969280 bytes in size, but ftpd only sends 31963184 bytes. The log file reads the smaller size. World and kernel are from source supped midnight GMT 10th August. I can help debug this or provide an account for someone else to look at this problem. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: KSE: not on run queue
On Sat, 27 Jul 2002, Julian Elischer wrote: On Sun, 28 Jul 2002, Gavin Atkinson wrote: Had this panic twice with current -current on an uniprocessor machine and kernel. Dumps still don't work... Both occurances, i had an ssh running, a portupgrade in progress, and the dnetc client running in the background. how new is the kernel? When you created it did you make sure you deleted all .o files first? Source was supped 26th july 1am (gmt). Kernel and world were built at the same time with make clean buildworld buildkernel. I was running portupgrade -RaO at the time, and two of the three panics were at the same point - after portupgrade has performed the pre-build clean, and has printed: --- Upgrading 'xxx' to 'xxx' (xxx) --- Building '/usr/ports/xxx' panic:... (xxx was gnomevfs the first time, and sawfish the second) I'll check it in a while but the fact that only you cave sen thid does suggest that maybe you have some mixed versions or something I will blow away the whole /usr/obj and recompile with fresh source. Thanks Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A fix of recent bugs in swapping in/out a process
On Sun, 28 Jul 2002, Seigo Tanimura wrote: If you are having a trouble of a broken thread state (eg a thread with TDS_RUNQ on no run queue) or a mysterious page fault on a kernel memory (probably in mi_switch()), you may want to try my patch at: http://people.FreeBSD.org/~tanimura/patches/procswap.diff.gz I applied this patch a few hours ago and have not had a panic since, even though the box has been used a lot and has been swapping a lot. It looks like this has fixed my problem. Thanks! gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: KSE: not on run queue
hi, FreeBSD epsilon.ury.york.ac.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Fri Jul 26 13:32:52 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON i386 Had this panic twice with current -current on an uniprocessor machine and kernel. Dumps still don't work... Both occurances, i had an ssh running, a portupgrade in progress, and the dnetc client running in the background. panic: KSE not on run queue panic: from debugger Uptime: 1d1h26m12s Dumping 127 MB ata0: resetting devices .. panic: mi_switch: switch in a critical section Uptime: 1d1h26m12s panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s ...etc... traceback from ddb is: panic runq_remove remrunqueue schedcpu softclock thread_loop forkexit forktrampoline Thanks Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New suspend/resume panic on new current?
Hi, I just got this panic on current source supped midnight GMT 26th July (today...). I haven't seen anyone else mention this, it happened when i ran 'fg' in a tcsh root shell. System dropped to debugger, i typed 'panic' but it couldn't dump to disk, it printed the _sx_xlock panic below many times then rebooted. panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206 panic: from debugger Uptime: 2h40m47s Dumping 127 MB ata0: resetting devices .. panic: msleep Uptime: 2h40m47s panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341
Re: Xircom RBEM56G-100 on Dell Latitude C600
On Sun, 21 Jul 2002, Andrzej Kwiatkowski wrote: Can anyone help me ? I've got Dell Latitude C600 Notebook with this PCMCIA Card. But i can't use this card because it isn't recognized by my System. Product version: 5.0 Product name: Xircom | CardBus Ethernet 10/100 + Modem 56 | CBEM56G | 1.03 Manufacturer ID: 0501030181 Functions: Network Adaptor, Multi-Functioned Function Extension: 04060010a47ad327 Function Extension: 0102 Function Extension: 0280969800 Function Extension: 0200e1f505 Function Extension: 0301 Function Extension: 0303 Function Extension: 0501 cardbus0: Invalid BAR number: 27(06) CIS reading done dc0: Xircom X3201 10/100BaseTX port 0x1000-0x107f mem 0x84002000-0x840020ff,0x84002100-0x8400217f irq 11 at device 0.0 on cardbus0 dc0: Ethernet address: 55:2b:21:02:06:00 dc0: MII without any PHY! device_probe_and_attach: dc0 attach returned 6 This is the network card part of the card failing to attach. It's a known problem, see http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1068910+0+archive/2002/freebsd-current/20020331.freebsd-current As far as I can tell, there are three revisions of this card. Revision 3 fails to attach, revision 1 works, and I haven't been able to find a revision 2 card to test. Product version: 5.0 Product name: Xircom | CardBus Ethernet 10/100 + Modem 56 | CBEM56G | 1.03 Manufacturer ID: 0501001081 Functions: Serial Port, Multi-Functioned Function Extension: 00020f5c Function Extension: 0206003f1c03030f070001b5 Function Extension: 1306000b000200b5 cardbus0: Invalid BAR number: 27(06) CIS reading done cardbus0: unknown card (vendor=0x115d, dev=0x0103) at 0.1 irq 11 pccbb0: CardBus card activation failed I don't really understand whats going wrong here. Do you have sio in your kerenl? This card is listed in src/sys/dev/sio/sio_pci.c on my system, see if it is on yours (search for 0103115d in the file) Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getting vmemoryuse resource limit: Invalid argument
Getting this since updating kernel/word to a cvsup a couple of days ago. Jul 18 09:21:24 epsilon login: getting vmemoryuse resource limit: Invalid argument Jul 18 09:22:00 epsilon /usr/sbin/cron[342]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:25:00 epsilon /usr/sbin/cron[355]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:30:00 epsilon /usr/sbin/cron[359]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:33:00 epsilon /usr/sbin/cron[363]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:34:26 epsilon sshd[367]: getting vmemoryuse resource limit: Invalid argument Jul 18 09:33:00 epsilon /usr/sbin/cron[369]: getting vmemoryuse resource limit: Invalid argument Previously working kernel was cvsupped June 23rd. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic on apm resume with ata
Hi, My laptop powered off due to a flat battery, and upon powerup, i immediately experienced a panic. ata0: resetting devices .. done panic: ata_dmasetup: transfer active on this device! #16 0xc01dd9e1 in panic () at /usr/src/sys/kern/kern_shutdown.c:490 #17 0xc0146428 in ata_dmastart (atadev=0x0, data=0xc55cf000 $\201\001, count=16384, dir=0) at /usr/src/sys/dev/ata/ata-dma.c:1287 #18 0xc0147dc7 in ad_transfer (request=0xc226cac0) at /usr/src/sys/dev/ata/ata-disk.c:490 #19 0xc013bd37 in ata_start (ch=0xc0b7e400) at /usr/src/sys/dev/ata/ata-all.c:678 #20 0xc013c6fd in ata_reinit (ch=0xc0b7e400) at /usr/src/sys/dev/ata/ata-all.c:921 #21 0xc013b213 in ata_resume (dev=0xc1863b80) at /usr/src/sys/dev/ata/ata-all.c:272 #22 0xc01eaf53 in bus_generic_resume (dev=0x0) at device_if.h:75 #23 0xc01eaf53 in bus_generic_resume (dev=0x0) at device_if.h:75 #24 0xc01eaf53 in bus_generic_resume (dev=0x0) at device_if.h:75 #25 0xc01eaf53 in bus_generic_resume (dev=0x0) at device_if.h:75 #26 0xc01eaf53 in bus_generic_resume (dev=0x0) at device_if.h:75 #27 0xc02e1983 in apm_resume () at device_if.h:75 #28 0xc02e21ef in apm_processevent () at /usr/src/sys/i386/apm/apm.c:983 #29 0xc02e175d in apm_do_suspend () at /usr/src/sys/i386/apm/apm.c:432 #30 0xc02e1bf0 in apm_timeout (dummy=0x0) at /usr/src/sys/i386/apm/apm.c:690 #31 0xc01e60bd in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:187 #32 0xc01ceee8 in ithread_loop (arg=0xc0b7d500) at /usr/src/sys/kern/kern_intr.c:534 #33 0xc01ce3b4 in fork_exit (callout=0xc01cedc8 ithread_loop, arg=0xc0b7d500, frame=0xc8d13d48) at /usr/src/sys/kern/kern_fork.c:830 I have a core file, if anyone wants to see it. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Laptop hangs with recent kernel
Hi all, I have a laptop running -CURRENT. A kernek dated June 10th works well, however I am experiencing hangs with a kernel dated 24th June. These hangs usually occur when closing a serial port (eg quitting tip) or when executing an 'apm -z' command. I have not yet tried to find the commit that caused it, as the hangs only happen once or twice a day. Breaking to the debugger is not possible. I'm going to try backing out the recent pcmcia changes (as it has a topic chipset) unless anyone can suggest anything else. However the hang is random, so it may be hard to know if the back-out it fixes it. Gavin Copyright (c) 1992-2002 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 5.0-CURRENT #3: Mon Jun 24 16:12:29 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON Preloaded elf kernel /boot/kernel/kernel at 0xc055d000. Preloaded userconfig_script /boot/kernel.conf at 0xc055d0a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc055d0f8. Preloaded elf module /boot/kernel/snd_ds1.ko at 0xc055d1a4. Preloaded elf module /boot/modules/ltmdm.ko at 0xc055d250. Preloaded elf module /boot/kernel/acpi.ko at 0xc055d2fc. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (547.32-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134086656 (130944K bytes) avail memory = 124485632 (121568K bytes) Pentium Pro MTRR support enabled VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc04065c2 (122) VESA: S3 Incorporated. M7 BIOS Using $PIR table, 9 entries at 0xc00f0190 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface acpi0: Other PM system enabled. pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 5.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfff0-0x at device 5.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xff80-0xff9f irq 11 at device 5.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 5.3 (no driver attached) ltmdm0: Lucent Winmodem port 0x1c00-0x1cff,0x2f8-0x2ff mem 0xffefff00-0xffef irq 3 at device 7.0 on pci0 ltmdm0: type Virtual 16550A pci0: unknown at device 9.0 (no driver attached) pccbb0: ToPIC95B PCI-CardBus Bridge irq 11 at device 11.0 on pci0 cardbus0: CardBus bus on pccbb0 pccard0: 16-bit PCCard bus on pccbb0 pccbb1: ToPIC95B PCI-CardBus Bridge irq 11 at device 11.1 on pci0 cardbus1: CardBus bus on pccbb1 pccard1: 16-bit PCCard bus on pccbb1 pcm0: Yamaha DS-1E (YMF744) port 0xfefc-0xfeff,0xff00-0xff3f mem 0xefff8000-0xefff irq 11 at device 12.0 on pci0
Re: Please test PAUSE on non-Intel processors
On Fri, 24 May 2002, John Baldwin wrote: Hey gang, although Intel's document seems to claim that they tested proper operation of pause I'd like people with non-Intel processors to verify that it actually works. Please compile the attached test program and run it. The only non-intel or AMD hardware I have access to is a debian linux box with a Cyrix 233 processor. gavin@gaspode:~$ cat /proc/cpuinfo vendor_id : CyrixInstead cpu family : 6 model : 2 model name : M II 3.5x Core/Bus Clock stepping: 8 cpu MHz : 233.863 flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr gavin@gaspode:~$ ./a.out Testing PAUSE instruction: Register esp changed: 0xbd68 - 0xbd2c gavin@gaspode:~$ So no problem there. Hope that's useful. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with wi and tcpdump?
On Thu, 23 May 2002, John Angelmo wrote: Another thin I noticed is that dhclient went nuts and started to use 100% CPU untill I killed it. Yes - this issue is known about. There are two patches on the stable list posted last friday, both of which fix the issue for me. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SRA login failed -- bug?
On Sun, 19 May 2002, Marcel Moolenaar wrote: I sometimes cannot get passed SRA secure login, even though credentials are given correctly: Connected to athlon.pn.xcllnt.net. Escape character is '^]'. Trying SRA secure login: User (marcel): Password: [ SRA login failed ] : (repeat last 3 lines -- Ad nauseam) I haven't seen anything on this topic, so I'd like to hear if others are experiencing this as well and if this is a security feature, a bug or misconfiguration. I see this as well - on both -STABLE and -CURRENT. I do you have two accounts you can try? I generally find that while the SRA login will refuse one account, a different account can log in fine, without reconnecting the telnet. I'm glad someone else has seen this, i thought i was going mad... Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Strange panic while dumping userspace core file
Hi, On this machine i'm running -CURRENT from around the end of april, so apologies if this has already been corrected, however i haven't seen anything similar reported before. Panic while writing a core file for a program that died on signal 11. Toshiba laptop, usually perfectly stable, resumed from suspend about two minutes before and was in the process of loading KDE... This panic has only ever happened once. there were lots of errors about calcru being negetive on the console and ATA interrupts arriving early, immediately before the panic. There was also a brief arcing type sound from the speakers as KDE loaded, 10 seconds before the panic. Console log, dmesg and backtrace attached. I'll keep the core file if anyone wants to see it or wants any information from it. Gavin /var/log/messages May 17 10:16:25 epsilon kernel: wakeup from sleeping state (slept 12:37:54) May 17 10:16:25 epsilon kernel: ata0: resetting devices .. done May 17 10:16:25 epsilon kernel: ata1: resetting devices .. done May 17 10:16:25 epsilon kernel: system power profile changed to 'economy' May 17 10:16:40 epsilon kernel: ep0: 3Com 3c589 10Mbps Ethernet at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 May 17 10:16:40 epsilon kernel: ep0: Ethernet address 00:a0:24:e3:3c:c6 May 17 10:17:21 epsilon kernel: system power profile changed to 'performance' May 17 10:18:28 epsilon kernel: lock order reversal May 17 10:18:28 epsilon kernel: 1st 0xc8e08580 pcm0 (sound softc) /usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:134 May 17 10:18:28 epsilon kernel: 2nd 0xc8e510c0 pcm0:play:0 (pcm channel) /usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/channel.c:441 May 17 10:18:31 epsilon kernel: calcru: negative time of -388077 usec for pid 2498 (artsd) May 17 10:19:37 epsilon kernel: calcru: negative time of -376553 usec for pid 2498 (artsd) May 17 10:19:39 epsilon kernel: calcru: negative time of -1491358277 usec for pid 245 (dnetc) May 17 10:19:40 epsilon kernel: calcru: negative time of -1491302617 usec for pid 245 (dnetc) May 17 10:19:40 epsilon kernel: calcru: negative time of -1491290967 usec for pid 245 (dnetc) May 17 10:19:40 epsilon kernel: calcru: negative time of -1491842832 usec for pid 245 (dnetc) May 17 10:20:20 epsilon kernel: calcru: negative time of -1492962087 usec for pid 245 (dnetc) May 17 10:20:54 epsilon kernel: calcru: negative time of -1492922647 usec for pid 245 (dnetc) May 17 10:20:54 epsilon kernel: calcru: negative time of -1493441241 usec for pid 245 (dnetc) May 17 10:20:54 epsilon kernel: calcru: negative time of -1493462215 usec for pid 245 (dnetc) May 17 10:20:54 epsilon kernel: calcru: negative time of -1493403019 usec for pid 245 (dnetc) May 17 10:21:41 epsilon syslogd: kernel boot file is /boot/kernel/kernel May 17 10:21:41 epsilon kernel: 534 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1705561199 usec for pid 245 (dnetc) [~100 similar lines snipped] May 17 10:21:41 epsilon kernel: ad0: READ command timeout tag=0 serv=0 - resetting May 17 10:21:41 epsilon kernel: ata0: resetting devices .. done May 17 10:21:41 epsilon kernel: ad0: read interrupt arrived earlyad0: read error detected (too) latespec_getpages:(ad0s1g) I/O read failure: (error=5) bp 0xc3ffce70 vp 0xc939ca50 May 17 10:21:41 epsilon kernel: size: 40960, resid: 16384, a_count: 40960, valid: 0x0 May 17 10:21:41 epsilon kernel: nread: 24576, reqpage: 7, pindex: 79, pcount: 10 May 17 10:21:41 epsilon kernel: vm_fault: pager read error, pid 2503 (kdeinit) May 17 10:21:41 epsilon kernel: calcru: negative time of -1750099965 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1750645169 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1752260850 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1752238389 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1752822526 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1752717624 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1244498 usec for pid 2498 (artsd) May 17 10:21:41 epsilon kernel: calcru: negative time of -1235784 usec for pid 2498 (artsd) May 17 10:21:41 epsilon kernel: calcru: negative time of -1753302582 usec for pid 245 (dnetc) May 17 10:21:41 epsilon kernel: calcru: negative time of -1753272571 usec for pid 245 (dnetc) [~100 similar lines snipped] May 17 10:21:42 epsilon kernel: ad0: WRITE command timeout tag=0 serv=0 - resetting May 17 10:21:42 epsilon kernel: ata0: resetting devices .. done May 17 10:21:42 epsilon kernel: calcru: negative time of -1193253 usec for pid 2498 (artsd) May 17 10:21:42 epsilon kernel: calcru: negative time of -1187881 usec for pid 2498 (artsd) May 17 10:21:42 epsilon kernel: panic: ffs_clusteralloc: map mismatch May 17
Re: Strange panic while dumping userspace core file
On Fri, 17 May 2002, Gavin Atkinson wrote: Panic while writing a core file for a program that died on signal 11. Toshiba laptop, usually perfectly stable, resumed from suspend about two minutes before and was in the process of loading KDE... This panic has only ever happened once. there were lots of errors about calcru being negetive on the console and ATA interrupts arriving early, immediately before the panic. I should probablt also point out that the messages about being unable to read the hard drive were a one-off. I suspect that they were a symptom of the overall problems (whatever it is), rather than a cause, although I realise that ultimately they could be responsible for the panic. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sound lock order reversal
I get this when starting mpg123 about 50% of the time: lock order reversal 1st 0xc8e22f40 pcm0:play:0 @ /usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/dsp.c:150 2nd 0xc8e24380 pcm0 @ /usr/src/sys/modules/sound/pcm/../../../dev/sound/pcm/sound.c:134 -current as of yesterday, using the ds1 driver loaded via loader.conf Probably unrelated, but I also get audible clicks on playback when I move the mouse in console mode (using moused). relevent dmesg: pcm0: Yamaha DS-1E (YMF744) port 0xfefc-0xfeff,0xff00-0xff3f mem 0xefff8000-0xefff irq 11 at device 12.0 on pci0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with FreeBSD dc driver and Xircom PCMCIA card
Hi,
(This email was originally sent to wpaul directly, without response. I'm
hoping a wider distribution may help to solve my problem)
I have a Xircom RBE-100 RealPort CardBus Ethernet 10/100 PCMCIA card,
which is not working correctly under 5.0-CURRENT. With the driver
unmodified, I get the following:
dc0: Xircom X3201 10/100BaseTX port 0x1000-0x107f mem
0x84002000-0x840020ff,0x84002000-0x8400207f irq 11 at device 0.0 on cardbus0
dc0: Ethernet address: 02:06:00:22:08:04
dc0: MII without any PHY!
device_probe_and_attach: dc0 attach returned 6
pccbb0: CardBus card activation failed
After probing around in the code, I decided to start trying things which
looked like possible candidates to be changed. After discovering that
forcing sc-dc_pmode to DC_PMODE_SYM helped, I tried the following:
--- if_dc.c.old Wed Jan 16 16:33:58 2002
+++ if_dc.c Sun Mar 17 22:25:02 2002
@@ -1989,7 +1989,7 @@
* The tricky ones are the Macronix/PNIC II and the
* Intel 21143.
*/
- if (DC_IS_INTEL(sc))
+ if (DC_IS_INTEL(sc) || DC_IS_XIRCOM(sc))
dc_parse_21143_srom(sc);
else if (DC_IS_MACRONIX(sc) || DC_IS_PNICII(sc)) {
if (sc-dc_type == DC_TYPE_98713)
This now produces the following output:
dc0: Xircom X3201 10/100BaseTX port 0x1000-0x107f mem
0x84002000-0x840020ff,0x84002100-0x8400217f irq 11 at device 0.0 on cardbus0
dc0: Ethernet address: 02:06:00:22:08:04
miibus0: MII bus on dc0
dcphy0: Intel 21143 NWAY media interface on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
It's starting to look promising. I even get a (red) link light on the
card, and once an IP is configured, ifconfig can tell if the link exists
or not, though cannot establish what the speed of it is (this is into a
100M switch). However, I still have almost no network connectivity with
it. An outbound ping loses 100% of packets, and hosts trying to ping it
cannot arp it's MAC address. However, once I have forced an entry into the
arp table of the second host, I can ping the Xircom card, albeit very
slowly (snipped down for clarity):
PING epsilon.ury.york.ac.uk (10.0.0.109): 56 data bytes
64 bytes from 10.0.0.109: icmp_seq=211 ttl=64 time=2020.368 ms
64 bytes from 10.0.0.109: icmp_seq=216 ttl=64 time=3030.348 ms
64 bytes from 10.0.0.109: icmp_seq=217 ttl=64 time=2020.406 ms
64 bytes from 10.0.0.109: icmp_seq=223 ttl=64 time=2020.374 ms
64 bytes from 10.0.0.109: icmp_seq=229 ttl=64 time=2020.374 ms
64 bytes from 10.0.0.109: icmp_seq=253 ttl=64 time=7070.335 ms
64 bytes from 10.0.0.109: icmp_seq=255 ttl=64 time=5050.412 ms
64 bytes from 10.0.0.109: icmp_seq=286 ttl=64 time=6060.318 ms
64 bytes from 10.0.0.109: icmp_seq=287 ttl=64 time=5050.348 ms
64 bytes from 10.0.0.109: icmp_seq=288 ttl=64 time=4040.382 ms
--- epsilon.ury.york.ac.uk ping statistics ---
311 packets transmitted, 139 packets received, 55% packet loss
round-trip min/avg/max/stddev = 614.382/5760.691/9090.237/2161.803 ms
Note the large mean time, and the fact that I consistantly lose 55% of
packets. Watching the link light, the card seems to receive the packets
instantly, buffer three or four, then lose the link. WHen the link comes
back, the replies to these packets all get sent back at once.
I'm now at a loss as to where to go. I have no idea how to progress with
this, as i'm not a kernel hacker. Has anyone seen this before? If it
helps, I am using revision 3 of the card (read using
pci_read_config(dev, DC_PCI_CFRV, 4) 0xff), and it's on a Toshiba ToPIC
95B cardbus bridge.
If anyone can help, i'd be most greatful...
Thanks,
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kernel build failure in amr
Hi, Without -DNO_WERROR, i sometimes get a build failure on CURRENT sources, as shown below. However, this does not always occur, maybe 30% of the compiles succeed. Why would it sometimes compile fine? I've deleted my /usr/obj and /usr/src, and even my cvs repositry, without success.# Gavin cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 -Werror /usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /usr/src/sys/dev/amr/amr.c: In function `amr_bio_command': /usr/src/sys/dev/amr/amr.c:817: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. epsilon# To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panics with CardBus
On Thu, 14 Mar 2002, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Gavin Atkinson [EMAIL PROTECTED] writes:
: The patches never fixed one of the panics I see, with a GlobalVillage
: Ethernet/Modem card. The kernel still traps with a page fault in
: pccard_scan_cis, however with the patches, this now nanifests itself with
: the panic message vm_fault: fault on nofault entry.
The pccard_scan_cis stuff is due to a memory mapping problem that I'm
seeing on some cards. :-(.
I'm reverting back to an earlier version of the cardbus code for teh
DP1 release and then trying again after DP1 is out.
With the reverted code, I still have th3e same panic problems. (see below)
I'm in no rush for this to work, it's only my backup modem, but if I can
help in any way, feel free to contact me off list.
Gavin
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x004e8000
initial pcb at physical address 0x003d0f00
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc9a3
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01869d0
stack pointer = 0x10:0xc8d12a18
frame pointer = 0x10:0xc8d12c0c
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 = 2 (pccbb0)
panic: from debugger
panic: from debugger
Uptime: 17s
pfs_vncache_unload(): 1 entries remaining
dumping to dev ad0s1b, offset 454912
dump ata0: resetting devices .. done
127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107
106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52
51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:505
505 if (!dodump)
(kgdb) where
[snipped stuff inside debugger]
#10 0xc030803b in trap (frame={tf_fs = -1062010856, tf_es = -925827056,
tf_ds = -1072168944, tf_edi = 0, tf_esi = -1048517120,
tf_ebp = -925815796, tf_isp = -925816316, tf_ebx = -1049120432,
tf_edx = -912068608, tf_ecx = -1047923136, tf_eax = 4096,
tf_trapno = 12, tf_err = 0, tf_eip = -1072141872, tf_cs = 8,
tf_eflags = 66050, tf_esp = -1049120344, tf_ss = -1048517120})
at /usr/src/sys/i386/i386/trap.c:433
---Type return to continue, or q return to quit---
#11 0xc01869d0 in pccard_scan_cis (dev=0xc1816a80,
fct=0xc0187810 pccard_parse_cis_tuple, arg=0xc8d12c20)
at machine/bus_at386.h:202
#12 0xc0186861 in pccard_read_cis (sc=0xc0b3d000)
at /usr/src/sys/dev/pccard/pccard_cis.c:99
#13 0xc0184ddd in pccard_attach_card (dev=0xc1816a80)
at /usr/src/sys/dev/pccard/pccard.c:160
#14 0xc018b5a2 in pccbb_insert (sc=0xc0b3d200) at card_if.h:67
#15 0xc018b421 in pccbb_event_thread (arg=0xc0b3d200)
at /usr/src/sys/dev/pccbb/pccbb.c:867
#16 0xc01dfce4 in fork_exit (callout=0xc018b3c4 pccbb_event_thread,
arg=0xc0b3d200, frame=0xc8d12d48) at /usr/src/sys/kern/kern_fork.c:799
(kgdb) f 11
#11 0xc01869d0 in pccard_scan_cis (dev=0xc1816a80,
fct=0xc0187810 pccard_parse_cis_tuple, arg=0xc8d12c20)
at machine/bus_at386.h:202
202 return (inb(handle + offset));
(kgdb) l
197 {
198 #if defined (_I386_BUS_PIO_H_)
199 #if defined (_I386_BUS_MEMIO_H_)
200 if (tag == I386_BUS_SPACE_IO)
201 #endif
202 return (inb(handle + offset));
203 #endif
204 #if defined (_I386_BUS_MEMIO_H_)
205 return (*(volatile u_int8_t *)(handle + offset));
206 #endif
(kgdb) p handle
$1 = 0
(kgdb) p offset
$2 = 0
(kgdb) up
#12 0xc0186861 in pccard_read_cis (sc=0xc0b3d000)
at /usr/src/sys/dev/pccard/pccard_cis.c:99
99 if (pccard_scan_cis(sc-dev, pccard_parse_cis_tuple,
(kgdb) l
94 state.card-product = PCMCIA_PRODUCT_INVALID;
95 STAILQ_INIT(state.card-pf_head);
96
97 state.pf = NULL;
98
99 if (pccard_scan_cis(sc-dev, pccard_parse_cis_tuple,
100 state) == -1)
101 state.card-error++;
102 }
103
(kgdb) l -
84 state.card = sc-card;
85
86 state.card-error = 0;
87 state.card-cis1_major = -1;
88 state.card-cis1_minor = -1;
89 state.card-cis1_info[0
Re: panics with CardBus
On Mon, 11 Mar 2002, M. Warner Losh wrote: John Baldwin also cornered me about these panics. I'll be looking at them tonight. I think he gave me a good way to recreate them. The patches never fixed one of the panics I see, with a GlobalVillage Ethernet/Modem card. The kernel still traps with a page fault in pccard_scan_cis, however with the patches, this now nanifests itself with the panic message vm_fault: fault on nofault entry. I am more than happy to help debug this. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panics with CardBus
On Mon, 11 Mar 2002, Michal Mertl wrote: I get panics for about 2 weeks (last tested with todays current - it's more unstable than friday's build - it crashed only when boot_verbose was set, now it sometimes crashes several times in a row). I was about to post about the same problems. I am using -CURRENT as of last week, and have three different PCMCIA cards which cause me problems. The first is also a Xircom 10/100 RBE-100 cardbus card (though mine has no serial port) If bootverbose=0, no panic occurs. (though the dc driver still fails to attach it, being unable to find a PHY). With bootverbose=1, inserting the card will panic the machine. pci_print_verbose() calls pci_read_config while cfg-dev=0x0, and so device_get_parent() blows up. The second card I have, GlobalVillage Powerport Platinum Pro A390 combined modem and ethernet card, will panic upon insert with a page fault in pccard_scan_cis with a page fault. The page fault is caused by trying to read memory location zero through pccard_cis_read_1 (/usr/src/sys/dev/pccard/pccard_cis.c v1.18 line 155) The third card I have, a Hayes PCMCIA modem, will hang the laptop solid after being detected correctly and after printing the sio4: line. As a possible datapoint, the latter two cards have no problem under -STABLE. I am happy to supply the vmcore and kernel files to people who contact me off list, and am also able to post the cards to anyone who I know as a FreeBSD developer as long as I get them back... Thanks, Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
