Re: programs vanish with 2.6.22+
Just forgot to mention: dmesg gives nothing (/var/log/messages) the global X log aswell and in the users .xsession-errors I have: amarokapp: Fatal IO error: client killed kdesktop: Fatal IO error: client killed konqueror: Fatal IO error: client killed The application 'xchat' lost its connection to the display :0.0; I dont know what that means, but at least its something ;) Markus > Hello! > > Excuse my bad english, I am no native speaker. And please CC me, as I am > not subscribed! > > I am running an amd64 system with a stable gentoo. Today I upgraded to > the kernel 2.6.22 and noticed many programs to disappear. > I use a kde desktop (3.5.7) and when amarok or kmail crash, normaly > a "kde-crash-manager" pops up (but that happend very rarely), but not > with 2.6.22+. It happens often and without any messagebox. > kdesktop, xchat, kicker, konqueror crashed as well. > It happens more often under heavy load. But it can also happen when > idle. Also I have the feeling that it happens more often on 2.6.23+ I > might be wrong. > > I tried 2.6.23 and the current 2.6.24-rc4, which all show this problem > aswell! > What has changed in 2.6.21 -> 2.6.22 that could cause such things? > Or who can tell that? > Can I help? How? (I use linux for years and can code, but I never > debugged anything as big as the kernel...) > > > Markus > > PS: Sorry thats so late, but I normaly stay on the distros stable kernel > and only try vanilla when something is wrong ;) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
programs vanish with 2.6.22+
Hello! Excuse my bad english, I am no native speaker. And please CC me, as I am not subscribed! I am running an amd64 system with a stable gentoo. Today I upgraded to the kernel 2.6.22 and noticed many programs to disappear. I use a kde desktop (3.5.7) and when amarok or kmail crash, normaly a "kde-crash-manager" pops up (but that happend very rarely), but not with 2.6.22+. It happens often and without any messagebox. kdesktop, xchat, kicker, konqueror crashed as well. It happens more often under heavy load. But it can also happen when idle. Also I have the feeling that it happens more often on 2.6.23+ I might be wrong. I tried 2.6.23 and the current 2.6.24-rc4, which all show this problem aswell! What has changed in 2.6.21 -> 2.6.22 that could cause such things? Or who can tell that? Can I help? How? (I use linux for years and can code, but I never debugged anything as big as the kernel...) Markus PS: Sorry thats so late, but I normaly stay on the distros stable kernel and only try vanilla when something is wrong ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Am Donnerstag, 6. Dezember 2007 schrieb Guennadi Liakhovetski: > On Thu, 6 Dec 2007, Markus wrote: > > > Just forgot to mention: > > dmesg gives nothing (/var/log/messages) > > the global X log aswell > > > > and in the users .xsession-errors I have: > > amarokapp: Fatal IO error: client killed > > kdesktop: Fatal IO error: client killed > > konqueror: Fatal IO error: client killed > > The application 'xchat' lost its connection to the display :0.0; > > > > I dont know what that means, but at least its something ;) > > Hm, no good idea, but some possible hints: > > 1. Ask Gentoo folks - if anyone has seen similar problems Noone gave a positiv answer so far. > 2. RAM test - even if earlier kernels ran stable, the new one might stress > your RAM differently Will do that overnight. > 3. Are you sure nothing else has changed apart from the kernel? Yes, I have some kernels installed and booted into them without changing anything else. > 4. You might try to recompile a vanilla 2.6.23+ kernel and enable as many > kernel debugging options as you can... I try that next. > 5. Are you sure the installed kernel matches your CPU and your user-space > 64- / 32-bit combination? Don't know whether a wrongly configured kernel > could cause such problems though Everything is "safe". Its a native 64-bit system with "safe" flags. > > Good luck > Guennadi > I will write when I did a ram-test and am running a 24-rc4 with full-debug. Will also try things from the gentoo-users... Is there any userspace software that is needed with newer kernels? Markus > > > > Markus > > > > > Hello! > > > > > > Excuse my bad english, I am no native speaker. And please CC me, as I > > am > > > not subscribed! > > > > > > I am running an amd64 system with a stable gentoo. Today I upgraded to > > > the kernel 2.6.22 and noticed many programs to disappear. > > > I use a kde desktop (3.5.7) and when amarok or kmail crash, normaly > > > a "kde-crash-manager" pops up (but that happend very rarely), but not > > > with 2.6.22+. It happens often and without any messagebox. > > > kdesktop, xchat, kicker, konqueror crashed as well. > > > It happens more often under heavy load. But it can also happen when > > > idle. Also I have the feeling that it happens more often on 2.6.23+ I > > > might be wrong. > > > > > > I tried 2.6.23 and the current 2.6.24-rc4, which all show this problem > > > aswell! > > > What has changed in 2.6.21 -> 2.6.22 that could cause such things? > > > Or who can tell that? > > > Can I help? How? (I use linux for years and can code, but I never > > > debugged anything as big as the kernel...) > > > > > > > > > Markus > > > > > > PS: Sorry thats so late, but I normaly stay on the distros stable > > kernel > > > and only try vanilla when something is wrong ;) > > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > --- > Guennadi Liakhovetski > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Hi again! The memtest ran 14 passes (~10h) without an error. I now have a 2.6.24-rc4 with some debug-options turned on, waiting for something to happen... can I just leave it untill a window disappears or do I need to manually enable something or run some user-space app?! Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
I try that, but it will take a lot of time! Markus > fre, 07 12 2007 kl. 23:52 +0100, skrev Markus: > > Well, now some windows vanished, but no additional messages were > > produced by kernel. When somebody could tell what I exactly need to > > do... would be nice. > > Or a hit, in what direction I should look. Because its really nasty to > > not being able to use a current kernel. > > > > I already rebuild the whole system, as suggested by the gentoo-devs, > > without success. > > > > I could also try to debug/strace/whatever the apps and wait for it to > > disappear. > > > > Just talk to me, I am not able to do this on my own... > > > If you feel like you are able to tell whether a specific kernel version > is buggy or not, you might want to try to bisect it. See > Documentation/BUG-HUNTING in the sources, and please ask. > > > Simon Holm Thøgersen > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Well, just tried it. Started a dozen konquerors and attached strace to everyone. When one disapeared, I only got a "Process 9246 detached", nothing else is printed or written in the log. Markus > On Fri, 7 Dec 2007, Markus wrote: > > > Well, now some windows vanished, but no additional messages were > > produced by kernel. When somebody could tell what I exactly need to > > do... would be nice. > > Or a hit, in what direction I should look. Because its really nasty to > > not being able to use a current kernel. > > > > I already rebuild the whole system, as suggested by the gentoo-devs, > > without success. > > > > I could also try to debug/strace/whatever the apps and wait for it to > > disappear. > > Well, you could attach strace to all likely crash candidates like > > strace -etrace=none -o/tmp/.trace -p > > which would at least tell you what signal it caught... > > good luck > Guennadi > > > > > Just talk to me, I am not able to do this on my own... > > > > > > Markus > > > > > On Fri, 7 Dec 2007, Markus wrote: > > > > > > > Hi again! > > > > > > > > The memtest ran 14 passes (~10h) without an error. > > > > > > > > I now have a 2.6.24-rc4 with some debug-options turned on, waiting > > for > > > > something to happen... can I just leave it untill a window > > disappears > > > > or do I need to manually enable something or run some user-space > > app?! > > > > > > It depends - different options have it differently. Most simple ones > > are > > > just compile-time, so, you don't have to enable them. Look in "help" > > for > > > respective debug-options. > > > > > > Thanks > > > Guennadi > > > --- > > > Guennadi Liakhovetski > > > > > > > > > --- > Guennadi Liakhovetski > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Well, now some windows vanished, but no additional messages were produced by kernel. When somebody could tell what I exactly need to do... would be nice. Or a hit, in what direction I should look. Because its really nasty to not being able to use a current kernel. I already rebuild the whole system, as suggested by the gentoo-devs, without success. I could also try to debug/strace/whatever the apps and wait for it to disappear. Just talk to me, I am not able to do this on my own... Markus > On Fri, 7 Dec 2007, Markus wrote: > > > Hi again! > > > > The memtest ran 14 passes (~10h) without an error. > > > > I now have a 2.6.24-rc4 with some debug-options turned on, waiting for > > something to happen... can I just leave it untill a window disappears > > or do I need to manually enable something or run some user-space app?! > > It depends - different options have it differently. Most simple ones are > just compile-time, so, you don't have to enable them. Look in "help" for > respective debug-options. > > Thanks > Guennadi > --- > Guennadi Liakhovetski > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Well, no I am not the same markus. And I found that before, but I thought it was something about cfs and imo that made it into linus-tree in .23 not .22. But I should perhaps try to change my name, perhaps that fixes it -.- Markus PS: am currently doing a bisect, thats really bad: third bisect and the kernel is unusable. > On Sat, 8 Dec 2007 13:12:14 +0100 > Markus <[EMAIL PROTECTED]> wrote: > > > I try that, but it will take a lot of time! > > > > Markus > > This problem remembers me something... > > http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gst&q=konqueror+vanish#591a0b3a05bd3596 > > > Are you the same Markus? (or it's just a coincidence?) > > It seems the same BUG... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
Well, after that I tried to verify that 22 is really fine. Unfortunatelly under heavy load its the same... even with .19 (the oldes kernel I have still installed) I just noticed it, because its harder to produce it on .22 and before. You guys tuned the kernel so it was easier. So it must be something in userspace, please excuse me ;) Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> i'm pleased to announce release -v19 of the CFS scheduler patchset. > > The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, > v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the > usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ Well, I took a 2.6.21 (gentoo-patchset...) and applied your cfs-v19 patch for the 2.6.21 kernels. Its a amd64 system and the "normal" (=only gentoo patches) kernel is working fine! > As usual, any sort of feedback, bugreport, fix and suggestion is more > than welcome! When I start the system, the mouse is jerking like under heavy load. (also its idle!) Then some programs just quit. They just disappear, no message in any log. (It were about four apps I realized in a period of about two hours of testing.) I'll try a git snapshot next, but is there a way I can get more output? Greetz Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
flooding: "new high speed USB device using ehci_hcd and address"
Hello! I just build 2.6.22-git5 to test the cfs. I looked in the log and found: usb 1-5: new high speed USB device using ehci_hcd and address 2 usb 1-5: new high speed USB device using ehci_hcd and address 3 usb 1-5: new high speed USB device using ehci_hcd and address 4 usb 1-5: new high speed USB device using ehci_hcd and address 5 usb 1-5: new high speed USB device using ehci_hcd and address 6 usb 1-5: new high speed USB device using ehci_hcd and address 7 usb 1-5: new high speed USB device using ehci_hcd and address 8 usb 1-5: new high speed USB device using ehci_hcd and address 9 They do from address 2 up to 127 and then begin again. They are printed about three to four times a second. # lsusb Bus 002 Device 006: ID 046d:c222 Logitech, Inc. Bus 002 Device 005: ID 046d:c221 Logitech, Inc. Bus 002 Device 004: ID 046d:08b5 Logitech, Inc. Bus 002 Device 003: ID 046d:c041 Logitech, Inc. Bus 002 Device 002: ID 046d:c223 Logitech, Inc. Bus 002 Device 001: ID : Bus 001 Device 001: ID : # lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS] (rev a1) 05:06.0 Network controller: Intersil Corporation ISL3890 [Prism GT/Prism Duette]/ISL3886 [Prism Javelin/Prism Xbow] (rev 01) 05:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev f0) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> I'll try a git snapshot next, but is there a way I can get more output? Did it. The mouse is smooth, just when one app is being quit (dont know why...) the mouse will be jerking for a few seconds... So, is there any way to get a more verbose output regarding the cfs? Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> Sending a few seconds of logged /proc/sched_debug will also help get a > picture of what's happening, and lovely would be a method to reproduce > the problem locally. Hi. Is there anything like the sched_debug in the 2.6.22-git5? Because I have a cfs-problem as well [1]. Markus [1] http://lkml.org/lkml/2007/07/14/60 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: flooding: "new high speed USB device using ehci_hcd and address"
I just noticed that the problem might be caused by the process disappearance [1], because it does not start right after the boot. And needs a random amount of time to appear. Never mind, Markus [1] http://lkml.org/lkml/2007/07/14/60 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.23-rc3: known regressions
> Subject : konqueror suddenly vanishing, "konqueror: Fatal IO error: client killed" > References : http://lkml.org/lkml/2007/7/22/86 > Last known good : ? > Submitter : Markus <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Status : problem is being debugged Last working kernel was the 2.6.22 without cfs. With the patch applied it shows the same problem (And so it does with the 2.6.23 as cfs was merged). And its caused by the cfs(-patch). And the real problem is not just restricted to konqueror. Its just easier to reproduce. (So the original mails started at http://lkml.org/lkml/2007/7/14/60 ) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> > [1] http://lkml.org/lkml/2007/07/14/60 > > Hm. Tasks disappearing isn't you're typical process scheduler problem > by any means, nor is an idle box exhibiting mouse "lurchiness". Is > there anything unusual in your logs? I know that its not typical, but when my current kernel is stable and shows the same problem with the cfs-patch applied like the git-snapshot, I would say its a cfs issue. There is nothing in the logs when a program dies, thats why asked for a way to make the kernel more verbose. But I can build a plain 2.6.22 without cfs and one with it and compare dmesgs output, if that helps. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> > [...] The mouse is smooth, just when one app is being quit (dont > > know why...) the mouse will be jerking for a few seconds... > is the mouse jerky on any app quitting? No. > Or is your observation the following: _sometimes_ apps quit > unexpectedly (their window just vanishes?), and _at the same time_, > the mouse becomes jerky as well, for a few seconds? Exactly. > the mouse typically only becomes jerky when there's some really high > load on the system - anything else would be a kernel bug. A jerky > mouse on an unloaded system is definitely a sign of some sort of > kernel bug (in or outside of the scheduler). An app vanishing > unexpectedly might mean an OOM-kill - but that would should up in the > syslog as well. > Pretty weird. Well, the system uses about 30% of the cpu (cool'n'quite put it on the lowest frequency). I made a plain 2.6.22.1 and could use it for about 2 hours without any problem. Then I applied the cfs-v19 for that kernel, rebuild from mrproper with the saved config and booted. After a few minutes the first app vanished... some more followed by time (I just surfed around a bit...) The dmesg output is not differing in any interesting point (just some numbers, like raid-benchmark, some irqs or usb-numbers...) So its obviously something within cfs... unfortunately... > Can you make this regression trigger arbitrarily, so that we could > debug it better? Apps exiting unexpectedly can be debugged via: > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/broken-out/vdso-print-fatal-signals.patch > > you can turn it on via the print-fatal-signals=1 boot option or via: > > echo 1 > /proc/sys/kernel/print-fatal-signals > > this feature will produce a small dump to the syslog about every app > that exits unexpectedly. Note that this might not cover all types of > "window suddenly vanishes" regressions. Nothing is printed for a disapeared app for me. Is there anything more I can try? Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> could you please send me the cfs-debug-info output nevertheless? private mail (4,9K) > > Nothing is printed for a disapeared app for me. > > > > Is there anything more I can try? > > sure - could you start one of those apps via: > > strace -ttt -TTT -o trace.log -f > > and wait for it to "disappear"? Then compress the trace.log via bzip2 -9 > (it's probably going to be a really large file) and send me it? private mail, aswell (187K) When attachments are allowed, I can resend them on the list as well (or just ask me...) To answer a private mail: I do not use any kernel-module thats not part of the official kernel! And of course nothing proprietary # cat /proc/sys/kernel/tainted 0 I used gcc-4.1.2 (glibc-2.5-r4) to build the kernels. (Its a amd64 system, quite stable so far.) Programs that "disappeared" are most graphical, because others I have not noticed so far... also [1] might be caused by this... amarok, kdesktop, whole X, konqueror, konsole but also gtk-apps Markus [1] http://lkml.org/lkml/2007/07/14/64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> 9173 1184675906.194424 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS,
0x7fff341af5c0)
> = -1 ENOTTY (Inappropriate ioctl for device) <0.06>
> 9173 1184675906.194463 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS,
0x7fff341af5c0)
> = -1 ENOTTY (Inappropriate ioctl for device) <0.04>
>
> ? Are those -ENOTTY results normal?
Yes, I see it on any kernel.
> 9173 1184675906.155015 write(2, "In file
kernel/qpixmap_x11.cpp, "..., 56) = 56 <0.06>
> 9173 1184675906.155052 write(2, "QImage::convertDepth: Image is
a"..., 44) = 44 <0.04>
> 9173 1184675906.155169 gettimeofday({1184675906, 155179}, NULL) = 0
<0.06>
> 9173 1184675906.155249 write(11, "close(6f1c2f7):about:konqueror\n",
31) = 31 <0.32>
>
> i think konqueror tried to say something here about an image problem?
Well, yes:
In file kernel/qpixmap_x11.cpp, line 633: Out of memory
QImage::convertDepth: Image is a null image
In file kernel/qpixmap_x11.cpp, line 633: Out of memory
QImage::convertDepth: Image is a null image
In file kernel/qpixmap_x11.cpp, line 633: Out of memory
QImage::convertDepth: Image is a null image
In file kernel/qpixmap_x11.cpp, line 633: Out of memory
QImage::convertDepth: Image is a null image
konqueror: Fatal IO error: client killed
And no, my 2 GB of RAM are not full:
$ free -m
total used free sharedbuffers
cached
Mem: 2012 1077935 0 22
441
-/+ buffers/cache:612 1400
Swap: 2070 0 2070
> could you perhaps upload the strace to some webpage so that others can
> take a look too?
hm, I dont have any webspace...
> it might also be good to add "-s 1000" to the strace command, so that
we
> can see the full messages that konqueror tried to log to some other
> task, i.e.:
>
> strace -s 1000 -ttt -TTT -o trace.log -f
>
> and perhaps try to do a 'comparison' trace.normal.log as well, with
> konqueror having no problems.
I now made some new strace logs:
- konq crash 251K
- Konq without crash on cfs 302K
- konq without crash on non-cfs 248K
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> hm, Markus indicated that he tried the v2.6.21.6-cfsv19 patch, and that > does not include the time.c change. Markus - does your kernel include > the code below? (if yes, please revert it via patch -p1 -R ) Well, the 2.6.22.1-cfs-v19 does include it, but the 2.6.21.6-cfs-v19 does not have that patch applied. But both show this problem. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> hm, Markus indicated that he tried the v2.6.21.6-cfsv19 patch, and that > does not include the time.c change. Markus - does your kernel include > the code below? (if yes, please revert it via patch -p1 -R ) As already said, 2.6.22.1-cfs-v19 includes the patch and 2.6.21.6-cfs-v19 does not include it. But both suffer of the problem. I now reversed the patch on 2.6.22.1-cfs-v19 but it does not help. 2.6.22-git15 is not working as well... so the problem did not magically disappear like the processes. Any further things I can do to track it down? (I go on vacation on monday for two weeks, but just send them, I'll try them when I am back or answer the mails, when I dont need to build a new kernel...) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: konqueror suddenly vanishing, "konqueror: Fatal IO error: client killed"
> it _seems_ to be related to KDE apps most of the time, right? You are right (although some gtk-apps have the same problem), but that may be caused by the fact that I dont _see_ other apps vanish... I'll try some console-based apps... > Could you perhaps mention the kde and Xorg versions you are using? I have konqueror 3.5.5 and Xorg 7.2 on a native amd64 system (gcc 4.1.2 and glibc 2.5). Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
Well, I am back now, but the problem still exists in 2.6.23-rc2. And as there is nothing more I can do thats it for now. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
> could you send me your debug-info: > > http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh > > just run that script on 2.6.23-rc2 system and send me the file it > produces. I've got a theory about what might be going on, and this > debug-info could help prove/disprove it. Done by private mail on friday. Also tried the very current linux-2.6.git (friday aswell) with sched-ingo-combo.patch (as told in a private answer mail). Nothing fixed it so far. If I can do anything... Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v19
Well, I am now running a 2.6.22 (without cfs) and could now see it once (within a month...) that exactly the same message from konqueror was produced. So I think its a general problem of konqueror that was hidden and somehow its triggered much more often with the cfs. I just wonder why nobody else has this problem. Markus PS: I am currently building a 2.6.23.1... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: trouble with eepro100+catalyst
Dennis, Your comment isn´t that productive What about ECN? Have acitivated it (proc/sys/net/ipv4/tcp_ecn, if I remember correctly) Markus Dennis wrote: > At 11:06 PM 10/20/2000, [EMAIL PROTECTED] wrote: > >We're having lots of trouble with eepro100 and Cisco Catalyst switch, > >and my net are a vlan. I am using RedHat 6.2/7.0 and not ping to gateway, > >but with o Slackware 7.0 ok. What's the magic? > > > >Regards, > > > >Umberto > >Systems Analyst > >.comDominio > >Brazil > > Ciscos and catalysts have all kinds of problems connecting to PCs. They > like to talk to each other mostly. Unfortunately, the widespread propaganda > that cisco is flawless hinders the true diagnosis in many cases. > > get yourself a cheap 10/100 hub or switch and wire it between the units and > then go watch some sports instead of banging your head for nothing > > Sometimes its better to sacrifice performance (ie catalysts) for something > that works. > > Dennis > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
I already pointed this out :-). Its not only write caching (dev null doesnt write at all) I think its read caching (read ahead) Cheers Markus "Mike A. Harris" wrote: > On Mon, 9 Oct 2000, blizbor wrote: > > >> On Mon, 9 Oct 2000, Andre Tomt wrote: > >> > >> The fastest ATA drives out that are not public yet are in 39-42mB/s. > >> Also SCSI can not sustain rates much better than maybe 60mB/s. > > > >Andre, how are you benchmarking drives ? > > > >In context you wrote, I've got rather curious results (maybe due to > >daulty measurement routines in tar). > >I've made > >tar clvf /dev/null --totals > >and got as follows: > > > >for ReiserFS: 53MB/s > >for ext2fs 27-28 MB/s > > 2 words: write caching > > -- > Mike A. Harris - Linux advocate - Open source advocate > Computer Consultant - Capslock Consulting > Copyright 2000 all rights reserved > -- > > #[Mike A. Harris bash tip #3 - how to disable core dumps] > # Put the following at the bottom of your ~/.bash_profile > ulimit -c 0 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre1 problems on 4-way SuperServer8050
Hi, someone looked at the XEON errata already, perhaps one can find the problem there? Just in case. G16 seems to have something to do with it ... But there are others also. I´ll boot linux and look into the sources ... Cheers Markus Tigran Aivazian wrote: > On Wed, 11 Oct 2000, Linus Torvalds wrote: > > What happens if MTRR support is entirely disabled? > > If MTRR support is disabled then both eepro100 interfaces work fine but > the system is still 40x slower. This is the entire bootlog of > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig > output > > Two currently active ideas (from Mark, Linus and Zoltan): > > a) one needs to use big-mtrr patch from Zoltan, look at e820 map and > manually set up mtrrs to cover all 6G. > > b) this is an L2 cache-tag issue and there is just not enough bits in the > tag to cover such high addresses so nothing will help, save removing the > extra 2G or so out of the machine (or using them as MTD devices : I > hope this is _not_ the case... > > another idea (in parallel) is that eepro100 stops working because its PCI > memory space is marked as cacheable. > > All should become clear soon -- I will spend the whole day on this, slowly > trying to understand what's going on. > > Regards, > Tigran > > Linux version 2.4.0-test9 (root@hilbert) (gcc version egcs-2.91.66 19990314/Linux >(egcs-1.1.2 release)) #15 SMP Wed Oct 11 19:23:15 BST 2000 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (reserved) > BIOS-e820: 0002 @ 000e (reserved) > BIOS-e820: fccf @ 0010 (usable) > BIOS-e820: f000 @ fcdf (ACPI data) > BIOS-e820: 1000 @ fcdff000 (ACPI NVS) > BIOS-e820: 1000 @ fec0 (reserved) > BIOS-e820: 1000 @ fee0 (reserved) > BIOS-e820: 0008 @ fff8 (reserved) > BIOS-e820: 8000 @ 0001 (usable) > 5248MB HIGHMEM available. > Scan SMP from c000 for 1024 bytes. > Scan SMP from c009fc00 for 1024 bytes. > Scan SMP from c00f for 65536 bytes. > found SMP MP-table at 000fb4d0 > hm, page 000fb000 reserved twice. > hm, page 000fc000 reserved twice. > hm, page 000f5000 reserved twice. > hm, page 000f6000 reserved twice. > On node 0 totalpages: 1572864 > zone(0): 4096 pages. > zone(1): 225280 pages. > zone(2): 1343488 pages. > Intel MultiProcessor Specification v1.1 > Virtual Wire compatibility mode. > OEM ID: AMI Product ID: CNB20HE APIC at: 0xFEE0 > Processor #0 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Bootup CPU > Processor #1 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Processor #2 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Processor #3 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Bus #0 is PCI > Bus #1 is PCI > Bus #2 is PCI > Bus #3 is ISA > I/O APIC #4 Version 17 at 0xFEC0. > I/O APIC #5 Version 17 at 0xFEC01000. > Int: type 0, pol 3, trig 3, bus 0, IRQ 04, APIC ID 5, APIC INT 0a > Int: type 0, pol 3, trig 3, bus 0, IRQ 08, APIC ID 5, APIC INT 0b > Int: type 0, pol 3, trig 3, bus 0, IRQ 0c, APIC ID 5, APIC INT 0f > Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 0a > Int: type 0, pol 3, trig 3, bus 1, IRQ 15, APIC ID 5, APIC INT 01 > Int: type 0, pol 3, trig 3, bus 1, IRQ 14, APIC ID 5, APIC INT 00 > Int: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 00 > Int: type 0, pol 1, trig 1, bus 3, IRQ 01, APIC ID 4, APIC INT 01 > Int: type 0, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 02 > Int: type 0, pol 1, trig 1, bus 3, IRQ 03, APIC ID 4, APIC INT 03 > Int: type 0, pol 1, trig 1, bus 3, IRQ 04, APIC ID 4, APIC INT 04 > Int: type 0, pol 1, trig 1, bus 3, IRQ 06, APIC ID 4, APIC INT 06 > Int: type 0, pol 1, trig 1, bus 3, IRQ 07, APIC ID 4, APIC INT 07 > Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 4, APIC INT 08 > Int: type 0, pol 1, trig 1, bus 3, IRQ 0c, APIC ID 4, APIC INT 0c > Int: type 0, pol 1, trig 1, bus 3, IRQ 0d, APIC ID 4, APIC INT 0d > Int: type 0,
WARNING: at lib/idr.c:678 idr_find_slowpath+0x97/0xc0()
Just hit the following warning on current git tree: [ cut here ] WARNING: at lib/idr.c:678 idr_find_slowpath+0x97/0xc0() Hardware name: System Product Name Pid: 12366, comm: okular Not tainted 3.8.0-09633-g2a7d2b9-dirty #312 Call Trace: [] ? warn_slowpath_common+0x60/0xa0 [] ? idr_find_slowpath+0x97/0xc0 [] ? inotify_idr_find_locked+0x32/0x80 [] ? fput+0x1d/0xc0 [] ? sys_inotify_rm_watch+0x50/0xc0 [] ? int_signal+0x12/0x17 [] ? system_call_fastpath+0x16/0x1b ---[ end trace be8364dcbafab6c6 ]--- -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Slow I/O performance on SAS1064
supported DMA: not supported PIO: pio0 --- Moduls load: lsmod | grep mpt mptctl 27359 0 mptsas 45861 5 mptscsih 25765 1 mptsas mptbase75530 3 mptctl,mptsas,mptscsih scsi_transport_sas 21624 1 mptsas --- The hdparm result looks like there is somethink not right . There were no features supported but why ? Greetings Markus signature.asc Description: Digital signature
Re: Slow I/O performance on SAS1064
On Wed, Mar 05, 2014 at 10:21:07AM -0800, Mark Knecht wrote: > On Wed, Mar 5, 2014 at 9:50 AM, Markus wrote: > > > > The hdparm result looks like there is somethink not right . There were no > > features supported but why ? > > > Does the HDD have S.M.A.R.T. features? Possibly > > smartctl -a /dev/sda root@outpost:~# smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 [sparc64-linux-3.13.5-mar] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Probable ATA device behind a SAT layer Try an additional '-d ata' or '-d sat' argument. so i try it with scsi. root@outpost:~# smartctl -d scsi -a /dev/sda smartctl 5.41 2011-06-09 r3365 [sparc64-linux-3.13.5-mar] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net User Capacity:2,000,398,934,016 bytes [2.00 TB] Logical block size: 512 bytes Logical Unit id: 0x5394e2380537 Serial number: 7365P4KNT Device type: disk Local Time is:Wed Mar 5 22:32:09 2014 CET Device supports SMART and is Disabled Temperature Warning Disabled or Not Supported SMART Health Status: OK Error Counter logging not supported Device does not support Self Test logging > > would provide some additional visibility? . [ 98.037209] Uniform Multi-Platform E-IDE driver [ 98.107564] SLAB: Unable to allocate memory on node 0 (gfp=0x40d1) [ 98.188985] cache: dma-kmalloc-512, object size: 512, order: 0 [ 98.268127] node 0: slabs: 0/0, objs: 0/0, free: 0 [ 98.333538] sr: out of memory. [ 98.373628] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 98.443390] sr 0:0:0:0: Attached scsi CD-ROM sr0 [ 98.448375] sr 0:0:0:0: Attached scsi generic sg0 type 5 [ 103.198705] scsi2 : ioc0: LSISAS1064 A3, FwRev=01080400h, Ports=1, MaxQ=511, IRQ=10 [ 103.329805] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221 [ 103.462762] scsi 2:0:0:0: Direct-Access ATA TOSHIBA MQ01ABB2 0U PQ: 0 ANSI: 5 [ 103.571610] scsi 2:0:0:0: Attached scsi generic sg1 type 0 [ 103.645418] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 1, phy 1, sas_addr 0x12210100 [ 103.777635] scsi 2:0:1:0: Direct-Access ATA TOSHIBA MQ01ABB2 0U PQ: 0 ANSI: 5 [ 103.886607] scsi 2:0:1:0: Attached scsi generic sg2 type 0 [ 103.960517] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 2, phy 2, sas_addr 0x12210200 [ 104.093109] scsi 2:0:2:0: Direct-Access ATA TOSHIBA MQ01ABB2 0U PQ: 0 ANSI: 5 [ 104.201973] scsi 2:0:2:0: Attached scsi generic sg3 type 0 [ 104.275830] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 3, phy 3, sas_addr 0x12210300 [ 104.408412] scsi 2:0:3:0: Direct-Access ATA TOSHIBA MQ01ABB2 0U PQ: 0 ANSI: 5 [ 104.517379] scsi 2:0:3:0: Attached scsi generic sg4 type 0 [ 104.618997] sd 2:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 104.721185] sd 2:0:3:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 104.823771] sd 2:0:1:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 104.824017] sd 2:0:2:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 104.828691] sd 2:0:0:0: [sda] Write Protect is off [ 104.828697] sd 2:0:0:0: [sda] Mode Sense: 67 00 00 08 [ 104.829940] sd 2:0:2:0: [sdc] Write Protect is off [ 104.829945] sd 2:0:2:0: [sdc] Mode Sense: 67 00 00 08 [ 104.830488] sd 2:0:3:0: [sdd] Write Protect is off [ 104.830493] sd 2:0:3:0: [sdd] Mode Sense: 67 00 00 08 [ 104.833225] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 104.834471] sd 2:0:2:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 104.835118] sd 2:0:3:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 105.583175] sd 2:0:1:0: [sdb] Write Protect is off [ 105.623801] sda: sda1 sda2 sda3 [ 105.651118] sdc: sdc1 sdc9 [ 105.654024] sdd: sdd1 sdd9 [ 105.761966] sd 2:0:1:0: [sdb] Mode Sense: 67 00 00 08 [ 105.769029] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 105.775293] sd 2:0:2:0: [sdc] Attached SCSI disk [ 105.775941] sd 2:0:3:0: [sdd] Attached SCSI disk [ 106.014357] sd 2:0:0:0: [sda] Attached SCSI disk [ 106.158864] sdb: sdb1 sdb9 [ 106.205879] sd 2:0:1:0: [sdb] Attached SCSI disk [ 106.502387] random: nonblocking pool is initialized [ 106.792978] device-mapper: uevent: version 1.0.3 [ 106.861434] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-de...@redhat.com [ 108.085062] bio: create slab at 1 . > > - Mark Markus signature.asc Description: Digital signature
Re: Slow I/O performance on SAS1064
On Thu, Mar 06, 2014 at 12:51:27PM -0800, Mark Knecht wrote: > On Wed, Mar 5, 2014 at 1:40 PM, markus wrote: > > On Wed, Mar 05, 2014 at 10:21:07AM -0800, Mark Knecht wrote: > >> On Wed, Mar 5, 2014 at 9:50 AM, Markus wrote: > >> > I am not familiar with this message: > > "Device supports SMART and is Disabled" > > but there are lots of posts out there with folks asking about it. > Possibly you can figure out what's causing smart not to turn on, get > it turned on and get some info. right , thats why i writing to the scsi and lsi devs , because die disk supports smart and lots of other features, but the controller driver failes to enable support for this. Now i get that the mpt driver provides /dev/sg[0-1] root@outpost:~# smartctl -d scsi -x /dev/sg1 smartctl 6.2 2013-07-26 r3841 [sparc64-linux-3.13.5-mar] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org User Capacity:2,000,398,934,016 bytes [2.00 TB] Logical block size: 512 bytes Logical Unit id: 0x5394e2380537 Serial number:7365P4KNT Device type: disk Local Time is:Fri Mar 7 09:54:47 2014 CET SMART support is: Available - device has SMART capability. SMART support is: Disabled Temperature Warning: Disabled or Not Supported Read Cache is:Enabled Writeback Cache is: Enabled === START OF READ SMART DATA SECTION === SMART Health Status: OK Error Counter logging not supported Device does not support Self Test logging Device does not support Background scan results logging scsiPrintSasPhy Log Sense Failed [unsupported field in scsi command] so i had read those posts and i tried but it won't work. root@outpost:~/lsiutil# smartctl -r scsiioctl,3 -s on -d scsi /dev/sg1 smartctl 6.2 2013-07-26 r3841 [sparc64-linux-3.13.5-mar] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org [inquiry: 12 01 00 01 fc 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=0 milliseconds resid=500 Incoming data, len=8: 00 00 00 00 04 00 80 83 89 [inquiry: 12 00 00 00 24 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=4 milliseconds resid=0 Incoming data, len=36: 00 00 00 05 12 45 00 00 02 41 54 41 20 20 20 20 20 10 54 4f 53 48 49 42 41 20 4d 51 30 31 41 42 42 32 20 30 55 20 20 === START OF ENABLE/DISABLE COMMANDS SECTION === [mode sense(6): 1a 00 1c 00 40 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=4 milliseconds resid=40 Incoming data, len=24: 00 17 00 00 08 00 00 00 00 00 00 02 00 1c 0a 08 06 10 08 00 00 00 00 00 00 00 [mode sense(6): 1a 00 5c 00 40 00 ] scsi_status=0x0, host_status=0x0, driver_status=0x0 info=0x0 duration=0 milliseconds resid=40 Incoming data, len=24: 00 17 00 00 08 00 00 00 00 00 00 02 00 1c 0a 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 02 00 1c 0a 08 06 10 08 00 00 00 00 00 00 00 [mode select(6): 15 10 00 00 18 00 ] Outgoing data, len=24: scsi_status=0x2, host_status=0x0, driver_status=0x8 info=0x1 duration=0 milliseconds resid=24 >>> Sense buffer, len=18: 00 70 00 0b 00 00 00 00 0a 00 00 00 00 00 00 00 00 10 00 00 status=2: sense_key=b asc=0 ascq=0 unable to enable Exception control and warning [aborted command] > > Sorry I cannot help more. > > Good luck, > Mark signature.asc Description: Digital signature
Re: Slow I/O performance on SAS1064
On Fri, Mar 07, 2014 at 08:24:48AM -0800, Purush Gupta wrote: > I noticed you had benchmarked only sda target, is the behavior same on > other targets? > Yes the other disk are equal to sda , but they are used with zfs and there were other preformance problems because of the multible disk access. config: NAMESTATE READ WRITE CKSUM homeONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sdb ONLINE 0 0 3 sdc ONLINE 0 0 0 sdd ONLINE 0 0 0 > Since they are SCSI targets, have you explored sg_utils [ > http://sg.danny.cz/sg/uu_index.html] > > And for benchmarking I also recommend FIO https://github.com/axboe/fio > Thanks for the tips. > Good luck, > Purush > signature.asc Description: Digital signature
Ext4 Recovery: Invalid checksum recovering block # in log
Hi! After an unclean "shutdown" the system hangs when mounting the filesystems. When I remove the affected ext4 drive from fstab the system starts and I can further investigate. Try to mount: syslog is flooded with JBD2: Invalid checksum recovering block 1152 in log (always the same number, it doesnt seem to stop filling the log file) Run e2fsck: console is flooded JBD: Invalid checksum recovering block 1152 in log debugfs gives an additional message: Block bitmap checksum does not match bitmap while reading block bitmap (But the filesystem is not opened, so logdump is not working.) Any help is highly appreciated. (I have not found this issue online.) Thanks, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hybrid raid1 with trim support
Hi! Still the same with 3.8.4 ... anybody? Best regards, Markus Markus schrieb am 12.03.2013: > Hello! > > I created a hybrid raid1 with one ssd and one hdd. Used writemostly and > writebehind and put ext4 with discard enabled on it. > This setup worked quite well for the last months (last kernel was 3.7.6). But > now as I booted 3.8.2 the hdd was dropped from the raid with: > > md/raid1:md2: Disk failure on sdb1, disabling device. > > md/raid1:md2: Operation continuing on 1 devices. > > Re-adding this drive it will try to resync but the hdd will be dropped short > time after. Now I remounted the device without the discard flag and the > resync and usage works as before. > After remounting it again with discard enabled the hdd is dropped again. So I > think this is the culprit as the hdd does obviously not support TRIM... > > As it worked fine before, I think this is a regression? Or is this an > intended change? > > > Thanks, > Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hybrid raid1 with trim support
Hello! I created a hybrid raid1 with one ssd and one hdd. Used writemostly and writebehind and put ext4 with discard enabled on it. This setup worked quite well for the last months (last kernel was 3.7.6). But now as I booted 3.8.2 the hdd was dropped from the raid with: > md/raid1:md2: Disk failure on sdb1, disabling device. > md/raid1:md2: Operation continuing on 1 devices. Re-adding this drive it will try to resync but the hdd will be dropped short time after. Now I remounted the device without the discard flag and the resync and usage works as before. After remounting it again with discard enabled the hdd is dropped again. So I think this is the culprit as the hdd does obviously not support TRIM... As it worked fine before, I think this is a regression? Or is this an intended change? Thanks, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hybrid raid1 with trim support [REGRESSION]
Hi! Now I had the time to bisect, started with 3.7 as good and 3.8 as bad. 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 is the bad commit. [1] block: add plug for blkdev_issue_discard While 3.8.10 was still bad, the same kernel with the reverted patch applied is fine. I found another report. [2] Thanks, Markus [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 [2] http://www.spinics.net/lists/raid/msg42758.html Markus schrieb am 24.03.2013: > Hi! > > Still the same with 3.8.4 ... anybody? > > Best regards, > Markus > > Markus schrieb am 12.03.2013: > > Hello! > > > > I created a hybrid raid1 with one ssd and one hdd. Used writemostly and > > writebehind and put ext4 with discard enabled on it. > > This setup worked quite well for the last months (last kernel was 3.7.6). > > But now as I booted 3.8.2 the hdd was dropped from the raid with: > > > md/raid1:md2: Disk failure on sdb1, disabling device. > > > md/raid1:md2: Operation continuing on 1 devices. > > > > Re-adding this drive it will try to resync but the hdd will be dropped > > short time after. Now I remounted the device without the discard flag and > > the resync and usage works as before. > > After remounting it again with discard enabled the hdd is dropped again. So > > I think this is the culprit as the hdd does obviously not support TRIM... > > > > As it worked fine before, I think this is a regression? Or is this an > > intended change? > > > > > > Thanks, > > Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hybrid raid1 with trim support [REGRESSION]
Hi!
Thanks for your work. The patch seems to work for me on a vanilla 3.8.10, at
least the hdds are no longer dropped from the raid.
The code now ignores some request? What was the reason the disks fell off the
raid? The discards are still passed to the ssd?
Thanks,
Markus
Shaohua Li schrieb am 28.04.2013:
> On Sun, Apr 28, 2013 at 08:54:46AM +0800, Shaohua Li wrote:
> > On Sat, Apr 27, 2013 at 06:29:49PM +0200, Markus wrote:
> > > Hi!
> > >
> > > Now I had the time to bisect, started with 3.7 as good and 3.8 as bad.
> > > 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 is the bad commit. [1]
> > > block: add plug for blkdev_issue_discard
> > >
> > > While 3.8.10 was still bad, the same kernel with the reverted patch
applied is fine.
> > Thanks for the reporting. Does below patch work for you?
> Oops, there is a typo there, should be this one:
>
> ---
> drivers/md/raid1.c |7 ++-
> drivers/md/raid10.c |7 ++-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> Index: linux/drivers/md/raid1.c
> ===
> --- linux.orig/drivers/md/raid1.c 2013-03-07 14:14:05.950824173 +0800
> +++ linux/drivers/md/raid1.c 2013-04-28 08:57:17.874058434 +0800
> @@ -981,7 +981,12 @@ static void raid1_unplug(struct blk_plug
> while (bio) { /* submit pending writes */
> struct bio *next = bio->bi_next;
> bio->bi_next = NULL;
> - generic_make_request(bio);
> + if (unlikely((bio->bi_rw & REQ_DISCARD) &&
> + !blk_queue_discard(bdev_get_queue(bio->bi_bdev
> + /* Just ignore it */
> + bio_endio(bio, 0);
> + else
> + generic_make_request(bio);
> bio = next;
> }
> kfree(plug);
> Index: linux/drivers/md/raid10.c
> ===
> --- linux.orig/drivers/md/raid10.c2013-03-07 14:14:05.950824173 +0800
> +++ linux/drivers/md/raid10.c 2013-04-28 08:57:44.765719067 +0800
> @@ -1133,7 +1133,12 @@ static void raid10_unplug(struct blk_plu
> while (bio) { /* submit pending writes */
> struct bio *next = bio->bi_next;
> bio->bi_next = NULL;
> - generic_make_request(bio);
> + if (unlikely((bio->bi_rw & REQ_DISCARD) &&
> + !blk_queue_discard(bdev_get_queue(bio->bi_bdev
> + /* Just ignore it */
> + bio_endio(bio, 0);
> + else
> + generic_make_request(bio);
> bio = next;
> }
> kfree(plug);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: objtool segfault with ORC unwinder enabled
On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > patches > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > symbols? > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user would > > > > > > be > > > > > > affected?) > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never > > > > > > had a > > > > > > problem with this. > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > > > > work after gcc, but before objtool. Can you try this patch? (Note > > > > > this > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > case.) > > > > > > Any more final patch I should test? > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > (But feel free to keep bugging me if I don't!) > > Ok, this should be the final patch (no description yet though). Want to > test it? Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. Manually editing just breaks the build with many "open: No such file or directory". Dont know what went wrong. Can you maybe append patch as file? BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > > > patches > > > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > > > symbols? > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user > > > > > > > > would > > > > > > > > be > > > > > > > > affected?) > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > Never > > > > > > > > had a > > > > > > > > problem with this. > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does > > > > > > > some > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > (Note > > > > > > > this > > > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > > > case.) > > > > > > > > > > Any more final patch I should test? > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > > > (But feel free to keep bugging me if I don't!) > > > > > > Ok, this should be the final patch (no description yet though). Want to > > > test it? > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > Manually editing just breaks the build with many "open: No such file or > > directory". > > > > Dont know what went wrong. Can you maybe append patch as file? > > Sure, patch is attached, based on 4.15-rc7. Applies cleanly to 4.15-rc7. But still: HOSTCC scripts/asn1_compiler HOSTCC scripts/extract-cert CC init/main.o open: No such file or directory make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 make: *** [Makefile:1015: init] Error 2 Reverting that patch makes it build again. BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Thursday, 11 January 2018 20:38:10 CET Josh Poimboeuf wrote: > On Thu, Jan 11, 2018 at 07:52:00PM +0100, Markus wrote: > > On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > > > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > > > > I don't see anything unusual there. Are there any > > > > > > > > > > > Gentoo > > > > > > > > > > > patches > > > > > > > > > > > against either the kernel or GCC which would strip > > > > > > > > > > > unused > > > > > > > > > > > symbols? > > > > > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also > > > > > > > > > > 4.15-rc6) > > > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo > > > > > > > > > > user > > > > > > > > > > would > > > > > > > > > > be > > > > > > > > > > affected?) > > > > > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > > > Never > > > > > > > > > > had a > > > > > > > > > > problem with this. > > > > > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker > > > > > > > > > does > > > > > > > > > some > > > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > > > (Note > > > > > > > > > this > > > > > > > > > isn't the final patch, as this breaks the > > > > > > > > > CONFIG_MODVERSIONS=n > > > > > > > > > case.) > > > > > > > > > > > > > > Any more final patch I should test? > > > > > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch > > > > > > soon. > > > > > > (But feel free to keep bugging me if I don't!) > > > > > > > > > > Ok, this should be the final patch (no description yet though). > > > > > Want to > > > > > test it? > > > > > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > > > Manually editing just breaks the build with many "open: No such file > > > > or > > > > directory". > > > > > > > > Dont know what went wrong. Can you maybe append patch as file? > > > > > > Sure, patch is attached, based on 4.15-rc7. > > > > Applies cleanly to 4.15-rc7. But still: > > HOSTCC scripts/asn1_compiler > > HOSTCC scripts/extract-cert > > CC init/main.o > > > > open: No such file or directory > > make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 > > make: *** [Makefile:1015: init] Error 2 > > > > > > Reverting that patch makes it build again. > > Weird. Here's a version which should hopefully give a better error > message. CC init/main.o objtool: can't open file /.tmp_ open: No such file or directory BR, Markus
objtool segfault with ORC unwinder enabled
Hello! ORC unwinder is enabled in stable for wider testing but still at least one bug is open: https://bugzilla.kernel.org/show_bug.cgi?id=197035 objtool will segfault because a NULL pointer is dereferenced. Is a NULL pointer sym valid? If a NULL pointer is invalid, it has to be checked why it is sometimes NULL. Thank you! Markus
Re: objtool segfault with ORC unwinder enabled
On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote: > On Wed, Jan 03, 2018 at 11:49:08AM +0100, Markus wrote: > > Hello! > > > > ORC unwinder is enabled in stable for wider testing but still at least one > > bug is open: > > https://bugzilla.kernel.org/show_bug.cgi?id=197035 > > Random web links on mailing lists don't help much, please put the > information here in the email. Its not a random web link. Its the official kernel.org bugtracker. But nobody seems to be looking at it. > > objtool will segfault because a NULL pointer is dereferenced. > > And how are you reproducing this? Just building the kernel with ORC enabled. (At least for me. Using framepointers compiles, enabling ORC again breaks it.) gcc 6.4.0 (In bug report others were tested as well.) elfutils 0.170 What else may be interesting? > > Is a NULL pointer sym valid? > > If a NULL pointer is invalid, it has to be checked why it is sometimes > > NULL. > What .config is triggering this problem? See attachment. > And does this show up on 4.14.11, and 4.15-rc6? Both: yes. /tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/irq.o" => segfault. Changing CFLAGS for objtool to O1 and starting from gdb: (gdb) r orc generate --no-fp "arch/x86/kernel/irq.o" Starting program: tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/ irq.o" Program received signal SIGSEGV, Segmentation fault. 0xe06c in elf_rebuild_rela_section (sec=sec@entry=0x7690d010) at elf.c:554 554 relas[idx].r_info = GELF_R_INFO(rela->sym->idx, rela- >type); (gdb) bt #0 0xe06c in elf_rebuild_rela_section (sec=sec@entry=0x7690d010) at elf.c:554 #1 0xd0aa in create_orc_sections (file=file@entry=0x7ff7d740) at orc_gen.c:210 #2 0xc146 in check (_objname=, _no_fp=, no_unreachable=, orc=orc@entry=true) at check.c:1971 #3 0x811f in cmd_orc (argc=, argv=0x7fffd8d8) at builtin-orc.c:54 #4 0xf490 in handle_internal_command (argv=0x7fffd8d0, argc=4) at objtool.c:108 #5 main (argc=4, argv=0x7fffd8d0) at objtool.c:131 (gdb) p rela->sym $1 = (struct symbol *) 0x0 BR, Markus config.xz Description: application/xz
Re: objtool segfault with ORC unwinder enabled
On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote: > On Wed, Jan 03, 2018 at 01:22:07PM +0100, Markus wrote: > > On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote: > > > On Wed, Jan 03, 2018 at 11:49:08AM +0100, Markus wrote: > > > > Hello! > > > > > > > > ORC unwinder is enabled in stable for wider testing but still at least > > > > one > > > > bug is open: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=197035 > > > > > > Random web links on mailing lists don't help much, please put the > > > information here in the email. > > > > Its not a random web link. Its the official kernel.org bugtracker. But > > nobody seems to be looking at it. > > > > > > objtool will segfault because a NULL pointer is dereferenced. > > > > > > And how are you reproducing this? > > > > Just building the kernel with ORC enabled. > > (At least for me. Using framepointers compiles, enabling ORC again breaks > > it.) gcc 6.4.0 (In bug report others were tested as well.) > > elfutils 0.170 > > What else may be interesting? > > > > > > Is a NULL pointer sym valid? > > > > If a NULL pointer is invalid, it has to be checked why it is sometimes > > > > NULL. > > > > > > What .config is triggering this problem? > > > > See attachment. > > > > > And does this show up on 4.14.11, and 4.15-rc6? > > > > Both: yes. > > > > /tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/irq.o" > > > > => segfault. > > > > Changing CFLAGS for objtool to O1 and starting from gdb: > > > > (gdb) r orc generate --no-fp "arch/x86/kernel/irq.o" > > Starting program: tools/objtool/objtool orc generate --no-fp > > "arch/x86/kernel/ irq.o" > > > > Program received signal SIGSEGV, Segmentation fault. > > 0xe06c in elf_rebuild_rela_section > > (sec=sec@entry=0x7690d010) at elf.c:554 > > 554 relas[idx].r_info = GELF_R_INFO(rela->sym->idx, > > rela-> > > >type); > > > > (gdb) bt > > #0 0xe06c in elf_rebuild_rela_section > > (sec=sec@entry=0x7690d010) at elf.c:554 > > #1 0xd0aa in create_orc_sections > > (file=file@entry=0x7ff7d740) at orc_gen.c:210 > > #2 0xc146 in check (_objname=, > > _no_fp=, no_unreachable=, > > orc=orc@entry=true) at check.c:1971 #3 0x811f in cmd_orc > > (argc=, argv=0x7fffd8d8) at builtin-orc.c:54 > > #4 0xf490 in handle_internal_command (argv=0x7fffd8d0, > > argc=4) at objtool.c:108 > > #5 main (argc=4, argv=0x7fffd8d0) at objtool.c:131 > > (gdb) p rela->sym > > $1 = (struct symbol *) 0x0 > > I'm unable to recreate. Can you attach one of the .o files (like the > above irq.o)? Sure, see attached. (From vanilla linux-4.14.11.) BR, Markus irq.o.xz Description: application/xz
Re: objtool segfault with ORC unwinder enabled
On Wed, Jan 03, 2018 15:14:01 CET Greg Kroah-Hartman wrote: > On Wed, Jan 03, 2018 at 01:22:07PM +0100, Markus wrote: > > On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote: > > > On Wed, Jan 03, 2018 at 11:49:08AM +0100, Markus wrote: > > > > Hello! > > > > > > > > ORC unwinder is enabled in stable for wider testing but still at least > > > > one > > > > bug is open: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=197035 > > > > > > Random web links on mailing lists don't help much, please put the > > > information here in the email. > > > > Its not a random web link. Its the official kernel.org bugtracker. But > > nobody seems to be looking at it. > > Not all subsystems use bugzilla.kernel.org, sorry. Email is the > preferred way for almost all subsystems. > > > > > objtool will segfault because a NULL pointer is dereferenced. > > > > > > And how are you reproducing this? > > > > Just building the kernel with ORC enabled. > > (At least for me. Using framepointers compiles, enabling ORC again breaks > > it.) gcc 6.4.0 (In bug report others were tested as well.) > > elfutils 0.170 > > What else may be interesting? > > Have you tried gcc 7? No I have no gcc 7 installed, yet. (In the bug report gcc 8.0.0 and gcc 5.4.0 were mentioned.) > What distro is this? Hopefully not hardened Gentoo? :) Just a normal gentoo. > > > > Is a NULL pointer sym valid? > > > > If a NULL pointer is invalid, it has to be checked why it is sometimes > > > > NULL. > > > > > > What .config is triggering this problem? > > > > See attachment. > > > > > And does this show up on 4.14.11, and 4.15-rc6? > > > > Both: yes. > > > > /tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/irq.o" > > > > => segfault. > > Ugh, I can't duplicate here :( How about the previously attached irq.o? BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Wed, Jan 03, 2018 at 17:36:30 CET Josh Poimboeuf wrote: > On Wed, Jan 03, 2018 at 03:14:55PM +0100, Markus wrote: > > On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote: > > > On Wed, Jan 03, 2018 at 01:22:07PM +0100, Markus wrote: > > > > /tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/irq.o" > > > > > > > > => segfault. > > > > > > > > Changing CFLAGS for objtool to O1 and starting from gdb: > > > > > > > > (gdb) r orc generate --no-fp "arch/x86/kernel/irq.o" > > > > Starting program: tools/objtool/objtool orc generate --no-fp > > > > "arch/x86/kernel/ irq.o" > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > 0xe06c in elf_rebuild_rela_section > > > > (sec=sec@entry=0x7690d010) at elf.c:554 > > > > 554 relas[idx].r_info = > > > > GELF_R_INFO(rela->sym->idx, > > > > rela-> > > > > > > > > >type); > > > > > > > > (gdb) bt > > > > #0 0xe06c in elf_rebuild_rela_section > > > > (sec=sec@entry=0x7690d010) at elf.c:554 > > > > #1 0xd0aa in create_orc_sections > > > > (file=file@entry=0x7ff7d740) at orc_gen.c:210 > > > > #2 0xc146 in check (_objname=, > > > > _no_fp=, no_unreachable=, > > > > orc=orc@entry=true) at check.c:1971 #3 0x811f in cmd_orc > > > > (argc=, argv=0x7fffd8d8) at builtin-orc.c:54 > > > > #4 0xf490 in handle_internal_command > > > > (argv=0x7fffd8d0, > > > > argc=4) at objtool.c:108 > > > > #5 main (argc=4, argv=0x7fffd8d0) at objtool.c:131 > > > > (gdb) p rela->sym > > > > $1 = (struct symbol *) 0x0 > > > > > > I'm unable to recreate. Can you attach one of the .o files (like the > > > above irq.o)? > > > > Sure, see attached. (From vanilla linux-4.14.11.) > > There's something weird with the toolchain. The object file doesn't > have an ELF section symbol for the .irqentry.text section. > > Are there any special KCFLAGS being added? Can you build the object > with V=1 to show the full gcc command line? I have not added anything. There is no env variable set like $KCFLAGS or $CFLAGS. (If that was the question.) I think you mean this line from output: gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- pc-linux-gnu/6.4.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./ include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h - D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno- format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow - mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 - mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone - mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 - DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO - Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable - Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments - Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes - Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init - Iarch/x86/kernel/../include/asm/trace-DKBUILD_BASENAME='"irq"' - DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o arch/x86/kernel/irq.c The next line is the objtool that segfaults. BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > On Wed, Jan 03, 2018 at 06:26:19PM +0100, Markus wrote: > > > > > I'm unable to recreate. Can you attach one of the .o files (like > > > > > the > > > > > above irq.o)? > > > > > > > > Sure, see attached. (From vanilla linux-4.14.11.) > > > > > > There's something weird with the toolchain. The object file doesn't > > > have an ELF section symbol for the .irqentry.text section. > > > > > > Are there any special KCFLAGS being added? Can you build the object > > > with V=1 to show the full gcc command line? > > > > I have not added anything. There is no env variable set like $KCFLAGS or > > $CFLAGS. (If that was the question.) > > > > I think you mean this line from output: > > gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem > > /usr/lib/gcc/x86_64- pc-linux-gnu/6.4.0/include -I./arch/x86/include > > -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi > > -I./arch/x86/include/generated/uapi -I./ include/uapi > > -I./include/generated/uapi -include ./include/linux/kconfig.h - > > D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- > > aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration > > -Wno- format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 > > -mno-3dnow - mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 > > -mno-fp-ret-in-387 - mpreferred-stack-boundary=3 -mskip-rax-setup > > -mtune=generic -mno-red-zone - mcmodel=kernel -funit-at-a-time > > -DCONFIG_AS_CFI=1 - > > DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 > > -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 > > -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - DCONFIG_AS_AVX512=1 > > -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- sign-compare > > -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - > > Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO > > - Wframe-larger-than=2048 -fno-stack-protector > > -Wno-unused-but-set-variable - Wno-unused-const-variable > > -fomit-frame-pointer -fno-var-tracking-assignments - > > Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- > > stack-check -fconserve-stack -Werror=implicit-int > > -Werror=strict-prototypes - Werror=date-time > > -Werror=incompatible-pointer-types -Werror=designated-init - > > Iarch/x86/kernel/../include/asm/trace-DKBUILD_BASENAME='"irq"' - > > DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o > > arch/x86/kernel/irq.c > > > > The next line is the objtool that segfaults. > > I don't see anything unusual there. Are there any Gentoo patches > against either the kernel or GCC which would strip unused symbols? The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) Its not a gentoo specific gcc patch. (Then every gentoo user would be affected?) But I enabled ld.gold as default linker like 5 years ago. Never had a problem with this. Is ld.gold supposed to fail here? I switched back to ld.bfd and it seems to work. BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > I don't see anything unusual there. Are there any Gentoo patches > > > against either the kernel or GCC which would strip unused symbols? > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > affected?) > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > problem with this. > > > > Is ld.gold supposed to fail here? > > > > I switched back to ld.bfd and it seems to work. > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > work after gcc, but before objtool. Can you try this patch? (Note this > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index cb8997ed0149..3cf3cc6077ea 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -270,7 +270,7 @@ endif > # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a > file cmd_objtool = $(if $(patsubst y%,, \ > $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$ (OBJECT_FILES_NON_STANDARD)n) > , \ - $(__objtool_obj) $(objtool_args) "$(@)";) > + $(__objtool_obj) $(objtool_args) "$(@D)/.tmp_$(@F)";) > objtool_obj = $(if $(patsubst y%,, \ > $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$ (OBJECT_FILES_NON_STANDARD)n) > , \ $(__objtool_obj)) > @@ -286,16 +286,16 @@ objtool_dep = $(objtool_obj) > \ > define rule_cc_o_c > $(call echo-cmd,checksrc) $(cmd_checksrc) \ > $(call cmd_and_fixdep,cc_o_c) \ > + $(call echo-cmd,objtool) $(cmd_objtool) \ > $(cmd_modversions_c) \ > $(cmd_checkdoc) \ > - $(call echo-cmd,objtool) $(cmd_objtool) \ > $(call echo-cmd,record_mcount) $(cmd_record_mcount) > endef > > define rule_as_o_S > $(call cmd_and_fixdep,as_o_S) \ > - $(cmd_modversions_S) \ > - $(call echo-cmd,objtool) $(cmd_objtool) > + $(call echo-cmd,objtool) $(cmd_objtool) \ > + $(cmd_modversions_S) > endef > > # List module undefined symbols (or empty line if not enabled) With that patch the kernel is building with ld.gold. BR, Markus
Re: objtool segfault with ORC unwinder enabled
On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > I don't see anything unusual there. Are there any Gentoo patches > > > > against either the kernel or GCC which would strip unused symbols? > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > > affected?) > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > > problem with this. > > > > > > Is ld.gold supposed to fail here? > > > > > > I switched back to ld.bfd and it seems to work. > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > work after gcc, but before objtool. Can you try this patch? (Note this > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) Any more final patch I should test? BR, Markus
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
* Matthew <[EMAIL PROTECTED]> wrote: > I read that now loop devices are being created on demand, which > obviously (still) not works yes, someone thought this was a good idea :( > Is there a way to trigger such creation? does modprobe loop max_loop=32 work? -- left blank, right bald pgp1Dm6S8T6gI.pgp Description: PGP signature
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
* Paolo Ornati <[EMAIL PROTECTED]> wrote: > So with this patch "max_loop=32" will create 32 loop devices... but > then it doesn't allow more of them. Well, that's what a max_ parameter implies ;p A manually set limit of loop devices is ok with me. (32 was just an example -- After all, I could have chosen 256 just to annoy some people :-) And with the recent hype of creating things when needed, or even recycling already used ones (sdx), I worry that this impacts stability or even usability as a whole. (yes, it's a -rc release ...) I'll be staying with 2.6.20.x for a year or so. Get the newly introduced bugs squashed before they have a chance to bug me, heh ;P PS: Just wondering: Who came up with this "on-demand" hype? -- left blank, right bald pgpj4JvUea3ww.pgp Description: PGP signature
Re: How to improve the quality of the kernel?
On 6/17/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
On 6/17/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
> > Adrian Bunk wrote:
> > >>> And we should be aware that reverting is only a workaround for the
real
> > >>> problem which lies in our bug handling.
> > >> ...
> > >
> > > And this is something I want to emphasize again.
> > >
> > > How can we make any progress with the real problem and not only the
> > > symptoms?
> > ...
> >
> > Perhaps make lists of
> >
> > - bug reports which never lead to any debug activity
> > (no responsible person/team was found, or a seemingly person/team
> > did not start to debug the report)
> >
> > - known regressions on release,
> >
> > - regressions that became known after release,
> >
> > - subsystems with notable backlogs of old bugs,
> >
> > - other categories?
> >
> > Select typical cases from each categories, analyze what went wrong in
> > these cases, and try to identify practicable countermeasures.
>
> No maintainer or no maintainer who is debugging bug reports is the
> major problem in all parts of your list.
>
> > Another approach: Figure out areas where quality is exemplary and try
> > to draw conclusions for areas where quality is lacking.
>
> ieee1394 has a maintainer who is looking after all bug reports he gets.
>
> Conclusion: We need such maintainers for all parts of the kernel.
>
I noticed some areas are well maintained because there is an awesome
maintainer, or good and well coordinated team - and this is mostly in
the "fun" areas ;) But there are "boring" areas that are about to be
deprecated or no new development expected etc. It will be hard to get
a dedicated person to take care of such. How about having people on
rotation, or jury duty so to speak - for a period of time (completely
voluntary!) Nice stats on the report about contributions in non-native
areas for a developer would be great accomplishment and also good
chance to look into other things! Besides, this way "old parts" will
get attention to be be revised and re-implemented sooner. And we can
post "Temp maintainer needed" list...
I'd vote for that, I've seen alot very bad code already within some
subsystems and critical problems which just have been ignored by some
maintainers.
It mostly helps if some volunteers read through existing code and
state out their considerations about implementations which they don't
like.
I just grep'ed some examples I noticed (note I do not want to jump
onto someone's toe here, just give some examples):
(sn9c102_ov7660.c)
...
err += sn9c102_i2c_write(cam, 0x12, 0x80);
err += sn9c102_i2c_write(cam, 0x11, 0x09);
err += sn9c102_i2c_write(cam, 0x00, 0x0A);
err += sn9c102_i2c_write(cam, 0x01, 0x80);
err += sn9c102_i2c_write(cam, 0x02, 0x80);
err += sn9c102_i2c_write(cam, 0x03, 0x00);
... (around 150 lines directly after each other doing such writes and
adding error values to a variable, I don't understand why someone
should add the errors but continue with sending 150 more updates, how
about one write failed but others succeeded for any reason)
(tvp5150.c)
static int tvp5150_read(struct i2c_client *c, unsigned char addr)
{
unsigned char buffer[1];
int rc;
buffer[0] = addr;
if (1 != (rc = i2c_master_send(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
msleep(10);
if (1 != (rc = i2c_master_recv(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
tvp5150_dbg(2, "tvp5150: read 0x%02x = 0x%02x\n", addr, buffer[0]);
return (buffer[0]);
}
(i2c issues within some driver)
/* This code detects calls by card attach_inform */
if (NULL == t->i2c.dev.driver) {
tuner_dbg ("tuner 0x%02x: called during i2c_client
register by adapter's attach_inform\n", c->addr);
return;
}
... that code doesn't even work anymore since the i2c.dev.driver is
always initialized.
just reading through it and cleaning up some code isn't so difficult
and can be done by many people - if they're allowed/wanted to do so.
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
very_ code which provides additional features and where noone expects further improvements within the next few weeks (without throwing away alot of work or generating useless extra work by telling someone to rewrite the core of his work); everyone still can try to write better code - but then he _has to do it completly_ and get in peace with the projects by supporting them to get further. The problem I have with this project is that many more things are upcoming at the moment (including bug fixing) but there are certain developers which first weren't experienced enough, afterwards started to think about the issues which were tried to discuss at the beginning already and who don't have an overview about the requirements, neither do they want to discuss the requirements. I can name numerous of bugs of this project which can be solved but which just get ignored. Some known bugs dont even get explained to people who are interested in fixing them, so this is what I consider that it's a major problem. I'm looking for a serious discussion about it, if anyone wants to know about the history I can point out to many logfiles/older emails which deeply explain the whole video4linux/dvb issues - the project should turn back to a real community. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
On 6/1/07, Bill Eldridge <[EMAIL PROTECTED]> wrote: Sounds good, Markus - do you have a list of known bugs that need to be handled? Yes, I put together a few things that came into mind: http://mcentral.de/wiki/index.php/Bugtracker Is this something that can go up on the Wiki, or are there enough that a bug tracking system is required? Wiki/ML should be fine, people use to avoid the bugzilla on kernel.org although I'd be fine with it (at least for the em28xx project) but people prefer to add bugreports to the wiki or send mails. While timelines won't be enforceable for people doing things in their spare time, it's still useful to put up time goals and priority lists on projects, both new development and bug fixes, to keep momentum going and gauge progress, including seeing that something that should have been fixed isn't getting handled. Can people accept Markus as a reasonable, informed arbiter of what will go into the main tree even if there are disagreements? It also sounds like new programmers here need more startup instructions/assistance/advice and ground rules than on many open source projects. I would appreciate to get more people involved with that project, VDR/mythTV/mplayer/ffmpeg etc. projects use the outcoming work. While the v4l and dvb project is doing really hard at the moment and improvements are handled in a snail speed (if ever handled) this should really change. cheers, Markus Regards, Bill Markus Rechberger wrote: > > Some developers are also sick of contributing since the whole > community is flawed at the moment. I propose a few ways to go > > * stopping that signed off by madness that every driver developer has > to sign off changes which happened at the core which will definitelly > never happen because people _do not like each other_. > > * change the maintainership and push it over to me, even if it sounds > selfish at the moment _every_ code which provides additional features > and where noone expects further improvements within the next few weeks > (without throwing away alot of work or generating useless extra work > by telling someone to rewrite the core of his work); everyone still > can try to write better code - but then he _has to do it completly_ > and get in peace with the projects by supporting them to get further. > > The problem I have with this project is that many more things are > upcoming at the moment (including bug fixing) but there are certain > developers which first weren't experienced enough, afterwards started > to think about the issues which were tried to discuss at the beginning > already and who don't have an overview about the requirements, neither > do they want to discuss the requirements. > I can name numerous of bugs of this project which can be solved but > which just get ignored. Some known bugs dont even get explained to > people who are interested in fixing them, so this is what I consider > that it's a major problem. > > I'm looking for a serious discussion about it, if anyone wants to know > about the history I can point out to many logfiles/older emails which > deeply explain the whole video4linux/dvb issues - the project should > turn back to a real community. > > Markus > -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] remove orphaned Email
Manuel Estrada Sainz passed away on May 9th 2004, his email account got
deactivated. He was in charge of the firmware_class code, and still got
CC'ed in recent discussions about it.
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
index e9cc8bb..d19eb19 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -1,7 +1,7 @@
request_firmware() hotplug interface:
- Copyright (C) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ Copyright (C) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
Why:
---
diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
index 87feccd..3d4a877 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_driver.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Sample code on how to use request_firmware() from drivers.
*
diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c
index 9e1b0e4..678b050 100644
--- a/Documentation/firmware_class/firmware_sample_firmware_class.c
+++ b/Documentation/firmware_class/firmware_sample_firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_firmware_class.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* NOTE: This is just a probe of concept, if you think that your driver would
* be well served by this mechanism please contact me first.
@@ -19,7 +19,7 @@
#include
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
MODULE_LICENSE("GPL");
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 97ab5bd..672c221 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_class.c - Multi purpose firmware loading support
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Please see Documentation/firmware_class/ for more information.
*
@@ -23,7 +23,7 @@
#define to_dev(obj) container_of(obj, struct device, kobj)
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Multi purpose firmware loading support");
MODULE_LICENSE("GPL");
Re: pci probe
On 5/30/07, Greg KH <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote: > Greg KH wrote: > > On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote: > >> Manu Abraham wrote: > >>> Hi, > >>> > >>> I do have a device that's a multifunction device. Eventhough a MFD, it > >>> just has one Interrupt which is shared by by a Configuration space for > >>> each function. ie, INTA is shared between them functions. > >>> > >>> In such a case, i am wondering, (since pci_probe returns a pointer to > >>> one PCI function alone and i need to use both the functions in one > >>> module alone rather than using a module for each function and that the > >>> functions are quite similar for them to be used in different modules, > >>> such that a separate probe/ISR etc is used) whether using pci_get_device > >>> would be a better alternative to do manual searching for the functions > >>> in such a case. > >>> > >> Just figured out that pci_get_subsys() does work in a better. Looking at > >> kernel sources all i find is just one single user of pci_get_subsys() > >> > >> building the code around pci_get_subsys(), does this have any negative > >> impact ? > > > > Yes: > > - your device will not show up properly in sysfs (no > > device/driver binding ability from userspace, no good > > information so that udev can properly name the device, etc.) > > This one sounds bad. > > > - your driver will not work on any pci-hotplug type system (that > > includes expresscard and pccard and lots of high-end servers. > > This doesn't matter Are you sure? PCI Hotplug is showing up in more places that people realize... In case of video4linux and dvb, there are cx88 and saa7134 based pcmcia devices available which show up as PCI devices, both of these drivers enable the interrupts as soon as they're connected and there's no need to access the device nodes for that. Another point is that they're not hotplug aware, the driver end up in an endless loop or crashes linux if someone unplugs the device (even if it's not in use). > > - your driver will not be notified if the system is being > > suspended or resumed or wanting to drop into a low power > > state. > > - another driver can bind to your device without you ever > > knowing it. > > These also sound bad. > > > So in short, use pci_probe and just handle the fact that you need to be > > called for two PCI devices and bind to both of them. It shouldn't be > > that hard... > > Thanks for the explanation. > > Do you mean to have two PCIID tables ? But then that does mean 2 modules > don't you ? (i thought probe would be called once per module) Or you > mean to say use PCI_ANY_ID in the table to match multiple devices and > then allow probe to return a list of devices ? No, you can specify multiple devices in the same device id table, and your driver will get called for all of the matching devices. You just need to "bind" them together in your driver to be able to handle everything properly. It shouldn't be that tough. Uwe posted an example how to tie multiple functions of a device together, there are quite a few ways how to solve that problem. http://linuxtv.org/pipermail/linux-dvb/2007-June/018481.html Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parallel port problems with 2.6.21_rc5 and 2.6.21_rc6_git3-20070410174235
Am Montag, 14. Mai 2007 schrieb Randy Dunlap: > On Sat, 5 May 2007 16:58:22 +0200 Markus Koßmann wrote: > > Am Donnerstag, 3. Mai 2007 schrieb Randy Dunlap: > > > On Wed, 11 Apr 2007 20:40:23 +0200 Markus Koßmann wrote: > > > > When using either the unpatched 2.6.21_rc5 or SUSEs patched > > > > 2.6.21_rc6_git3-20070410174235 on a SUSE-10.2 x86_64 system the > > > > parallel port doesn't work right. If I "cat some_asciifile >/dev/lp0" > > > > the output on my Epson Stylus Color 880 is unreadable. "cat > > > > /dev/zero >/dev/lp0" creates random characters on the paper. Printing > > > > using cups also doesn't work any more. > > > > Switching back to SUSEs 2.6.18.8-0.1 kernel fixes the problem. > > > > Any Ideas, what might be broken here ? > > > > > > Nope, but I have the same problem. > > > I'll dig into it some day, but it's not very high priority for me. > > > > > > I haven't tested it lately. Do you still see this problem? > > > > Yes, it still exists with SUSEs 2.6.21-20070502152652 kernel. Didn't > > check with vanilla 2.6.21 yet. > > Hi Markus, > > I just retested this on 2.6.21-git12 and didn't have a problem > with printing. Can you test on 2.6.22-rc1? > Seems to be fixed in 2.6.22-rc1 but vanilla 2.6.21 was also bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.2a file/swap crypto package
* Jari Ruusu <[EMAIL PROTECTED]> wrote: > loop-AES changes since previous release: > - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. > They are not built by default. Add EXTRA_CIPHERS=y make parameter > to build them. Just curious, will the ciphers package also be continued/available separately as before or is it merged from now on into the loop-aes package? -- left blank, right bald pgp07NXkceOEL.pgp Description: PGP signature
Re: [PATCH] em28xx and ivtv should depend on PCI
On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > Al Viro wrote: > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > --- > > drivers/media/video/em28xx/Kconfig |2 +- > > drivers/media/video/ivtv/Kconfig |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/em28xx/Kconfig b/drivers/media/video/em28xx/Kconfig > > index 3823b62..2c450bd 100644 > > --- a/drivers/media/video/em28xx/Kconfig > > +++ b/drivers/media/video/em28xx/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_EM28XX > > tristate "Empia EM2800/2820/2840 USB video capture support" > > - depends on VIDEO_V4L1 && I2C > > + depends on VIDEO_V4L1 && I2C && PCI > > Err .. why would a USB device need to be depend on PCI ? Because video-buf.c does. And VIDEO_EM28XX selects it. the em28xx does not rely on video-buf, this seems to be a dependency derived from another dependency. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parallel port problems with 2.6.21_rc5 and 2.6.21_rc6_git3-20070410174235
Am Donnerstag, 3. Mai 2007 schrieb Randy Dunlap: > On Wed, 11 Apr 2007 20:40:23 +0200 Markus Koßmann wrote: > > When using either the unpatched 2.6.21_rc5 or SUSEs patched > > 2.6.21_rc6_git3-20070410174235 on a SUSE-10.2 x86_64 system the parallel > > port doesn't work right. If I "cat some_asciifile >/dev/lp0" the output > > on my Epson Stylus Color 880 is unreadable. "cat /dev/zero >/dev/lp0" > > creates random characters on the paper. Printing using cups also doesn't > > work any more. > > Switching back to SUSEs 2.6.18.8-0.1 kernel fixes the problem. > > Any Ideas, what might be broken here ? > > Nope, but I have the same problem. > I'll dig into it some day, but it's not very high priority for me. > > I haven't tested it lately. Do you still see this problem? > Yes, it still exists with SUSEs 2.6.21-20070502152652 kernel. Didn't check with vanilla 2.6.21 yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
Hi Jiri,
I have some comments for your driver.
> + * Copyright (C) Nicolas VIVIEN
It would be interesting to have Nicolas SOB as well, if possible.
> +
> +#ifndef CONFIG_STK11XX_DEBUG_STREAM
> +#define CONFIG_STK11XX_DEBUG_STREAM 0
> +#endif
> +
> +#if CONFIG_STK11XX_DEBUG_STREAM
I would instead use:
#ifdef CONFIG_STK11XX_DEBUG_STREAM
> +/*
> + * Bayer conversion
> + */
We don't do format conversions in kernel. Instead, you should return a
proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).
It's ok in his case since most userspace applications do not support
this format, it helps noone if there's a driver out there which isn't
supported by most userspace applications and I don't expect that all
applications will add a conversion for that format soon.
This would moreover raise the question about a userspace library,
though there are many more important issues which are outstanding and
which got smashed down.
> +static void stk11xx_resize_image(u8 *out, const u8 *in,
> + unsigned int width, unsigned int height, unsigned int factor)
Also, kernel shouldn't be doing image resize.
> +static int stk11xx_decompress(struct stk11xx *dev)
> +{
We don't do format conversions in kernel. Instead, you should return a
proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).
> +static int stk1125_load_microcode(struct stk11xx *dev)
> +{
> + unsigned int i;
> + const u8 *values_204, *values_205;
> + int retok, value;
> +
> + /* From 80x60 to 640x480 */
> + const u8 values_1_204[] = {
> + 0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> + 0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> + 0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> + 0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> + 0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> + 0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> + };
> + const u8 values_1_205[] = {
> + 0x45, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> + 0x50, 0x93, 0x00, 0x81, 0x20, 0x45, 0x00, 0x00, 0x00, 0x24,
> + 0xc4, 0xb6, 0x00, 0x3c, 0x36, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> + 0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> + 0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> + 0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> + };
> +
> + /* From 800x600 to 1280x1024 */
> + const u8 values_2_204[] = {
> + 0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> + 0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> + 0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> + 0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> + 0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> + 0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> + };
> + const u8 values_2_205[] = {
> + 0x05, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> + 0x50, 0x93, 0x00, 0x81, 0x20, 0x05, 0x00, 0x00, 0x00, 0x1b,
> + 0xbb, 0xa4, 0x01, 0x81, 0x12, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> + 0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> + 0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> + 0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> + };
Please use instead the load_firmware routines. It is not a good idea to
have firmware inside the kernel. Also, this might rise some legal issues
due to licensing models.
Jiri, are you allowed to include that microcode, did you get any
information about this from the manufacturer which could allow the
inclusion?
The sequences are rather small not putting it into extra firmware
files would make life much easier for some users, on the other side if
it raises legal issues Mauro's right with loading it from a file
Markus
> +
> +/*
> + * The configuration of device is composed of 11 steps.
> + * This function is called by the initialization process.
> + *
> + * We don't know the meaning of these steps! We only replay the USB log.
> + *
> + * The steps 0 to 9 are called during the initialization.
> + * Then, the driver choose the last step :
> + * 10 : for a resolution from 80x60 to 640x480
> + * 11 : for a resolution from 800x600 to 1280x1024
> + */
> +static int stk1125_configure_device(struct stk11xx *dev, int step)
> +{
> + int value;
> +
> + /* 0,1,2,3,4,5,6,7,8,9,
> + 10, 11 */
> +
> + const u8 values_001B[] = {
> + 0x0E, 0x03, 0x0E, 0
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
On 5/24/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> Hi Jiri,
>
> On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> > Well, no objections on v4l list, try to merge it. Any further comments
will
> > be
> > appreciated.
> >
> > --
> >
> > stk11xx, add a new webcam driver
> >
> > Cc: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> >
[...]
> > +/*
> > + * Bayer conversion
> > + */
> > +
> > +#define STK11XX_AVG2(x,y) (u8)(((int)x + (int)y) / 2)
> > +#define STK11XX_AVG4(a,b,c,d) (u8)(((int)a + (int)b + (int)c + (int)d)
/ 4)
> > +
> > +static void stk11xx_bayer_to_rgb(u8 *rgb, const u8 *bayer,
> > + const int width, const int height)
>
> hmm.. this is probably to support xawtv/tvtime?
> It would be better to do that in userspace, but the argument which
> seems to be against it is that userspace applications often don't
> support bayer.
Exactly. This would make the webcam driver unusable. Another one,
which awaits RGB is camstream, which also I use. After moving all
major used userspace apps to something like pwlib, this may be wiped
out.
> > +{
> > + unsigned int x, y, nwidth, nheight;
> > +
> > + nheight = height / factor;
> > + nwidth = width / factor;
> > +
> > + for (y = 0; y < nheight; y++) {
> > + for (x = 0; x < nwidth; x++) {
> > + /* R */
> > + out[y * nwidth * 3 + x * 3 + 0] =
> > + in[y * factor * width * 3 + x * factor * 3 +
0];
> > + /* G */
> > + out[y * nwidth * 3 + x * 3 + 1] =
> > + in[y * factor * width * 3 + x * factor * 3 +
1];
> > + /* B */
> > + out[y * nwidth * 3 + x * 3 + 2] =
> > + in[y * factor * width * 3 + x * factor * 3 +
2];
> > + }
> > + }
> > +}
> > +
> > +static void stk11xx_correct_brightness(u8 *rgb, unsigned int width,
> > + unsigned int height, int brightness)
> > +{
>
> same here, why do you want to have that in kernelspace?
not sure who from userspace can do this nowadays. Will check.
> > +/*
> > + * The configuration of device is composed of 12 steps.
> > + * This function is called by the initialization process.
> > + *
> > + * We don't know the meaning of these steps! We only replay the USB
log.
> > + */
> > +static int stk1135_configure_device(struct stk11xx *dev, int step)
> > +{
> > + int value;
> > +
> > + /* 0,1,2,3,4,5,6,7,8,9,
> > + 10, 11, 12, 13 */
> > +
> > + const u8 values_001B[] = {
> > + 0x0E, 0x03, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
0x07,
> > + 0x07, 0x07, 0x07, 0x07
> > + };
> > + const u8 values_001C[] = {
> > + 0x06, 0x02, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x06,
0x06,
> > + 0x06, 0x06, 0x06, 0x07
> > + };
> > + const u8 values_0202[] = {
> > + 0x1E, 0x0A, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E,
0x1E,
> > + 0x1E, 0x1E, 0x1E, 0x1E
> > + };
> > + const u8 values_0110[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x3E, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0112[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x09, 0x09, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0114[] = {
> > + 0x87, 0x80, 0x80, 0x80, 0x80, 0xBE, 0xBE, 0x80, 0x84,
0x80,
> > + 0x80, 0x80, 0x80, 0x80
> > + };
> > + const u8 values_0116[] = {
> > + 0xE7, 0xE0, 0xE0, 0xE0, 0xE0, 0xE9, 0xE9, 0xE0, 0xE4,
0xE0,
> > + 0xE0, 0xE0, 0xE0, 0xE0
> > + };
> > + const u8 values_0100[] = {
> > + 0x20, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x23,
0x20,
> > + 0x20, 0x20, 0x20, 0x20
> > + };
> > +
> > + dev_dbg(&dev->udev->dev, "stk1135_configure_device: %d\n", step);
> > +
> > + stk11xx_write_registry(dev, 0x, 0x0024);
> > + stk11xx_write_registry(dev, 0x0002, 0x0068);
> >
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Luca Risolia <[EMAIL PROTECTED]> wrote: On Monday 28 May 2007 17:14:51 Markus Rechberger wrote: > On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. Markus, I do think the userspace library is THE real problem with the whole V4L subsystem. It's annoying to keep repeating why these convertions should be done outside the kernel, be them in a library or not. I deliberatly never implemented the above convertion in the drivers that I have been maintaing for years, since I had the idea that this approach whould have pushed the developers to write the _best_ algorithm by themselves. I still think it's the correct approach, but now I give up. Mauro, if you are planning to accept this BayerToSomething color convertion, be also prepared to accept the same convertion for other drivers in the kernel. Rules are made for everyone. Initially asking for help doesn't lead anywhere either because most people aren't skilled enough or have personal issues with helping out at linuxtv. I'm fine with the conversion, a valid point is scaling, this is something userspace can handle already. And as I mentioned there are more important issues out there which should be handled first, but they're greatly getting ignored again (just as usual, and this also takes regressions and current implementation bugs in account). Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: Em Seg, 2007-05-28 às 17:14 +0200, Markus Rechberger escreveu: > > > +/* > > > + * Bayer conversion > > > + */ > > > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Instead starting another one (which would lack any design since I haven't seen any thread that was picking together requirements), improving that existing one might also be helpful for applications like ekiga. As for libpw it also supports colourspace conversion and software scaling, the used algorithms seem to need some improvement, but alot work has already been done there. Of course other libraries should also be taken into account, maybe someone knows something better which is more complete. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
; 1. Andrew Morton should not obey to Chehab anymore and be real open > > 2. Chehab and Abraham should be substituted as quick as possible without > any hesitation in no way > > > > The one that got to be fired with the most urgent priority is called > Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper, but this > is nothing but a real personified ape or disease. > > > > And the argument whether those people are paid for their work or not is > exactly as important as if a sack of rice falls down somewhere in > capitalist China or not. > > OBSOLETE!!! > > > > Yours sincerely > > Uwe > > > > If eventually somebody thinks this kind of stuff could be helpful, > please say so and give us some pointers. > > Hermann > Hi Hermann, now if you are searching for helpful stuff I can make public a ten Emails ping pong betwwen stupid Chehab and me about my almost excellent dst-deselection patch contributions. In this ten Emails you will yourself see the intellectual and technical proof in how far Mr. Chehab is acting with nothing else but: a. Lies b. Unproven thesis c. Stigmatizations and so on. THIS MAN HAS NO IDEA, BUT HE HAS THE POWER! That's it what I cannot live with! I swear I never stumbled over such an utomst stubborn, stupid and horrible idiot in my whole year lasting Linux experience, and I thought I could not trust my eyes when I saw what incredible crap work was pushed into mainline by the signature of this incredible and horrible team chief from Brazil. If you want to see the Emails, just ask me and I will forward them with a couple of CCs. They will show the truth about the real consistence of this "maintainer leader". Uwe, which patches do you refer to? Can you submit a list of your patches which got no attention (I'm only interested in the patches, not in discussions you had) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Uwe Bugla" <[EMAIL PROTECTED]> CC: "hermann pitton" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > > > Original-Nachricht > > Datum: Mon, 30 Apr 2007 02:58:33 +0200 > > Von: hermann pitton <[EMAIL PROTECTED]> > > An: Uwe Bugla <[EMAIL PROTECTED]> > > CC: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > [EMAIL PROTECTED], [EMAIL PROTECTED], > > linux-kernel@vger.kernel.org > > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 > > and pseudo-authorities > > > > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > > > > Original-Nachricht > > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > > > > Von: Linus Torvalds <[EMAIL PROTECTED]> > > > > An: Uwe Bugla <[EMAIL PROTECTED]> > > > > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], > > > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > > > > Betreff: Re: Critical points about kernel 2.6.21 and > pseudo-authorities > > > > > > > > > > > > > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > > > > > > > I have been trying diff and other tools in various variants > (except > > > > > > git-bisect that I cannot handle because I do not understand the > > > practice > > > > > > of it). > > > > > > > > > > git bisect is _really_ simple if you already have a git tree > anyway. > > > And > > > > > even if you don't, getting one isn't really hard either. Just do > > > > > > > > > >git clone > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > > linux-2.6 > > > > > > > > > > and you have a tree (it will take a little while - it's going to > > > dowload > > > > > about 170MB or so of stuff, so the initial clone is going to be a > bit > > > > > painful unless you have a fast internet connection). > > > > > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for > you, > > > it's > > > > > really as easy as just saying > > > > > > > > > >git bisect start > > > > >git bisect good v2.6.21-rc7 > > > > >git bisect bad v2.6.21 > > > > > > > > > > and git will think for a short while (most of the time is going to > be > > > > > checking out the new tree) and give you a tree to test. > > > > > > > > > > Just build, boot, and test that tree. > > > > > > > > > > If it was fine, do > > > > > > > > > >git bisect good > > > > > > > > > > and git will pick a new tree to test. And if it wasn't, instead > just > > > do > > > > > "git bisect bad", and git will pick _another_ version to test. Do > this > > > a > > > > > few times, and git will tell you which commit introduced them. > > > > > > > > > > There were just 125 commits in between 2.6.21-rc7 and the final > one, > > > so it > > > > > should be quite quick - bisection basically does a binary search, > so > > > doing > > > > > seven reboots should have you with the result. > > > > > > > > > > The fact that it already works in 2.6.21-git2 obviously means that > _I_ > > > end > > > > > up being less interested, but the -stable tree people would love > to > > > hear > > > > > what broke! > > > > > > > > Hi again Linus, > > > > my deep thanks for your excellent explication of git-bisect. > > > > But I unfortunately owe a 100Kbit flatrate, and so downloading some > 170 > > > MB git tree will need the time amount of one entire night (11.5 kb /s > if I > > > am lucky - no more). >
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
all these discussions are about Makefile and documentation changes as far as I see. I don't see the point why there's a need for such a big discussion here just about these changes. Uwe please resend your patch files and lets get this story done, if your work breaks something we can point you out to what is wrong. We have what's in the repository now and it won't change unless we put some time in it again. Uwe, if you have a problem with anyone here keep it for yourself just submit the latest patches and I'll have a look asap at it. There's no need to be unfriendly here. Markus On 4/30/07, Helge Hafting <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Mon, 30 Apr 2007 13:21:29 +0200 > Von: Helge Hafting <[EMAIL PROTECTED]> > An: Uwe Bugla <[EMAIL PROTECTED]> > CC: linux-kernel@vger.kernel.org > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > > >> Uwe Bugla wrote: >> >>> In this ten Emails you will yourself see the intellectual and technical >>> >> proof in how far Mr. Chehab is acting with nothing else but: >> >>> a. Lies >>> b. Unproven thesis >>> c. Stigmatizations >>> >>> and so on. >>> >>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER! >>> >>> >> Please note that there are ways to replace a bad maintainer. >> We still try to keep it polite. >> >> But note that you can't have someone "fired", no matter how bad they >> do their job. A bad maintainer is usually better than none - the bad >> maintainer might improve. Or at least get some simple stuff done. >> >> You therefore replace a bad maintainer by taking over the position. >> Contact whoever is above the maintainer (Linus or some other >> higher-level maintainer). You explain the problem, and you must also >> show that you have the time and knowledge to do a better job. >> > > Hi Helge, > A. I do neither have enough skills to take up a maintainers role > Then your only hope is to find someone else that is interested. > B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement. > That is at least my impression. > The aren't doing any less than you do. They don't provide a better maintainer, but neither do you. Linus and Andrew don't have that much more resources than you have. They have programming skills and lots of trust in the community. >> You can, for example, maintain the same subsystem in parallel. After a >> while, >> all interested parties sees that your tree works better and that >> communicating with you is easier. >> If you aren't prepared to do this - then you have to live with the current >> maintainer. There is no staff ready to replace maintainers after >> complaints, a volunteer doing a better job is always necessary. >> > > Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. > ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. > A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. > So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all! > Well then - create a patch to the MAINTAINERS file that removes this maintainer leaving the position open. Perhaps you can get that accepted despite the existing maintainer - *if* you can get most other developers for that subsystem to add signed-off lines. It will then be clear that the community agrees with you. However, if the bulk of them thinks the current maintainer is fine, then it stays that way. Satisfying everybody is unfortunately not always possible. You can always try submitting your own patches above this maintainer. > But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years. > > So there will be no "soft" or "polite" solution at all, but only a harsh and rude one: > "Kick out the Jams!" Dropping lazy or incompetent maintainers do happen occationally. But don't let frustration lead to angry emails - al
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST >AND DST_CA ARE NOT NEEDED AT ALL >[...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DST/BT878 module customization (.. was: Critical points about ...)
Hi, Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb as far as I see from that patch it cleans up a memory leak which would happen when the system tries to load the dst module if it's not available and it also prints a message that points the user should enable it in the kernel if needed. It also bundles the dst and dst_ca objects to one selectable option. So the idea remains the same. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. Markus On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Apr 30 2007 19:25, Uwe Bugla wrote: > > >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT > DST > >AND DST_CA ARE NOT NEEDED AT ALL > >[...] > > > How much on the Theo-meter are we yet? > it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Trent Piepho wrote: > The issue with dst is just a minor missing feature to fully support the dvb > helper module customization system. So nobody needs to worry about this > anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Manu, also for you please stop it, we know that Uwe writes abusive stuff but you don't have to go on with it. It's about the patch Trent wrote if you're not able to discuss it wait for others to comment it. I only saw subjective reasons why you are against it, but the actual patch doesn't cross your development there. Markus On 5/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! > 2. You did not even want to imply to resolve that issue by incarnating that "community and synergy principle" that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: "synchronization problems" Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, "You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS." I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! "Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches." In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: "bythe" or, even worse: "autodected" and "Recognise") It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx" caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug param
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/1/07, Simon Arlott <[EMAIL PROTECTED]> wrote: On 30/04/07 22:17, Markus Rechberger wrote: > Trent Piepho wrote another patch for it, it just completes Uwe's patch > in the end. > From my side I do not see any problem with that patch, if someone else > has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: On 01/05/07 00:05, Uwe Bugla wrote: > Piepho, you are a devil, and your links do not work at all! > Uwe On 01/05/07 00:40, Uwe Bugla wrote: > Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again > Just goto hell, you goddamn deeply asocial miserable sonofabitch!! > > Uwe > On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: >> it's enough, I told him that I'll look at it and try to get some other >> people involved if it really breaks something it should get stated >> out; and I'll refuse any further help if he starts to write any more >> abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. this patch was written by Trent, and it seems like he already had that idea earlier too. I really don't care if that patch goes in or not in the end, there's just no need to flame around for it. The only reason I see is that it's not needed to link it statically against the bt878 module and there isn't even much work to do. Uwe's Makefile patch worked as expected, but it wasn't clean/complete enough that was a reason to not include it. Now with Trent's patch I don't see that as a valid argument against it anymore. And the email from Manu claiming that it generates alot work (which is btw. 2 years old) doesn't seem to be valid either. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/2/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list , [EMAIL PROTECTED], Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB <[EMAIL PROTECTED]> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Criticalpoints about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: >>>> On 30/04/07 22:17, Markus Rechberger wrote: >>>>> From my side I do not see any problem with that patch, if someone else >>>>> has a problem with it please state out the reason. >>>> I have no problem with the patch since it has nothing to do with my DVB >>>> card but you're only encouraging Uwe to be abusive since it seems to >>>> help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... > > Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appre
Re: [PATCH] pcmcia/pccard deadlock fix
Andrew Morton wrote:
On Tue, 20 Feb 2007 16:08:11 +0100
20 Feb was a long time ago, sorry. I was hoping to feed the pcmcia patches
through Dominik but I think he's busy with exams or such. So I get to
pretend to be pcmcia maintainer.
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
following patch prevents a mutex/semaphore deadlock within the pcmcia
framework when ejecting devices multiple times using pccardctl eject.
For some more details see:
http://lkml.org/lkml/2007/2/19/58
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
--
Markus Rechberger
Operating System Research Center
AMD Saxony LLC & Co. KG
[pcmcia-pccard-deadlock-fix.diff text/plain (757B)]
index ac00424..c02bf0d 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt)
cs_dbg(skt, 1, "user eject request\n");
- mutex_lock(&skt->skt_mutex);
+ if (!mutex_trylock(&skt->skt_mutex))
+ return -EAGAIN;
do {
if (!(skt->state & SOCKET_PRESENT)) {
ret = -ENODEV;
index 18e111e..b9d3440 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct
device *dev,
if (!count)
return -EINVAL;
- mutex_lock(&p_dev->socket->skt_mutex);
+ if (!mutex_trylock(&p_dev->socket->skt_mutex))
+ return -EAGAIN;
+
p_dev->allow_func_id_match = 1;
mutex_unlock(&p_dev->socket->skt_mutex);
This is a pretty sad-looking solution. Does it not mean that sometimes
user-initiated actions will mysteriously fail?
The userspace application should return the appropriate error then. It
can really happen any time when someone tries to eject the pcmcia device
(any time as within 1 minute - never in a normal scenario)
Are you able to provide a more detailed description of why/how the deadlock
actually occurs so that perhaps a more robust fix can be implemented?
There's a description about it in following Email:
http://lkml.org/lkml/2007/2/19/58
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Hi Manu, > > But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the "politicians" here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus > Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > Manu, > > to me it looks like your attitude is not acceptable here, I sent > several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. You should stop to rely on the history, since such a flame needs at least 2 parties and back then you were also involved. There's nothing else to say about that. > If you don't change that attitude immediatelly I'd really wish to get > you banned of this community until you're open for discussions. > > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html > > there's a bugreport and you fully ignore it, and you blame it on the > "politicians" here, telling me that there are mails out there > somewhere shows that you're not interested in getting forward. > That bug report very well proves my point. Well it would be nice if you could answer the question in that mail then, I don't see any reason why you shouldn't answer it. It's just a guess, but it seems like that you had a problem with other developers at that part and it seems like it didn't get to an end (probably because both parties didn't agree with each other) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, VDR User <[EMAIL PROTECTED]> wrote: STOP FIGHTING ALL THE DAMN TIME! From an outsiders perspective there is a lot of unnecessary & childish behavior going on at the expense of good ideas and coding. It seems as though the Markus/Mauro team will go against anything Manu says simply because Manu is the one saying it. From what I've seen he is very knowledgeable and a good coder. From his technical knowledge he's as ok as many other developers are who have been involved for several years now. He tries to become the DVB Maintainer, from my side I wrote he first has to prove it for at least a half year that he supports the project and helps out people. Till now I haven't seen any response to the technical questions I had. And telling that the politicians here are so bad to everyone who'd like to help finding a solution for it is definitelly the wrong way either, so other people will not even be able to get an insight into the whole story. Manu is an asset and all the personal bickering and immature attitudes being displayed do not benefit any projects in any way. If you can't get past your personal problems then step down until you can learn to be unbiased and start treating these projects with some sanity/common sense. When you drive good people away, guess who loses? EVERYONE. Grow up and quit letting your personal feelings interfere in places it should not be in the first place!! Since all these issues have been there for more than one year now it either would be better that he leaves the project OR starts to seriously discuss the issues and how it would be best to solve them (and in a way where everyone agrees here) He just nacks the changes proposed by Uwe which got implemented by Trent and now Mauro wants to get it done somehow, either in a way explaining what he wants to do with it in future or changing these few lines NOW. I couldn't care less what will happen with his driver, the whole story gets blown up just because one party here doesn't understand that the other one doesn't know what he wants to do (and if he seriously will do something) I apologize for going off-topic but this is relevant to dvb dev as a whole. Things have degraded to a ridiculous state and it's time to knock it off. Enough is enough. The dvb projects should NOT have to suffer simply because people have lost the decency to act civil towards one another! Lastly, the opinions I'm sharing in this post are held by many others, although they hesitate to do the same publicly for certain reasons. I fully agree with that. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Mauro Carvalho Chehab wrote: > Enough. Let's stop arguing non technical issues. > > If either one of you have any technical argue against the Trent's > patches, please point where the fix is wrong. Otherwise, if you wish, > you may send an acked-by agreeing with the fix. > Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. You wouldn't be better at the moment, Mauro at least aknowlidges the work of others. I don't know what problems you have with Mauro I heard that there have been some mails between you and some other developers as well and the whole situation is just terrible. If you want to change the whole situation, think about what you can do for improving the whole situation even if it means that you have to work with people you don't like. (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership I wrote what I'd like to see from you, it would be a start if you could work on that first. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >> Mauro Carvalho Chehab wrote: >> > Enough. Let's stop arguing non technical issues. >> > >> > If either one of you have any technical argue against the Trent's >> > patches, please point where the fix is wrong. Otherwise, if you wish, >> > you may send an acked-by agreeing with the fix. >> > >> >> Why don't you stop this childish behaviour ? >> >> After explaining to you the reasons in the previous mail: >> being the author and maintainer of dst/dst_ca and maintainer of >> dvb-bt8xx, i NACK this change >> >> (1) You aren't DVB maintainer > > I've seen that too often already, now we could point to a mail someone > sent to Uwe regarding maintainership. FYI, I have never written to Uwe regarding any sort of maintainership. You seem to be quite up with an overdose of drugs I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from my side to Uwe, none of which has a topic whatsoever you say. Only the first mail was a private mail and that is CC'd to Johannes as well. Firstly you seem to play politics by getting Uwe to flame me, then when it backfired, you are trying to play tricks with the rest of the community as well, by spreading nonsense statements. I sent several comments to Uwe to stop flaming, Trent was in the CC sometimes I never wrote that he should flame on anyone. I can simply forward you all mails I sent to Uwe there's not one bad mail. My point is moreover to get that issue sorted out by either accepting his "proposal" or stating out why not to add it (and there must be a reason behind it, and no mail which is 2 years old, or explaining what the device is, again it got explained what's required from you) seems like your response is based on that misunderstood sentence, sorry for not beeing clear enough. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/4/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > I mean the mail from Helge Hafting (thread [linux-dvb] Critical > points about kernel 2.6.21 and pseudo-authorities) at the very first > beginning. > I am replying to this mail, just because someone's spreading lies all around. On the mentioned thread, what i wrote (and that was the only mail from my side): There is a saying: "He who lives by the sword, dies by the sword." And what issues are outstanding of these discussions? I went over it and it just shows up that there have been communication problems in 2005. We now have open issues with several device drivers and that's what we should focus at. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: Fix interrupt enable in i8042_ctr when enabling interrupt fails
When enabling interrupts fails, the interrupt enable bit remains set
in i8042_ctr. Later writes of i8042_ctr to the hardware could
accidentally retry enabling interrupts. Clear the bit on failure.
Signed-off-by: Markus Armbruster <[EMAIL PROTECTED]>
Acked-by: Steven Rostedt <[EMAIL PROTECTED]>
---
Some time ago Steven Rostedt and I went over this changeset:
commit de9ce703c6b807b1dfef5942df4f2fadd0fdb67a
Author: Dmitry Torokhov <[EMAIL PROTECTED]>
Date: Sun Sep 10 21:57:21 2006 -0400
Input: i8042 - get rid of polling timer
Remove polling timer that was used to detect keybord/mice hotplug and
register both IRQs right away instead of waiting for a driver to
attach to a port.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Steven pointed out to me that it changes behavior when enabling IRQ
fails.
The old code enabled IRQs this way:
i8042_ctr |= port->irqen;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
i8042_ctr &= ~port->irqen;
return -1;
}
i8042_ctr shadows the 8042's CTR. So, when enabling fails, the bit is
cleared in the shadow.
The new code does not clear the bit on the error path:
static int i8042_enable_kbd_port(void)
{
i8042_ctr &= ~I8042_CTR_KBDDIS;
i8042_ctr |= I8042_CTR_KBDINT;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
return -EIO;
}
return 0;
}
Same for i8042_enable_aux_port().
This leads to the question whether there are later writes of i8042_ctr
(possibly with other bits altered) to the hardware, which could
accidentally retry enabling interrupts.
I believe this possible, but unlikely (perhaps not so unlikely on
virtual machines). Scenarios involve enable succeeding the first
time, failing the second time, and succeeding the third time. I can
provide details, but the point I'd like to make is not that this is
broken (although it is, strictly speaking), but that it is not
obviously correct where it easily could be: just clear the interrupt
enable bits when writing them to the hardware failed, like the old
code did.
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index db9cca3..71a7e39 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -385,6 +385,7 @@ static int i8042_enable_kbd_port(void)
i8042_ctr |= I8042_CTR_KBDINT;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ i8042_ctr &= ~I8042_CTR_KBDINT;
printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
return -EIO;
}
@@ -402,6 +403,7 @@ static int i8042_enable_aux_port(void)
i8042_ctr |= I8042_CTR_AUXINT;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ i8042_ctr &= ~I8042_CTR_AUXINT;
printk(KERN_ERR "i8042.c: Failed to enable AUX port.\n");
return -EIO;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Markus, > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > Following patch adds the possibility to implement tuner drivers in > > > userspace. > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > give you my feedback about it. > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > means that, once a newer API is created, this should remain supported > > for all future versions. So, such APIs should be carefully analyzed and > > accepted by the community, before going to mainstream. > > > > The V4L and DVB API is stable at the moment because it's at a stage > which is sufficient for older devices but not sufficient for newer > devices anymore. > To support newer device it needs a change. > > > I don't see any technical reason why tuner drivers should be moved to > > userspace. Looking at xc3028 device, the driver is very simple and > > doesn't require any special treatment that it isn't possible to be done > > at kernel. There are already some implementations on kernelspace that > > works fine. > > > > As from my side to support the xceive driver properly it needs a > rewrite and a proper API description. Since it's not possible to > discuss any API changes I will work around at least for those devices > which I can support for. > > > On the other hand, a TV driver without a tuner is a broken driver. With > > parts of the driver being at userspace, this means to add undesired > > complexity at the drivers architecture, while not bringing any benefit. > > > > If you look at V4L history, the first drivers started at userspace, > > being migrated to kernelspace, where we have the proper scenario for > > managing those devices. > > > > Another aspect that should be analyzed is what is desired by the > > community: > > don't get me wrong but the existing community is rather small and > kicking off people who are interested in changing things. > I recently had a talk with someone and I've been told that I'm kicking > off people. > Guess why I kick off people? -> because they do not contribute in a > productive way which also means submitting patches. Optical useless > changes don't make any difference at the functionality in the end. And > my requirements are ignored constantly here. > > > kernelspace tuners or userspace tuners. Keeping support for > > both at long term doesn't seem reasonable. The Linux community should > > decide what is the better way. Currently, only you are pushing for > > userspace tuners, mainly due to non-technical reasons. > > read the project site and you will see the reasons. > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > Another advantage is that I have cygwin based code here which I can > easily reuse with all that work I'm not going to reinvent the wheel > even for newer devices which I work on. > > > Almost all the > > other developers are comfortable with kernelspace tuners. So, creating > > an userspace interface just to make you happy is not the way we should > > go. > > > > I'm afraid of giving the people which are against what I submitted the > responsibility over the project. Initially there was an RFC which > didn't get commented either (well there was one useless comment, I > tried to discuss it on IRC before with the same guy) after I > implemented exactly what I proposed there I got the first non > technical comments - also keep in mind that working on something costs > alot of time and talking about something unknown is rather cheap. > > > A final aspect is that having an userspace driver for tuner will mean > > that the kernel driver will depend on an userspace counterpart in order > > to work. This will allow a vendor with bad intentions to release a > > partially broken userspace driver, with limited capabilities, and a > > closed source driver for full support. This model is likely to occur, if > > you take a look at the past. For example: ATI and Nvidia closed source > > drivers, several soft modem drivers, some network drivers, ... > > > > Please go forward and discuss the UIO driver with Greg Kroah Hartmann > and the fuse driver with the other people. If companies want to > release binary drivers they can easily use the existing code put it > into an RPM or DEB package and Ubuntu will pick it up. > > > With all
Re: [linux-dvb] [PATCH] Userspace tuner
Hi, On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2007, Markus Rechberger wrote: > > > > We currently have an implementation that works, although > > it works by downloading several firmwares for several devices > > or even several countries. This is not what I want to have in > > future since it's not needed and it's also hard to manage for > > distributors. All those differences could be adjusted by > > software even without module parameter hacks. > > This argument doesn't hold water. The unpleasant point > for users and distributors isn't the "binary-only" > thing, it's the "no right to distribute" problem. > And that's the same for firmware blobs or binary-only > userspace blobs. > > IOW, if you can get the right to redistribute a binary-only > userspace blob which incudes the firmware inside, why > shouldn't you be able to get the right to redistribute > just the firmware? > In particular xceive based drivers provide a numerous set of features which cannot be implemented into the kernel because the API (both V4L and DVB) are limited. Since to me it seriously has the impression that the project especially the core of the project is closed to the outside world (just how someone stated it out recently "he licked the butts of others" to get his stuff accepted) > Or the other way round: Do you think your binary-only software > will be important enough so distributors will go through > all the trouble of trying to get a license to include it in > their distribution? If so, why wouldn't they do the same > for the plain firmware blobs for in-kernel drivers? I don't have any binary only software just as all the time before. I am also allowed to publish firmware for several drivers (not only the em28xx driver). Although as mentioned earlier already the current existing driver is not really manageable due the firmware mess and that driver will change completly and include templates for several other bridge drivers. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2007, Markus Rechberger wrote: > > Let's add the LKML to this. > > > > On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > > > I don't see any technical reason why tuner drivers should be moved to > > > > userspace. Looking at xc3028 device, the driver is very simple and > > > > doesn't require any special treatment that it isn't possible to be > done > > > > at kernel. There are already some implementations on kernelspace that > > > > works fine. > > > > > > As from my side to support the xceive driver properly it needs a > > > rewrite and a proper API description. Since it's not possible to > > > discuss any API changes > > Not possible? We're doing it all the time... > Then ask Mauro about the audio standard discussion which I had with him. > However, your ideas were rejected in this discussion, > and you can't seem to get over it. > As for future projects I see other people having the same problems if they want to join the project. If deeper requirements and/or ideas will come up some particular people will try to run their own game. If I'm doing something wrong technically then state it out show me the bugs that I can understand what I did wrong or what I am doing wrong. As for design changes if someone thinks he has to deny something he has to state out _why_ and not only some overall nontechnical statements which do not help anyone. > > > don't get me wrong but the existing community is rather small and > > > kicking off people who are interested in changing things. > > IMHO there is a lack of openness caused by people being burned > in past flamewars. This makes it a bit difficult to see through > what happens and why, and to participate. However, I think it > is completely wrong to say that the community is "kicking off people". > You identified it already the right way in one mail much earlier. It's a messup caused by many people and not only by one single person. And that's also how I see it. > > > I'm against how the project works out at the moment and how it worked > > > out in history. Exactly this way will kick off companies to be > > > interested in future like Avermedia. A driver can easily be written > > > within a few weeks and I've been struggling with it for 2 years(!!!) > > > now just for nothing finally telling me that some guys want to steal > > > my code and move it to kernelspace although it would raise more > > > complications with upcoming and current devices which have even more > > > requirements. > > Oh dear, there we go again... more flame bait... > > I reality, 95% of your driver code could have been merged > without problems, but you refused to take the small, objectionable > part out of the picture. > the driver itself still evolves, so the main point is in getting those incomplete APIs to support further requirements. Instead of acknowlidging and seriously discussing the solutions of others all that's beeing done now is to redo things hundred times and splitting development one side beeing more open (which is the userspace work) and the other part beeing more closed to a few people only (the inkernel work). It's not my task to convince myself to rewrite the base of something which I don't think that it would be valueable. The one who wants me that I spend days in changing my code should try to convince me to change my mind on that, unless he can provide patches which demonstrate that his changes are definitelly an advantage over what has been done from my side. I will for sure acknowlidge everything that will seriously improve the work which has been done. > (For those interested: > http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch > The patch changed the internal tuner API and required changes > to all tuner drivers.) > The main problem is moreover that the RFC didn't get discussed properly, afterwards people wondered what happened, even though the sources were also available all the time in a public repository. > Your all-or-nothing approach didn't work out. > well we got far enough that I end up to step away and preparing the sources to be able to get submitted beside linuxtv since I don't/didn't get any useful technical feedback there. Convince me that my work is welcome then I might start to submit smaller patches, I already spent days for exporting patches in history and it all end up nowhere but in unfriendly discussions - which also turned
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > It's only a step in development, I do not intend to keep the kernel > > stub in the end, but I do intend to keep and use the userspace drivers > > with i2c-dev in the long run, this requires a v4l/dvb library at the front > > of everything. > > Well, this was what adq and myself did with libdvbapi and mti, (much > before UIO was announced at LK.) It is not tied to I2C either. > I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. > But, according to your statements (with regards to i2c-dev) you can > handle only some I2C based devices, which is in fact a subset of a > subset. Also not to forget that hardly a few I2C devices are in fact > "truly" I2C compatible. In fact many variables to be considered. > The analogue tuner core is also only for i2c only devices which most devices rely on. > Also there is to consider a non technical aspect, whether vendors will > misuse this interface for binary only, undermining the efforts put in > for OSS drivers. > What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > Markus Rechberger wrote: > > On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > >>> It's only a step in development, I do not intend to keep the kernel > >>> stub in the end, but I do intend to keep and use the userspace drivers > >>> with i2c-dev in the long run, this requires a v4l/dvb library at the > front > >>> of everything. > >> Well, this was what adq and myself did with libdvbapi and mti, (much > >> before UIO was announced at LK.) It is not tied to I2C either. > >> > > > > I2C is the main communication path for it, although there are callback > > mechanisms available which add the possibility for different configuration > > paths. > > Sorry, i must say that what you said is wrong. > > The example implementation in libdvbapi/mti is I2C only with a STV0299 > on the TTPCI, if that was what you meant. > But if you need examples for every possible interface, then probably you > are out of luck. > I didn't comment the libdvbapi/mti driver. I'm quite confident that non I2C protocols can be handled by a callback function. In the end it's either a usb control command or pci mmio writes in the current usual cases and such calls could be handled behind a callback function which is implemented in the driver. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > >> Also there is to consider a non technical aspect, whether vendors will > >> misuse this interface for binary only, undermining the efforts put in > >> for OSS drivers. > >> > >> > > > > What holds companies for using the current available code putting it > > into an rpm or deb package and releasing such code now? > > > > The Avermedia example I pointed out to is a good example already. > > As from my side I won't release binary drivers. > > Although on the other side: > > * are drivers from vendors which work through several kernel versions > > that bad? > > * Why did someone duallicense videodev2 with BSD/GPL? > > > > I would appreciate if someone else on the list could also comment > > the reason that drivers should all be included in the linuxkernel just > > because forcing the companies to release binary drivers because > > of that. My opinion about that is if a company wants to go opensource > > they will do so, if not they will either not release a driver or release > > nothing. > > > > > > > I know for certain that adding a userland API tuner/demod interface to > the kernel, allowing non-caring opportunistic silicon or board vendors > to developer closed source proprietary drivers, will have a negative > effect on the community and we'd set back linuxtv 3-5 years. > > I know for certain that it would happen. Trust me. > > I've told you this countless times and you're not hearing me. > > Hauppauge have some leverage with Conexant and NXP to release public > datasheets. If they just have to release a demod.so (or similar) > loadable, they'll defer to the board vendors and we'll see the certain > board vendors 'locking other board vendors' out of their drivers. We'll > see embedded firmware, not shared between drivers. > > Except, it won't stop at demod.so. It will extend into unfixable bugs > for VendorB's board, because VendorA doesn't want to release a new > demod.so, and VendorB has no linux resources. What happens next? For > financial reasons - demod.so will begin to include checks to see if > specific PCI or USB devices are present in the system, and will fail to > work properly (if at all) when they're not being used with the preferred > products. > Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. What stops companies to intercept the ioctl calls and overriding some I2C commands? Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? What do you think about IOMMU? please answer those questions. thanks, Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > Markus Rechberger wrote: > > On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > >>>> Also there is to consider a non technical aspect, whether vendors will > >>>> misuse this interface for binary only, undermining the efforts put in > >>>> for OSS drivers. > >>>> > >>>> > >>>> > >>> What holds companies for using the current available code putting it > >>> into an rpm or deb package and releasing such code now? > >>> > >>> The Avermedia example I pointed out to is a good example already. > >>> As from my side I won't release binary drivers. > >>> Although on the other side: > >>> * are drivers from vendors which work through several kernel versions > >>> that bad? > >>> * Why did someone duallicense videodev2 with BSD/GPL? > >>> > >>> I would appreciate if someone else on the list could also comment > >>> the reason that drivers should all be included in the linuxkernel just > >>> because forcing the companies to release binary drivers because > >>> of that. My opinion about that is if a company wants to go opensource > >>> they will do so, if not they will either not release a driver or release > >>> nothing. > >>> > >>> > >>> > >> I know for certain that adding a userland API tuner/demod interface to > >> the kernel, allowing non-caring opportunistic silicon or board vendors > >> to developer closed source proprietary drivers, will have a negative > >> effect on the community and we'd set back linuxtv 3-5 years. > >> > >> I know for certain that it would happen. Trust me. > >> > >> I've told you this countless times and you're not hearing me. > >> > >> Hauppauge have some leverage with Conexant and NXP to release public > >> datasheets. If they just have to release a demod.so (or similar) > >> loadable, they'll defer to the board vendors and we'll see the certain > >> board vendors 'locking other board vendors' out of their drivers. We'll > >> see embedded firmware, not shared between drivers. > >> > >> Except, it won't stop at demod.so. It will extend into unfixable bugs > >> for VendorB's board, because VendorA doesn't want to release a new > >> demod.so, and VendorB has no linux resources. What happens next? For > >> financial reasons - demod.so will begin to include checks to see if > >> specific PCI or USB devices are present in the system, and will fail to > >> work properly (if at all) when they're not being used with the preferred > >> products. > >> > >> > > Steven, > > > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > > > > > Because the good people in this mailing list are keeping them honest. > Give any board or silicon company the ability to protect their IP, even > in the smallest way and they'll do it, and for no good technical reason. > It's a cut throat market and it's not clear that everyone understands > just how thin sales margins really are. > > That means Hauppauge potentially releasing a binary driver, because it's > much easier than seeking silicon vendor permission for a public diver. > The net result of that would mean I'd have to leave the company and find > another company that practices the one thing I truly care about > open source and open development groups. > well you could already release binary drivers if you would be concerned about it, so again all that seems to be no reason for me. What stops Hauppauge in implementing drivers another way? For example the USB drivers completly in userspace. > I'm keeping Hauppauge honest with their Linux involvement and I'm not > alone. Other devs in other linux subsystems in other companies are doing > the same thing. > For example the UIO thing, accessing MMIO through userspace, also accessing usb control messages from userspace. Because of that reason since it is already possible to provide binary drivers your reason is again not valid. The code which the userspace tuners are connected to is GPL so what. Beside that Hauppauge is not the only company out there although I also have contacts there at Hauppauge Europe. > Binary drivers (or binary components) leads Linux back in time. > > I can't believe your so passionat
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > Joerg Roedel wrote: > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > >>>>> What do you think about IOMMU? > >>>>> > >>>>> > >>>> Just because AMD or INTEL want to invent some whizzy new technology it > >>>> doesn't say anything about the TV card development and retail business. > >>>> Intel and AMD have teams of Linux engineers helping operating system > >>>> developers bring their ideas and technologies to new platforms. That's > a > >>>> million miles away from any of the TV board vendors I know of, who have > >>>> little or NO fulltime linux developers and consider the < 5% market > >>>> fringe at best. > >>>> > >>> it helps to virtualize devices and introduces newer features for that. > >>> Some interesting projects could be derrived out of that, there are > >>> quite a few interesting papers floating around how drivers could be > >>> handled in future. > >>> > >> IOMMU can be considered similar to the AGP GART, which is similar, > >> remapping the Addresses, as far as i understand. > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > fact, with current modern IOMMU hardware it will be possible to > > implement secure userspace device drivers that are even able to do DMA. > > This is not possible with the GART. > > > >> Though you get a physical to virtual translation, what about interrupts, > > > > Modern IOMMUs are able to remap interrupts. This will solve the problem > > with PCI interrupt sharing. > > What CPU's are we talking about ? > upcoming x86-64 processors from the AMD side. I'm not into what Intel is doing in that area at the moment. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Alan Cox <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 01:17:05AM +0200, Markus Rechberger wrote: > > what stops vendors of using the current existing code to achieve that > > goal. They could provide binary drivers with the existing API. > > If you feel lucky about the GPL > > > What stops companies to intercept the ioctl calls and overriding some > > I2C commands? > > The GPL - derivative work is the boundary not code linkage. Possibly a > userspace > tuner hack would probably fit this too. Especially if a specific vendor is > producing both bits together and trying to claim they are independant. > > > How about proprietary video formats, would you also place the decoding > > algorithms in kernel just to force companies to release their code > > for it? > > No, I would assume they'd provide a proprietary conversion library that > no nobody would use (just like their hw). We keep format conversion firmly > seperated from hardware I/O processing. > In general there are known formats available, the drawback is that every TV application deals with it in a non-unified way at the moment, meaning alot code duplication in userspace since there's no library available at the moment which does the videoconversion from one to another format. Such a library is beeing developed at the moment which gets plugged infront of accessing the devicenodes. Although in the long run I'm looking forward to reuse the userspace tuners with such a library infront of everything by using i2c-dev. This would also make it easy to reuse the sample code of several companies, without having to cut out several features of the drivers and to rewrite them to an inkernel format. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > On 9/14/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > > > > > If you care about LinuxTV you'll work with the core subsystem developers > > > to bring your em28xx tree inline. If you don't care then why are you > here? > > > > It doesn't really work out to work with those 3-5 "core" people who are > active > > there. > > It starts at the point where RFCs are submitted and not answered, > > discussions are avoided and finally some people start to complain. > > In case of pointing people to wrong or bad solutions, one "Maintainer" > > pointed out it would be like manipulating others work ... this exactly > > happened with the em28xx project. It's not only about the current > > implementation, as from my side I also take upcoming products into > > account and how long it would take to get something which isn't > > supported by the API fixed.. it's just something that is too hard and > > I don't want to debate about things where I know that the outcome > > is that I have to wait till someone of those 3-5 "core" people come up > > with an own idea. > > Maybe you still don't realize how tiresome it is to talk to you. > What you present as "linuxtv people block my contributions" is > IMHO "linuxtv people got fed up talking to you". Because when > people disagree with you, you keep rambling on and on instead > of just accepting it. See, working with an Open source community > requires that you don't piss everyone off, but instead find > ways to _motivate_ them to help you fix the problems which > prevent your code from being merged. When people are doing > software development _for fun_, then it should be a _pleasure_ > for them to work with you, and not a pain in the ass. > Johannes, people do contribute to the em28xx project. If noone keeps finding solutions for requirements I will of course go on to find my own way. Although upcoming and even the current requirements are not met by the existing API. It's worth nothing to merge what's available now since I'm not even ok with how several issues are solved with the driver itself at the moment. I'm going forward step by step with it now. there's also an active and even problem solving oriented ML available: http://mcentral.de/pipermail/em28xx/ Also if you look at the mercurial code you'll see several people contributing to that project. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Markus, > > > > > > > Maybe you still don't realize how tiresome it is to talk to you. > > > What you present as "linuxtv people block my contributions" is > > > IMHO "linuxtv people got fed up talking to you". Because when > > > people disagree with you, you keep rambling on and on instead > > > of just accepting it. See, working with an Open source community > > > requires that you don't piss everyone off, but instead find > > > ways to _motivate_ them to help you fix the problems which > > > prevent your code from being merged. When people are doing > > > software development _for fun_, then it should be a _pleasure_ > > > for them to work with you, and not a pain in the ass. > > > > > > > Johannes, > > > > people do contribute to the em28xx project. > > If noone keeps finding solutions for requirements I will of course > > go on to find my own way. > > Although upcoming and even the current requirements are not met > > by the existing API. > > It's worth nothing to merge what's available now since I'm not even > > ok with how several issues are solved with the driver itself at the > > moment. > > I'm going forward step by step with it now. > > > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Solutions for your requirements can be reachable via a kernelspace > solution: > > - The hybrid tuner support, that where your requirement, when all those > discussions started, were already added to the subsystem. So now, an > hybrid tuner can be accessed by both DVB and V4L devices; > It's far more complex as the thing which is implemented there. The only thing that has been implemented is that one moduleformat can be loaded by the v4l and by the dvb framework nothing else at the moment. I told you at the kernel summit about that and I think you knew about that before. Just to quote some text: "Right now, a separate instance of the driver is used for analog / digital tuning. In order to use a single instance, we will have to store a pointer to the dvb_frontend structure on the bridge level, but there are various other prerequisites that must be dealt with before we get to that point. We _will_ get there though, eventually." > - Audio standard selection is already possible via S_STD (it is already > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more > standards should be needed, but hey, we still have 34 bits available at > std mask. > Let me quote some text where you've been in CC and which didn't get far enough to get a solution implemented. (Michael Schimek) "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2 > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2 > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM > Group delay: See RecITU-R BT.470-6 p.21 Response "A" > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM > Group delay: See RecITU-R BT.470-6 p.21 Response "B" > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM We cannot add new standards for each of these files because only six bits are unassigned in the lower half of v4l2_std_id. It seems unecessary too, please correct me if I'm wrong. (Well the driver could define its own video standards for each of the firmwares and put them into the upper 32 bits of v4l2_std_id, which were set aside for this purpose. But adding standards to the API also has its advantages. Maybe it's time to reserve bits 40-55 for future expansion.) I suppose you choose firmwares with IF or baseband sound output depending on the design of the card?" > The point is: there's no technical need for userspace. This will just > add userless complexity. > > However, you insist with your selfish idea that every other solution, > except the one you're proposing are bogus. This is not the way Open > Source development works. You should listen to people. > I pointed out a few requirements which didn't get commented at all, and I explained why things where done in a particular way. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Alex Deucher <[EMAIL PROTECTED]> wrote: > On 9/14/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > On 9/14/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > Joerg Roedel wrote: > > > > On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote: > > > >>>>> What do you think about IOMMU? > > > >>>>> > > > >>>>> > > > >>>> Just because AMD or INTEL want to invent some whizzy new technology > it > > > >>>> doesn't say anything about the TV card development and retail > business. > > > >>>> Intel and AMD have teams of Linux engineers helping operating > system > > > >>>> developers bring their ideas and technologies to new platforms. > That's > > > a > > > >>>> million miles away from any of the TV board vendors I know of, who > have > > > >>>> little or NO fulltime linux developers and consider the < 5% market > > > >>>> fringe at best. > > > >>>> > > > >>> it helps to virtualize devices and introduces newer features for > that. > > > >>> Some interesting projects could be derrived out of that, there are > > > >>> quite a few interesting papers floating around how drivers could be > > > >>> handled in future. > > > >>> > > > >> IOMMU can be considered similar to the AGP GART, which is similar, > > > >> remapping the Addresses, as far as i understand. > > > > > > > > Common new IOMMUs have only very few in common with the AGP GART. In > > > > fact, with current modern IOMMU hardware it will be possible to > > > > implement secure userspace device drivers that are even able to do > DMA. > > > > This is not possible with the GART. > > > > > > > >> Though you get a physical to virtual translation, what about > interrupts, > > > > > > > > Modern IOMMUs are able to remap interrupts. This will solve the > problem > > > > with PCI interrupt sharing. > > > > > > What CPU's are we talking about ? > > > > > > > upcoming x86-64 processors from the AMD side. I'm not into what Intel > > is doing in that area at the moment. > > All AMD64 chips have an IOMMU. Only Intel's most recent chips do. > It's not available yet, you can read more about it in the following article: http://developer.amd.com/articlex.jsp?id=101 If you're interested in it I can put together some more information about it. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > > > people do contribute to the em28xx project. > ... > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Of course, people who own such a device and want to use > it with Linux have no choice but to work with you. > And you do a good job for your users, you support them > well and in return they contribute info and patches > to support new devices. > > But the thing is that at mcentral.de you're the man at the top, > and your users will hardly disagree with you on core > technical questions. (Well, admittedly I'm speculating > here as I don't read your em28xx list.) > they can. Put technical issues infront of everything also see the whole picture that userspace tv applications have to support all the codecs which are available. > On for drivers/media/ OTOH you are just one developer among others, > and some of them choose to disagree with you. Even worse, > IIRC there wasn't even _a single_ other developer willing > to ACK your offending patch. > there was not a single developer of the old crufted developers who didn't bring the project forward during the last 2 years. yes you're right. > Now, doesn't _that_ get you thinking? > it gets me thinking. Some core developers who I met during the last few weeks (kernel summit, suse conference in czech) told me to go on with it actually because the final plan isn't that bad.. I don't expect anyone of the old crufted v4l/dvb (well many of them already left the party) will join the game... (I'll leave that open here) spend some time read the whole history of this thread and it will show up what this all is targeting at. I'll answer your questions with technical reasons why I'm doing all that stuff that way if you'll just ask. Someone told me during the last 2 weeks "but v4l2 was about to solve all those problems" it didn't. (point) and I think I explained good enough why all that crap still goes on as it is. Beside that I'm just curious how much did you contribute during the last 2 years to the lkml/linux kernel, and how much do you want to contribute in future? (also from my side talk is cheap (even for me) but getting something done costs quite some time and feedback from other people) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007, Markus Rechberger wrote: > > > > people do contribute to the em28xx project. > ... > > there's also an active and even problem solving oriented ML available: > > http://mcentral.de/pipermail/em28xx/ > > > > Also if you look at the mercurial code you'll see several people > > contributing to that project. > > Of course, people who own such a device and want to use > it with Linux have no choice but to work with you. > And you do a good job for your users, you support them > well and in return they contribute info and patches > to support new devices. > > But the thing is that at mcentral.de you're the man at the top, why is it mcentral.de at the moment? I started several discussions about the whole topic. The thing which is in v4l-dvb on linuxtv does not satisfy any requirements, also further additions will be hard to achieve with it. > and your users will hardly disagree with you on core > technical questions. (Well, admittedly I'm speculating > here as I don't read your em28xx list.) > they can disagree, I even pointed out to design flaws lately when some users posted bugreports. > On for drivers/media/ OTOH you are just one developer among others, > and some of them choose to disagree with you. Even worse, > IIRC there wasn't even _a single_ other developer willing > to ACK your offending patch. > the current patch isn't offending anymore, see it as a chance I'm giving you the chance to acknowlidge what has been done now from my side. The main discussion in this thread was about drivers in userspace are bad because the API will allow binary drivers. The guy who works for Hauppauge (again I also have good contacts at Hauppauge Europe) writes it's bad - for no technical reason. If someone points out that it is bad (after reading the whole thread) why don't we put X.org, bash, well everything into the kernel? GPL is the saviour seems to be the saviour for some people in this world, but in the end it's still if people want to go that way. Much work has been done by other people before, my work is also just an additional contribution and I (again) don't intend to release binary drivers. (also keep in mind that ubuntu takes everything which makes things work - this matters to the enduser) Hey I can also write I can help you to get things right with some other people, and I can financially support people by giving away hardware and even specs for free in some cases. Who is able to do that from the old crufted v4l/dvb guys? Manu throws his drivers over the wall to the OSS community, although I don't mind. Mauro is copying the logic of my code and writes I told him I'm ok with taking my code without just adding a single line of how his driver got developed. (I still wonder why he skipped some significant parts of the driver .. because he used the existing one as logic template) http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c (not looking at the specific changeset but he copied the firmware loading instructions without taking care about the copyright?) > Now, doesn't _that_ get you thinking? > oh yes. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > The main discussion in this thread was about drivers in userspace > > are bad because the API will allow binary drivers. > > No. The focus is that userspace API is not needed at all, and the > community believe that this is a regression from all efforts that are > being done by the community to have good quality OSS software. > please have a look at: http://mcentral.de/wiki/index.php/Bugtracker > > The guy > > who works for Hauppauge (again I also have good contacts > > at Hauppauge Europe) writes it's bad - for no technical reason. > > Please stop with personal attacks. > This is no personal attack. > > I (again) don't intend to > > release binary drivers. (also keep in mind that ubuntu takes > > everything which makes things work - this matters to the enduser) > > Markus, you are thinking that all the community are fool? You're using the word "community" in a quite abstract way here. Please document how the linuxtv community behaves behind the lines, and I would even like that those people who discussed several things would start to write about their other personal issues with that project which I'm not part of. > You used to > state on your website that your intention were to release binary-only > xc5000 drivers. people talk alot, in the end only the result counts. So if you've seen any binary driver from my side point out to it. To be honest I think if I would have gone the same way as Avermedia from the beginning on to release binary drivers it would have saved months of development and the main distros could already have _full_ support for all the features. The driver as it is now is not perfect either it requires quite some more work to get all features work flawlessly around the globe for all the users. > So, please stop with childish and assume what you've said. > > > Mauro is copying the logic of my code and writes I told him I'm ok with > > taking my code without just adding a single line of how his driver > > got developed. (I still wonder why he skipped some significant parts > > of the driver .. because he used the existing one as logic template) > > > > > http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c > > The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers > is very simple: > > a) load the proper firmware; > b) send one 32 bits command to select frequency + the frequency divider. > well people see if they compare the code what you took from the existing driver. > All the rest is the common logic of a tuner driver. > > If you take a look at my driver, you will see that the implementation is > different, providing also those functionalities: > > - provides a sync during frequency setting, needed by tm6000; > - has the logic to retrieve signal status; > - part of the firmware need to be reload every time you change a freq > (tm6000 driver needs it); > - supports just the firmwares I've identified as being used by tm6000 > driver; > > The only thing I used is your usbreplay.pl, as properly stated at > README.first (properly pointing to your site). > > Again, please stop with personal attacks. This leads to nowhere. > If you look at my current implementation and even the implementation which I had a year ago many problems are solved there. I don't mind if you don't want to use the userspace tuner API, it's not a replacement for the inkernel version, it makes it just easy to implement it. The current and upcoming em28xx devices will use it, just to avoid that I have to redo all the work hundret times for no real reason. > > >From my side, I've nacked your userspace tuner. > > However, I keep open to accept your kernelspace em28xx/xc3028 drivers, > providing that they fits at the current V4L/DVB core. > I don't even want to use that existing driver in future (as I wrote earlier already). The newer module will be a dropin userspace replacement for what's available. I got around 70 devices work with it at the moment, although I don't even want to reinvent the wheel so I'll take what I've received from some companies. That way all I have to do is to use the provided API of those silicon sample drivers. > Changes at common APIs, and especially at Kernel to userspace API should > be discussed with the community. If you accept this fact, you may also > propose improvements at the APIs. > That for I wrote the RFCs which didn't get discussed properly and where 2 people of that "community" told me to use something which won't work out at all. And hey, why didn't those guys do what they told me to
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/15/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Sat, Sep 15, 2007, Markus Rechberger wrote: > > > > it gets me thinking. Some core developers who I met during > > the last few weeks (kernel summit, suse conference in czech) > > told me to go on with it actually because the final plan isn't that > > bad.. > > I was referring to your code you posted for merging on linux-dvb, > and which got rejected. Anyway, it's easy to agree with you if one > has just heard _your_ version -- the purpose of this thread is to > give people an alternate version of the story to complement > yours, which would allow the people you talked to to think it over > and change their mind. See if you can get of those people you > talked to to post here to support you. > Everyone knows that there are some issues even some internal ones which I'm not part of. Not sure if you met some other kernel developers recently, all you can hear is "those crazy media guys" (which just includes everyone who works with media related drivers) > > Beside that I'm just curious how much did you contribute > > during the last 2 years to the lkml/linux kernel, and how much > > do you want to contribute in future? (also from my side > > talk is cheap (even for me) but getting something done costs > > quite some time and feedback from other people) > > IOW you say if I don't write code I should shut up? > Is that also what you tell users on your em28xx list > when they dare to disagree with you? > > Nice... > This is a free world you can write whatever you want, but if you want me to change my code you need to convince me that I should acknowlidge your ideas. And by not acknowlidging my requirements don't expect that I will go back to the start and try to reinvent the wheel. After almost 2 years I'm quite into those things and I know what I want for my project and what I'll try to achieve with what I'm doing. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Everyone knows that there are some issues even some internal > > ones which I'm not part of. > > With respect to your kernel-userspace API for xc3028, you made something > that seemed to be a dream: there's a consensus: not a single developer > believed that this is the better way; nobody seems that this is the > better approach. > Not a single developer out of 3-5 people? Seems fine with me, because people didn't agree with anything else before either and tried to point me to wrong solutions. http://threebit.net/mail-archive/video4linux/msg07548.html > So, or you are the only media developer with good sense in the face of > the Earth, or you're incapable of understand the obvious: you're wrong > with this approach. IMO, the answer is quite obvious. > that for you don't have to use it. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages I'm off for the weekend now so have a nice one :-) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/15/07, Bernard Jungen <[EMAIL PROTECTED]> wrote: > On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote: > > With respect to your kernel-userspace API for xc3028, you made something > > that seemed to be a dream: there's a consensus: not a single developer > > believed that this is the better way; nobody seems that this is the > > better approach. > > > > So, or you are the only media developer with good sense in the face of > > the Earth, or you're incapable of understand the obvious: you're wrong > > with this approach. IMO, the answer is quite obvious. > > Yes, as a newbie observer on the v4l list, the answer is obvious to me, > at last, and the reason is not entirely technical. I can't read so many > bogus arguments on so few lines without reacting. > > Rephrasing Mauro: > > "Not a single developer out of a few SEEMS to believe that it is the BETTER > approach, so since the FEW represent ALL media developers in the world, and > since there is only ONE RIGHT way to do things, and since the GROUP is > always RIGHT and always knows better than the individual, then YOU're WRONG > and I'm right. Conform to the group and do as the group says, whatever the > consequences!" > > Geeks are decidedly as prone as others to blindly accept travelling on the > slippery road of herd mentality and "obvious" conclusions based on > appearances. Is this OPEN source development or a dictatorship or what? > > So in the end Mauro will be right. And Markus will continue to develop and > defend his stuff as HE sees fit. He knows his own work better than anyone > else. It will be HIS way or nothing with his own stuff, it's his inalienable > right. > > And don't be naive, if there's no solution more viable than Markus' one, > then the latter will eventually be widely adopted somehow, sometime, > whatever the amount of grumbling from the establishment. No > dictatorship/forced consensus can decide future's direction, nor improve > its already low own viability. > I see it exactly the same way. Well I will continue to provide an alternative stack with alternative drivers. The peer review shows that it doesn't work too well without people participating fixing problems, the initial drivers were inkernel based and due some updates in modules which are used by the em28xx some devices which previously worked don't work anymore in the kernel. As for the em28xx the driver will use userspace i2c based tuners, decoders and demodulators. The userspace modules will use unaltered sample drivers which are provided by several companies, which also saves alot time in future for that project. Those drivers will also officially be provided and recommended by the manufacturing company of those devices, including the proper firmware. Personally I won't spend any time on reinventing the wheel and fixing drivers which get broken by not taking care of it. Beside that people are welcome to contribute without having to fear a political overhead of discussing requirements and other issues when changing the corresponding alternative core code. The project and how it will/should go on is documented at mcentral.de. I also see that as a good way for the community, that way the linuxtv guys have to prove that they can be open to other people without adding too much noise and overhead otherwise people will contribute to the alternative project as some already do. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Floating point computations in kernel modules
Hi, On 9/17/07, Ram <[EMAIL PROTECTED]> wrote: > Hi, > >I am trying to write a driver which uses double, float. I am using > an arm11 with gcc 3.4.4 > >When i try to compile my modules (with float variables) i get the error > >WARNING: "__extendsfdf2" undefined! >WARNING: "__mulsf3"undefined! >WARNING: "__fixsfsi"undefined! >WARNING: "__floatsisf"undefined! > >Can we use float, double in kernel modules?. > in general you shouldn't use floating point in the kernel since there's no portable way which will work among different architectures. > Obviously it is a linking error, I am using soft-float. I tried with > -msoft-float but got the same result. > > I suspect that its a toolchain issue. However i am able to compile > my applications > with float, double variables. > > > Please do advice. > if you need a solution inkernel best would be to try to get around by converting your algorithm to integer. although you might have a look at: http://www.fi.muni.cz/~xslaby/unpr.html http://www.mail-archive.com/linuxppc-embedded%40ozlabs.org/msg01291.html Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
