Re: F22 Self Contained Change: Wine to use mesa Direct3D
Hey, On Wed, Jan 14, 2015 at 01:28:57PM +0100, Jaroslav Reznik wrote: > = Proposed Self Contained Change: Wine to use mesa Direct3D = > https://fedoraproject.org/wiki/Changes/Wine_to_use_mesa_Direct3D > > Change owner(s): Igor Gnatenko > > Enhancing mesa and wine with Direct3D9 support will increase performance and > reduce resource usage in applications which using D3D9 framework. > > == Detailed Description == > When playing d3d9 games on Wine, their d3d9 calls are translated to OpenGL. > This is complicated process, because you have to deal with different drivers > having different extensions available, and the fact that opengl and d3d9 > don't > map perfectly together. Gallium Nine implements the d3d9 API with Gallium > internal API, which maps better to d3d9 than OpenGL. You remove some layers > of > translation in the process which enables better performance. Gallium Nine is > not as mature as Wine OpenGL translation, and it is likely to have more bugs, > but when the games work, you can expect 5-10% improvement for gpu limited > games, or much more (sometimes 100%) for cpu limited games. > > what is Gallium: Gallium is an internal graphic driver abstraction of Mesa to > enable support of non-opengl languages more easily (it is used for vdpau and > vaapi on r600/radeonsi for example). It is used by nouveau and r300 up to > radeonsi for AMD. Intel OpenGL support doesn't use gallium, but a gallium > driver named ilo exists, but isn't sponsored by Intel. > > In practice, games have also smoother frame rate on Gallium Nine. Gallium > Nine > has good DRI_PRIME support, and if you have a system with an iGPU+dGPU, you > can play without issues with the parameters DRI_PRIME=1 thread_submit=true > > https://wiki.ixit.cz/d3d9 > The wiki link doesn't seem to work.. Is it possible for the user to tell wine which backend to use? OpenGL or Gallium-Nine ? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Mon, Jan 12, 2015 at 10:35:39AM +0200, Pasi Kärkkäinen wrote: > On Mon, Jan 12, 2015 at 09:15:39AM +0100, Petr Lautrbach wrote: > > On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote: > > > Hello, > > > > > > People who have their names in the Fedora tcp_wrappers changelog added to > > > CC list.. > > > > > > Any comments about the below? Obviously aclexec feature would be useful > > > for all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs, > > > and many others), > > > and thus very nice to have. > > > > > > > Hi > > > > please file a RFE bug on tcp_wrappers. I'll try to use the Debian patch. > > I'm going to use the Debian patch adding tcpwrappers support in > > openssh-6.7p1 likewise. > > > Now done: https://bugzilla.redhat.com/show_bug.cgi?id=1181815 Thanks a lot, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Mon, Jan 12, 2015 at 05:17:08PM +0100, Lennart Poettering wrote: > On Sun, 11.01.15 21:29, Tomasz Torcz (to...@pipebreaker.pl) wrote: > > > On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote: > > > Hello, > > > > > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > > > tcp_wrappers via a custom patch since 2006, > > > so you can do this in /etc/hosts.allow or hosts.deny: > > > > > > > > > What do people feel about that? I'd like to see support for aclexec > > > included in Fedora's tcp_wrappers package. > > > >Enhancing tcpwrappers isn't generally a way we are going: > > https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html > > > > Above discussions is only about proposal, no change was made. But I > > highly doubt > > any serious work on tcpwrappers will happen. > > Well, we *did* drop tcpwrap support from systemd. It's not just OpenSSH > that is dropping it... > > tcpwrap should really be removed. Having such crap, unmaintained code > responsible for security checks is completely backwards. > Then again there is no better option available atm which provides the *same* features as tcpwrapper, mostly: 1) Centralized configuration, same syntax and configfile for all the services using tcpwrapper (which is most services). 2) DNS-based checks (yes, there are valid use-cases for reverse-DNS checks aswell). 3) Execute custom "ACL"-scripts for any service, integrate with DNS RBLs, or lookup other IP databases. If there was better option than tcpwrapper I'd be happy to use it. > Lennart > > -- > Lennart Poettering, Red Hat > -- -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Mon, Jan 12, 2015 at 09:15:39AM +0100, Petr Lautrbach wrote: > On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote: > > Hello, > > > > People who have their names in the Fedora tcp_wrappers changelog added to > > CC list.. > > > > Any comments about the below? Obviously aclexec feature would be useful for > > all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs, and many > > others), > > and thus very nice to have. > > > > Hi > > please file a RFE bug on tcp_wrappers. I'll try to use the Debian patch. > I'm going to use the Debian patch adding tcpwrappers support in > openssh-6.7p1 likewise. > OK, will do! Thanks, -- Pasi > Petr > > > > > > On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote: > >> Hello, > >> > >> I recently noticed Debian/Ubuntu has had support for "aclexec" in > >> tcp_wrappers via a custom patch since 2006, > >> so you can do this in /etc/hosts.allow or hosts.deny: > >> > >> sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a > >> > >> if sshfilter.sh returns true the access is allowed, if sshfilter.sh > >> returns false the access is denied. > >> Very handy for integrating DNS RBLs and other IP databases etc. > >> > >> What do people feel about that? I'd like to see support for aclexec > >> included in Fedora's tcp_wrappers package. > >> > >> I don't think there has been any upstream releases of tcp_wrappers in the > >> near past, > >> so that aclexec feature is not upstream.. but the patch that Debian/Ubuntu > >> are using is available. > >> > >> > >> Debian tcp_wrappers changelog: > >> http://archive.debian.net/changelogs/pool/main/t/tcp-wrappers/tcp-wrappers_7.6.q-16/changelog > >> > >> "New patch aclexec: adds the aclexec command and its documentation." was > >> added in 2006. > >> > >> > >> Thanks, > >> > >> -- Pasi > >> > > > > > -- > Petr Lautrbach > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Sun, Jan 11, 2015 at 09:29:08PM +0100, Tomasz Torcz wrote: > On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote: > > Hello, > > > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > > tcp_wrappers via a custom patch since 2006, > > so you can do this in /etc/hosts.allow or hosts.deny: > > > > > > What do people feel about that? I'd like to see support for aclexec > > included in Fedora's tcp_wrappers package. > >Enhancing tcpwrappers isn't generally a way we are going: > https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html > > Above discussions is only about proposal, no change was made. But I highly > doubt > any serious work on tcpwrappers will happen. > Right.. I'm very used to using tcpwrappers, and it's pretty much in use on all the servers and desktops/laptops I have. But it seems there are some technical issues why other people feel it should be nuked. Oh well.. For example (reverse) DNS based filtering is very simple with tcpwrappers, and the acl scripts.. Thanks for the pointer to the ml discussion! -- Pasi > -- > Tomasz Torcz ,,If you try to upissue this patchset I shall be > seeking > xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton > (LKML) > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
Hello, People who have their names in the Fedora tcp_wrappers changelog added to CC list.. Any comments about the below? Obviously aclexec feature would be useful for all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs, and many others), and thus very nice to have. Thanks, -- Pasi On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote: > Hello, > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > tcp_wrappers via a custom patch since 2006, > so you can do this in /etc/hosts.allow or hosts.deny: > > sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a > > if sshfilter.sh returns true the access is allowed, if sshfilter.sh returns > false the access is denied. > Very handy for integrating DNS RBLs and other IP databases etc. > > What do people feel about that? I'd like to see support for aclexec included > in Fedora's tcp_wrappers package. > > I don't think there has been any upstream releases of tcp_wrappers in the > near past, > so that aclexec feature is not upstream.. but the patch that Debian/Ubuntu > are using is available. > > > Debian tcp_wrappers changelog: > http://archive.debian.net/changelogs/pool/main/t/tcp-wrappers/tcp-wrappers_7.6.q-16/changelog > > "New patch aclexec: adds the aclexec command and its documentation." was > added in 2006. > > > Thanks, > > -- Pasi > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Sat, Jan 10, 2015 at 12:57:22AM +0200, Pasi Kärkkäinen wrote: > On Fri, Jan 09, 2015 at 11:47:52PM +0100, Michael Stahl wrote: > > On 09.01.2015 23:16, Pasi Kärkkäinen wrote: > > > Hello, > > > > > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > > > tcp_wrappers via a custom patch since 2006, > > > so you can do this in /etc/hosts.allow or hosts.deny: > > > > > > sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a > > > > > > if sshfilter.sh returns true the access is allowed, if sshfilter.sh > > > returns false the access is denied. > > > Very handy for integrating DNS RBLs and other IP databases etc. > > > > > > What do people feel about that? I'd like to see support for aclexec > > > included in Fedora's tcp_wrappers package. > > > > seems a bit pointless to add this now considering this bit from the > > OpenSSH 6.7 release notes: > > > > http://lwn.net/Articles/615173/ > > > > * sshd(8): Support for tcpwrappers/libwrap has been removed. > > > > Right.. I wasn't aware of that. Why on earth did they remove tcpwrappers > support :( > Do you know what was the reasoning behind that? > > Then again tcpwrappers "aclexec" can be used for other services aswell, not > just openssh.. > It seems that at least Debian has added tcpwrappers support back to their version of Openssh 6.7: https://launchpad.net/debian/+source/openssh/1:6.7p1-1 "* Restore TCP wrappers support, removed upstream in 6.7. It is true that dropping this reduces preauth attack surface in sshd. On the other hand, this support seems to be quite widely used, and abruptly dropping it (from the perspective of users who don't read openssh-unix-dev) could easily cause more serious problems in practice. It's not entirely clear what the right long-term answer for Debian is, but it at least probably doesn't involve dropping this feature shortly before a freeze." -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On Fri, Jan 09, 2015 at 11:47:52PM +0100, Michael Stahl wrote: > On 09.01.2015 23:16, Pasi Kärkkäinen wrote: > > Hello, > > > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > > tcp_wrappers via a custom patch since 2006, > > so you can do this in /etc/hosts.allow or hosts.deny: > > > > sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a > > > > if sshfilter.sh returns true the access is allowed, if sshfilter.sh returns > > false the access is denied. > > Very handy for integrating DNS RBLs and other IP databases etc. > > > > What do people feel about that? I'd like to see support for aclexec > > included in Fedora's tcp_wrappers package. > > seems a bit pointless to add this now considering this bit from the > OpenSSH 6.7 release notes: > > http://lwn.net/Articles/615173/ > > * sshd(8): Support for tcpwrappers/libwrap has been removed. > Right.. I wasn't aware of that. Why on earth did they remove tcpwrappers support :( Do you know what was the reasoning behind that? Then again tcpwrappers "aclexec" can be used for other services aswell, not just openssh.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
Hello, I recently noticed Debian/Ubuntu has had support for "aclexec" in tcp_wrappers via a custom patch since 2006, so you can do this in /etc/hosts.allow or hosts.deny: sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a if sshfilter.sh returns true the access is allowed, if sshfilter.sh returns false the access is denied. Very handy for integrating DNS RBLs and other IP databases etc. What do people feel about that? I'd like to see support for aclexec included in Fedora's tcp_wrappers package. I don't think there has been any upstream releases of tcp_wrappers in the near past, so that aclexec feature is not upstream.. but the patch that Debian/Ubuntu are using is available. Debian tcp_wrappers changelog: http://archive.debian.net/changelogs/pool/main/t/tcp-wrappers/tcp-wrappers_7.6.q-16/changelog "New patch aclexec: adds the aclexec command and its documentation." was added in 2006. Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SSSD 1.11 and AD homeDirectory
On Wed, Sep 11, 2013 at 05:32:29PM -0400, Simo Sorce wrote: > On Wed, 2013-09-11 at 15:26 -0500, Jeffrey Ollie wrote: > > On Wed, Sep 11, 2013 at 3:07 PM, Simo Sorce wrote: > > > > > > Almost certainly you do not want a home directory backed by a cifs > > > filesystem, however if you really do I suggest you configure autofs and > > > cifs with multi-user mounts on your machine. > > > > It's not a question of "want", I'm trying to integrate a Fedora > > desktop(s) as seamlessly as possible into an existing Active Directory > > environment, and that means having a user's personal files accessible > > as seamlessly as possible. > > Having a 'separate' path accessible, and using a Windows share as the > home directory for a unix-like machine are quite different things. > Not even windows machine have their profile on a network share. > > > The new AD support in SSSD 1.11 means that > > the AD admins don't need to extend the AD schema and maintain the new > > attributes. > > I know I helped build that. > > > > You will not be able to have the home directory be specified by the AD > > > server though unless you want to cleverly use the unixHomeDirectory > > > attribute (and your windows admin properly populates it for each user). > > > > The actual attribute in AD is "homeDirectory" and is populated with > > UNC paths to the user's home directory. > > That's the windows attribute yes, and homeDrive has the drive letter to > use (IIRC). > > > I'll have to dig into autofs to see if it can do what I want. > > autofs won't have access to the arbitrary UNC stored in AD, but it may > be a good feature request for SSSD. > We do have autofs support in SSSD, maybe we could have some special > module for AD to fake up an autofs configuration out of the Windows > homeDirectory for use with a cifs mount point. > > May be worth opening a RFE upstream. > Automatically mounting per-user windows-shares sounds like something that definitely should be supported. Did you already open a RFE? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 18 status / F18-RC4 Xen tests
On Wed, Jan 09, 2013 at 08:36:59PM +0200, Pasi Kärkkäinen wrote: > On Tue, Jan 08, 2013 at 10:39:53PM -0800, Adam Williamson wrote: > > > > QA:Testcase_Boot_Methods_Xen_Para_Virt - we need someone who's set up > > for Xen to test this, if Konrad is reading, are you able to check it? > > > > I'll try this soon. > As I posted here: https://bugzilla.redhat.com/show_bug.cgi?id=810040 I just finished testing F18-RC4: - 32bit F18-RC4 Xen PV domU installs and works OK using virt-install http install. - 64bit F18-RC4 Xen PV domU installs and works OK using virt-install http install. - 64bit F18-RC4-live Xen HVM guest works OK (live image booted from emulated CD-drive). I can confirm F18-RC4 fixes the fprintd bug. I get proper GDM login prompts on the F18-RC4 PV domU pvfb consoles after installation; F18-RC3 gave the sad face with "Oh no! Something went horribly wrong" text due to the fprintd bug. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 status
On Tue, Jan 08, 2013 at 10:39:53PM -0800, Adam Williamson wrote: > > QA:Testcase_Boot_Methods_Xen_Para_Virt - we need someone who's set up > for Xen to test this, if Konrad is reading, are you able to check it? > I'll try this soon. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Aug 09, 2012 at 09:05:26PM +0300, Pasi Kärkkäinen wrote: > On Tue, Jul 31, 2012 at 08:33:04PM +0100, Matthew Garrett wrote: > > On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote: > > > > > .. and it's stuck there. I need to press Reset button to continue. > > > It did read the CD for a while until it got frozen. > > > > Yeah, that's definitely a bug then. We'll see if we can reproduce it. > > > > Any luck reproducing? Anything else I should try? > Ok, this issue is now resolved. It was an Intel BIOS/firmware bug. DQ77MK BIOS v0050 has this in the changelog/releasenotes: "Fixed issue with UEFI Linux* installation." And indeed, with BIOS 0050 I can now successfully UEFI boot both Fedora 17 and RHEL 6.3. Thanks a lot to everyone involved! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 08:33:04PM +0100, Matthew Garrett wrote: > On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote: > > > .. and it's stuck there. I need to press Reset button to continue. > > It did read the CD for a while until it got frozen. > > Yeah, that's definitely a bug then. We'll see if we can reproduce it. > Any luck reproducing? Anything else I should try? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Aug 02, 2012 at 08:09:05PM +0100, Matthew Garrett wrote: > On Mon, Jul 30, 2012 at 05:54:46PM +0300, Pasi Kärkkäinen wrote: > > > "nomodeset" doesn't help or change anything unfortunately.. > > Try with noapic? > That didn't help either :( -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 08:16:29PM +0100, Matthew Garrett wrote: > On Tue, Jul 31, 2012 at 09:41:48PM +0300, Pasi Kärkkäinen wrote: > > Secure boot not enabled > > error: failure reading sector 0x40 from `cd0Ž. > > Try changing the firmware from AHCI to IDE mode. We're pretty sure this > is a bug in Intel's AHCI driver, but we'll try to figure out a > workaround in grub. > Ok, I changed from AHCI to IDE mode, and now I get: - Booting `Fedora 17Ž Secure boot not enabled - .. and it's stuck there. I need to press Reset button to continue. It did read the CD for a while until it got frozen. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Tue, Jul 31, 2012 at 11:11:07AM -0400, Peter Jones wrote: > On Mon, 2012-07-30 at 21:23 +0300, Pasi Kärkkäinen wrote: > > On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote: > > > > > > > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be > > > > >able to > > > > >confirm that somehow.. > > > > > > > > Well, either the bootloader or the kernel (or something after that) is > > > > not > > > > succeeding If Windows works in UEFI mode on the machine, then we would > > > > still > > > > consider it to be a bug we should fix, even if the firmware fails to > > > > comply to > > > > precisely to our previous interpretation of the spec. > > > > > > > > > > I'll try installing Windows aswell. > > > > > > > I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. > > After installation I verified it had created GPT system partition, > > and also I used "bcdedit" to verify windows has booted using bootmgfw.efi > > and winload.efi. > > > > So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode. > > > > Should I open a fedora bugzilla ticket? > > Probably - but first, could you try booting the iso at > http://pjones.fedorapeople.org/sb/boot-sb4.iso ? It's using a boot > process that's a bit different (and more like what F18 will have), so > and the code is different enough that there's some chance any given > bug is incidentally fixed. > with that boot-sb4.iso I get first the grub 2.00 menu, and after choosing Fedora 17 entry: -- Booting `Fedora 17` Secure boot not enabled error: failure reading sector 0x40 from `cd0Ž. Press any key to continue... -- And it's stuck there.. pressing "any key" doesn't help, and ctrl+alt+del doesn't work either. I have to press Reset button. I tried burning the iso image twice to different cdr's.. didn't help. Any ideas? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote: > > > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able > > >to > > >confirm that somehow.. > > > > Well, either the bootloader or the kernel (or something after that) is not > > succeeding If Windows works in UEFI mode on the machine, then we would still > > consider it to be a bug we should fix, even if the firmware fails to comply > > to > > precisely to our previous interpretation of the spec. > > > > I'll try installing Windows aswell. > I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. After installation I verified it had created GPT system partition, and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and winload.efi. So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode. Should I open a fedora bugzilla ticket? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 09:59:11AM -0600, Chris Murphy wrote: > > On Jul 30, 2012, at 9:36 AM, Pasi Kärkkäinen wrote: > > > Multiple people have confirmed UEFI boot is broken on Intel 7-series > > motherboards, > > so I believe this is Intel BIOS/firmware bug. > > Does it UEFI boot a Windows 7 X86_64 install disk? > I just tried it, and yes, Win7 SP1 x64 seems to install and work in UEFI mode. After win7 x64 installation I verified there is a GPT system partition on the hdd, and also I used "bcdedit" to verify Windows has booted using bootmgfw.efi and winload.efi. > Does Intel think it's broken? > I opened a thread about it on Intel forums/communities, where a person from Intel asked if "supported operating system" worked OK.. It seems RHEL is "supported", and RHEL 6.3 server x64 shows the same problem as Fedora, so that's good in a way. I guess I need to figure out how to open a proper bugreport to Intel. http://communities.intel.com/message/162124 so in short: Win7 x64 UEFI works, but fedora16/fedora17/rhel63 x64 fail in UEFI mode. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 11:34:12AM -0400, Gerry Reno wrote: > On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote: > > On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: > >> On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: > >>> On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > >>>> On 07/26/2012 05:12 PM, Matthew Garrett wrote: > >>>>> On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > >>>>> > >>>>>> When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >>>>>> background image, > >>>>>> I let it boot the default entry "Fedora 17", I see it the allocating > >>>>>> memory pages, loading VMLINUZ etc, > >>>>>> and then the display mode / resolution changes, and then there's just > >>>>>> blank screen and a cursor blinking.. > >>>>> If you see a resoution change then try booting with nomodeset. > >>>>> > >>>> You might also see if you can get one of the alternate terminals. If > >>>> that works then the kernel is booted and its just > >>>> X which is not starting. > >>>> > >>> I can't change terminals. I assume the kernel doesn't boot at all, or > >>> crashes very early. > >>> I can't see any kind of activity from Linux kernel after GRUB-efi > >>> messages and the screen switches to blank.. > >>> > >>> -- Pasi > >>> > >> Have you tried booting with more logging? Without "quiet" param? > >> > > There's no "quiet" param. The default UEFI boot options are "verbose" as a > > default. > > > > I can't see *any* output from Linux kernel. Also I tried settings up SOL > > serial console, > > but I can't see any Linux messages there either. SOL stays empty/silent. > > > > Is serial console supposed to work OK in the usual way, with UEFI boot? > > > > And again: Booting in legacy BIOS mode works OK, and the serial console > > works there aswell. > > I have problems only in UEFI mode, where I can't get *any* output from > > Linux. > > > > -- Pasi > > > > > > Are you booting x86 or x86_64 version? > > I don't think x86 is supported for UEFI boot. > x86_64 (64bit), of course. I get grub-EFI boot menu from the DVD, I choose Fedora, I get the grub-EFI texts about allocating memory pages for LINUX-EFI, loading VMLINUZ, etc.. and then the screen goes blank and everything stops there. Multiple people have confirmed UEFI boot is broken on Intel 7-series motherboards, so I believe this is Intel BIOS/firmware bug. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: > On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: > > On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > >> On 07/26/2012 05:12 PM, Matthew Garrett wrote: > >>> On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > >>> > >>>> When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >>>> background image, > >>>> I let it boot the default entry "Fedora 17", I see it the allocating > >>>> memory pages, loading VMLINUZ etc, > >>>> and then the display mode / resolution changes, and then there's just > >>>> blank screen and a cursor blinking.. > >>> If you see a resoution change then try booting with nomodeset. > >>> > >> You might also see if you can get one of the alternate terminals. If that > >> works then the kernel is booted and its just > >> X which is not starting. > >> > > I can't change terminals. I assume the kernel doesn't boot at all, or > > crashes very early. > > I can't see any kind of activity from Linux kernel after GRUB-efi messages > > and the screen switches to blank.. > > > > -- Pasi > > > > Have you tried booting with more logging? Without "quiet" param? > There's no "quiet" param. The default UEFI boot options are "verbose" as a default. I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent. Is serial console supposed to work OK in the usual way, with UEFI boot? And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > On 07/26/2012 05:12 PM, Matthew Garrett wrote: > > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > > > >> When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >> background image, > >> I let it boot the default entry "Fedora 17", I see it the allocating > >> memory pages, loading VMLINUZ etc, > >> and then the display mode / resolution changes, and then there's just > >> blank screen and a cursor blinking.. > > If you see a resoution change then try booting with nomodeset. > > > > You might also see if you can get one of the alternate terminals. If that > works then the kernel is booted and its just > X which is not starting. > I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 10:12:19PM +0100, Matthew Garrett wrote: > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > > > When booting Fedora 17 x64 there's the GRUB bootloader with graphical > > background image, > > I let it boot the default entry "Fedora 17", I see it the allocating memory > > pages, loading VMLINUZ etc, > > and then the display mode / resolution changes, and then there's just blank > > screen and a cursor blinking.. > > If you see a resoution change then try booting with nomodeset. > "nomodeset" doesn't help or change anything unfortunately.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 04:44:03PM -0400, Gerry Reno wrote: > On 07/26/2012 04:31 PM, Pasi Kärkkäinen wrote: > > On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote: > >> There are missing Ivy Bridge definitions in the intel_chipset.h file in > >> libdrm which causes machines with Ivy Bridge > >> CPU's w/embedded iGPU to fail when starting X. > >> > >> As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue > >> on my F17 machine. > >> > > bz#840180 is a probably a different issue. > > > > My problem is that I can't even boot the f16/f17/rhel63 installer dvds > > because the UEFI boot doesn't work (it gets stuck with a blank screen), > > so I'm not able to install OS in UEFI mode.. > > > > Installing the same distros using legacy BIOS boot works OK. > > > > -- Pasi > > > >> > >> On 07/26/2012 02:05 PM, Gerry Reno wrote: > >>> I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) > >>> CPU. > >>> > >>> The issue occurred with Ivy Bridge w/iGPU onboard. > >>> > >>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180 > >>> > >>> . > >> > >> > > > Maybe UEFI is looking for a boot file and not finding it on DVD. > I don't get any errors about files not found.. When I boot Fedora 16, Fedora 17 or RHEL 6.3 (all x64) installer dvd, I get the following: - I boot the burned DVDR in UEFI mode. - I get the GRUB menu, I choose the default entry to install the Fedora/RHEL distro. - I get messages about loading VMLINUZ, allocating memory pages for Linux-EFI, etc. - The display gets cleared (or the resolution changes) and screen goes black/blank, there's only a cursor blinking. - Nothing happens after this, the boot is stuck, and I have to reset the system. So I can't install any Fedora/RHEL Linux in UEFI mode. Installing in legacy BIOS mode works OK. I've tried enabling serial console etc to get *some* output to figure out what's happening with the UEFI boot but I haven't been successful yet in getting any output from the kernel.. so I'm not sure if the Linux kernel gets booted/started or not. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote: > There are missing Ivy Bridge definitions in the intel_chipset.h file in > libdrm which causes machines with Ivy Bridge > CPU's w/embedded iGPU to fail when starting X. > > As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on > my F17 machine. > bz#840180 is a probably a different issue. My problem is that I can't even boot the f16/f17/rhel63 installer dvds because the UEFI boot doesn't work (it gets stuck with a blank screen), so I'm not able to install OS in UEFI mode.. Installing the same distros using legacy BIOS boot works OK. -- Pasi > > > On 07/26/2012 02:05 PM, Gerry Reno wrote: > > I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) > > CPU. > > > > The issue occurred with Ivy Bridge w/iGPU onboard. > > > > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180 > > > > . > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 02:36:39PM -0400, Przemek Klosowski wrote: > On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote: > > >I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. > >CPU is Intel Ivy Bridge i7-3770. > >I'm running the latest BIOS version (0048), and UEFI boot is enabled in the > >BIOS. > > I take it that this one doesn't have the secure boot yet? The secure > UEFI boot is almost certainly not the cause here---AFAIK there > aren't any publicly available secure UEFI implementations yet, and > your board seemed to execute the bootloader just fine and got bogged > down during the kernel startup. > Yep, no secure boot involved here. Just "normal" UEFI. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 03:52:25PM -0400, Peter Jones wrote: > On 07/26/2012 01:59 PM, Pasi Kärkkäinen wrote: > >"noefi" kernel cmdline option didn't help unfortunately. > > > >When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >background image, I let it boot the default entry "Fedora 17", I see it the > >allocating memory pages, loading VMLINUZ etc, and then the display mode / > >resolution changes, and then there's just blank screen and a cursor > >blinking.. > > > >Does that ring any bells? > > Not really, no. The fact that you're seeing a mode switch proceeding a > blinking cursor makes me think the kernel is probably starting, but you may > be seeing a series of failures after that point. > Ok. earlier I tried enabling the Linux serial console with "console=ttyS1,115200", but that didn't show any kernel messages on the SOL. I wonder if commands like "serial --port=0xf0e0" works with the EFI grub and if that'd show anything important.. (I can't try right now). > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to > >confirm that somehow.. > > Well, either the bootloader or the kernel (or something after that) is not > succeeding If Windows works in UEFI mode on the machine, then we would still > consider it to be a bug we should fix, even if the firmware fails to comply to > precisely to our previous interpretation of the spec. > I'll try installing Windows aswell. > That being said, I doubt if we're going to have a high degree of success > debugging this over email. > Yeah.. I'm not very familiar with the EFI stuff yet, so I don't known if/how serial console stuff is supposed to work, or if it's any different from legacy BIOS boot.. and why I didn't see anything on the SOL. Thanks for the help anyway! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 01:17:58PM -0400, Peter Jones wrote: > On 07/26/2012 06:32 AM, Pasi Kärkkäinen wrote: > >UEFI boot fails with all of the listed operating systems. Symptoms: > > > >- I get the Fedora/RHEL EFI boot menu, and I let it boot with the default > >options. > >- I get text on the screen about allocating memory pages for Linux-EFI, > >loading VMLINUZ, etc. > >- The screen goes empty/black, there's only a cursor blinking, and nothing > >happens.. > >- The boot failed or is stuck with nothing happening. I need to reset the > >box. > > > >It looks like Linux kernel doesn't get started at all.. so it could be a > >UEFI > >firmware or a bootloader problem. > > > >I'm actually expecting this is an Intel BIOS/UEFI firmware bug, because I've > >seen reports about UEFI boot problems on other Intel 7-series chipset > >as well. > > > >Does anyone know how to debug/troubleshoot UEFI boot problems? > > The fact that the cursor is blinking is a bit strange; if grub has attempted > to boot the kernel, that's unexpected. Nevertheless, one thing to try is > to add "noefi" to the kernel command line. If it gets farther, that's an > indication that we're hitting a kernel bug. > "noefi" kernel cmdline option didn't help unfortunately. When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. Does that ring any bells? I forgot to mention earlier that fedora/rhel works OK using legacy BIOS boot, so only UEFI is problematic on this box. I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able to confirm that somehow.. Thanks for the reply! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Debugging Fedora UEFI boot problems on Intel DQ77MK
Hello, I hope someone here can help me out.. I have a new Intel DQ77MK motherboard, based on the Intel Q77 chipset. CPU is Intel Ivy Bridge i7-3770. I'm running the latest BIOS version (0048), and UEFI boot is enabled in the BIOS. I've tried UEFI booting the following operating systems from burned DVDR discs: - Fedora 16 x64 DVD. - Fedora 17 x64 DVD. - Redhat Enterprise Linux (RHEL) 6.3 Server DVD. (Redhat Linux is supposed to be UEFI supported per the motherboard manuals). UEFI boot fails with all of the listed operating systems. Symptoms: - I get the Fedora/RHEL EFI boot menu, and I let it boot with the default options. - I get text on the screen about allocating memory pages for Linux-EFI, loading VMLINUZ, etc. - The screen goes empty/black, there's only a cursor blinking, and nothing happens.. - The boot failed or is stuck with nothing happening. I need to reset the box. It looks like Linux kernel doesn't get started at all.. so it could be a UEFI firmware or a bootloader problem. I'm actually expecting this is an Intel BIOS/UEFI firmware bug, because I've seen reports about UEFI boot problems on other Intel 7-series chipset aswell. Does anyone know how to debug/troubleshoot UEFI boot problems? The motherboard in question has Intel vPro/AMT, so it has SOL, so I could use a serial console, if there's a way to use it with UEFI/bootloader before Linux is started.. Any help is welcome! Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 12:47:58PM -0700, Adam Williamson wrote: > On Fri, 2011-10-14 at 22:44 +0300, Pasi Kärkkäinen wrote: > > On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: > > > On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: > > > > On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: > > > > > On systems where 32-bit is XP is running, one by definition is running > > > > > with a disk of 2 TB or less. Fedora installation must by default do > > > > > the right thing. We need to agree on what that happens to be. > > > > > > > > On systems with legacy operating systems installed Fedora does not > > > > touch the > > > > partition table at all. On all other systems GPT is the way to go I'd > > > > say... > > > > > > > > > > In F16 is it still possible to force creation of MSDOS partition table > > > without GPT using a kickstart script ? > > > > > > > Or with some boot/cmdline option? > > > > Afaik for example rhel5 Xen pygrub has issues with GPT, > > and it'd be good to be able to install F16 domUs on rhel5 Xen > > by forcing creation of msdos partition table.. > > As of Final TC1 (anaconda 16.21) this should be possible by passing > 'nogpt' as a kernel parameter to the installer. > I tried F16 Final TC1 with "nogpt" boot option but it didn't work unfortunately.. More info here: https://bugzilla.redhat.com/show_bug.cgi?id=735733 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 12:47:58PM -0700, Adam Williamson wrote: > On Fri, 2011-10-14 at 22:44 +0300, Pasi Kärkkäinen wrote: > > On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: > > > On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: > > > > On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: > > > > > On systems where 32-bit is XP is running, one by definition is running > > > > > with a disk of 2 TB or less. Fedora installation must by default do > > > > > the right thing. We need to agree on what that happens to be. > > > > > > > > On systems with legacy operating systems installed Fedora does not > > > > touch the > > > > partition table at all. On all other systems GPT is the way to go I'd > > > > say... > > > > > > > > > > In F16 is it still possible to force creation of MSDOS partition table > > > without GPT using a kickstart script ? > > > > > > > Or with some boot/cmdline option? > > > > Afaik for example rhel5 Xen pygrub has issues with GPT, > > and it'd be good to be able to install F16 domUs on rhel5 Xen > > by forcing creation of msdos partition table.. > > As of Final TC1 (anaconda 16.21) this should be possible by passing > 'nogpt' as a kernel parameter to the installer. > This is great! Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Fri, Oct 14, 2011 at 09:53:53PM +0300, Pasi Kärkkäinen wrote: > On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: > > On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: > > > On systems where 32-bit is XP is running, one by definition is running > > > with a disk of 2 TB or less. Fedora installation must by default do > > > the right thing. We need to agree on what that happens to be. > > > > On systems with legacy operating systems installed Fedora does not touch > > the > > partition table at all. On all other systems GPT is the way to go I'd say... > > > > In F16 is it still possible to force creation of MSDOS partition table > without GPT using a kickstart script ? > Or with some boot/cmdline option? Afaik for example rhel5 Xen pygrub has issues with GPT, and it'd be good to be able to install F16 domUs on rhel5 Xen by forcing creation of msdos partition table.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Sat, Aug 27, 2011 at 04:04:30AM +0200, Lars Seipel wrote: > On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote: > > On systems where 32-bit is XP is running, one by definition is running > > with a disk of 2 TB or less. Fedora installation must by default do > > the right thing. We need to agree on what that happens to be. > > On systems with legacy operating systems installed Fedora does not touch the > partition table at all. On all other systems GPT is the way to go I'd say... > In F16 is it still possible to force creation of MSDOS partition table without GPT using a kickstart script ? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 Final Release Criterion for Xen DomU
On Mon, Oct 10, 2011 at 12:09:51PM -0600, Tim Flink wrote: > Since the beta criterion for running Fedora as a Xen guest (DomU) was > removed for Fedora 16, there has been some discussion [1] [2] on test@ > about whether or not we should add it back for Fedora 16 final. The old > criterion read: > > The release must boot successfully as a virtual guest in a situation > where the virtual host is running a supported Xen implementation > It's good to remember Fedora 16 will have Xen Dom0 (host) support again! (The previous Fedora release with Xen dom0 was Fedora 8). Xen dom0 support has been merged to upstream Linux kernel, and more features (ang bugfixes) are being added in every upstream kernel release now. So F16 Xen VM on F16 Xen dom0 is possible.. and F17 Xen domU on F16 dom0, and of course any other distro VM on F16.. I believe F16 will also run on RHEL5 Xen dom0 now that the missing xen-kbdfront bug has been fixed in F16 lorax. (https://bugzilla.redhat.com/show_bug.cgi?id=740657) > As it stands, we are leaning towards accepting it as at least an NTH > criteria for Fedora 16. This means that any Xen guest issues would > become at least NTH (ability to update past code freeze, does not > block release) for final. The reasons listed are: > > - If Fedora is not usable as a Xen guest at release time, it will not >be possible to use the released install media to create Xen guests. >This is not fixable through updates > - Several cloud platforms (EC2, Linode etc.) use Xen in their >platforms. It is possible that issues preventing the usage of Fedora >as a Xen guest could affect the ability to use Fedora on those >platforms. > > Are there any objections to moving forward with this? There seems to be > no objections from the kernel maintainers who have been participating > in the discussion on test@ but we wanted a bit more devel input before > moving forward. > Yep, Xen domU (both PV and PVHVM) should be release criteria for F16 RC and Final! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Wed, Sep 21, 2011 at 04:03:49PM -0400, Konrad Rzeszutek Wilk wrote: > > >> So, there's a meta-point here: we currently 'require' Beta releases to > > >> boot as guests on Xen hosts: > > >> > > >> "The release must boot successfully as a virtual guest in a situation > > >> where the virtual host is running a supported Xen implementation" > > >> > > >> I really don't have much knowledge of Xen and haven't followed this > > >> discussion closely, but do any currently-known bugs prevent this? If so, > > >> please flag them up so they can be considered as Beta blockers...thanks! > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha under > Xen (regression) as guest > which is pretty descripting what is below. > > Also adding in Jeremy's workaround in it. > > Besides that, there is also > 738085 - Patch to reduce spurious Xen entries in grub menu > > which has a patch to fix the grub2 menu-thingy.. > I also filed the F16 Xen pvfb problem on rhel5 dom0: "Fedora 16 beta Xen pvfb graphical console does not work on rhel5 dom0": https://bugzilla.redhat.com/show_bug.cgi?id=740657 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Thu, Sep 22, 2011 at 03:08:41PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 22, 2011 at 12:47:57PM +0300, Pasi Kärkkäinen wrote: > > On Wed, Sep 21, 2011 at 06:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > > > > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > > > > >>>> So, there's a meta-point here: we currently 'require' Beta > > > > >>>> releases to > > > > >>>> boot as guests on Xen hosts: > > > > >>>> > > > > >>>> "The release must boot successfully as a virtual guest in a > > > > >>>> situation > > > > >>>> where the virtual host is running a supported Xen implementation" > > > > >>>> > > > > >>>> I really don't have much knowledge of Xen and haven't followed this > > > > >>>> discussion closely, but do any currently-known bugs prevent this? > > > > >>>> If so, > > > > >>>> please flag them up so they can be considered as Beta > > > > >>>> blockers...thanks! > > > > > I filled Bug 740378 - F16: Can't use keyboard when installing > > > > > F16-Alpha under Xen (regression) as guest > > > > > which is pretty descripting what is below. > > > > > > > > > > Also adding in Jeremy's workaround in it. > > > > > > > > Though I couldn't repro the general problems I was having - I later did > > > > a clean F14 install with no problems. So I don't really know what's > > > > going on here; I might try another F16 hvm install to see how it goes. > > > > > > > > But there is a bona-fide bug that F16 doesn't include xen-platform-pci > > > > by default in its initramfs, so it ends up unplugging its emulated > > > > devices without discovering the PV ones to replace them... > > > > > > Can you open a BZ at bugzilla.redhat.com please? > > > > > > > Also should we change the default xen-platform-pci to =y in upstream Linux > > .config to avoid having problems with every distro ? > > Or some form of it. Stefano is working to provide a patch that will latch > on CONFIG_PVONHVM and make that work. > Ok, great! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Wed, Sep 21, 2011 at 06:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2011 at 03:46:31PM -0700, Jeremy Fitzhardinge wrote: > > On 09/21/2011 01:03 PM, Konrad Rzeszutek Wilk wrote: > > So, there's a meta-point here: we currently 'require' Beta releases to > > boot as guests on Xen hosts: > > > > "The release must boot successfully as a virtual guest in a situation > > where the virtual host is running a supported Xen implementation" > > > > I really don't have much knowledge of Xen and haven't followed this > > discussion closely, but do any currently-known bugs prevent this? If > > so, > > please flag them up so they can be considered as Beta > > blockers...thanks! > > > I filled Bug 740378 - F16: Can't use keyboard when installing F16-Alpha > > > under Xen (regression) as guest > > > which is pretty descripting what is below. > > > > > > Also adding in Jeremy's workaround in it. > > > > Though I couldn't repro the general problems I was having - I later did > > a clean F14 install with no problems. So I don't really know what's > > going on here; I might try another F16 hvm install to see how it goes. > > > > But there is a bona-fide bug that F16 doesn't include xen-platform-pci > > by default in its initramfs, so it ends up unplugging its emulated > > devices without discovering the PV ones to replace them... > > Can you open a BZ at bugzilla.redhat.com please? > Also should we change the default xen-platform-pci to =y in upstream Linux .config to avoid having problems with every distro ? -- Pasi > It might need to be assigned to the kernel team. > > > > > Besides that, there is also > > > 738085 - Patch to reduce spurious Xen entries in grub menu > > > > > > which has a patch to fix the grub2 menu-thingy.. > > > > I'd noticed that - though at present I haven't managed to get F16 Xen to > > boot in an hvm domain (it hangs when setting up interrupts in the nested > > dom0). > > > > J > > > > ___ > > Xen-devel mailing list > > xen-de...@lists.xensource.com > > http://lists.xensource.com/xen-devel > > ___ > Xen-devel mailing list > xen-de...@lists.xensource.com > http://lists.xensource.com/xen-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Fri, Sep 16, 2011 at 12:08:40PM +0100, Richard W.M. Jones wrote: > On Fri, Sep 16, 2011 at 12:14:23PM +0300, Myroslav Opyr wrote: > > Hi, > > > > What Xen implementation is considered "supported" for FC16 DomU? > > Any commonly available upstream Xen releases. > > Fedora itself > (ie. https://fedoraproject.org/wiki/Features/XenPvopsDom0). > I think Fedora itself currently has Xen 4.1.1 in F15 and F16. > Also Xen in RHEL 5, although that's more of a thing for Red Hat to > worry about. > Actually F16 PV domU fails to start with vfb (graphical console) on RHEL5 dom0, the vfb never gets to fully initialized state.. so vncviewer won't work for the console. F15 and earlier versions do work OK with pvfb on the same RHEL5 dom0. I'll report to redhat bugzilla soon.. > > I'm asking because on "Xen implementation" we were testing yesterday > > FC16 DomU installation failed compared to FC15 DomU success on the > > very same Dom0. Are failures like we've encountered candidates for > > bugreports? > > Yes. > Yeah.. it could be the xen-kbdfront issue.. (it's missing from the F16 installer kernel/initrd). > > Is there a place (wikipage, bugzilla keyword, etc.) to collect > > Fedora 16 Xen issues? > > https://bugzilla.redhat.com/ > > Product: Fedora. Component: depends on what is failing but common > ones would be "kernel", "anaconda", "grubby", "grub2", "xen", and > "libvirt". > > There is also a Fedora Xen mailing list where you can get more > detailed help: > > https://lists.fedoraproject.org/mailman/listinfo/xen > -- Pasi > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming blog: http://rwmj.wordpress.com > Fedora now supports 80 OCaml packages (the OPEN alternative to F#) > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora > > ___ > Xen-devel mailing list > xen-de...@lists.xensource.com > http://lists.xensource.com/xen-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen / dom0 testing instructions
On Wed, Sep 14, 2011 at 05:45:39PM +0300, Pasi Kärkkäinen wrote:
> >
> > > >([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time
> > > > for us
> > > >to setup test environment, and would be good to have some info in
> > > > advance.
> >
Ok, so some basic steps to test Xen dom0 functionality in Fedora 16:
- Install Fedora 16 Beta TC2 host, to become Xen dom0. Installable ISO images
available here:
http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Fedora/
(and LIVE ISO's here:
http://alt.fedoraproject.org/pub/alt/stage/16-Beta.TC2/Live/).
- Disk partitioning on the host: First partition should be /boot as ext3,
for the rest of the disk use LVM volume group, and remember to leave free
space in the
volume group so you can later after installation create LVM volumes for the
VMs.
See these tutorials for an example about disk partitioning:
http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial
http://wiki.xen.org/xenwiki/RHEL6Xen4Tutorial
- After Fedora 16 is installed and everything works properly on baremetal,
including Internet access,
proceed to installing Xen and virtualization related packages:
yum install xen xen-hypervisor xen-runtime libvirt virt-manager virt-viewer
xorg-x11-xauth
- Enable automatic start of xend and libvirtd
chkconfig xend on
chkconfig libvirtd on
chkconfig --list xend
chkconfig --list libvirtd
- Add a suitable grub entry for Xen.
This grub entry is just an example, keep your own root device uuids/names etc
and modify to suit your setup:
menuentry 'Xen dom0, Fedora Linux 3.1.0-rc6' --class fedora --class gnu-linux
--class gnu --class os {
load_video
insmod part_gpt
insmod ext2
set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root
6b84e53a-8a3a-4465-ac5a-c1c98758e448
multiboot /xen-4.1.gz placeholder dom0_mem=1024M loglvl=all
guest_loglvl=all console_to_ring cpuidle=xen
echo'Loading Linux 3.1.0-rc6 ...'
module /vmlinuz-3.1.0-rc6 root=/dev/mapper/VolGroup00-lv_root ro
rd.md=0 rd.dm=0 KEYTABLE=us debug loglvel=8 rd.lvm.lv=VolGroup00/lv_swap
SYSFONT=latarcyrheb-sun16 rd.luks=0 rd.lvm.lv=VolGroup00/lv_root
LANG=en_US.UTF-8
echo'Loading initial ramdisk ...'
module /initramfs-3.1.0-rc6.img
}
grub entries will be automatically generated later, but currently grub/grubby
does not have all required patches to do it automatically.
- Reboot to Xen dom0!
- Verify Xen and xend works:
xm info
xm list
- Verify you have a bridge called "virbr0" (use: "brctl show"). It should get
created by libvirtd.
There should be a "dnsmasq" process running for virbr0 providing that bridge
a DHCP server with private IPs,
dns relay and NAT to internet, so you can use it for VM network installations.
- Install a Fedora 15 Xen PV domU:
First create a new LVM volume for the VM:
lvcreate -L30G -nf15_disk1 /dev/VolGroup00
(Replace VolGroup00 with your VG name.. use "vgdisplay" to check.)
Start actual installation:
virt-install -d -n f15 -r 1024 --vcpus=1 -f /dev/VolGroup00/f15_disk1 --vnc
-p -l
"ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/x86_64/os/";
(replace the URL with your local Fedora mirror site).
virt-install will open a virt-viewer (VNC) graphical window of the guest
console (pvfb) where you can do the Fedora installation as usual.
- Install and test various other types of VMs, both PV and HVM.
- Try using file: disk backend (image files) aswell.
- Try using graphical "virt-manager" GUI to install Xen VMs.
- Disable automatic start of xend, reboot, and test xl / libxl,
also with virt-manager/virt-install.
That should get you started with testing.
Btw. I noticed some issues installing F16 Alpha Xen PV domU, so F16 needs some
more investigation/debugging before F16 final.
-- Pasi
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Xen-devel] Re: Virtualization Test Day for F16 and Xen
On Wed, Sep 14, 2011 at 10:25:23AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 14, 2011 at 02:25:52PM +0300, Pasi Kärkkäinen wrote: > > On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: > > >Hi, > > > > Hello, > > > > >Virtualization Test day is expected to be on September 15th this year > > >([1]https://fedorahosted.org/fedora-qa/ticket/232). > > Cool. > > > > > > > So that's tomorrow! > > > > Luckily Xen Hackathon (@Munich) event is just happening, > > so hopefully we can get some more testing from people in that event. > > > > >We are willing to help test > > >[2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too > > > little > > >information about test methods > > It really ought to be parallel to what you would do with KVM/QEMU. Basically > the same steps - but I am not sure how well does libvirt work with xm/xl > nowadays. > Or the virt-manager - but it suppose to interact with magically. > libvirt support for xm/xend *should* work, and there's also the libvirt libxl driver written by Jim Fehlig from Novell/SUSE. > Is there a KVM/QEMU/libvirt help test Wiki? I saw this: > https://fedoraproject.org/wiki/Getting_started_with_virtualization > and it kind of parallels it, albeit I didn't see anything about setting the > network > which sometimes is the biggest pain point: > > http://www.fedoraforum.org/forum/showthread.php?t=268427 > When you install libvirt it'll automatically create/start a bridge called "virbr0", which is an host-internal bridge with "dnsmasq" running and configured to provide dhcp server with private ip range, dns relay and NAT on that bridge. So that's good enough for trying some VMs or running VM netboot installs. > > > >([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for > > > us > > >to setup test environment, and would be good to have some info in > > > advance. > > > There are known bugs in FC15/FC16 that have been filled some time ago that > folks will sadly run into: 728775, 658387 and 668063 > > Fortunatly the bugs have patches attached and the files to be modified are > shell scripts. > Yep, links here: https://bugzilla.redhat.com/show_bug.cgi?id=728775 https://bugzilla.redhat.com/show_bug.cgi?id=658387 https://bugzilla.redhat.com/show_bug.cgi?id=668063 -- Pasi > > >Regards, > > > > > > > I just added some Xen related mailinglists to the CC list, > > so we can get more feedback. > > > > Thanks, > > > > -- Pasi > > > > > > ___ > > Xen-devel mailing list > > xen-de...@lists.xensource.com > > http://lists.xensource.com/xen-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Virtualization Test Day for F16 and Xen
On Sat, Sep 10, 2011 at 01:33:54AM +0300, Myroslav Opyr wrote: >Hi, Hello, >Virtualization Test day is expected to be on September 15th this year >([1]https://fedorahosted.org/fedora-qa/ticket/232). > So that's tomorrow! Luckily Xen Hackathon (@Munich) event is just happening, so hopefully we can get some more testing from people in that event. >We are willing to help test >[2]http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little >information about test methods >([3]https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us >to setup test environment, and would be good to have some info in advance. >Regards, > I just added some Xen related mailinglists to the CC list, so we can get more feedback. Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grubby and Xen (patch to apply) - needed for F16
On Wed, Aug 10, 2011 at 03:02:39PM +0300, Pasi Kärkkäinen wrote: > On Sun, Aug 07, 2011 at 09:41:17PM +0300, Pasi Kärkkäinen wrote: > > On Mon, Jul 25, 2011 at 08:36:00AM -0400, Adam Jackson wrote: > > > On 7/25/11 8:31 AM, Roman Rakus wrote: > > > > On 07/25/2011 04:38 AM, W. Michael Petullo wrote: > > > >> Is anyone who is a grubby contributor interested in adding these > > > >> features > > > >> to grubby to support the XenPvopsDom0 feature? I've provided a patch in > > > >> bug #658387. > > > >> > > > > Is it possible to use augeas [1]? There is currently lens for grub.conf > > > > > > > > [1] http://augeas.net/ > > > > > > It may certainly be possible - and perhaps even desirable - to replace > > > grubby with augeas, but that's not really what he asked. > > > > > > > Yep. Anyone willing to apply the patch from #658387 ? > > > > Ping? > Hello again, These two bugs/patches are needed for F16 grubby: https://bugzilla.redhat.com/show_bug.cgi?id=658387 https://bugzilla.redhat.com/show_bug.cgi?id=668063 Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grubby and Xen (patch to apply) - needed for F16
On Sun, Aug 07, 2011 at 09:41:17PM +0300, Pasi Kärkkäinen wrote: > On Mon, Jul 25, 2011 at 08:36:00AM -0400, Adam Jackson wrote: > > On 7/25/11 8:31 AM, Roman Rakus wrote: > > > On 07/25/2011 04:38 AM, W. Michael Petullo wrote: > > >> Is anyone who is a grubby contributor interested in adding these features > > >> to grubby to support the XenPvopsDom0 feature? I've provided a patch in > > >> bug #658387. > > >> > > > Is it possible to use augeas [1]? There is currently lens for grub.conf > > > > > > [1] http://augeas.net/ > > > > It may certainly be possible - and perhaps even desirable - to replace > > grubby with augeas, but that's not really what he asked. > > > > Yep. Anyone willing to apply the patch from #658387 ? > Ping? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grubby and Xen (patch to apply)
On Mon, Jul 25, 2011 at 08:36:00AM -0400, Adam Jackson wrote: > On 7/25/11 8:31 AM, Roman Rakus wrote: > > On 07/25/2011 04:38 AM, W. Michael Petullo wrote: > >> Is anyone who is a grubby contributor interested in adding these features > >> to grubby to support the XenPvopsDom0 feature? I've provided a patch in > >> bug #658387. > >> > > Is it possible to use augeas [1]? There is currently lens for grub.conf > > > > [1] http://augeas.net/ > > It may certainly be possible - and perhaps even desirable - to replace > grubby with augeas, but that's not really what he asked. > Yep. Anyone willing to apply the patch from #658387 ? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Thu, Jul 21, 2011 at 08:52:08AM -0700, Adam Williamson wrote: > On Tue, 2011-07-19 at 23:14 +0300, Pasi Kärkkäinen wrote: > > On Tue, Jul 19, 2011 at 09:56:11AM -0700, Adam Williamson wrote: > > > On Tue, 2011-07-19 at 13:46 +0300, Pasi Kärkkäinen wrote: > > > > > > > > I think I recall discussing this with the anaconda team before; we > > > > > agreed in principle that it would make sense for anaconda to default > > > > > to > > > > > clone mode, but the problem is X doesn't have any very easy mechanism > > > > > for overriding the default, there is no simple command line parameter > > > > > anaconda could pass to X to launch it in clone mode instead of span > > > > > mode. anaconda would have to include an X config stub to specify clone > > > > > mode and then ensure that stub wasn't installed. I think no-one got > > > > > around to getting that done yet. I'm not sure if there's a bug for it, > > > > > but you could have a look. > > > > > > > > > > > > > Did you mean Redhat bugzilla or Freedesktop/Xorg bugzilla? > > > > With some searching I couldn't find one.. should I file a > > > > bugreport/rfe? > > > > > > I don't recall, it may well have been just an IRC conversation. A bug > > > report would certainly be a good idea, then we won't lose track of it > > > again =) > > > > > > > Ok :) > > > > Should I file it against xorg or anaconda? > > The basic bug - 'anaconda should run in clone not span mode' - against > anaconda. Depending on how that bug goes, we may wind up filing some > kind of enhancement request for X, I guess. > Done. "anaconda should run in clone not span mode": https://bugzilla.redhat.com/show_bug.cgi?id=725219 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 19, 2011 at 09:56:11AM -0700, Adam Williamson wrote: > On Tue, 2011-07-19 at 13:46 +0300, Pasi Kärkkäinen wrote: > > > > I think I recall discussing this with the anaconda team before; we > > > agreed in principle that it would make sense for anaconda to default to > > > clone mode, but the problem is X doesn't have any very easy mechanism > > > for overriding the default, there is no simple command line parameter > > > anaconda could pass to X to launch it in clone mode instead of span > > > mode. anaconda would have to include an X config stub to specify clone > > > mode and then ensure that stub wasn't installed. I think no-one got > > > around to getting that done yet. I'm not sure if there's a bug for it, > > > but you could have a look. > > > > > > > Did you mean Redhat bugzilla or Freedesktop/Xorg bugzilla? > > With some searching I couldn't find one.. should I file a bugreport/rfe? > > I don't recall, it may well have been just an IRC conversation. A bug > report would certainly be a good idea, then we won't lose track of it > again =) > Ok :) Should I file it against xorg or anaconda? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, Jul 13, 2011 at 10:44:21AM -0700, Adam Williamson wrote: > On Wed, 2011-07-13 at 15:21 +0300, Pasi Kärkkäinen wrote: > > On Tue, Jul 12, 2011 at 05:01:11PM -0400, Adam Jackson wrote: > > > On Tue, 2011-07-12 at 23:44 +0300, Pasi Kärkkäinen wrote: > > > > Hello list, > > > > > > > > I'm curious to know how many laptops have problems with > > > > ACPI lid state in Linux. I've been told some laptops report > > > > wrong lid state through ACPI, while my laptop seems to report it > > > > properly. > > > > > > Once you have this data, what do you intend to do with it? > > > > > > > Good question. I was just curious to know how widespread problem that is. > > > > I tend to use my laptop in the docking station, only using external monitor, > > so it's annoying when testing new alpha/beta/final Fedora releases > > and Fedora uses the internal lvds, under the *closed* lid, as a primary > > display.. > > ie. the installer/livedesktop is not visible at all on my setup, until I > > open the lid. > > > > So just trying to find some kind of workaround to that.. > > Using "clone-mode" as a default would solve the problem.. > > (now the default mode in Fedora is to use "extended desktop") > > I think I recall discussing this with the anaconda team before; we > agreed in principle that it would make sense for anaconda to default to > clone mode, but the problem is X doesn't have any very easy mechanism > for overriding the default, there is no simple command line parameter > anaconda could pass to X to launch it in clone mode instead of span > mode. anaconda would have to include an X config stub to specify clone > mode and then ensure that stub wasn't installed. I think no-one got > around to getting that done yet. I'm not sure if there's a bug for it, > but you could have a look. > Did you mean Redhat bugzilla or Freedesktop/Xorg bugzilla? With some searching I couldn't find one.. should I file a bugreport/rfe? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Thu, Jul 14, 2011 at 10:37:51AM +0300, Pasi Kärkkäinen wrote: > On Thu, Jul 14, 2011 at 09:11:23AM +0200, Hans de Goede wrote: > > Hi, > > > > On 07/13/2011 07:47 PM, Adam Williamson wrote: > > > On Wed, 2011-07-13 at 11:35 -0400, Adam Jackson wrote: > > >> On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: > > >> > > >>> Maybe it it is an idea to build a whitelist for machines which do > > >>> have working ACPI lid support? I realize maintaining such a list is > > >>> a pain, but this way people who care and are lucky enough to have > > >>> actually > > >>> working hardware can at least use this ? > > >> > > >> It's an idea, but not one I'd do. Either a whitelist or a blacklist > > >> would be oppressively large. > > > > > > I suppose a whitelist has the advantage that it can't hurt anything > > > compared to the current state, and no matter how short it is, it > > > benefits *some* people. > > > > Yeah, that is my main reason for suggesting this, thanks for wording it > > so eloquently for me :) Note I'm not volunteering to do the work > > -ENOTIME. > > > > Would something like "use_acpi_lid_status" kernel cmdline option be too ugly? > :) > At least it would be easy to parse (grep /proc/cmdline) .. > Any comments about this way of doing it? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Thu, Jul 14, 2011 at 09:11:23AM +0200, Hans de Goede wrote: > Hi, > > On 07/13/2011 07:47 PM, Adam Williamson wrote: > > On Wed, 2011-07-13 at 11:35 -0400, Adam Jackson wrote: > >> On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: > >> > >>> Maybe it it is an idea to build a whitelist for machines which do > >>> have working ACPI lid support? I realize maintaining such a list is > >>> a pain, but this way people who care and are lucky enough to have actually > >>> working hardware can at least use this ? > >> > >> It's an idea, but not one I'd do. Either a whitelist or a blacklist > >> would be oppressively large. > > > > I suppose a whitelist has the advantage that it can't hurt anything > > compared to the current state, and no matter how short it is, it > > benefits *some* people. > > Yeah, that is my main reason for suggesting this, thanks for wording it > so eloquently for me :) Note I'm not volunteering to do the work > -ENOTIME. > Would something like "use_acpi_lid_status" kernel cmdline option be too ugly? :) At least it would be easy to parse (grep /proc/cmdline) .. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 12, 2011 at 10:01:25PM +0100, Matthew Garrett wrote: > On Tue, Jul 12, 2011 at 11:44:59PM +0300, Pasi Kärkkäinen wrote: > > > I guess that should cover all the usecases.. > > Please post your findings to this list. > > Please don't. ACPI lid state is not reliable on a range of hardware for > a bunch of reasons, ranging from open events that are never fired to > query methods that read from the wrong register. We can't pay attention > to it by default, and running a survey doesn't change that. > Ok. Do you know if there are other (better working) methods to get the lid state info? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 12, 2011 at 05:01:11PM -0400, Adam Jackson wrote: > On Tue, 2011-07-12 at 23:44 +0300, Pasi Kärkkäinen wrote: > > Hello list, > > > > I'm curious to know how many laptops have problems with > > ACPI lid state in Linux. I've been told some laptops report > > wrong lid state through ACPI, while my laptop seems to report it properly. > > Once you have this data, what do you intend to do with it? > Good question. I was just curious to know how widespread problem that is. I tend to use my laptop in the docking station, only using external monitor, so it's annoying when testing new alpha/beta/final Fedora releases and Fedora uses the internal lvds, under the *closed* lid, as a primary display.. ie. the installer/livedesktop is not visible at all on my setup, until I open the lid. So just trying to find some kind of workaround to that.. Using "clone-mode" as a default would solve the problem.. (now the default mode in Fedora is to use "extended desktop") -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Poll: Does ACPI lid state work on your Linux laptop?
Hello list, I'm curious to know how many laptops have problems with ACPI lid state in Linux. I've been told some laptops report wrong lid state through ACPI, while my laptop seems to report it properly. This poll is related to Fedora bugreport: "ACPI LID state ignored on laptop, wrong display used for desktop/installer": https://bugzilla.redhat.com/show_bug.cgi?id=712706 So, if you want to help and test this on your laptop, please try these things with recent Fedora/kernel: - You can check the ACPI lid state like this: cat /proc/acpi/button/lid/LID/state - Set up external monitor/display, and disable the laptop internal LVDS display panel using xrandr or gnome display settings tool. 1) Close the laptop LID and then check the lid state. Is it reported correct? 2) Open the laptop LID and then check the lid state. Is it reported correct? 3) Repeat the previous steps multiple times. Is the lid state still reported correctly? 4) Reboot the laptop with LID closed. Then check the lid state, is it properly reported as closed? 5) Reboot the laptop with LID open. Then check the lid state, is it properly reported as open? The point of checks 4 and 5 is to verify the "initial" lid state is correctly reported. I guess that should cover all the usecases.. Please post your findings to this list. btw. if you don't have external display you could also ssh into the laptop and run the tests over ssh. Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
On Sun, Jun 12, 2011 at 08:54:40PM +0200, Andreas Tunek wrote: > 2011/6/12 José Matos : > > On Sunday 12 June 2011 18:26:25 Pasi Kärkkäinen wrote: > >> > What is the graphics card? > >> > > >> > > >> > >> It's ATI radeon RV635. Do you have the same graphics card? > > > > I think so (but I think that are mixing the references :-) ): > > > > # lspci | grep ATI > > 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD > > 3650 > > 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD > > 3600 > > Series] > > > > so I think that the 365 here refers to the digital sound part. > > > >> Thanks for the reply! > > > > Glad to help. :-) > > > >> -- Pasi > > > > -- > > José Abílio > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > You are probably hitting https://bugzilla.redhat.com/show_bug.cgi?id=702953 > That could be it.. I'll try if "echo mid > /sys/class/drm/card0/device/power_profile" helps. Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
On Sun, Jun 12, 2011 at 07:24:38PM +0100, José Matos wrote: > On Sunday 12 June 2011 18:26:25 Pasi Kärkkäinen wrote: > > > What is the graphics card? > > > > > > > > > > It's ATI radeon RV635. Do you have the same graphics card? > > I think so (but I think that are mixing the references :-) ): > > # lspci | grep ATI > 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD > 3650 > 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 > Series] > > so I think that the 365 here refers to the digital sound part. > Doh, of course :) > > Thanks for the reply! > > Glad to help. :-) > -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
On Sun, Jun 12, 2011 at 06:20:55PM +0100, José Matos wrote: > On Sunday 12 June 2011 16:56:33 Pasi Kärkkäinen wrote: > > Hello list, > > > > Any tips how to debug why laptop CPU temperature is around 30 degrees > > celsius higher on Fedora 14 or Fedora 15 compared to Windows 7 ? Both > > Linux and Windows were idle when measuring.. > > > > I tried both Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38). > > Laptop specs: > > - HP Elitebook 8530p. > > - CPU: Mobile Intel Core 2 Duo T9600 (Penryn). > > > > Results: > > - Windows: CPU is 57 - 65 celsius when idle. > > - Fedora/Linux: CPU is 85 - 95 celsius when idle. > > > > The laptop definitely feels much more hot when in Linux > > and sometimes shuts down with thermal overheating warning. > > That overheating problem never happens in Windows. > > > > Checking "powertop" in Linux shows the CPU is mostly running > > with the lowest MHz available. Not much "idle" time though.. > > > > I was using "Core Temp" in Windows and /sys ACPI interface in Linux: > > > > # cat /sys/bus/acpi/devices/LNXTHERM\:03/thermal_zone/temp > > 86000 > > > > # cat /sys/bus/acpi/devices/LNXTHERM\:03/path > > \_TZ_.CPUZ > > > > "acpi -t" also shows the same CPU temperature. > > Fedora 15 Linux 2.6.38 dmesg here: > > http://pasik.reaktio.net/fedora/f15/cputemp/dmesg-laptop-f15.txt > > > > > > Any ideas how to track what's causing that? All suggestions welcome! > > Thanks, > > > > -- Pasi > > What is the graphics card? > It's ATI radeon RV635. Do you have the same graphics card? > I am running this from a laptop of the same model and I see: > > $ sensors > acpitz-virtual-0 > Adapter: Virtual device > temp1:+30.0°C (crit = +115.0°C) > temp2:+50.0°C (crit = +105.0°C) > temp3:+26.6°C (crit = +112.0°C) > temp4:+58.0°C (crit = +112.0°C) > temp5:+46.0°C (crit = +90.0°C) > temp6:+16.0°C (crit = +112.0°C) > So your CPU temp is what it should be.. > radeon-pci-0100 > Adapter: PCI adapter > temp1:+58.0°C > > coretemp-isa- > Adapter: ISA adapter > Core 0: +51.0°C (high = +105.0°C, crit = +105.0°C) > > coretemp-isa-0001 > Adapter: ISA adapter > Core 1: +50.0°C (high = +105.0°C, crit = +105.0°C) > > The only thing I have done in order to cool down graphics card was to run: > > # echo mid > /sys/class/drm/card0/device/power_profile > Oh, I wasn't aware of this. I'll try and see if that makes a difference. > instead of the default value auto (that alternates between mid (middle) and > high) for the graphics card. > > Definitivily I saw an improvement between F14 and F15. > > Running the graphics card power profile as low brings the temperature even > lower (at the expense of some slower window updates). > > FWIW I never had a problem with overheating. > Ok, good to know. > Regarding the comparison with windows (win.. what?) ;-) this computer came > with freedos installed so no such luck here. :-D > :) Thanks for the reply! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Laptop CPU overheating in Fedora, temperature +30 celsius higher than in Windows
Hello list, Any tips how to debug why laptop CPU temperature is around 30 degrees celsius higher on Fedora 14 or Fedora 15 compared to Windows 7 ? Both Linux and Windows were idle when measuring.. I tried both Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38). Laptop specs: - HP Elitebook 8530p. - CPU: Mobile Intel Core 2 Duo T9600 (Penryn). Results: - Windows: CPU is 57 - 65 celsius when idle. - Fedora/Linux: CPU is 85 - 95 celsius when idle. The laptop definitely feels much more hot when in Linux and sometimes shuts down with thermal overheating warning. That overheating problem never happens in Windows. Checking "powertop" in Linux shows the CPU is mostly running with the lowest MHz available. Not much "idle" time though.. I was using "Core Temp" in Windows and /sys ACPI interface in Linux: # cat /sys/bus/acpi/devices/LNXTHERM\:03/thermal_zone/temp 86000 # cat /sys/bus/acpi/devices/LNXTHERM\:03/path \_TZ_.CPUZ "acpi -t" also shows the same CPU temperature. Fedora 15 Linux 2.6.38 dmesg here: http://pasik.reaktio.net/fedora/f15/cputemp/dmesg-laptop-f15.txt Any ideas how to track what's causing that? All suggestions welcome! Thanks, -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On Thu, Apr 14, 2011 at 08:59:49AM -0500, Eric Sandeen wrote: > > >> What kind of SSD is it? > > > > OCZ Vertex 2 with firmware 1.25 (this is not the latest version, but I > > did not have too much courage to update it :)) > > Ok. We (the ext4 list) had a report a year ago or so where someone had > really debugged some odd behavior with one ssd and its firmware, but not this > one :) > > So not the same thing exactly, at least. > > > > > Do the barriers are somehow dependent on the hardware? Maybe I need to > > look in the SSD documentation to find out if proper commands are > > supported? > > I don't think you'll find that sort of thing; it's a question of implementing > the spec properly, really. All I meant is that it is -possible- for hardware > to be broken or noncompliant, so it's -possible- that that's what you're > seeing. I'm NOT saying that the OCZ-VERTEX2 -is- broken, just musing that > the hardware needs to exhibit proper behavior as much as the application > needs to issue the right data integrity syscalls. :) > I remember reading on the ZFS list that the consumer Vertex2 models do not have a battery backup (or a supercapasitor) to flush the internal cache in the case of power loss. So they'll corrupt the data in the case of power loss.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] This week is Graphics Test Week
On Sun, Feb 20, 2011 at 09:06:03PM -0800, Adam Williamson wrote: > Hi, Fedorans. Please be informed that this week is Fedora Graphics Test > Week. Tuesday 2011-02-22 is Nouveau Test Day [1], Wednesday 2011-02-23 > is Radeon Test Day [2] and Thursday 2011-02-24 is Intel (graphics) Test > Day [3]. > > Testing is very easy and can be done entirely with a live image, there's > no need to install F15 or Rawhide; full instructions are available on > the Wiki pages. QA folks and graphics developers will be in > #fedora-test-day during the events. These test days are super-important > this release because we'll be checking out the support for GNOME Shell, > one of the major features of F15; we really need to get a good idea of > the state of hardware support for the Shell, so PLEASE do come out and > help test if you have any spare time this week! Also please help spread > the word anywhere you can - your local enthusiast community, any news > websites you know, particularly ones in non-English languages (as I'm > not great at covering those). > > There's a longer write-up on my blog [4]. Please get in touch with me > directly or the test mailing list if you have any questions or > suggestions. Thanks! > > [1] http://fedoraproject.org/wiki/Test_Day:2011-02-22_Nouveau > [2] http://fedoraproject.org/wiki/Test_Day:2011-02-23_Radeon > [3] http://fedoraproject.org/wiki/Test_Day:2011-02-24_Intel > [4] http://www.happyassassin.net/2011/02/20/its-graphics-test-week-again/ > Hello, I'd like to remind about issues I've had with graphics in Fedora.. ie. support for laptops with external monitors (in a docking station). I can probably attend the radeon test day and try my setup, but others should test this stuff aswell! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Sun, Oct 17, 2010 at 02:05:34PM +0300, Pasi Kärkkäinen wrote: > On Thu, Oct 07, 2010 at 09:43:22PM +0200, Dan Horák wrote: > > Pasi Kärkkäinen píše v ??t 07. 10. 2010 v 22:29 +0300: > > > On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: > > > > On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: > > > > > > > > > > that bug is already inconvenient for some people; if they have > > > > > > laptops > > > > > > with bad lid switches it'd be much more inconvenient. The only > > > > > > active > > > > > > display would be the external display they weren't actually using. > > > > > > > > > > I read that bugzilla as it's a driver bug.. so it'll get fixed at > > > > > some point. > > > > > > > > Not really; the driver isn't able to detect if connected monitors are > > > > turned on. It's not clear if this is really *theoretically* possible, > > > > which is why the report's been closed. And it doesn't cover the case > > > > where a connected monitor is powered on but not actually being used for > > > > the computer. > > > > > > > > > > Hmm... things seem to work always ok on Windows, so it should be > > > possible.. > > > > And I dare to call the recent behaviour a regression, because IIRC it > > worked well until one (not identified) update in F-12. > > > > > > Also it would be perfectly ok if I could enable "trust_acpi_lid_state" option > somewhere (since I know it works on my laptop), but today we don't have a > daemon/tool/script to handle laptop lids.. > > So we're not even trying to do the right thing.. > I was asking about the "monitor connected but turned off" thing on dri-devel, and the reply was that it's impossible to detect if the display is turned on or off. Displays are designed to always send the EDID info, no difference if they're on or off. So.. we can't detect that. And others can't either. What we need is a daemon/tool/script that monitors the ACPI LID state and enables/disables the internal LVDS based on that, and also enables/disables the external monitors based on their "connected" status. If the external monitor is connected but turned off then the user just has to turn the monitor on to see the content. The bigger problem was the laptop LID thing, and this solution fixes that. (bugs in acpi drivers or hardware aside). A couple of possible scenarios: - Laptop lid closed, external monitor connected and on -> only external display should be enabled. - Laptop lid closed, external monitor connected but off -> only external display should be enabled. - Laptop lid open, external monitor connected and on -> both internal lvds and external display should be enabled. - Laptop lid open, external monitor connected but off -> both internal lvds and external display should be enabled. - Laptop lid open, no external monitor connected -> only internal lvds should be enabled. - Laptop lid closed, no external monitor connected -> what to do here? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in curl makes Fedora ftp:// URL installations fail with some mirrors
On Mon, Oct 18, 2010 at 09:44:47AM -0500, Chris Adams wrote: > Once upon a time, Chuck Anderson said: > > On Sun, Oct 17, 2010 at 02:03:20PM +0300, Pasi Kärkkäinen wrote: > > > Yes, indeed, it seems more likely a bug in the FTP server (pure-ftpd), > > > but it would be very nice to have a workaround in curl or in anaconda for > > > it.. > > > > Why not fix the the problem at the source? > > Under the "be generous in what you accept", curl should be changed to > handle this (especially if other clients can handle it). > > Looking at a packet dump, I'm not sure which side is at fault. FTP > allows you to specify the start of data (start at offset 1384) but not > an end, so the only way to get less than the full rest of the file is to > abort the data transfer. It looks like curl just closes the data socket > without sending an ABOR on the command socket, so I think the server is > allowed to dump the client. > > It would be nicer for the server to handle this better as well, but I > think the problem starts with curl. > There now curl updates.img available for F14 anaconda. so people who care about this curl issue should test the updates.img so we can figure out if the curl patch fixes the issue. https://bugzilla.redhat.com/show_bug.cgi?id=643656 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Thu, Oct 07, 2010 at 09:43:22PM +0200, Dan Horák wrote: > Pasi Kärkkäinen píše v ??t 07. 10. 2010 v 22:29 +0300: > > On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: > > > On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: > > > > > > > > that bug is already inconvenient for some people; if they have laptops > > > > > with bad lid switches it'd be much more inconvenient. The only active > > > > > display would be the external display they weren't actually using. > > > > > > > > I read that bugzilla as it's a driver bug.. so it'll get fixed at some > > > > point. > > > > > > Not really; the driver isn't able to detect if connected monitors are > > > turned on. It's not clear if this is really *theoretically* possible, > > > which is why the report's been closed. And it doesn't cover the case > > > where a connected monitor is powered on but not actually being used for > > > the computer. > > > > > > > Hmm... things seem to work always ok on Windows, so it should be possible.. > > And I dare to call the recent behaviour a regression, because IIRC it > worked well until one (not identified) update in F-12. > > Also it would be perfectly ok if I could enable "trust_acpi_lid_state" option somewhere (since I know it works on my laptop), but today we don't have a daemon/tool/script to handle laptop lids.. So we're not even trying to do the right thing.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in curl makes Fedora ftp:// URL installations fail with some mirrors
On Sun, Oct 17, 2010 at 09:29:48AM +0100, Richard W.M. Jones wrote: > On Sat, Oct 16, 2010 at 11:49:39PM +0300, Pasi Kärkkäinen wrote: > > You can reproduce the bug like this: > > curl -o iputils-20071127-10.fc13.x86_64.rpm --range 1384-1400 > > ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/13/Fedora/x86_64/os/Packages/iputils-20071127-10.fc13.x86_64.rpm > > > > It gives error "(28) FTP response timeout" after around one minute. > > (1384 is the size of the header in many rpms). > > That command worked fine for me, with curl-7.21.0-5.fc14.x86_64, but I > realized that it worked because I was using a proxy. So I would > suggest people do: > > unset ftp_proxy > > before running the test. The command fails in the way you described > without a proxy. > > I looked at the trace (curl -v) and it looks like the FTP server > itself is not responding correctly. The problem does not seem to be > the REST command, but the short RETR: curl only downloads 17 bytes > then closes the connection, but this appears to confuse the FTP > server. The FTP server appears to die when this happens, whereas I > think I would expect it to send an error message on the control > connection. > Yes, indeed, it seems more likely a bug in the FTP server (pure-ftpd), but it would be very nice to have a workaround in curl or in anaconda for it.. I'm sure ftp.funet.fi is not the only Fedora mirror running pure-ftpd. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bug in curl makes Fedora ftp:// URL installations fail with some mirrors
Hello, This bug is present in Fedora 13, and probably in Fedora 14 aswell. Initial report about the issue: "Fedora 13 installer fails to fetch some files from FTP mirror and installation fails, wget works ok": https://bugzilla.redhat.com/show_bug.cgi?id=624431 Actual bug: "curl range support (REST) is broken with some FTP servers: "(28) FTP response timeout": https://bugzilla.redhat.com/show_bug.cgi?id=643656 Short version: Anaconda installer uses urlgrabber to grab the rpms from the mirror site, and urlgrabber uses pycurl, which uses curl. When anaconda requests urlgrabber to skip the rpm headers using byte ranges, it makes curl to issue ftp REST command to skip specific amount of bytes. Curl doesn't seem to work with some FTP servers when using the REST command, and the transfer times out, and fails, which makes the whole Fedora installation fail. Example of failing Fedora mirror: ftp.funet.fi (which is the original home of Linux kernel, and it's a very well connected FTP mirror site in Europe). You can reproduce the bug like this: curl -o iputils-20071127-10.fc13.x86_64.rpm --range 1384-1400 ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/13/Fedora/x86_64/os/Packages/iputils-20071127-10.fc13.x86_64.rpm It gives error "(28) FTP response timeout" after around one minute. (1384 is the size of the header in many rpms). -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: > On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: > > > > that bug is already inconvenient for some people; if they have laptops > > > with bad lid switches it'd be much more inconvenient. The only active > > > display would be the external display they weren't actually using. > > > > I read that bugzilla as it's a driver bug.. so it'll get fixed at some > > point. > > Not really; the driver isn't able to detect if connected monitors are > turned on. It's not clear if this is really *theoretically* possible, > which is why the report's been closed. And it doesn't cover the case > where a connected monitor is powered on but not actually being used for > the computer. > Hmm... things seem to work always ok on Windows, so it should be possible.. > > We should define "policy" based on wanted behaviour, not based on various > > bugs out there.. Bugs need to be fixed, and then the policy works like it's > > expected. > > In theory, yeah, but in practice, we can't take this to extremes if it > means we wind up with people staring at blank screens with no apparent > explanation. > Well, I'm staring at blank screens with the current behaviour.. :) > > atm we're lacking a policy regarding these laptop lid/dock things. > > Ie. there's no daemon/script even trying to do the right thing.. > > > > (drm/kms driver guys have made it clear the "policy" has to be decided and > > set up by userspace). > > > > For the "transition period" we could have a boot/grub menu item > > that automatically enables the "old behaviour" for people who have > > hardware with buggy bios/drivers. Just like we have the "safe (vesa) > > graphics" > > boot option on install CDs. > > > > Does this make sense? > > No, not really, parameters aren't magic, they can only do things if the > drivers / userspace utilities are written with these parameters in mind. > I don't believe there's any such framework at present, and besides, we > want to have *fewer* icky bootloader menu workarounds, really, not more. > Ok. But yes, we need some daemon that monitors ACPI lid state, and kms/drm output states, and enables/disables displays based on those. We're clearly lacking that atm. Driver developers have made it clear userspace needs a component that takes care of that. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Wed, Oct 06, 2010 at 02:31:22PM -0700, Adam Williamson wrote: > On Wed, 2010-10-06 at 23:32 +0300, Pasi Kärkkäinen wrote: > > > What's the worst thing that can happen when trusting the ACPI lid state? > > > > Think about this: > > > > - Laptop lid open (so internal lvds enabled), and also external monitor > > connected. > > - lid state is wrong at boot, so it says lid closed. > > - Scripts check: "lid closed, external display enabled -> use only external > > monitor". > > > > That gives you a working setup, you can login using the external display, > > and use the system perfectly fine. You can then manually enable the > > internal lvds display, or possibly enable some workaround, > > as you have a buggy laptop/driver/bios. > > > > That doesn't sound bad at all. > > However, it's not the worst case. The worst case is if someone has an > external monitor connected which they're not actually using (it may be > hidden or being used with some other input or just turned off). This > does happen: > > https://bugzilla.redhat.com/show_bug.cgi?id=582525 > > that bug is already inconvenient for some people; if they have laptops > with bad lid switches it'd be much more inconvenient. The only active > display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. We should define "policy" based on wanted behaviour, not based on various bugs out there.. Bugs need to be fixed, and then the policy works like it's expected. atm we're lacking a policy regarding these laptop lid/dock things. Ie. there's no daemon/script even trying to do the right thing.. (drm/kms driver guys have made it clear the "policy" has to be decided and set up by userspace). For the "transition period" we could have a boot/grub menu item that automatically enables the "old behaviour" for people who have hardware with buggy bios/drivers. Just like we have the "safe (vesa) graphics" boot option on install CDs. Does this make sense? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Wed, Oct 06, 2010 at 12:33:58PM -0700, Adam Williamson wrote: > On Wed, 2010-10-06 at 22:03 +0300, Pasi Kärkkäinen wrote: > > On Tue, Oct 05, 2010 at 11:28:43AM -0700, Adam Williamson wrote: > > > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote: > > > > On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: > > > > > > > > > don't we already have default behaviours based on the lid switch, > > > > > anyway? So why don't we have this problem with those? IIRC, we default > > > > > to suspending the system when the lid is closed on battery power - so > > > > > are we suspending people's systems at random, if those systems have > > > > > lying lid switches? > > > > > > > > Because we only do that on lid state transitions. > > > > > > So we could at least cover the case where you plug in an external > > > monitor, then close the lid? That would be better than nothing. I assume > > > the problem case is booting with the lid closed and an external monitor > > > connected. > > > > > > > Exactly, that's the problematic case. > > > > When you boot F14 laptop lid closed and only external monitor > > connected, GDM still appears only on the closed internal LVDS, > > not on the external monitor where is should be. > > So the behaviour is clearly wrong. > > > > This is on HP laptop with radeon graphics. > > > > You're missing the nuance of the debate. What I mean by 'problem case' > is that, according to mjg59, lid sensors don't always actually work > correctly; there are many documented cases of systems whose lid switches > report incorrect state, especially at boot. So we can't just say 'always > enable the external monitor and disable the internal monitor if the lid > switch says 'closed' and there's an external monitor connected', because > the lid switch might be lying. > Well.. I think as a default we should trust the lid state. Buggy drivers should be fixed. Buggy BIOSes should be reported to system vendors. What's the worst thing that can happen when trusting the ACPI lid state? Think about this: - Laptop lid open (so internal lvds enabled), and also external monitor connected. - lid state is wrong at boot, so it says lid closed. - Scripts check: "lid closed, external display enabled -> use only external monitor". That gives you a working setup, you can login using the external display, and use the system perfectly fine. You can then manually enable the internal lvds display, or possibly enable some workaround, as you have a buggy laptop/driver/bios. That doesn't sound bad at all. The current situation is far more problematic. If you the lid state is "closed" and there are no external connected monitors, then maybe enable the lvds anyway.. Did I miss something? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote: > On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson wrote: > > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote: > >> On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: > >> > >> > don't we already have default behaviours based on the lid switch, > >> > anyway? So why don't we have this problem with those? IIRC, we default > >> > to suspending the system when the lid is closed on battery power - so > >> > are we suspending people's systems at random, if those systems have > >> > lying lid switches? > >> > >> Because we only do that on lid state transitions. > > > > So we could at least cover the case where you plug in an external > > monitor, then close the lid? That would be better than nothing. I assume > > the problem case is booting with the lid closed and an external monitor > > connected. > > The BIOS generally manages to get that one correct, can we not query > and keep the current state on boot? > Yep, BIOS gets it correct for me (HP laptop with radeon graphics). For Fedora to get it correct it's enough for to check: $ cat /proc/acpi/button/lid/LID/state state: closed and then disable the internal LVDS, and enable external (connected) monitor. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 11:28:43AM -0700, Adam Williamson wrote: > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote: > > On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: > > > > > don't we already have default behaviours based on the lid switch, > > > anyway? So why don't we have this problem with those? IIRC, we default > > > to suspending the system when the lid is closed on battery power - so > > > are we suspending people's systems at random, if those systems have > > > lying lid switches? > > > > Because we only do that on lid state transitions. > > So we could at least cover the case where you plug in an external > monitor, then close the lid? That would be better than nothing. I assume > the problem case is booting with the lid closed and an external monitor > connected. > Exactly, that's the problematic case. When you boot F14 laptop lid closed and only external monitor connected, GDM still appears only on the closed internal LVDS, not on the external monitor where is should be. So the behaviour is clearly wrong. This is on HP laptop with radeon graphics. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote: > On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote: > > On 5 October 2010 05:30, Orion Poplawski wrote: > > > Are we really stuck with gdm/kdm/lxdm/...dm > > > implementing it? > > > > No, I think what we need to do is to teach GPM how to turn off the > > internal panel when docked and with the lid closed. The only missing > > piece is for the kernel to export some kind of sysfs boolean saying > > "in-dock". From talks with mjg59, detecting a dock is pretty hard. > > Maybe just 'lid closed and external monitor connected' would be close > enough? Is there a use case where you'd want to have an external monitor > connected and the internal system's lid closed, but still have the > internal system's display turned on? > Yep, that's enough info. $ cat /proc/acpi/button/lid/LID/state state: open $ cat /proc/acpi/button/lid/LID/state state: closed That lid info combined with info about external monitors connected or not: $ ls /sys/class/drm/card0 card0-DVI-D-1card0-LVDS-1 dev power uevent card0-HDMI Type A-1 card0-VGA-1 device subsystem $ cat /sys/class/drm/card0/card0-LVDS-1/status connected $ cat /sys/class/drm/card0/card0-LVDS-1/enabled enabled Same info is available for external VGA/DVI/HDMI outputs. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 06:29:21PM -0600, Dariusz J. Garbowski wrote: > On 05/10/10 08:40 AM, FlorianFesti wrote: > > On 10/05/2010 03:15 PM, Nathaniel McCallum wrote: > >> If the lid is open, both output should be enabled by default (you are > >> free to manually disable one). If the lid is closed on battery power > >> the system should suspend (unless you choose otherwise in GPM prefs). > >> > > I wonder if there are latops that can be booted with lid closed and that > > make a subtle sematic difference between the lid was just being closed > > and is lid was already closed when we booted up. > > Dells can boot with lid closed when connected to dock. I do that every day :-) > Yep, I also boot my HP laptop lid closed, in a dock. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Making Fedora work with laptops on docking station with external monitor
Hello, I just tried Fedora 14 Beta LIVE CD and noticed things are still problematic on my setup: - Laptop with radeon graphics - Attached to a docking station with external (DVI) monitor. The lid of the laptop is closed when the laptop is in the docking station, so only the external monitor is in use. Internal LVDS display should not be used at all in this case. Now what happens when Fedora 14 Beta boots up: - I can see the BIOS, grub and kernel booting up on the external monitor. - when GDM starts the external monitor goes blank/black !! - If I open the (closed) laptop LID I can see the internal LVDS display is enabled and GDM login prompt is there !! I was tracking this down, and it happens probably because the internal LVDS is always reported as 'connected' by the radeon driver, so it gets enabled even when the laptop lid is closed. The radeon/drm driver maintainer (Alex Deucher) confirmed this is not a bug, that's how it's designed to be, and the "policy" of enabling/disabling outputs is left to userspace! So, some component in userspace should check the ACPI lid state and based on that enable/disable the internal LVDS. On my laptop ACPI lid state works just fine: $ cat /proc/acpi/button/lid/LID/state state: open or closed, depending if the lid is actually open or closed. So the question is which userspace component should be taking care of disabling the internal LVDS when the laptop lid is closed? - plymouth - GDM - Xorg - gnome-power-manager - something else? Please let us know what you think of this.. This behaviour is very problematic for laptop users who use docking stations, so it would be very nice to get this resolved.. There are many bug reports about this problem on Fedora bugzilla for various Fedora versions. Some bugzilla entries about/related to this problem: "internal LCD under the closed lid used as primary display": https://bugzilla.redhat.com/show_bug.cgi?id=595644 "KMS forcing LVDS laptop display active with lid closed": https://bugzilla.redhat.com/show_bug.cgi?id=539180 "External monitor output is switched off when closing the laptop lid": https://bugzilla.gnome.org/show_bug.cgi?id=589736 "Gnome power manager suspends system when notebook in docking station is closed." https://bugzilla.redhat.com/show_bug.cgi?id=598540 "maybe we shouldn't suspend on lid close if using external inputs and outputs": https://bugzilla.redhat.com/show_bug.cgi?id=546497 Thank you! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deactivating LVDS display when laptop lid is closed
On Wed, Jul 07, 2010 at 08:54:31AM +0200, Dan Horák wrote: > Orion Poplawski píše v Út 06. 07. 2010 v 17:03 -0600: > > Apparently[1] it is up to the desktop environment now to deactivate the > > LVDS > > display if the laptop lid is closed at boot (or whenever?). I now have > > several F13 laptops in docks with external monitors that boot with the lid > > closed, but kdm_greet puts the login panel on the closed LVDS display (see > > bug[2]). I've also filed a Fedora bug for similar stuff here [3]. I don't > > know how gdm behaves. > > I think I have noticed the same behaviour, but with gdm - > https://bugzilla.redhat.com/show_bug.cgi?id=595644 is cloned from older > F-12 bug, because the issue reappeared in F-13. > > Links to related bugzillas: https://bugzilla.redhat.com/show_bug.cgi?id=595644 https://bugzilla.redhat.com/show_bug.cgi?id=539180 https://bugs.freedesktop.org/show_bug.cgi?id=28936 https://bugs.kde.org/show_bug.cgi?id=243807 Any news about this? I have the same problem.. I can help debugging if someone familiar with this stuff can give pointers where to start looking at.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 laptop radeon graphics broken when connected to a docking station
On Tue, May 18, 2010 at 11:13:50AM +0100, Adam Williamson wrote: > On Tue, 2010-05-18 at 09:16 +0300, Pasi Kärkkäinen wrote: > > On Mon, May 17, 2010 at 11:49:52PM +0100, Adam Williamson wrote: > > > On Sun, 2010-05-16 at 19:49 +0300, Pasi Kärkkäinen wrote: > > > > > > > Any ideas how to troubleshoot? > > > > > > https://fedoraproject.org/wiki/How_to_debug_Xorg_problems > > > > > > Please file a bug against xorg-x11-drv-ati . Thanks. > > > > > > > I think there's also a kernel bug here, but I'll investigate more and file > > bugs. > > It's fine to file bugs on the kernel code for ATI adapters against the > ati driver (and same for intel and nouveau); in fact in some ways it's > better, as the bug will actually get assigned to someone who cares > faster. (It'd be nice to have a better mechanism for directing kernel > bugs...) > And here's the bug: https://bugzilla.redhat.com/show_bug.cgi?id=593429 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 laptop radeon graphics broken when connected to a docking station
On Tue, May 18, 2010 at 11:13:50AM +0100, Adam Williamson wrote: > On Tue, 2010-05-18 at 09:16 +0300, Pasi Kärkkäinen wrote: > > On Mon, May 17, 2010 at 11:49:52PM +0100, Adam Williamson wrote: > > > On Sun, 2010-05-16 at 19:49 +0300, Pasi Kärkkäinen wrote: > > > > > > > Any ideas how to troubleshoot? > > > > > > https://fedoraproject.org/wiki/How_to_debug_Xorg_problems > > > > > > Please file a bug against xorg-x11-drv-ati . Thanks. > > > > > > > I think there's also a kernel bug here, but I'll investigate more and file > > bugs. > > It's fine to file bugs on the kernel code for ATI adapters against the > ati driver (and same for intel and nouveau); in fact in some ways it's > better, as the bug will actually get assigned to someone who cares > faster. (It'd be nice to have a better mechanism for directing kernel > bugs...) > Ok.. thanks for the update :) -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 laptop radeon graphics broken when connected to a docking station
On Mon, May 17, 2010 at 11:49:52PM +0100, Adam Williamson wrote: > On Sun, 2010-05-16 at 19:49 +0300, Pasi Kärkkäinen wrote: > > > Any ideas how to troubleshoot? > > https://fedoraproject.org/wiki/How_to_debug_Xorg_problems > > Please file a bug against xorg-x11-drv-ati . Thanks. > I think there's also a kernel bug here, but I'll investigate more and file bugs. Thanks. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?
On Fri, Jan 22, 2010 at 11:04:18PM +0100, Richard Zidlicky wrote: > On Fri, Jan 22, 2010 at 10:05:04PM +0100, Richard Zidlicky wrote: > > On Fri, Jan 22, 2010 at 03:42:47PM -0500, Bill Nottingham wrote: > > > Tony Nelson (tonynel...@georgeanelson.com) said: > > > > > > same opinion here. I have actually used this for a while, adds > > > > > > one more thing that needs be verified after system upgrades, not > > > > > > very nice. > > > > > > > > > > Realistically, the conglomeration of configuration and scripts in > > > > > /etc/sysconfing/network-scripts was never thought out well. But it's > > > > > not worth dealing with the historical baggage to change it now. > > > > > > > > Perhaps there should be a default /sbin/ifup-local script that > > > > dispatches to /etc/sysconfig/network-scripts/ifup-local/? > > > > It could contain useful comments, including that it is by default > > > > replaceable as its target directory is empty by default. > > > > > > ... which would then try and overwrite any prior user-created files > > > in that place on upgrade. > > > > it could be in an optional package or declared config, noreplace. I do not > > feel good about user-created files in /sbin. > > thought about it a bit more, I think it would be better to add a separate > hook > to /sbin/ifup calling config post-up scripts in /etc and leave > /sbin/ifup-local > alone. > I just filed RHEL5 RFE bug about this: https://bugzilla.redhat.com/show_bug.cgi?id=592928 -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 13 laptop radeon graphics broken when connected to a docking station
Hello, I just installed Fedora 13 RC on my laptop (HP EliteBook 8530p) and I noticed the graphics are broken if I have the laptop on the docking station. Also F13 installer fails when the laptop is in the dock (display goes blank). What works: - F13 starts OK with only the internal laptop display in use, NOT connected to the dock, graphics/X works OK. The problem with the dock: - Screen goes blank early in the boot if I have the laptop on the dock and external display (DVI) in use, laptop lid closed, and I never get picture on the external display. - If I have the laptop on the dock with the external display connected and the laptop lid OPEN, I see Fedora boot/start and when X should start both the displays go blank. In all cases when the display goes blank I think the system crashes - at least nothing happens from ctrl-alt-del or from the power button. Any ideas how to troubleshoot? The display adapter is: RADEON(0): Chipset: "ATI Mobility Radeon HD 3650" (ChipID = 0x9591) kernel: 2.6.33.3-85.fc13.x86_64 lspci, dmesg, and Xorg.0.log attached. -- Pasi $ zegrep -i 'drm|radeon|ttm' dmesg-2.6.33.3-85.fc13.x86_64.gz [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 radeon :01:00.0: setting latency timer to 64 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0xD830 [drm] register mmio size: 65536 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 2012172 kiB. [ttm] Initializing pool allocator. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. radeon :01:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV635 Microcode platform radeon_cp.0: firmware: requesting radeon/RV635_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV635_me.bin platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Enabling audio support [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] LVDS [drm] Encoders: [drm] LCD1: INTERNAL_KLDSCP_LVTMA [drm] Connector 2: [drm] DVI-D [drm] HPD1 [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] Connector 3: [drm] HDMI-A [drm] HPD2 [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY [drm] fb mappable at 0xC0141000 [drm] vram apper at 0xC000 [drm] size 7257600 [drm] fb depth is 24 [drm]pitch is 6912 fbcon: radeondrmfb (fb0) is primary device fb0: radeondrmfb frame buffer device [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 dmesg-2.6.33.3-85.fc13.x86_64.gz Description: Binary data Xorg.0.log.gz Description: Binary data 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) Subsystem: Hewlett-Packard Company Device 30e7 Flags: bus master, fast devsel, latency 0 Capabilities: 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 7000-7fff Memory behind bridge: d830-d83f Prefetchable memory behind bridge: c000-cfff Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07) Subsystem: Hewlett-Packard Company Device 30e7 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at d8427000 (64-bit, non-prefetchable) [size=16] Capabilities: 00:03.2 IDE interface: Intel Corporation Mobile 4 Series Chipset PT IDER Controller (rev 07) (prog-if 85 [Master SecO PriO]) Subsystem: Hewlett-Packard Company Device 30e7 Flags: 66MHz, fast devsel, IRQ 18 I/O ports at 8130 [size=8] I/O ports at 8144 [size=4] I/O ports at 8128 [size=8] I/O ports at 8140 [size=4] I/O ports at 8100 [size=16] Capabilities: Kernel modules: ata_generic, pata_acpi 00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07) (prog-if 02 [16550]) Subsystem: Hewlett-Packard Company Device 30e7
Re: Working network install tree for Fedora 13 rc?
On Fri, May 14, 2010 at 06:31:08PM +0300, Pasi Kärkkäinen wrote: > Hello, > > Sorry to bother with a stupid question.. but I couldn't find a tree that > actually works. > What's a working url to test F13 rc installer? > > I tried installing F13 Xen PV guests with virt-manager using the following > urls: > > - http://serverbeach1.fedoraproject.org/pub/alt/stage/13.RC3/Fedora/x86_64/os/ > > -> anaconda complains about missing repomd -> installation doesn't > start. > > - > ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/13/x86_64/os/ > > -> anaconda complains about missing rsyslog and iputils packages -> > installation fails. > Ok, changing from ftp://ftp.funet.fi to http://ftp.funet.fi made it work. Sorry for the spam :) -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Working network install tree for Fedora 13 rc?
Hello, Sorry to bother with a stupid question.. but I couldn't find a tree that actually works. What's a working url to test F13 rc installer? I tried installing F13 Xen PV guests with virt-manager using the following urls: - http://serverbeach1.fedoraproject.org/pub/alt/stage/13.RC3/Fedora/x86_64/os/ -> anaconda complains about missing repomd -> installation doesn't start. - ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/13/x86_64/os/ -> anaconda complains about missing rsyslog and iputils packages -> installation fails. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 13 Beta RC#1 Available for testing Now! / kernel crash
On Fri, Mar 26, 2010 at 11:33:09AM +0800, He Rui wrote: > Greetings testers, > > F13 Beta RC1 has been uploaded for testing. As before, please follow the > guidance in the below > links to download the images and execute test cases to make sure they meet > the beta release criteria[1]: > > Installation: > > https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test > > Desktop: > > https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test > > > Please leave your results on the above pages and feel free to discuss > queries/problems/issues on #fedora-qa or t...@lists.fedoraproject.org. > > I just tried booting the latest F13 tree as a Xen PV guest, and the kernel crashes during the boot. Bug submitted already earlier here: https://bugzilla.redhat.com/show_bug.cgi?id=571241 Please include that upstream patch to the Fedora F13 kernel! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Disabling drm/ttm/radeon module loading for debugging
On Mon, Jan 25, 2010 at 05:42:49PM -0800, Adam Williamson wrote: > On Sun, 2010-01-24 at 18:13 +0200, Pasi Kärkkäinen wrote: > > > Ok, I just also blacklisted the radeon/drm/ttm modules in > > /etc/modprobe.d/ > > and now they aren't loaded automatically anymore. > > For the record, for graphics modules, you need to double-blacklist them: > blacklist in /etc/modprobe.d and either remove them from initrd (as you > did) or use the rdblacklist kernel parameter to stop them being loaded > from the initrd. > Thanks for the tip. I didn't know "rdblacklist" exists.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Disabling drm/ttm/radeon module loading for debugging
On Sun, Jan 24, 2010 at 02:29:03PM +0200, Pasi Kärkkäinen wrote: > On Sun, Jan 24, 2010 at 07:07:22AM +1000, Dave Airlie wrote: > > On Sat, 2010-01-23 at 18:49 +0200, Pasi Kärkkäinen wrote: > > > On Sat, Jan 23, 2010 at 11:41:15AM -0500, Clyde E. Kunkel wrote: > > > > On 01/23/2010 09:08 AM, Pasi Kärkkäinen wrote: > > > >> Hello, > > > >> > > > >> How can I make sure drm/radeon/ttm modules are not loaded, > > > >> until I do it manually myself? > > > >> > > > >> I extracted the initrd image, edited the 'init' script and > > > >> commented out loading of the modules, repacked the initrd, > > > >> and booted but something (plymouth? udev?) still loads the modules.. > > > >> > > > >> I'd like to load them later manually, for some debugging purposes.. > > > >> > > > >> -- Pasi > > > >> > > > > > > > > Try adding nomodeset to the kernel line in grub.conf. > > > > > > > > > > Sorry forgot to mention that I already have nomodeset.. > > > It seems it's not enough. > > > > You should be able to rmmod them with nomodeset, the driver > > doesn't do any initialisation in that case. though you > > should boot to runlevel 3 as once X starts the hw will > > be initialised. > > > > Then you need to load radeon with modeset=1 to override it. > > > > What I'm trying to do here is to debug some kind of text 'offset' > problem when the kernel is booted as Xen dom0, under the hypervisor. > > I just tried booting the kernel on baremetal, without Xen. > > It seems something is initialized when the drivers are loaded > for the first time (automatically by most probably udev, > trying to blacklist them now and see if that prevents them > from being loaded), because there's a small 'flash' on the screen > when udev is started. This 'flash' happens on baremetal. > Ok, I just also blacklisted the radeon/drm/ttm modules in /etc/modprobe.d/ and now they aren't loaded automatically anymore. The offset-problem still happens, so it's actually not related to radeon driver, it's something else. Thanks for the help! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Disabling drm/ttm/radeon module loading for debugging
On Sun, Jan 24, 2010 at 07:07:22AM +1000, Dave Airlie wrote: > On Sat, 2010-01-23 at 18:49 +0200, Pasi Kärkkäinen wrote: > > On Sat, Jan 23, 2010 at 11:41:15AM -0500, Clyde E. Kunkel wrote: > > > On 01/23/2010 09:08 AM, Pasi Kärkkäinen wrote: > > >> Hello, > > >> > > >> How can I make sure drm/radeon/ttm modules are not loaded, > > >> until I do it manually myself? > > >> > > >> I extracted the initrd image, edited the 'init' script and > > >> commented out loading of the modules, repacked the initrd, > > >> and booted but something (plymouth? udev?) still loads the modules.. > > >> > > >> I'd like to load them later manually, for some debugging purposes.. > > >> > > >> -- Pasi > > >> > > > > > > Try adding nomodeset to the kernel line in grub.conf. > > > > > > > Sorry forgot to mention that I already have nomodeset.. > > It seems it's not enough. > > You should be able to rmmod them with nomodeset, the driver > doesn't do any initialisation in that case. though you > should boot to runlevel 3 as once X starts the hw will > be initialised. > > Then you need to load radeon with modeset=1 to override it. > What I'm trying to do here is to debug some kind of text 'offset' problem when the kernel is booted as Xen dom0, under the hypervisor. I just tried booting the kernel on baremetal, without Xen. It seems something is initialized when the drivers are loaded for the first time (automatically by most probably udev, trying to blacklist them now and see if that prevents them from being loaded), because there's a small 'flash' on the screen when udev is started. This 'flash' happens on baremetal. When booting the same kernel binary as Xen dom0, I get weird 'offset' to every line of text when drm/radeon/ttm modules are loaded.. (this offset thing happens at the same moment when there's the 'flash' on baremetal). The beginning of every line moves from the left edge of the screen to 1/4 of the screen.. and the end of each line wraps to the beginning of next line. It's a bit difficult to read the screen :) Anyway, I want to make sure drm/radeon/ttm drivers are not loaded automatically so I can load them manually and debug what exactly happens. Video of the boot process here, showing the "offset" problem: http://pasik.reaktio.net/xen/pv_ops-dom0-debug/xen_pvops_dom0_vga_console_line_offset_problem-xvid.avi Same kernel binary doesnt' have the "offset" problem when booted on baremetal, so it's some kind of issue when the kernel is ran under the hypervisor. Kernel is version 2.6.31.6. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Disabling drm/ttm/radeon module loading for debugging
On Sat, Jan 23, 2010 at 11:41:15AM -0500, Clyde E. Kunkel wrote: > On 01/23/2010 09:08 AM, Pasi Kärkkäinen wrote: >> Hello, >> >> How can I make sure drm/radeon/ttm modules are not loaded, >> until I do it manually myself? >> >> I extracted the initrd image, edited the 'init' script and >> commented out loading of the modules, repacked the initrd, >> and booted but something (plymouth? udev?) still loads the modules.. >> >> I'd like to load them later manually, for some debugging purposes.. >> >> -- Pasi >> > > Try adding nomodeset to the kernel line in grub.conf. > Sorry forgot to mention that I already have nomodeset.. It seems it's not enough. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Disabling drm/ttm/radeon module loading for debugging
Hello, How can I make sure drm/radeon/ttm modules are not loaded, until I do it manually myself? I extracted the initrd image, edited the 'init' script and commented out loading of the modules, repacked the initrd, and booted but something (plymouth? udev?) still loads the modules.. I'd like to load them later manually, for some debugging purposes.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?
On Fri, Jan 22, 2010 at 01:06:11PM +0200, Pasi Kärkkäinen wrote: > On Fri, Jan 22, 2010 at 10:35:13AM +0100, Miloslav Trma?? wrote: > > Pasi Kärkkäinen píše v Pá 22. 01. 2010 v 11:01 +0200: > > > Has there been any plans to support running custom post-up scripts for > > > each interface, after "ifup " ? > > > > > > Debian allows you to specify: > > > > > > iface eth0 inet static > > > .. > > > post-up /etc/network/if-up.d/fw.start > > > > > > I'm looking for something similar for rhel/fedora. > > > Any ideas? > > grep ifup-local /etc/sysconfig/network-scripts/ifup-post > > > > Thanks for pointing that out. I was looking at ifup-post, > and I thought ifup-local was a script provided by the system, > but it seems there's no such script as a default (on RHEL5). > > So I can create it and use that. > .. just wondering why it's under /sbin and not under /etc/sysconfig/network-scripts/ It doesn't feel very good to add custom configuration under /sbin. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?
On Fri, Jan 22, 2010 at 10:35:13AM +0100, Miloslav Trma?? wrote: > Pasi Kärkkäinen píše v Pá 22. 01. 2010 v 11:01 +0200: > > Has there been any plans to support running custom post-up scripts for each > > interface, after "ifup " ? > > > > Debian allows you to specify: > > > > iface eth0 inet static > > .. > > post-up /etc/network/if-up.d/fw.start > > > > I'm looking for something similar for rhel/fedora. > > Any ideas? > grep ifup-local /etc/sysconfig/network-scripts/ifup-post > Thanks for pointing that out. I was looking at ifup-post, and I thought ifup-local was a script provided by the system, but it seems there's no such script as a default (on RHEL5). So I can create it and use that. Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?
On Fri, Jan 22, 2010 at 10:13:38AM +0100, Tomasz Torcz wrote: > On Fri, Jan 22, 2010 at 11:01:37AM +0200, Pasi Kärkkäinen wrote: > > Hello, > > > > Has there been any plans to support running custom post-up scripts for each > > interface, after "ifup " ? > > > > Debian allows you to specify: > > > > iface eth0 inet static > > .. > > post-up /etc/network/if-up.d/fw.start > > > > I'm looking for something similar for rhel/fedora. > > Any ideas? > > > > Maybe something like POST_UP="/path/script" in > > /etc/sysconfig/network-scripts/ifcfg-int > > You can drop a script into /etc/NetworkManager/dispatcher.d/ and check > parameters. IIRC $1 is interface name and $2 is state (up, down). > Thanks for the tip. I'll look into that.. Would be nicer if it was directly in ifcfg- file though.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sysconfig ifcfg-* support for running custom post-up scripts per interface?
Hello, Has there been any plans to support running custom post-up scripts for each interface, after "ifup " ? Debian allows you to specify: iface eth0 inet static .. post-up /etc/network/if-up.d/fw.start I'm looking for something similar for rhel/fedora. Any ideas? Maybe something like POST_UP="/path/script" in /etc/sysconfig/network-scripts/ifcfg-int Thanks! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
