Re: Maintainer for nvidia-crap in lvn wanted (Re: Pull off AIGLX repoistory?)
by Horst H. von Brand
Arjan van de Ven <arjan(a)fenrus.demon.nl> wrote:
> On Sun, 2006-07-30 at 15:50 +0200, Denis Leroy wrote:
> > Peter Gordon wrote:
> > > Christian Fredrik Kalager Schaller wrote:
> > >
> > >> The Nvidia drivers (or ATI ones) are not 'illegal'. The slides you point
> > >> to doesn't even claim they are. [...]
> > >
> > >
> > > No disrespect intended, but did you even read those slides? The 13th
> > > slide that Greg KH has on his site explicitly states - in big bold red
> > > lettering: "Closed source Linux kernel modules are illegal."
> >
> > The problem is obviously that it's not up to him to decide.
> I think you're mistaken there. Since Greg is one of the authors of the
> kernel, to a large degree it IS up to him to decide under what terms
> people get to use the parts of the kernel he wrote. Now Greg is a nice
> guy and he makes them available under a restricted but open license
> (generally called "GPL version 2"), but still.
The point is that the kernel is available under GPLv2, and /that/ decides
what is (or isn't) allowed. Sure, any reasonable judge will take into
(some) account the wishes of the author(s) (in general, owners of the
relevant copyrights) where the license isn't crystal clear, but what those
areas are (and what the law/the judge says about them) isn't Greg's call.
The nVidia (et al) folks certainly did look into the matter, and I'd bet
their lawyers told them there was no (or just a very tiny) chance for them
doing wrong before they went ahead, so I'd guess Greg is mistaken. Also
remember that the code was written by a collection of thousands, it isn't
easy to ask all them (and then weigh their opinions according to some
"importance of contribution" measure...).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
17 years, 8 months
Latest libtheora
by Matthias Saou
Hi,
The latest libtheora (alpha7), now includes all the MMX optimisations
that were only available previously in the special MMX version of
alpha5 (which only worked on x86 AFAIK). So now it should also works
much faster on x86_64!
FC devel is still at alpha5, so if anyone feels like bumping it to
alpha7 it would be great. I've already updated many FC5 systems I have,
encoding streams 24/7, and all works fine. I was using the MMX version
already, but still managed to see a 4% drop in CPU usage.
The update is a no-brainer as the package contains zero patches...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168773
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2356.fc6
Load : 0.24 0.42 0.32
17 years, 8 months
rawhide report: 20060731 changes
by Build System
Updated Packages:
devhelp-0.12-1
--------------
* Sat Jul 29 2006 Matthias Clasen <mclasen(a)redhat.com> - 0.12-1
- Update to 0.12
- Rebuild against firefox
epiphany-2.15.4-1
-----------------
* Sat Jul 29 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.15.4-1
- Update to 2.15.4
- Rebuild against firefox-devel
firefox-1.5.0.5-8
-----------------
* Sun Jul 30 2006 Matthias Clasen <mclasen(a)redhat.com> - 1.5.0.5-8
- Pass --libdir to configure
module-init-tools-3.3-0.pre1.4.6
--------------------------------
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.6
- Don't call depmod on removing a kernel.
- Warn rather than exit if we can't process weak-updates on new kernel
- Handle duplicate modules by picking the latter version of the two.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.4
- Don't call mkinitrd when removing a kernel.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.3
- New weak-modules with fixes
openoffice.org-1:2.0.3-7.7
--------------------------
* Wed Jul 26 2006 Caolan McNamara <caolanm(a)redhat.com> - 1:2.0.3-7.7
- rh#200207# -> openoffice.org-2.0.3.ooo67779.svx.toolbarcrash.patch
- rh#200194# -> openoffice.org-2.0.3.ooo67793.sw.stickymenu.patch
- rh#199056# -> openoffice.org-2.0.3.ooo67829.dtrans.64bitpaste.patch
- rh#200042# -> openoffice.org-2.0.3.ooo65081.sw.layout.patch
- rh#200193# -> openoffice.org-2.0.3.ooo67781.sc.reloadhiddenrows.patch
- rh#200369# help build glitch
- drop openoffice.org-2.0.3.oooXXXXX.all.ODR.anonymousmembers.patch
- drop openoffice.org-2.0.3.oooXXXXX.sal.importvisibilityasexported.patch
- require dejavu-lgc-fonts, Greek coverage problems begone
- rh#200512# South African translations
- move to firefox-devel instead of mozilla-devel, --with-firefox
+ add workspace.configure18.patch
pirut-1.1.8-1
-------------
* Sun Jul 30 2006 Jeremy Katz <katzj(a)redhat.com> - 1.1.8-1
- Fix traceback (clumens, #200515)
redhat-rpm-config-8.0.45-1
--------------------------
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 8.0.45-1
- Fix inverted kernel test.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 8.0.44-1
- Add a better check for a kernel vs. kmod.
yelp-2.15.5-1
-------------
* Thu Jul 27 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.15.5-1
- Update to 2.15.5
- Rebuild against firefox-devel
17 years, 8 months
Re: Leaving? (cont'd)
by Arthur Pemberton
First of all, I would like to apologize for breaking the thread, but
this thread has been longer than most "top posting" flaming threads.
Also, I do not feel as qualified to comment on the same level as the
many others on this list. I am speaking a full time Fedora user who
only boots Windows to play one game, "Age of Empires 3". And that is
actual of relevance. I am generally a "no games on my computer" kind
of guy, the reasoning for me playing this game is a bit too offtopic
to go into, but I got an Nvidia card with enough juice. When I fist
installed FC5 on said machine, I realised the hardware power the
machine, and thought it a shame to waste since KDE could have use for
it. So for the first time I installed a binary driver on my Fedora
Core desktop, so it seems that I will be directly affected by the
outcome of this ongoing war.
Back in FC4 I think it was, a newer vesion of KDE came out
approximately halfway though the Fedora life which fixed at least
three problems that I (and others I am sure) had which had rendered
serveral applications useless. So for half of a Fedora an update was
_not_ made as I was told it was a general policy not to do major
updates within a realse cycle.
Similarly, when MySQL jumped to 4.1 I think it was, Fedora stayed with
4.0 for the entire release cycle, for apperently no reason other than
the no major update policy.
So how is it, that now when a major update, mid life cycle, which is
known to cause problems is getting considered to the point of all
these bad vibes. We the users have waited for updates before. I
haven't been able to use and .17 kernel released by Fedora: I filed a
bug report, but I am pretty sure no one cares. To break my system,
would be wholey unfair, it has worked so well (aside from the kernel)
issues.
>From my admittedly limited understanding of the problem, this seems to
be little more than a programming problem. The parameters that would
cause breakage seem to be known by you guy. RPM supports the use of
post and pre scripts, can't these be used to go around this problme?
If not, why not do parallel releases. I seem to remember this being
done for at least gstreamer. have the xorg packages, and parallel
xorg71 packages. Those who need the 7.1 updates, can switch over to
xorg71, the rest of us will continue as normal, and hopefully, the
entire issue will be resolved by FC6.
If there can be no mutual solution can be arrived at, I vote for the
potetially selfish way of just not doing the update.
What ever you all do, please try to contain yourselves, Fedora already
has a not so good impression among the Slashdot type crowd, for
whatever that is worse. Issues like this, if prolonged will be no good
for anyone.
And to those that say yum needs fixing, I totally agree, there are
"features" and design decisions that in my humble opinion, need
adding/fixing. Other's have already pointed some issues out.
Peace to all.
--
To be updated...
17 years, 8 months
Heads-up: Requiring PAE for running Xen
by Jeremy Katz
As we move forward with Xen enablement, there's a desire for
being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The
options for handling this are
1) Another kernel. This is bad due to
a) we're running out of CD space already
b) keeping things matched up between the HV and the guest kernels
c) migration is worlds of pain with two types of kernels
2) Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't
work a lot of earlier PentiumM laptops
3) Do nothing, tell people to use 64bit if they want more than 4 gigs of
RAM
4) Make the PAE code handled at runtime. This is a pretty non-trivial
amount of work :)
Given these, we're looking at going with #2 and thus only having Xen
work on PAE-capable hardware in the development tree. And we're
planning to try to execute this switchover the beginning of next week.
Note that this will not affect bare metal installs at all.
Jeremy
17 years, 8 months
inconsistent lock state
by Erwin Rol
My log files show the following error. Where should i report this (if
not here) and what other information is needed ?
- Erwin
.....
Jul 24 14:56:19 lat kernel: Bluetooth: RFCOMM ver 1.8
Jul 24 14:56:19 lat kernel: usb 5-4.4.2: new full speed USB device using ehci_hcd and address 7
Jul 24 14:56:19 lat kernel: usb 5-4.4.2: configuration #1 chosen from 1 choice
Jul 24 14:56:19 lat kernel:
Jul 24 14:56:19 lat kernel: =================================
Jul 24 14:56:19 lat kernel: [ INFO: inconsistent lock state ]
Jul 24 14:56:19 lat kernel: ---------------------------------
Jul 24 14:56:19 lat kernel: inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
Jul 24 14:56:19 lat kernel: swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
Jul 24 14:56:19 lat kernel: (&skb_queue_lock_key){++..}, at: [<c05ad505>] skb_queue_tail+0x14/0x32
Jul 24 14:56:19 lat kernel: {hardirq-on-W} state was registered at:
Jul 24 14:56:19 lat kernel: [<c043c39f>] lock_acquire+0x4b/0x6c
Jul 24 14:56:19 lat kernel: [<c0609960>] _spin_lock_bh+0x1e/0x2d
Jul 24 14:56:19 lat kernel: [<c05e8096>] udp_ioctl+0x3b/0x6e
Jul 24 14:56:19 lat kernel: [<c05ecaef>] inet_ioctl+0x8c/0x91
Jul 24 14:56:19 lat kernel: [<c05a9377>] sock_ioctl+0x1b5/0x1d3
Jul 24 14:56:19 lat kernel: [<c04830b2>] do_ioctl+0x22/0x67
Jul 24 14:56:19 lat kernel: [<c048334f>] vfs_ioctl+0x258/0x26b
Jul 24 14:56:19 lat kernel: [<c04833a9>] sys_ioctl+0x47/0x62
Jul 24 14:56:19 lat kernel: [<c0403f31>] sysenter_past_esp+0x56/0x8d
Jul 24 14:56:19 lat kernel: irq event stamp: 410064
Jul 24 14:56:19 lat kernel: hardirqs last enabled at (410063): [<c052114c>] acpi_processor_idle+0x24f/0x403
Jul 24 14:56:19 lat kernel: hardirqs last disabled at (410064): [<c0404a3f>] common_interrupt+0x1b/0x2c
Jul 24 14:56:19 lat kernel: softirqs last enabled at (410046): [<c04298a1>] __do_softirq+0xec/0xf2
Jul 24 14:56:19 lat kernel: softirqs last disabled at (410013): [<c040661b>] do_softirq+0x5a/0xbe
Jul 24 14:56:19 lat kernel:
Jul 24 14:56:19 lat kernel: other info that might help us debug this:
Jul 24 14:56:19 lat kernel: 1 lock held by swapper/0:
Jul 24 14:56:19 lat kernel: #0: (&husb->completion_lock){..?+}, at: [<f8adc3f8>] hci_usb_rx_complete+0x2a/0x4d6 [hci_usb]
Jul 24 14:56:19 lat kernel:
Jul 24 14:56:19 lat kernel: stack backtrace:
Jul 24 14:56:19 lat kernel: [<c04051e0>] show_trace_log_lvl+0x54/0xfd
Jul 24 14:56:19 lat kernel: [<c040579c>] show_trace+0xd/0x10
Jul 24 14:56:19 lat kernel: [<c04058ac>] dump_stack+0x19/0x1b
Jul 24 14:56:19 lat kernel: [<c043a7ea>] print_usage_bug+0x1ca/0x1d7
Jul 24 14:56:19 lat kernel: [<c043ab30>] mark_lock+0x96/0x353
Jul 24 14:56:19 lat kernel: [<c043b849>] __lock_acquire+0x3b2/0x997
Jul 24 14:56:19 lat kernel: [<c043c39f>] lock_acquire+0x4b/0x6c
Jul 24 14:56:19 lat kernel: [<c0609c5f>] _spin_lock_irqsave+0x22/0x32
Jul 24 14:56:19 lat kernel: [<c05ad505>] skb_queue_tail+0x14/0x32
Jul 24 14:56:19 lat kernel: [<f8adc816>] hci_usb_rx_complete+0x448/0x4d6 [hci_usb]
Jul 24 14:56:19 lat kernel: [<c057c612>] usb_hcd_giveback_urb+0x2d/0x5d
Jul 24 14:56:19 lat kernel: [<f881f67a>] uhci_giveback_urb+0x11b/0x142 [uhci_hcd]
Jul 24 14:56:19 lat kernel: [<f881fc9f>] uhci_scan_schedule+0x50d/0x784 [uhci_hcd]
Jul 24 14:56:19 lat kernel: [<f8821744>] uhci_irq+0x11f/0x135 [uhci_hcd]
Jul 24 14:56:19 lat kernel: [<c057d137>] usb_hcd_irq+0x26/0x54
Jul 24 14:56:19 lat kernel: [<c044ff28>] handle_IRQ_event+0x20/0x4d
Jul 24 14:56:20 lat kernel: [<c044ffe9>] __do_IRQ+0x94/0xef
Jul 24 14:56:20 lat kernel: [<c0406738>] do_IRQ+0xb9/0xcd
Jul 24 14:56:20 lat kernel: [<c0404a49>] common_interrupt+0x25/0x2c
Jul 24 14:56:20 lat kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.1
Jul 24 14:56:20 lat kernel: NET: Registered protocol family 10
......
17 years, 8 months
usb hub problems
by Erwin Rol
I have a USB webcam and that now works with the normal kernel pwc
driver. I noticed a strange problem, since I got to many USB devices I
got a hub and at that point my webcam disappeared. It seems when it is
connected to the HUB ekiga can not use it, it doesn't show up in the
settings. When i directly connect it to my computer it does work. In
both cases the kernel reports the new /dev/video0 so it does see the
device.
this is what the USB bus looks like with the HUB
Bus 004 Device 021: ID 046d:08b2 Logitech, Inc. QuickCam Pro 4000
Bus 004 Device 010: ID 046d:c501 Logitech, Inc. Cordless Mouse Receiver
Bus 004 Device 005: ID 0731:0528 Susteen, Inc. SonyEricsson DCU-11 Cable
Bus 004 Device 004: ID 03f0:0317 Hewlett-Packard LaserJet 1200
Bus 004 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640
USB-2.0 "TetraHub"
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
when I unplug the webcam and replug it logs show;
Jul 29 22:57:35 xpc kernel: usb 4-1.3: new full speed USB device using ehci_hcd and address 22
Jul 29 22:57:35 xpc kernel: usb 4-1.3: configuration #1 chosen from 1 choice
Jul 29 22:57:35 xpc kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected.
Jul 29 22:57:35 xpc kernel: pwc: Registered as /dev/video0.
When I now start ekiga it doesn't find the webcam and I get the
following messages in my log file;
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
When I now plug it directly into my computer i see the following in the log file;
Jul 29 23:01:09 xpc kernel: usb 4-1.3: USB disconnect, address 22
Jul 29 23:01:13 xpc kernel: ohci_hcd 0000:00:1c.0: wakeup
Jul 29 23:01:13 xpc kernel: usb 1-3: new full speed USB device using ohci_hcd and address 6
Jul 29 23:01:15 xpc kernel: usb 1-3: configuration #1 chosen from 1 choice
Jul 29 23:01:15 xpc kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected.
Jul 29 23:01:15 xpc kernel: pwc: Registered as /dev/video0.
Notice the difference that it now reports it is using _O_hci_hcd instead
of _E_hci_hcd. When I now start ekiga it finds the webcam and it works,
and the log files show the following;
Jul 29 23:04:12 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
I had the same problem with my HP-scanner, it worked when it was
directly connected to the computer but could not be found when connected
to the hub. the other devices like my mouse, printer, phone work just
fine. I tried the HUB with and without external power supply and with
other devices on it and just the webcam on it, and the results are the
same, when connected to the hub the webcam doesn't work.
Any idea what the problem could be ?
TIA,
Erwin
17 years, 8 months