Running recent kernels the insertion of a MemoryStick into the card reader of a Sony Vaio VGNSZ3XWP is detected but the card does not seem to be probed for partitions and hence is not made available to userspace. Here is the message upon card insertion: tifm_7xx1: ms card detected in socket 0 lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML E...

Well, the "docs" I was using was a half-finished, broken version of the driver released by NVidia which had to be significantly revised, and the public ADMA spec which the hardware was vaguely based on and which a few things could be inferred from. If NVidia had just released the docs it would have been much easier, I would have gladly written it from scratch. There are still things in the driver that could likely be improved if we had the actual hardware documents, registers that we don't k...

Is it just me, or should some of these device quirk entries that keep being added be made unconditional? Adding entries for every single device that shows up with these problems seems like not a very scalable approach. These devices obviously work in Windows, can't we just emulate its behavior here? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ -

I *really* wouldn't want to expose kernel addresses to user space, it just ends up being a piece of data that they shouldn't have. If we have some security issue, this is just too much kernel information that a bad user could get at. Linus -

On another side, some PATA drivers are incomplete or missing. When we switch to PATA and drop old ide stack, what will happen ? Will all driver be ported and full-feature, or some will be obsoleted ? Matthieu -

Which ones are incomplete? All drivers for which we can find users will be ported. If any features disappear that's a bug. Jeff -

Anton (added to cc list) may be another good reviewer of According to Tom Gleixner, "hrtimer_forward is a convenience function to move the expiry time of a timer forward in multiples of the interval, so it is in the future. After setting the expiry time you restart the timer either with [sic] a return HRTIMER_RESTART (if you are in the Since OProfile is a statistical profiler, the exact frequency is not critical. The user is going to be looking for hot spots in their code, so it's all relati...

I've given this some more thought, and I'm coming to the conclusion that a pure array-based implementation for holding cached_info (getting rid of the lists) would work well for the vast majority of cases in which OProfile will be used. Yes, it is true that the mapping of an SPU context to a phsyical spu-numbered array location cannot be guaranteed to stay valid, and that's why I discard the cached_info at that array location when the SPU task is switched out. Yes, it would be terribly ine...

Hi there, Random .config: 20-rc6-mm3a/002 found the following boo-boo... From: Grant Coady <gcoady.lk@gmail.com> Defining protos twice caused: In file included from kernel/sched.c:39: include/linux/blkdev.h:928: error: redefinition of 'blk_replug_current_nested' include/linux/blkdev.h:907: error: previous definition of 'blk_replug_current_nested' was here include/linux/blkdev.h:932: error: redefinition of 'blk_plug_current' include/linux/blkdev.h:911: error: previous definition of 'b...

Yee-haa! I looked at this approach a long time ago, and basically gave up because it looked like too much work. I heartily approve, although I only gave the actual patches a very cursory glance. I think the approach is the proper one, but the devil is in the details. It might be that the stack allocation overhead or some other subtle fundamental problem ends up making this impractical in the end, but I would _really_ like for this to basically go in. One of the biggest issues I see ...

Actually, the thing I like about kernel micro-threads (and that "fibril" name is starting to grow on me) is that I'm hoping we might be able to use them for that kevent thing too. And perhaps some other issues (ACPI has some "events" that might work with synchronously scheduled threads). IOW, synchronous threading does have its advantages.. Btw, I noticed that you didn't Cc Ingo. Definitely worth doing. Not just because he's basically the normal scheduler maintainer, but also because h...

Side note (and maybe this was obvious to people already): I would suggest that the "limiting" not be done the way fork() is limited ("return EAGAIN if you go over a limit") but be done as a per-task counting semaphore (down() on submit, up() on fibril exit). So we should limit these to basically have some maximum concurrency factor, but rather than consider it an error to go over it, we'd just cap the concurrency by default, so that people can freely use asynchronous interfaces without ...

This finally does something useful with the notion of being able to schedule stacks as fibrils under a task_struct. Again, i386-specific and in need of proper layering with archs. sys_asys_submit() is added to let userspace submit asynchronous system calls. It specifies the system call number and arguments. A fibril is constructed for each call. Each starts with a stack which executes the given system call handler and then returns to a function which records the return code of the system call ha...

The addition of multiple sleeping fibrils under a task_struct means that we can't simply wake a task_struct to be able to wake a specific sleeping code path. This patch introduces task_wake_target() as a way to refer to a code path that is about to sleep and will be woken in the future. Sleepers that used to wake a current task_struct reference with wake_up_process() now use this helper to get a wake target cookie and wake it with wake_up_target(). Some paths know that waking a task will be suff...

There is much more (useful) line status information than is output through usbatm, this patch stores the status array and overrides atm_proc_read to output all of it. This change may affect users polling the /proc/net/atm/cxacru file for line up/down status, however better status information is already provided through INFO level printks. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> --- drivers/usb/atm/cxacru.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 144 ...

M:N threading is an unnecessary performance hack that's needed by people who are living in a C or C++ exile away from some language that has lexical closures, generators or first-class continuations. Not having these niceties, they resort to emulating them with threads. The proper thing to do is to rewrite the code to use state machines which can be driven by any available thread. Or else, write yourself a source-to-source transformer that will give C the lexical closure, generator, or continuation...

I didn't realize that all your postings to this list were the official views of Steeleye? I can't say what SGI will do on this, I'm an engineer not a manager, I can however suggest to them that they do. As Willy said, if it was an even playing field it would probably be a lot more likely they would, compared to how it is today. Cheers, Jes -

Since they depends on TASKSTATS, it would be nice to move them closer to another options depending on TASKSTATS. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- Yes, it cost me ~10 minutes to turn TASK_XACCT on. init/Kconfig | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) --- a/init/Kconfig +++ b/init/Kconfig @@ -192,6 +192,24 @@ config TASK_DELAY_ACCT Say N if unsure. +config TASK_XACCT + bool "Enable extended acc...

Hi, pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that is written to the device is lost after umount. I rarely use pktcdvd but at some point it used to work on my system. This is what I'm doing: root@dreamland:/tmp# cdrwtool -d /dev/scd0 -q using device /dev/scd0 1029KB internal buffer setting write speed to 12x Settings for /dev/scd0: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/scd0. The disc is going to be blanked and form...

Yup, It used to work but since I rarely use it I don't remember which It's libata jmicron driver. Shall I try the "old" PATA driver on the next reboot? Luca -- "Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti; chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi" Sun Tzu -- L'arte della guerra -

Hi Jeff, linux-ide, I'm having troubles with libata and UDF on RW media. See below. With the legacy IDE driver it works fine. The unit is DVD-RAM capable so the firmware should handle random writes fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still lose files. So I guess it has something to do with libata. So to recap, after formatting the disk with UDF: * libata - mount with pktcdvd: all files are lost upon umount - mount scd0 w/out pktcdvd: all files are lost upon ...

On Tue, 30 Jan 2007 10:03:40 -0600 that's probably true. afaict, this powerpc platform <--> RTC class code glue is totally unnecessary; RTC class sets things up fine on 83xx based boards that have rtc chips supported in RTC class (e.g., the ITX). I'm referring to the third bullet point here: http://marc.theaimsgroup.com/?l=linux-kernel&m=116387226902131&w=2 For the MDS boards, which use the ds1374, I'd rather fix the problem properly and add a ds1374 driver to the RTC class. While ...

When calling into an EFI firmware, the parameters need to be passed on the stack. The recent change to use -mregparm=3 breaks x86 EFI support. This patch is needed to allow the new Intel-based Macs to suspend to ram when run in EFI mode (efi.get_time is called during the suspend phase). Signed-off-by: Frederic Riss <frederic.riss@gmail.com> --- [As I couldn't find an official maintainer for the linux/efi.h file and the file header is quite old, I'm Cc:ing the last 2 commiters.] This ...

[ Disclaimer: I don't know much about EFI. I wanted to download the spec, but it required me to sign some sort of agreement about needing a license to write an implementation... I ran away. ] You're totally right, I first thought it wasn't possible, but the functions in the 'struct efi' can be set to whatever is wanted. Bellow's a patch which won't have any impact on ia64 and fixes the issue on my Mac Mini. I don't think x86_64 can be configured to boot from EFI, so this shouldn't cause any regre...

Not by me, the only EFI box I've access to is my Mac Mini. Fred. -