[Bug 250173] Re: gnat broken with last gcc update
Hello, Using the Ubuntu Development version if gnat is important to you, appears to be a specifically bad idea as they appear to have disabled all the tests at least for Ada. I am no longer an Ubuntu user myself, as its Development version has become too unstable for me. But I can confirm having seen my collegue struck by your problem too. Also don't necessarily expect any feedback, the last time it was fixed silently (and left open) too. Best regards, Kay Hayen -- gnat broken with last gcc update https://bugs.launchpad.net/bugs/250173 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125302] Re: kvm-ifup fails to initialize tap networking
Hello Soren! My concern was neither the non-existance or _your_ interest to write a better solution, nor the fact that you inherit the bug from upstream. Not even that it exists, bugs are perfectly fine. My disappointment that I was interested in writing a better solution, offered so, but lacked response in any form. That's a loss, even if not to you. Also, more than one year ago, the documentation certainly wasn't clear that libvirt was the only supported way to run kvm. Best regards, Kay Hayen -- kvm-ifup fails to initialize tap networking https://bugs.launchpad.net/bugs/125302 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125302] Re: kvm-ifup fails to initialize tap networking
Hello Matt, just for the record, I retract my year old offer willing to provide a patch, because in the mean time I switched back to Debian. Should anybody make a statement that Ubuntu is not responsive to bugs, I may consider to mention this bug. The help offers in this bug were ignored all the time, and that while KVM was pronounced as the official virtualization method for Ubuntu. Sad. Best regards, Kay Hayen -- kvm-ifup fails to initialize tap networking https://bugs.launchpad.net/bugs/125302 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 252728] Re: Jiffies too low for acceptable ppoll accuracy
Hello, please find attached the output of one of our RHEL machines with comparable hardware. We normally use HP G5 machines, but that is a normal desktop PC with Dual Core too. The claim is that the problem shows relatively hardware independent. I must admit, that we never use the same hardware with RHEL and Ubuntu, but all Ubuntu machines fail the test, all RHEL machines (version 3, 4 or 5) pass it. ** Attachment added: dmesg http://launchpadlibrarian.net/16378512/dmesg -- Jiffies too low for acceptable ppoll accuracy https://bugs.launchpad.net/bugs/252728 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 252728] Re: Jiffies too low for acceptable ppoll accuracy
Hello, please find attached the output of dmesg from the Ubuntu machine. Please ignore the NVidia modules, this is only a recent change that I made, because xserver-xorg-driver-nv started to segfault too badly. The problem existed before. The only other noteworthy difference is that I am using the RT2500 driver, because the RT2x00 that Ubuntu is using for a couple of releases was deeply broken. I can reproduce the issue on machines without both the drivers. The CPU is Intel Dual Core with 2G RAM. The problem was initially observed on 2.6.22 already, a kernel that I was using longer due to the RT2x00 problem that I got only recently under control. ** Attachment added: dmesg http://launchpadlibrarian.net/16378423/dmesg -- Jiffies too low for acceptable ppoll accuracy https://bugs.launchpad.net/bugs/252728 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 252728] Re: Jiffies too low for acceptable ppoll accuracy
Hello, according the ps sources, the ELF note is the only reliable way to get the hands on the period one jiffy in /proc represents. The issue at hand is that I have implemented lock files that contain a life information from a process that is supposed to be unique, by combining the start time and pid (together they will be unique across reboots, provided time is not way off). For that I needed to decode the started this many jiffies after boot value of the running kernel. So even if 100Hz is not correct, for the decoding that value must be had: It seems Ubuntu is in fact using: CONFIG_NO_HZ=y CONFIG_HZ=250 CONFIG_HZ_250=y My understanding of tickless is not that you achieve a higher granularity for scheduler sleeps that 4ms, but it would mean not every tick must be performed, but instead multiple can be done at later wakeup, mostly only relevant for idle machines, isn't it? That maches the values I measure, waking up 4ms too late. On RHEL they appear to be using: CONFIG_HZ_1000=y CONFIG_HZ=1000 And that matches the 2ms obversation fine too. What I do not get is why ppoll is using a resolution for the wake up time of nanoseconds, when in fact little more than 1ms can actually be had anyway. May have its uses when the CPU slice from scheduler is used up, and we want to wake up with values below 1ms in the future, to not have to round up. Other than that I would be confused. With nanosleep or things from hrtimer.h, I could try to use poll on the monitored file handles, but I am wondering if the scheduler will not still limit me. I am going to make a prototype implementation that is going to use poll with 0 timeout and small nanosleeps (100us e.g.) in between to avoid busy loop. May work and would be a nice improvement. But why wouldn't ppoll already do that?! About the desktop tuning of generic. Indeed. For a desktop machines low latencies should be easy to achieve, for a server that's not normally needed. I will try the -rt kernel if that nanosleep trick doesn't work, our goal is to not require too much about the used kernel. Yours, Kay Hayen -- Jiffies too low for acceptable ppoll accuracy https://bugs.launchpad.net/bugs/252728 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 252728] Re: How to achieve low latency sleeps.
Hello, thanks for the explanations. I have now implemented the following: loop poll with 0 timeout exit when poll reports readable file handles delta := target_time - current_time exit when delta =0 nanosleep min(100us,delta) That is giving much better values below 1ms. In one instance I had 24us max for 10 tries, in others 400us, still 10 times better, plus I think I still have a few relicts around that would account for loss of accuracy. Funny thing: On RHEL I am not getting the same improvement, but quite reliably close to 1ms and a small amound of microseconds, like 55us for example. But that would be a RHEL bug I guess. So I am quite content now, but I think that: a) The man page of ppoll (2) should be more specific about the lack of actual accuracy. In fact, I was using ppoll over poll, after notificng the issue first, and had no way to know that ppoll just translates a higher accuracy of the argument, but no different behaviour otherwise. b) The glibc should get a patch for its ppoll wrapper that implements the algorithm. c) I share the assumption that the values have been decided consciously, yet I question: Why for a desktop machine when considering 1000-250, make the decision that increases throughput (less scheduler context switches wins). I don't want to resort to FUD, but I could image that these 2.5ms could be detrimental to the interactive behaviour. It's the server that I'd expect to prefer and schedule longer slices. Before tickless I could very well see how one doesn't want to have useless extra ticks, but these times are gone now, aren't they? Best regards, Kay Hayen -- How to achieve low latency sleeps. https://bugs.launchpad.net/bugs/252728 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 252728] [NEW] Jiffies too low for acceptable ppoll accuracy
Public bug reported: Binary package hint: linux-image-2.6.26-4-generic Hello, we are developing an application that wants to (relatively precise) wake up at chosen microsecond values in the future. We are using the ppoll (2). When we wake up, we compare the gettimeofday (2) value with the expected result. Our process has normal nice level and is subject to the default scheduler of the kernel. What we observe: On RHEL we reliably achieve delays below 2ms. On Ubuntu we fail to achieve this low delays, we get around 4ms, sometimes 8ms on relatively idle machines. I have checked the ELF note 17 to determine the Hertz (as done in ps source code too), and on RHEL it's 1000, whereas on Ubuntu it's 100 only. I believe this explains the poor performance on even an idle machine compare to RHEL. I could understand if the server kernel of Ubuntu had a low jiffy value, because higher jiffies loose throughput, but for the desktop kernel this is a surprise. And RHEL doesn't seem to consider 1000 too high. With tickless kernels the impact on notebooks power usage should not exist, so I don't see any obstacles. My proposal would be to increase the HZ configuration of the non-server kernels of Ubuntu to 1000 to take advantage of tickless. Yours, Kay Hayen ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Description changed: Binary package hint: linux-image-2.6.26-4-generic Hello, we are developing an application that wants to (relatively precise) wake - up at chose us values in the future. We are using the ppoll (2). When we - wake up, we compare the gettimeofday (2) value with the expected result. - Our process has normal nice level and is subject to the default - scheduler of the kernel. + up at chosen microsecond values in the future. We are using the ppoll + (2). When we wake up, we compare the gettimeofday (2) value with the + expected result. Our process has normal nice level and is subject to the + default scheduler of the kernel. What we observe: On RHEL we reliably achieve delays below 2ms. On Ubuntu we fail to achieve this low delays, we get around 4ms, sometimes 8ms on relatively idle machines. I have checked the ELF note 17 to determine the Hertz (as done in ps source code too), and on RHEL it's 1000, whereas on Ubuntu it's 100 only. I believe this explains the poor performance on even an idle machine compare to RHEL. I could understand if the server kernel of Ubuntu had a low jiffy value, because higher jiffies loose throughput, but for the desktop kernel this is a surprise. And RHEL doesn't seem to consider 1000 too high. With tickless kernels the impact on notebooks power usage should not exist, so I don't see any obstacles. My proposal would be to increase the HZ configuration of the non-server kernels of Ubuntu to 1000 to take advantage of tickless. Yours, Kay Hayen -- Jiffies too low for acceptable ppoll accuracy https://bugs.launchpad.net/bugs/252728 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 250173] [NEW] gnat broken with last gcc update
Public bug reported: Binary package hint: gnat-4.3 Hello, with the current gnat it is impossible to compile anything. Neither gnat itself, nor any other file it seems. To reproduce, install gnat and attempt to compile vanill gcc, it will report: configure: error: GNAT is required to build ada dpkg -l gnat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii gnat4.3.1-1ubuntu2 The GNU Ada compiler This was first noted when compiling our own Ada project broke for 2 people on independent machines. Yours, Kay Hayen ** Affects: gnat-4.3 (Ubuntu) Importance: Undecided Status: New -- gnat broken with last gcc update https://bugs.launchpad.net/bugs/250173 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 149785] KVM version is outdated in Ubuntu
Public bug reported: Binary package hint: kvm The version of kvm is 28, while upstream is at version 45. Can you please upgrade early in the next update cycle, or even better, before Gutsy release? ** Affects: kvm (Ubuntu) Importance: Undecided Status: New -- KVM version is outdated in Ubuntu https://bugs.launchpad.net/bugs/149785 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125302] Re: kvm-ifup fails to bring up tap0 in feisty
Hello, I am on Gutsy. The original complaint is likely wrong, in that executing ifconfig tap0 0.0.0.0 up of course won't work, because tap0 will be deleted again after the failure. But /etc/kvm/kvm-ifup script is also most likely wrong, because it doesn't give a bridge to brctl, but instead the $switch, which is supposed to be the device with the default router I take. That's my wireless in my case, and far from a bridge. I tried creating a bridge inside the script and addif the both $switch and $1 (tap0). It seems to work insofar as I can see in tcpdump my packets, for which the WLAN likely will have no friendly words. Can you clarify, if and where the bridge should be created? tap0 is no bridge. And can you provide a means to say where to bridge to? I would be perfectly happy to bridge to lo device. My only goal is to ssh into the virtual machine from the local machine, but so far I have no succeeded. -- kvm-ifup fails to bring up tap0 in feisty https://bugs.launchpad.net/bugs/125302 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125302] Re: kvm-ifup fails to bring up tap0 in feisty
I sincerly doubt that the code can possibly work as it is. It's in violation of the man page of brctl and I am the second to experience its failure. ** Changed in: kvm (Ubuntu) Status: Invalid = Confirmed -- kvm-ifup fails to bring up tap0 in feisty https://bugs.launchpad.net/bugs/125302 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125302] Re: kvm-ifup fails to bring up tap0 in feisty
Just to add, given more hints on where to look, I am willing to provide a patch myself. -- kvm-ifup fails to bring up tap0 in feisty https://bugs.launchpad.net/bugs/125302 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 59242] Re: KDM fails to launch X on edgy
Thank you Guillaume, after executing apt-get install ubuntu-minimal I also found that I was still on the old sysvinit and not upstart. Now the problem is gone for me too. -- KDM fails to launch X on edgy https://launchpad.net/bugs/59242 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 59242] Re: KDM fails to launch X on edgy
I can confirm the bug. My edgy system displays a black screen after boot. When I press ALT, I see the login screen of tty1. Then when I press ALT-F7 it will start X and kdm will run normally. -- KDM fails to launch X on edgy https://launchpad.net/bugs/59242 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
