Re: system hangs after logging into gdm
В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? ___ 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: system hangs after logging into gdm
on 11/10/2010 10:59 Ivan Klymenko said the following: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? If you can access the system remotely or quickly switch to console, then you should be able to examine state of your system and get some facts. -- Andriy Gapon ___ 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: [RFC] ifconfig description support in rc.d
Hi, pluknet pluk...@gmail.com wrote in aanlktintgji3vzrb8xuuqhwp+7ydvhtd7ynp0mmv0...@mail.gmail.com: pl On 27 August 2010 00:09, Doug Barton do...@freebsd.org wrote: pl On 08/26/2010 12:53 PM, pluknet wrote: pl pl [cc'ing current@ as rc@ looks too quite] pl pl Hi. pl pl Since ifconfig has grown to label interfaces with pl ifconfig $ifname description foobar, what about pl to give it more life and store i/face descriptions pl semi-permanently, so they will survive between reboots? pl pl This patch adds a functionality to rc.d to label pl interfaces at boot time. pl pl Comments are welcome. pl pl This seems like a good addition, thanks. Please also write a patch for pl rc.conf.5 to describe this new functionality and I'll be happy to commit it. pl pl Xin Li helped me with updating rc.conf.5 (thanks!). pl It's included in attached patch. (snip) pl + # ifconfig_IF_descr pl + for _if in `ifconfig -l`; do I think using ifconfig -l here is not a good idea. Setting a description for each interface in a function invoked by ifn_start() would be better. This is beacuse the netif script can be run not only at boottime but also via devd or by hand for a specific interface. So, if the ifnet_descr is there, /etc/rc.d/netif start IF does not make it run. Since the description is a per-interface property, /etc/rc.d/netif start IF should set one, and /etc/rc.d/netif stop IF should clear one, IMHO. Also, ifconfig -l is not compatible with $network_interfaces, so you need to use list_net_interface() for that purpose instead (if you move ifnet_descr() into ifn_start() it is useless, though). -- Hiroki pgpvMmS5Le8b3.pgp Description: PGP signature
truss calls setpgid()
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in truss which calls ioctls on TTYs, it just
locks up. This is because truss runs jobs in a separate process group.
This also means you cannot send signals to it:
truss sleep 1
Pressing ^C here won't work.
I've fixed it locally like this:
Index: usr.bin/truss/setup.c
===
--- usr.bin/truss/setup.c (revision 213113)
+++ usr.bin/truss/setup.c (working copy)
@@ -78,7 +78,6 @@
}
if (pid == 0) { /* Child */
ptrace(PT_TRACE_ME, 0, 0, 0);
- setpgid (0, 0);
execvp(command[0], command);
err(1, execvp %s, command[0]);
Question: was this intentional? I'd rather not break stuff.
Greetings,
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpgLNWsANUMZ.pgp
Description: PGP signature
Fwd: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010
Hello, this is a reminder to anyone who's planning on sending a status report to us. The submission deadline is 15th Sept 2010. I know that many of you guys have spent last few days in Karlsruhe (and I hope to receive some additional reports covering the EuroBSDCon/DevSummit events), so that I understand that the reports might still be on their way. I just wanted to note, that to this date we have received only 5 entries. Please, if you are planning to send your entry, let us know so we can at least count with you and poke you if we don't receive it soon :) Original Message Subject: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 Date: Thu, 30 Sep 2010 08:29:48 +0200 From: Daniel Gerzo dan...@freebsd.org Organization: The FreeBSD Project To: curr...@freebsd.org, hack...@freebsd.org, questi...@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2010 is due on October 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ 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: system hangs after logging into gdm
On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon a...@icyb.net.ua wrote: on 11/10/2010 10:59 Ivan Klymenko said the following: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? That seems a bit interesting. The other thing you can do is start running a binary search on the breakage because you have a range of good versions vs bad versions to look through. If you can access the system remotely or quickly switch to console, then you should be able to examine state of your system and get some facts. If you have ddb compiled into the kernel (and you should) try CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead, which would require a serial connection (RS-232 or IEEE-1394). HTH, -Garrett ___ 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 under Xen
On Sun, Sep 26, 2010 at 11:06 PM, Julian Elischer jul...@freebsd.org wrote: After bruce C gave me the hint of kern.eventtimer.periodic=1, I was able to boot -current on my vps at rootbsd.com, but it hangs on reboot.. some time before the unmounts as the file systems need to be cleaned on the next successful boot. Has anyone had any experience with this? unfortunately I can't yet tell you the version of Xen in use there. For what it is worth, I have the same shutdown issues on real hardware using 9 CURRENT eg dell 6450 (old p3 xeon) dell 2650 as well as a white box (below is a partial dmesg) Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #20: Mon Oct 11 07:57:28 CDT 2010 r...@fnfs.puffybsd.com:/usr/obj/usr/src/sys/FNFS amd64 CPU: AMD Phenom(tm) II X4 B50 Processor (3100.28-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 7986311168 (7616 MB) Event timer LAPIC quality 400 ACPI APIC Table: 041410 APIC1753 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20100915/tbfadt-655) ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 041410 XSDT1753 on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fec1, 20 (3) failed acpi0: reservation of fed4, 5000 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 I think I have a HP machine that wont shut down either -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ 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 on kthread_exit under INVARIANTS
Hi, If kernel threads were created via kproc_kthread_add() when last kernel thread exits it will trigger panic. It panics in queue.h probably introduced with recent commit. ___ 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: fcntl always fails to delete lock file, and PID is always -6464
On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. -- John Baldwin ___ 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: letting glabel recognise a media change
On Sunday, October 10, 2010 4:55:15 pm Alexander Motin wrote: Pawel Jakub Dawidek wrote: On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: Andriy Gapon wrote: on 30/09/2010 01:28 Matthew Jacob said the following: If something like that was in place, I assure you that things would start to use it very quickly. I am not sure about this. Because, e.g. I don't see an easy way to know that media is changed in scsi_cd driver. That is, without polling. I don't consider polling to be an easy way for a number of reasons. SATA specification defines concept of Asynchronous Notification. It is already used by port multipliers to report about PHY events. It is also supposed to be used by CD drives to report media change. I haven't seen such devices yet, but hope they may appear sometimes. And even without AN support it would be nice to implement proper handling for SCSI UA - media changed errors within CAM. It still won't be perfect without using polling, but probably still something. I'd like to know the original reason why CD device is represented by GEOM provider and not CD media. For my naive thinking CD media should be GEOM provider that we taste once the media is inserted and orphan once the media is removed. I don't see any reasons for CD device to be useful GEOM provider, but maybe I'm overlooking something. Poul-Henning or Soren, do you remember who made and why this design choice? SCSI drivers receive no notification on media insertion. Somebody should poll device. At this moment it is handled by consumers. Indeed not sure it is the best idea. If we want driver to bother with this polling - we may do as you propose. Actually in sdhci(4) driver I am doing this way - mmcsdX device appears when card inserted and disappears on removal. I think first thing that may brake if there will be no cdX device - loading the media with some commands. Also it may be non-intuitive that drive is present, but disk is not registered in GEOM. With CD drives you are also rather stuck in that the existing ABI for controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are done on the /dev/cdX device. Ideally enclosures for removable media would be separate devices from the removable media itself, but a lot of existing software for CD's would break if this changes now. -- John Baldwin ___ 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: system hangs after logging into gdm
On Monday, October 11, 2010 3:59:04 am Ivan Klymenko wrote: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? Did you recompile the nvidia.ko module after upgrading? -- John Baldwin ___ 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: truss calls setpgid()
On Monday, October 11, 2010 9:17:19 am Ed Schouten wrote:
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in truss which calls ioctls on TTYs, it just
locks up. This is because truss runs jobs in a separate process group.
This also means you cannot send signals to it:
truss sleep 1
Pressing ^C here won't work.
I've fixed it locally like this:
Index: usr.bin/truss/setup.c
===
--- usr.bin/truss/setup.c (revision 213113)
+++ usr.bin/truss/setup.c (working copy)
@@ -78,7 +78,6 @@
}
if (pid == 0) { /* Child */
ptrace(PT_TRACE_ME, 0, 0, 0);
- setpgid (0, 0);
execvp(command[0], command);
err(1, execvp %s, command[0]);
Question: was this intentional? I'd rather not break stuff.
It was added in the switch from procfs to ptrace(), but it's not clear why the
child has a new process group. It doesn't look like truss ever tries to kill
the entire group for example.
--
John Baldwin
___
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: system hangs after logging into gdm
В Mon, 11 Oct 2010 11:10:17 -0400 John Baldwin j...@freebsd.org пишет: On Monday, October 11, 2010 3:59:04 am Ivan Klymenko wrote: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? Did you recompile the nvidia.ko module after upgrading? Yes, of course. ___ 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: system hangs after logging into gdm
В Mon, 11 Oct 2010 08:37:05 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon a...@icyb.net.ua wrote: on 11/10/2010 10:59 Ivan Klymenko said the following: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org пишет: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? -Garrett NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-username-hash may hang system due to gvfsd? That seems a bit interesting. The other thing you can do is start running a binary search on the breakage because you have a range of good versions vs bad versions to look through. If you can access the system remotely or quickly switch to console, then you should be able to examine state of your system and get some facts. If you have ddb compiled into the kernel (and you should) try CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead, which would require a serial connection (RS-232 or IEEE-1394). HTH, -Garrett Thank you! I'll try to recompile the kernel with DDB shortly and after blocking press ctrl+alt+esc, which would show the trace output... ___ 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: system hangs after logging into gdm
Ivan Klymenko fi...@ukr.net writes: В Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper gcoo...@freebsd.org writes: On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net wrote: My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 What video driver are you using? NVIDIA Driver Version: 260.19.06 Do you have local patches to make it compile on /head? Could they be the cause of the hang? 260.19.04 and 260.19.06 use taskqueue_run(9) that was removed in /h...@r210377. ___ 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: system hangs after logging into gdm
В Mon, 11 Oct 2010 22:49:29 +0400
Anonymous swel...@gmail.com пишет:
Ivan Klymenko fi...@ukr.net writes:
В Sun, 10 Oct 2010 15:37:55 -0700
Garrett Cooper gcoo...@freebsd.org writes:
On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko fi...@ukr.net
wrote:
My system has an svn r213507
FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun
Oct 10 22:43:18 EEST 2010
r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
after upgrading to r213666 my system hangs after logging into gdm
had to go back to r213507
What video driver are you using?
NVIDIA Driver Version: 260.19.06
Do you have local patches to make it compile on /head? Could they be
the cause of the hang? 260.19.04 and 260.19.06 use taskqueue_run(9)
that was removed in /h...@r210377.
patches exist, but the cause is not in them - as Xorg starts, the
system hangs after a few seconds after entering the password box to
login gdm
without a password - it works
--- src/nvidia_os.c.orig2010-09-15 01:26:27.0 +0300
+++ src/nvidia_os.c 2010-09-15 01:27:51.0 +0300
@@ -13,6 +13,67 @@
#include nv.h
#include nv-freebsd.h
+struct taskqueue {
+STAILQ_HEAD(, task) tq_queue;
+const char *tq_name;
+taskqueue_enqueue_fntq_enqueue;
+void*tq_context;
+struct task *tq_running;
+struct mtx tq_mutex;
+struct thread **tq_threads;
+int tq_tcount;
+int tq_spin;
+int tq_flags;
+};
+
+static void taskqueue_run(struct taskqueue *, struct task **);
+
+static __inline void
+TQ_LOCK(struct taskqueue *tq)
+{
+if (tq-tq_spin)
+ mtx_lock_spin(tq-tq_mutex);
+else
+mtx_lock(tq-tq_mutex);
+}
+
+static __inline void
+TQ_UNLOCK(struct taskqueue *tq)
+{
+ if (tq-tq_spin)
+ mtx_unlock_spin(tq-tq_mutex);
+ else
+ mtx_unlock(tq-tq_mutex);
+}
+
+static void
+taskqueue_run(struct taskqueue *queue, struct task **tpp)
+{
+ struct task *task;
+ int pending;
+
+ mtx_assert(queue-tq_mutex, MA_OWNED);
+ while (STAILQ_FIRST(queue-tq_queue)) {
+ /*
+ * Carefully remove the first task from the queue and
+ * zero its pending count.
+ */
+ task = STAILQ_FIRST(queue-tq_queue);
+ STAILQ_REMOVE_HEAD(queue-tq_queue, ta_link);
+ pending = task-ta_pending;
+ task-ta_pending = 0;
+ task-ta_running = tpp;
+ *tpp = task;
+ TQ_UNLOCK(queue);
+
+ task-ta_func(task-ta_context, pending);
+
+ TQ_LOCK(queue);
+ *tpp = NULL;
+ wakeup(task);
+ }
+}
+
MALLOC_DEFINE(M_NVIDIA, nvidia, NVIDIA memory allocations);
TASKQUEUE_DEFINE_THREAD(nvidia);
@@ -332,7 +393,8 @@
RM_STATUS NV_API_CALL os_flush_work_queue(void)
{
-taskqueue_run(taskqueue_nvidia);
+//taskqueue_run(taskqueue_nvidia);
+taskqueue_run(taskqueue_nvidia, taskqueue_nvidia-tq_running);
return RM_OK;
}
___
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: letting glabel recognise a media change
On Mon, Oct 11, 2010 at 11:03:26AM -0400, John Baldwin wrote: With CD drives you are also rather stuck in that the existing ABI for controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are done on the /dev/cdX device. Ideally enclosures for removable media would be separate devices from the removable media itself, but a lot of existing software for CD's would break if this changes now. Right, but I still wonder if we could execute provider orphan and retaste on various events like media insertion or removal. If media is removed we orphan provider and recreate it, which will trigger retaste, and this is fine there will be nothing to read from or write to (we will simply return errors as we do now, I think). This way we nicely co-operate with GEOM, but also with other tools that don't require media to be present (if there is no media devfs entry still exists and handles ioctls, it just return errors on read requests). -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp57kBd4EwFu.pgp Description: PGP signature
nfs zfs lockup
I believe NFS is upsetting ZFS v15 on FreeBSD current (kernel sources from today) this happened while trying to sftp a 4gb file here is a back trace # procstat -k 2675 2436 1081 18 5 0 PIDTID COMM TDNAME KSTACK 2675 100292 sftp-server -mi_switch sleepq_wait _cv_wait txg_wait_open zfs_freebsd_write VOP_WRITE_APV vn_write dofilewrite kern_writev write syscallenter syscall Xfast_syscall 2436 100337 cvsup-mi_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup zfs_dirent_lock zfs_dirlook zfs_lookup zfs_freebsd_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei kern_statat_vnhook 1081 100299 nfsd nfsd: master mi_switch sleepq_wait _cv_wait zio_wait dbuf_read dbuf_findbp dbuf_hold_impl dbuf_hold dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup zfs_dirent_lock zfs_dirlook zfs_lookup zfs_freebsd_lookup vfs_cache_lookup VOP_LOOKUP_APV 1081 100318 nfsd nfsd: servicemi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 1081 100319 nfsd nfsd: servicemi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 1081 100320 nfsd nfsd: servicemi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 18 100081 syncer -mi_switch sleepq_wait _cv_wait zio_wait zil_commit zfs_sync sync_fsync sync_vnode sched_sync fork_exit fork_trampoline 5 100071 zfskern arc_reclaim_thre mi_switch sleepq_timedwait _cv_timedwait arc_reclaim_thread fork_exit fork_trampoline 5 100072 zfskern l2arc_feed_threa mi_switch sleepq_timedwait _cv_timedwait l2arc_feed_thread fork_exit fork_trampoline 5 100125 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait txg_thread_wait txg_quiesce_thread fork_exit fork_trampoline 5 100126 zfskern txg_thread_enter mi_switch sleepq_timedwait _cv_timedwait txg_thread_wait txg_sync_thread fork_exit fork_trampoline 5 100182 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait txg_quiesce_thread fork_exit fork_trampoline 5 100183 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait zio_wait dsl_pool_sync spa_sync txg_sync_thread fork_exit fork_trampoline 0 10 kernel swapper mi_switch sleepq_timedwait _sleep scheduler mi_startup btext 0 100016 kernel firmware taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100021 kernel acpi_task_0 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100022 kernel acpi_task_1 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100023 kernel acpi_task_2 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100024 kernel kqueue taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100026 kernel thread taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100059 kernel em0 taskqmi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100067 kernel system_taskq_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100068 kernel system_taskq_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100069 kernel system_taskq_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100070 kernel system_taskq_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100073 kernel deadlkresmi_switch sleepq_timedwait _sleep deadlkres fork_exit fork_trampoline 0 100084 kernel zio_null_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100085 kernel zio_null_intrmi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100086 kernel zio_read_issue_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100087 kernel zio_read_issue_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100088 kernel zio_read_issue_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100089 kernel zio_read_issue_3 mi_switch
Re:HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing . or .. path component - names ending with '/' - already existing device names So, if you see a bad si_name panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko Hi, I faced that kind of panic today and now I'm able to boot again into CURRENT after applying the patch and rebuilding kernel. The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? Thanks Barbara ___ 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 under Xen
on 11/10/2010 19:46 Sam Fourman Jr. said the following: On Sun, Sep 26, 2010 at 11:06 PM, Julian Elischer jul...@freebsd.org wrote: After bruce C gave me the hint of kern.eventtimer.periodic=1, I was able to boot -current on my vps at rootbsd.com, but it hangs on reboot.. some time before the unmounts as the file systems need to be cleaned on the next successful boot. Has anyone had any experience with this? unfortunately I can't yet tell you the version of Xen in use there. For what it is worth, I have the same shutdown issues on real hardware using 9 CURRENT Breaking into ddb at that point and examining stacks of all threads[*] would greatly help to pinpoint the issue. [*] or forcing a dump for postmortem examination with kgdb. -- Andriy Gapon ___ 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
recent bge(4) changes causing problems
It seems recent changes to the bge driver are causing some problems with my hardware where the watchdog is now timing out. /var/log/messages contains 14:23:14 kernel: SMP: AP CPU #1 Launched! 14:23:14 kernel: Trying to mount root from ufs:/dev/ad6s1a 14:23:15 kernel: bge1: link state changed to UP 14:23:15 lpd[1190]: lpd startup: logging=0 14:23:15 ntpd[1224]: ntpd 4.2.4p5-a (1) 14:23:15 kernel: bge0: link state changed to UP 14:23:24 ntpd[1225]: time reset -0.677316 s 14:23:24 ntpd[1225]: kernel time sync status change 2001 14:31:01 kernel: bge0: watchdog timeout -- resetting 14:31:01 kernel: bge0: link state changed to DOWN 14:31:02 kernel: Limiting icmp unreach response from 613 to 200 packets/sec 14:31:04 ntpd[1225]: sendto(140.142.2.8) (fd=22): No route to host 14:31:04 kernel: bge0: link state changed to UP 14:31:30 kernel: Limiting icmp unreach response from 205 to 200 packets/sec 14:31:31 kernel: Limiting icmp unreach response from 203 to 200 packets/sec 15:40:11 su: kargl to root on /dev/pts/0 15:40:35 kernel: bge0: link state changed to DOWN 15:40:38 kernel: bge0: link state changed to UP The last 2 bge messages are from me manually using ifconfig to bring my net connect back to life. troutmask:kargl[206] sysctl -a | grep bge.0 dev.bge.0.%desc: Broadcom Gigabit Ethernet Controller, ASIC rev. 0x002100 dev.bge.0.%driver: bge dev.bge.0.%location: slot=9 function=0 handle=\_SB_.PCI0.GOLA.GLAN dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1648 subvendor=0x14e4 subdevice=0x1644 class=0x02 dev.bge.0.%parent: pci2 dev.bge.0.forced_collapse: 0 dev.bge.0.forced_udpcsum: 0 dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 325 dev.bge.0.stats.DmaReadQueueFull: 0 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 469 dev.bge.0.stats.RingStatusUpdate: 330 dev.bge.0.stats.Interrupts: 330 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.ifHCInOctets: 569452 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UnicastPkts: 497 dev.bge.0.stats.rx.MulticastPkts: 1 dev.bge.0.stats.rx.FCSErrors: 0 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.ifHCOutOctets: 39056 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UnicastPkts: 468 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 1 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 dev.bge.0.wake: 0 In the time that it's taken me to compose this message the timeout has fire again. 15:47:01 kernel: Limiting icmp unreach response from 662 to 200 packets/sec 15:47:02 kernel: Limiting icmp unreach response from 446 to 200 packets/sec 15:47:03 kernel: Limiting icmp unreach response from 436 to 200 packets/sec 15:47:04 kernel: Limiting icmp unreach response from 464 to 200 packets/sec 15:47:05 kernel: Limiting icmp unreach response from 438 to 200 packets/sec 15:47:06 kernel: Limiting icmp unreach response from 445 to 200 packets/sec 15:47:07 kernel: bge0: watchdog timeout -- resetting 15:47:07 kernel: bge0: link state changed to DOWN 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec 15:47:11 kernel: bge0: link state changed to UP 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec 15:49:42 kernel: bge0: link state changed to DOWN 15:49:44 kernel: bge0: link state changed to UP I not seen these icmp unreach response messages. -- Steve ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: It seems recent changes to the bge driver are causing some problems with my hardware where the watchdog is now timing out. /var/log/messages contains 14:23:14 kernel: SMP: AP CPU #1 Launched! 14:23:14 kernel: Trying to mount root from ufs:/dev/ad6s1a 14:23:15 kernel: bge1: link state changed to UP 14:23:15 lpd[1190]: lpd startup: logging=0 14:23:15 ntpd[1224]: ntpd 4.2.4p5-a (1) 14:23:15 kernel: bge0: link state changed to UP 14:23:24 ntpd[1225]: time reset -0.677316 s 14:23:24 ntpd[1225]: kernel time sync status change 2001 14:31:01 kernel: bge0: watchdog timeout -- resetting 14:31:01 kernel: bge0: link state changed to DOWN 14:31:02 kernel: Limiting icmp unreach response from 613 to 200 packets/sec 14:31:04 ntpd[1225]: sendto(140.142.2.8) (fd=22): No route to host 14:31:04 kernel: bge0: link state changed to UP 14:31:30 kernel: Limiting icmp unreach response from 205 to 200 packets/sec 14:31:31 kernel: Limiting icmp unreach response from 203 to 200 packets/sec 15:40:11 su: kargl to root on /dev/pts/0 15:40:35 kernel: bge0: link state changed to DOWN 15:40:38 kernel: bge0: link state changed to UP The last 2 bge messages are from me manually using ifconfig to bring my net connect back to life. troutmask:kargl[206] sysctl -a | grep bge.0 dev.bge.0.%desc: Broadcom Gigabit Ethernet Controller, ASIC rev. 0x002100 dev.bge.0.%driver: bge dev.bge.0.%location: slot=9 function=0 handle=\_SB_.PCI0.GOLA.GLAN dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1648 subvendor=0x14e4 subdevice=0x1644 class=0x02 dev.bge.0.%parent: pci2 dev.bge.0.forced_collapse: 0 dev.bge.0.forced_udpcsum: 0 dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 325 dev.bge.0.stats.DmaReadQueueFull: 0 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 469 dev.bge.0.stats.RingStatusUpdate: 330 dev.bge.0.stats.Interrupts: 330 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.ifHCInOctets: 569452 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UnicastPkts: 497 dev.bge.0.stats.rx.MulticastPkts: 1 dev.bge.0.stats.rx.FCSErrors: 0 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.ifHCOutOctets: 39056 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UnicastPkts: 468 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 1 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 dev.bge.0.wake: 0 In the time that it's taken me to compose this message the timeout has fire again. 15:47:01 kernel: Limiting icmp unreach response from 662 to 200 packets/sec 15:47:02 kernel: Limiting icmp unreach response from 446 to 200 packets/sec 15:47:03 kernel: Limiting icmp unreach response from 436 to 200 packets/sec 15:47:04 kernel: Limiting icmp unreach response from 464 to 200 packets/sec 15:47:05 kernel: Limiting icmp unreach response from 438 to 200 packets/sec 15:47:06 kernel: Limiting icmp unreach response from 445 to 200 packets/sec 15:47:07 kernel: bge0: watchdog timeout -- resetting 15:47:07 kernel: bge0: link state changed to DOWN 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec 15:47:11 kernel: bge0: link state changed to UP 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec 15:49:42 kernel: bge0: link state changed to DOWN 15:49:44 kernel: bge0: link state changed to UP I not seen these icmp unreach response messages. The icmp unreach has nothing to do with bge(4). Check whether a server that listens on an UDP port is still alive on your box. What worries me is bge(4) watchdog timeouts. It looks like your controller is
Call for bge(4) testers
Hi, I have been working on bge(4) for a while to support a new Broadcom controller. Before doing that I committed many fundamental changes to bge(4) in order to make it easy to add more controllers. Because bge(4) supports many variants of controllers and have lots of workaround for specific controller revisions it is possible for me to break something on certain controllers. If you have bge(4) controller please give it try and let me know how it works. Thanks. ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 04:16:04PM -0700, Pyun YongHyeon wrote: On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: In the time that it's taken me to compose this message the timeout has fire again. 15:47:07 kernel: bge0: watchdog timeout -- resetting 15:47:07 kernel: bge0: link state changed to DOWN 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec 15:47:11 kernel: bge0: link state changed to UP 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec 15:49:42 kernel: bge0: link state changed to DOWN 15:49:44 kernel: bge0: link state changed to UP I not seen these icmp unreach response messages. The icmp unreach has nothing to do with bge(4). Check whether a server that listens on an UDP port is still alive on your box. What worries me is bge(4) watchdog timeouts. It looks like your controller is BCM5704. I also have bge(4) regression report from marius on sparc64. He said r213945 seemed to cause the issue and I'm working on the issue. Could you also try the attached patch? The patch did not help. In fact, the icmp (which may be a side effect of the bge0 device wedging) has become much worse. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad6s1a bge1: link state changed to UP bge0: link state changed to UP Limiting icmp unreach response from 3433 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2049 to 200 packets/sec bge0: watchdog timeout -- resetting bge0: link state changed to DOWN Limiting icmp unreach response from 1962 to 200 packets/sec Limiting icmp unreach response from 2174 to 200 packets/sec Limiting icmp unreach response from 2180 to 200 packets/sec Limiting icmp unreach response from 2163 to 200 packets/sec bge0: link state changed to UP (removing 50 or so icmp messages). I don't know if the following helps, but thought I would include it here. troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available -- Steve ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: On Mon, Oct 11, 2010 at 04:16:04PM -0700, Pyun YongHyeon wrote: On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: In the time that it's taken me to compose this message the timeout has fire again. 15:47:07 kernel: bge0: watchdog timeout -- resetting 15:47:07 kernel: bge0: link state changed to DOWN 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec 15:47:11 kernel: bge0: link state changed to UP 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec 15:49:42 kernel: bge0: link state changed to DOWN 15:49:44 kernel: bge0: link state changed to UP I not seen these icmp unreach response messages. The icmp unreach has nothing to do with bge(4). Check whether a server that listens on an UDP port is still alive on your box. What worries me is bge(4) watchdog timeouts. It looks like your controller is BCM5704. I also have bge(4) regression report from marius on sparc64. He said r213945 seemed to cause the issue and I'm working on the issue. Could you also try the attached patch? The patch did not help. In fact, the icmp (which may be a side effect of the bge0 device wedging) has become much worse. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad6s1a bge1: link state changed to UP bge0: link state changed to UP Limiting icmp unreach response from 3433 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2049 to 200 packets/sec bge0: watchdog timeout -- resetting bge0: link state changed to DOWN Limiting icmp unreach response from 1962 to 200 packets/sec Limiting icmp unreach response from 2174 to 200 packets/sec Limiting icmp unreach response from 2180 to 200 packets/sec Limiting icmp unreach response from 2163 to 200 packets/sec bge0: link state changed to UP (removing 50 or so icmp messages). I don't know if the following helps, but thought I would include it here. troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available Would you show me the revision number of if_bge.c/if_bgereg.h? %cd /usr/src/sys/dev/bge %ident if_bge.c if_bgereg.h -- Steve ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available Would you show me the revision number of if_bge.c/if_bgereg.h? %cd /usr/src/sys/dev/bge %ident if_bge.c if_bgereg.h if_bge.c: $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ if_bgereg.h: $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari -- Steve ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 05:15:10PM -0700, Steve Kargl wrote: On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available Would you show me the revision number of if_bge.c/if_bgereg.h? %cd /usr/src/sys/dev/bge %ident if_bge.c if_bgereg.h if_bge.c: $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ if_bgereg.h: $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari Note, my old kernel which works fine shows troutmask:kargl[202] ident /boot/sgk/kernel | grep bge $FreeBSD: head/sys/dev/bge/if_bge.c 211596 2010-08-22 01:39:09Z yongari $ -- Steve ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 05:26:21PM -0700, Steve Kargl wrote: On Mon, Oct 11, 2010 at 05:15:10PM -0700, Steve Kargl wrote: On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available Would you show me the revision number of if_bge.c/if_bgereg.h? %cd /usr/src/sys/dev/bge %ident if_bge.c if_bgereg.h if_bge.c: $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ if_bgereg.h: $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari Note, my old kernel which works fine shows troutmask:kargl[202] ident /boot/sgk/kernel | grep bge $FreeBSD: head/sys/dev/bge/if_bge.c 211596 2010-08-22 01:39:09Z yongari $ Thanks for the info. I still suspect r213495 might break BCM5704. Due to lack of BCM5704 I still couldn't test it except guessing. How about attached one? Index: sys/dev/bge/if_bge.c === --- sys/dev/bge/if_bge.c(revision 213711) +++ sys/dev/bge/if_bge.c(working copy) @@ -1736,7 +1736,8 @@ RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, - BGE_RCB_FLAG_RING_DISABLED); + BGE_RCB_MAXLEN_FLAGS(sc-bge_return_ring_cnt, + BGE_RCB_FLAG_RING_DISABLED)); RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); bge_writembx(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(uint64_t))), 0); ___ 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 on kthread_exit under INVARIANTS
Paul B Mahol wrote: Hi, If kernel threads were created via kproc_kthread_add() when last kernel thread exits it will trigger panic. It panics in queue.h probably introduced with rec I have committed a patch, can you try it ? http://svn.freebsd.org/changeset/base/213714 Regards, David Xu ___ 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
[PATCH] fix shell bug in ${var%pattern} expansion
At $WORK we hit a bug where ${var%/*} was not producing the correct
expansion. There are two patches to fix this. I prefer the first
as I feel it is cleaner from an API perspective. I've also added
a regression testcase that shows the problem.
Thoughts?
--
-- David (obr...@freebsd.org)
Commit log:
Do not assume in growstackstr() that a precious character will be
immediately written into the stack after the call. Instead let the
caller manage the space left.
Currently growstackstr()'s assumption causes problems with
STACKSTRNUL() where we want to be able to turn a stack into a C
string, and later pretend the NUL is not there.
This fixes a bug in STACKSTRNUL() (that grew the stack) where:
1. STADJUST() called after a STACKSTRNUL() results in an improper
adjust. This can be seen in ${var%pattern} and ${var%%pattern}
evaluation.
2. Memory leak in STPUTC() called after a STACKSTRNUL().
--%--%--%--%--%--
Index: bin/sh/memalloc.h
===
--- bin/sh/memalloc.h (revision 213714)
+++ bin/sh/memalloc.h (working copy)
@@ -67,9 +67,16 @@ void ungrabstackstr(char *, char *);
#define stackblock() stacknxt
#define stackblocksize() stacknleft
#define STARTSTACKSTR(p) p = stackblock(), sstrnleft = stackblocksize()
-#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
*p++ = (c)))
+#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
--sstrnleft, *p++ = (c)))
#define CHECKSTRSPACE(n, p){ if (sstrnleft n) p = makestrspace(); }
#define USTPUTC(c, p) (--sstrnleft, *p++ = (c))
+/*
+ * STACKSTRNUL's use is where we want to be able to turn a stack
+ * (non-sentinel, character counting string) into a C string,
+ * and later pretend the NUL is not there.
+ * Note: Because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used
+ * on a stack that will grabstackstr()ed.
+ */
#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0') : (*p
= '\0'))
#define STUNPUTC(p)(++sstrnleft, --p)
#define STTOPC(p) p[-1]
Index: bin/sh/histedit.c
===
--- bin/sh/histedit.c (revision 213714)
+++ bin/sh/histedit.c (working copy)
@@ -418,7 +418,7 @@ fc_replace(const char *s, char *p, char
} else
STPUTC(*s++, dest);
}
- STACKSTRNUL(dest);
+ STPUTC('\0', dest);
dest = grabstackstr(dest);
return (dest);
Index: bin/sh/memalloc.c
===
--- bin/sh/memalloc.c (revision 213714)
+++ bin/sh/memalloc.c (working copy)
@@ -295,6 +295,12 @@ grabstackblock(int len)
* is space for at least one character.
*/
+static char *
+growstrstackblock(int n) {
+ growstackblock();
+ sstrnleft = stackblocksize() - n;
+ return stackblock() + n;
+}
char *
growstackstr(void)
@@ -304,12 +310,10 @@ growstackstr(void)
len = stackblocksize();
if (herefd = 0 len = 1024) {
xwrite(herefd, stackblock(), len);
- sstrnleft = len - 1;
+ sstrnleft = len;
return stackblock();
}
- growstackblock();
- sstrnleft = stackblocksize() - len - 1;
- return stackblock() + len;
+ return growstrstackblock(len);
}
@@ -323,9 +327,7 @@ makestrspace(void)
int len;
len = stackblocksize() - sstrnleft;
- growstackblock();
- sstrnleft = stackblocksize() - len;
- return stackblock() + len;
+ return growstrstackblock(len);
}
--%--%--%--%--%--
ALTERNATE PATCH:
Index: bin/sh-1/memalloc.h
===
--- bin/sh-1/memalloc.h (revision 213696)
+++ bin/sh-1/memalloc.h (working copy)
@@ -70,7 +70,17 @@ void ungrabstackstr(char *, char *);
#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
*p++ = (c)))
#define CHECKSTRSPACE(n, p){ if (sstrnleft n) p = makestrspace(); }
#define USTPUTC(c, p) (--sstrnleft, *p++ = (c))
-#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0') : (*p
= '\0'))
+/*
+ * growstackstr() has the assumption that a precious character will be
+ * immediately written into it, so it sets up 'sstrnleft' appropriately.
+ * But that is not the case for STACKSTRNUL, where we want to be able to
+ * turn a stack (non-sentinel, character counting string) into a C string,
+ * and later pretend the NUL is not there (without adjusting 'sstrnleft').
+ * Note: because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used on
+ * a stack that will grabstackstr()ed.
+ */
+#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0',
++sstrnleft) : (*p = '\0'))
+//#define STACKSTRNUL(p)
Re: fcntl always fails to delete lock file, and PID is always -6464
Sent from my iPad On Oct 11, 2010, at 5:50 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: Next step discussion engaged from this research I guess. Should we do change FreeBSD's fcntl(2) to return correct l_pid when called with F_SETLK? Or keep current behavior?? I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. Yes, I agree. POSIX says so. -- John Baldwin ___ 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: nfs zfs lockup
On Mon, Oct 11, 2010 at 3:45 PM, Sam Fourman Jr. sfour...@gmail.com wrote: I believe NFS is upsetting ZFS v15 on FreeBSD current (kernel sources from today) this happened while trying to sftp a 4gb file here is a lockup without nfs even started FNFS# procstat -k 2503 PIDTID COMM TDNAME KSTACK 2503 100340 sftp-server -mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select select syscallenter syscall Xfast_syscall FNFS# -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ 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
