Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On 4/28/07, Mikulas Patocka <[EMAIL PROTECTED]> wrote: I most wonder, why vim fsyncs its swapfile regularly (blocking typing during that) and doesn't fsync the resulting file on :w :-/ Never seen this. Why would fsync block typing unless vim was doing disk IO for every keystroke? Lee - 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: 3c905B - Transmit error, Tx status register 82
On 3/1/07, WHITE, JOE (ASI-AIT) <[EMAIL PROTECTED]> wrote: Mar 1 09:44:04 thor kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt Um... did you check Documentation/networking/vortex.txt? 261 Transmit error, Tx status register 82 262 - 263 264 This is a common error which is almost always caused by another host on 265 the same network being in full-duplex mode, while this host is in 266 half-duplex mode. You need to find that other host and make it run in 267 half-duplex mode or fix this host to run in full-duplex mode. 268 269 As a last resort, you can force the 3c59x driver into full-duplex mode 270 with 271 272 options 3c59x full_duplex=1 273 274 but this has to be viewed as a workaround for broken network gear and 275 should only really be used for equipment which cannot autonegotiate. 276 Lee - 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: 3c905B - Transmit error, Tx status register 82
On 3/1/07, WHITE, JOE (ASI-AIT) <[EMAIL PROTECTED]> wrote: Lee, Thanks for the reply. We have tried moving my network connection to a new switch, replaced the cables, but still getting that error. What do I do with that command options 3c59x full_duplex=1, where do I put it? Bare with me as I am a newbie. Easiest way to test is to shut down all networking, "rmmod 3c59x", then "modprobe 3c59x full_duplex=1". If that solves the problem you need to figure out where your distro stores kernel module options and add it there. They all do it differently (for no good reason). Lee - 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: userspace pagecache management tool
On 3/3/07, Andrew Morton <[EMAIL PROTECTED]> wrote: The tool uses an LD_PRELOAD hack to intercept glibc's read(), pread(), write(), pwrite(), close() and dup2() functions. pagecache control is done via posix_fadvise() and sync_file_range(). How could this have any effect on the updatedb problem? updatedb does not read() anything, it just open()s and stat()s every file on the disk. Lee - 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: Question: work_queue or kthreads
On 3/3/07, Mockern <[EMAIL PROTECTED]> wrote: hi, I need to use something like the work_queue to separate my ISR and long time sending data function in my driver. I noticed, that after using work_queue my driver became slow than it was before. Should I use kthreads to make it faster or something else? I can't use tasklet since tasklet can't sleep. Please post a link to your driver source code. Lee - 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: userspace pagecache management tool
On 3/3/07, Andrew Morton <[EMAIL PROTECTED]> wrote: But yes, updatedb's pagecache usage will be mainly metadata, and this tool doesn't address metadata pagecache, although it could do so. With no kernel changes? How? I can't find an equivalent API to posix_fadvise() for metadata. Lee - 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: [IPW3945] Can't load microcode
On 3/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote: ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0d ipw3945: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt :05:00.0[A] -> GSI 18 (level, low) -> IRQ 22 PCI: Setting latency timer of device :05:00.0 to 64 ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of :05:00.0 failed with error -2 Error -2 is "No such file or directory". Maybe it expects the firmware to be somewhere other than /lib/firmware or your driver and firmware versions don't match. Try adding some debug printk()s around the request_firmware() call in the driver. If you're using out of tree drivers the error should be reported to Intel rather than this list. Lee - 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] RSDL completely fair starvation free interactive cpu scheduler
On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> wrote: On Monday 05 March 2007, Nicolas Mailhot wrote: >This looks like -mm stuff if you want it in 2.6.22 This needs to get to 2.6.21, it really is that big an improvement. You can probably speed things up by regression testing against a wide range of non-desktop workloads and posting your numbers... Lee - 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: [RFC] BadRAM still not ready for inclusion ? (was: Re: Free Linux Driver Development!)
On 3/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It seems, that BadRAM is not being maintained very actively and the original author doesn`t seem to have the time pushing it into mainline, but i know it's actively being used by more then just a handful of people. Unfortunately there is no mailinglist to approve this and some "central point of communication" besides Rick van Rein doesn't seem to exist. There is a fork named BadMEM at http://sourceforge.net/projects/badmem, Memtest86 also supporting BadRAM and i have seen LOTs of discussion about BadRAM on the net. Most of that discussion was due to problems getting it run with Kernel XYZ. Basically, this feature is a matter of adding/modifying 200 lines of code, so iŽm even more wondering, why it exists for more than 7 years and nothing happening here. Because most kernel developers don't have time to scour the net for random kernel patches and pull them. If you have a useful patch you want merged it's up to you to push it. What's so hard about submitting a 200 line patch to LKML? Lee - 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: CONFIG_SYSFS_DEPRECATED and similar issues
On 3/6/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: The other issue is to avoid "trap door" changes, which occur when a kernel change requires new user tools, and the user tools will not run with older kernels. CONFIG_SYSFS_DEPRECATED is on by default. So this upgrading the kernel does not require userspace changes, unless the user changes the config, which always has the potential to break userspace. Users can break their systems by disabling CONFIG_SYSVIPC and CONFIG_SYSCTL too... Lee - 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: Problem: how to make kernel thread more faster?
On 3/6/07, Mockern <[EMAIL PROTECTED]> wrote: hi, Is there a way how to make kernel thread more faster? I put some of my code to the kthread, but I noticed that kthread sends data more slow than original driver without kthread. Please post a link to your driver source code. Lee - 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: pxa.c cat problem
On 3/7/07, Mockern <[EMAIL PROTECTED]> wrote: Hi, I have two PXA Linux boards, I connected them and tried cat myfile > /dev/ttyS0 on one board and cat < /dev/ttyS0 on another. But I can't see nothing. What is wrong with my pxa.c driver? Impossible to tell without seeing the driver source which you seem to be unwilling to post. Lee - 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: [2.6.22 patch] the scheduled removal of OBSOLETE_OSS options
On 3/7/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: Real problem is that we can expect several "sound does not work anymore" because people doing "make oldconfig" will get no warning at all about the removed options. Remember people complaining about keyboard not working ? Perhaps the real problem is more Kconfig than OSS, but it would be fine if we found a solution to enumerate the list of options which have been removed when they do their make oldconfig. I doubt there are that many users of the old OSS drivers. Even proprietary apps like Flash and Skype require ALSA these days. Lee - 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: Sleeping thread not receive signal until it wakes up
On 3/7/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: Interruptible_sleep_on is interruptible, but for your task to actually be awakened and your alarm handler to get some CPU, it needs to be scheduled. If the BKL (big kernel lock) is held, it won't be scheduled until it is released. You can schedule while holding the BKL and it will be dropped and reacquired. Lee - 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: 2.6.20.3-rt8 - DMA suffers excessive delay periodically
On 3/27/07, John <[EMAIL PROTECTED]> wrote: I'm runnning 2.6.20.3 patched with -rt8 (and glibc 2.3.6). http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8 I've written a program to highlight a phenomenon I don't understand. This system includes a PCI board that provides data at ~38 Mbit/s. I request data in lumps of 1316 bytes. In other words, a new request should complete every 277 µs. However, if I time stamp each packet as soon as I receive it, I notice that almost exactly every 2 seconds, the packet is received 30-100 microseconds late. Sounds like periodic SMM traps. There's not much you can do about them other than to avoid such hardware if you have tight RT constraints. The RTAI people have some code to disable SMM but it does not work on all chipsets and may render some of your hardware inoperable. Is this a laptop? They are plagued with SMM problems... Lee - 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: oracle sqlplus loop on 2.6.20
On 3/28/07, Marco Berizzi <[EMAIL PROTECTED]> wrote: Hello everybody. I'm running oracle 10.2.0.1 on Slackware Linux 10.2 After 50 days uptime, sqlplus was looping forever. I have killed all oracle processes and cleared all semaphore and shared memory segment with ipcrm. I have also unmounted & remounted the file system where the oracle binaries and library resides, but no luck. I have to do a shutdown. This is the output from 'strace sqlplus'. Any hint? Why do you think it's a kernel issue? Sounds like an Oracle bug to me... Lee - 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: 2.6.20.3-rt8 - DMA suffers excessive delay periodically
On 3/28/07, John <[EMAIL PROTECTED]> wrote: Would someone know how to disable SMM in this BIOS? There's no generic way. Try disabling USB keyboard emulation and any unused peripherals. Also google "RTAI disable SMM". > Is this a laptop? They are plagued with SMM problems... No it is an "indutrial" motherboard. Although I don't know what makes it "industrial". One would really hope that such a device would be designed for machine control and similar RT apps and thus free of SMM... Lee - 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: fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function
On 3/28/07, Toralf Förster <[EMAIL PROTECTED]> wrote: I compiled current git source 2.6.21-rc5-g28defbe and got this warning: ... fs/block_dev.c: In function `bd_claim_by_kobject': fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function ... Most of these warnings are really GCC bugs. Please examine the code in question. Lee - 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: 2.6.20.3-rt8 - DMA suffers excessive delay periodically
On 3/29/07, Kevin Perros <[EMAIL PROTECTED]> wrote: > No it is an "indutrial" motherboard. > Although I don't know what makes it "industrial". > > Regards. > > Is this related to SMM? > > As far as I can tell, the BIOS is Phoenix AwardBIOS v6.00PG. > > Would someone know how to disable SMM in this BIOS? Usually you cannot disable SMM via the BIOS. You have to write chipset specific Kernel code for that. The problem could also be something other than SMM, like DMA starvation by a video or disk controller. Try disabling all hard drive controllers and booting from a CD or USB stick. Also, try tweaking the expire_centisecs and writeback_centisecs values in /proc/sys/vm and see if it changes the period of the glitches. Lee - 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] queued spinlocks (i386)
On 3/29/07, Davide Libenzi wrote: On Thu, 29 Mar 2007, Oleg Nesterov wrote: > On 03/28, Nick Piggin wrote: > > > > Well with my queued spinlocks, all that lockbreak stuff can just come out > > of the spin_lock, break_lock out of the spinlock structure, and > > need_lockbreak just becomes (lock->qhead - lock->qtail > 1). > > Q: queued spinlocks are not CONFIG_PREEMPT friendly, Why? Is CONFIG_PREEMPT friendly to anyone? :) Until someone fixes all the places in the kernel where scheduling can be held off for tens of milliseconds, CONFIG_PREEMPT will be an absolute requirement for many applications like audio and gaming. Many of these were fixed a while back during early -rt development but at some point the process stalled as the remaining cases were too hard to fix... Lee - 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: strange high system cpu usage.
On 3/29/07, Elliott Johnson <[EMAIL PROTECTED]> wrote: Hello, I've been upgrading a few machines here at work and noticed some problems with high system cpu usage on one machine. In trying to debug the problem I've come across a few confusing stats that I was hoping could be cleared up by someone on this list. What problem are you trying to solve? IOW, how do you know it's not just an artifact of diferent load average calculation between 2.4 and 2.6? Are you actually seeing reduced throughput/performance? Or are you just looking at load average? Lee - 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: 2.6.21-rc4-mm1 and rc5-mm2 - problem with cpuidle routine
On 3/29/07, Ed Sweetman <[EMAIL PROTECTED]> wrote: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 PCI: Setting latency timer of device :01:00.0 to 64 NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 **WARNING** I2C adapter driver [NVIDIA i2c adapter ] forgot to specify physical Please try to reproduce with an untainted kernel. Lee - 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: strange high system cpu usage.
On 3/29/07, Elliott Johnson <[EMAIL PROTECTED]> wrote: >What problem are you trying to solve? IOW, how do you know it's not >just an artifact of diferent load average calculation between 2.4 and >2.6? > >Are you actually seeing reduced throughput/performance? Or are you >just looking at load average? > >Lee Well the problem is apparent, we are having abnormally high cpu usage. It's about a 20-40% performance hit. Please post a kernel profile for the problematic workload with the "good" and "bad" kernels (search the list archive for Andrew Morton's instructions on doing it with oprofile, email me privately if you can't find it). The vmstat man page has little information on this statistic and there seems to be varying explanations on the web. I was hoping for a decisive explanation (or link) and possibly advice in toggling this value (or reasons not to). The meaning of these numbers can change drastically from one minor release to the next, and the docs often lag behind the code. I would not focus on tweaking VM knobs, but on describing the problem in enough detail to fix the kernel - it's a bug if the same workload regresses significantly from one release to another. Lee - 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] queued spinlocks (i386)
On 3/29/07, Nick Piggin <[EMAIL PROTECTED]> wrote: On Thu, Mar 29, 2007 at 10:06:41PM -0400, Lee Revell wrote: > Until someone fixes all the places in the kernel where scheduling can > be held off for tens of milliseconds, CONFIG_PREEMPT will be an > absolute requirement for many applications like audio and gaming. There's nothing wrong with CONFIG_PREEMPT for those users. We have a few other performance concessions activated with CONFIG_PREEMPT on. I think a usual upper of a few miliseconds (especially for SMP) is reasonable for a non preempt kernel. This is within reach - the only major offender left is rt_secret_rebuild (and possibly other areas of the route cache handling). Eric Dumazet had some suggestions to fix it, but the details are beyond my area of expertise. Lee - 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: [Quick question] serial core issue
On 3/29/07, Aubrey Li <[EMAIL PROTECTED]> wrote: When register serial driver as a console, the driver function my_remove() my_shutdown() seems be never called. So the driver can't reclaim resource when the command "reboot" is issued. Is it intended? Please post your code for review and someone can probably help. Lee - 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: Student Project Ideas
On 3/29/07, Russ Meyerriecks <[EMAIL PROTECTED]> wrote: Hi all, I've been hacking on the Linux kernel all semester for my OS: Internals class. We are given full autonomy in picking our final programming project and I would love for mine to be /useful/ for the Linux kernel and not just a theoretical exorcise. If anybody has any bug fixes or features maybe they never got around to, and would be suitable for this situation, I would love to hear about them. You could try to get scheduling latency down into the 1-2ms range without resorting to kernel preemption. rt_secret_rebuild is the main problem - it does not take any spinlocks, and is not a hot path, but runs in softirq context and is thus non-preemptible. Even if you don't succeed you'll acquire a deep knowledge of the networking code. Lee - 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: 2.6.20.4: NETDEV WATCHDOG and lockups
On 4/3/07, Christian Kujau <[EMAIL PROTECTED]> wrote: On Tue, 3 Apr 2007, Robert Hancock wrote: > Although it's not as bad with servers, many machines are designed to run only > Windows (which normally always uses ACPI) and simply aren't tested well or at > all with ACPI disabled so you can run into a lot of problems which are just > bugs in the BIOS, etc. I only thought it was the other way around: less (active, used) code - less bug (caused by strange ACPI implementations). But I can see your point. We have a bunch of servers here where Linux will only see one core per processor unless ACPI is enabled. Lee - 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: High Resolution Timer DOS
On 4/28/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: Well, it is not really a DoS. The rescheduling of the process is limited by the scheduler and the available CPU time (depending on the number of runnable tasks in the system). Shouldn't an unprivileged process be rate limited somehow to avoid flooding the machine with interrupts? We restrict nonroot users from setting the RTC interrupt rate higher than 64Hz for a similar reason (granted, this limit dates back to the 486 days and should probably be increased to 1024 Hz). Root and SCHED_FIFO tasks could be exempt from rate limiting, to avoid the need to introduce a new rlimit which would take years for userspace to catch up to. Lee - 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: 24 lost ticks with 2.6.20.10 kernel
On 5/1/07, Kok, Auke <[EMAIL PROTECTED]> wrote: Michel Lespinasse wrote: > (I've added the E1000 maintainers to the thread as I found the issue > seems to go away after I compile out that driver. For reference, I was > trying to figure out why I lose exactly 24 ticks about every two > seconds, as shown with report_lost_ticks. This is with a DQ965GF > motherboard with onboard E1000). that's perfectly likely. The main issue is that we read the hardware stats every two seconds and that can consume quite some time. It's strange that you are losing that many ticks IMHO, but losing one or two might very well be. Why do you have to disable all interrupts? Shouldn't it be sufficient to disable interrupts on the e1000 only? Lee - 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/RFC] doc: about email clients for Linux kernel patches
On 9/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Tue, 2007-09-11 at 10:16 -0700, Randy Dunlap wrote: > > > +~~ > > +Evolutions (GUI) > > I take it you mean: Evolution > > > +Some people seem to use this successfully for patches. > > + > > +What config options are needed? > > When composing mail select: Preformat > from Format->Heading->Preformatted (Ctrl-7) > or the toolbar > > Then use: > Insert->Text File... (Alt-n x) > > to insert the patch. You can also diff -Nru old.c new.c | xclip, select Preformat, then paste with the middle button. Lee - 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: getting FUSD compiled with current kernels
On 9/29/07, Florian Schmidt <[EMAIL PROTECTED]> wrote: > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal > is to create a virtual ALSA soundcard [which would multiplex access to a real > non hw-mixing capable soundcard] to finally end the dmix software mixing woes > linux users have to endure for the last years :) What problems with ALSA's userspace mixing are you trying to solve? Lee - 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/
